【原創(chuàng)，轉(zhuǎn)載請(qǐng)注明出處】
應(yīng)屆生小祖參加了個(gè)需求分析會(huì)回來后跟我說被產(chǎn)品懟了一句：
"不就是寫SQL嗎夜焦，要那么久嗎"
我去壳澳，欺負(fù)我小弟，這我肯定不能忍呀糊探，于是我寫了一篇文章發(fā)在了公司的wiki
貼出來給大家看看钾埂，省略了一些敏感的內(nèi)容。當(dāng)然內(nèi)部版言辭也會(huì)溫和一點(diǎn)科平，嘻嘻
在哪里寫SQL褥紫？
這個(gè)問題高級(jí)點(diǎn)的問法是用哪種SQL引擎？
SparkSQL瞪慧、Hive髓考、Phoenix、Drill弃酌、Impala氨菇、Presto、Druid妓湘、Kylin （這里的SQL引擎是廣義的查蓉，大家不必鉆牛角尖）
我用一句話概括下這幾個(gè)東西，先不管你們現(xiàn)在看不看得懂：
- Hive：把sql解析后用MapReduce跑
- SparkSQL：把sql解析后用Spark跑榜贴，比hive快點(diǎn)
- Phoenix：一個(gè)繞過了MapReduce運(yùn)行在HBase上的SQL框架
- Drill/Impala/Presto 交互式查詢,都是類似google Dremel的東西豌研，區(qū)別這里就不說了
- Druid/Kylin olap預(yù)計(jì)算系統(tǒng)
這就涉及到更多的問題了，對(duì)這些組件不熟悉的同學(xué)可能調(diào)研過程就得花上一個(gè)多月唬党。
比如需求是實(shí)時(shí)計(jì)算還是離線分析鹃共？
數(shù)據(jù)是增量數(shù)據(jù)還是靜態(tài)數(shù)據(jù)？
數(shù)據(jù)量有多大驶拱？
能容忍多長的響應(yīng)時(shí)間霜浴？
總之，功能蓝纲、性能阴孟、穩(wěn)定性、運(yùn)維難度税迷、開發(fā)難度這些都是要考慮的
對(duì)哪里的數(shù)據(jù)執(zhí)行SQL永丝？
你以為選完引擎就可以開寫了？too naive翁狐！
上面提到的大部分工具都僅僅是查詢引擎，存儲(chǔ)呢凌蔬？
“啥露懒，為啥還要管存儲(chǔ)闯冷？”
不管存儲(chǔ)，那是要把PB級(jí)的數(shù)據(jù)存在mysql是吧...
關(guān)系型數(shù)據(jù)庫像mysql這種懈词，查詢引擎和存儲(chǔ)是緊耦合的蛇耀，這其實(shí)是有助于優(yōu)化性能的，你不能把它們拆分開來坎弯。
而大數(shù)據(jù)系統(tǒng)SQL引擎一般都是獨(dú)立于數(shù)據(jù)存儲(chǔ)系統(tǒng)纺涤，獲得了更大的靈活性。這都是出于數(shù)據(jù)量和性能的考慮抠忘。
這涉及到的問題就更多了撩炊。先要搞清楚引擎支持對(duì)接哪些存儲(chǔ)，怎么存查詢起來方便高效崎脉。
可以對(duì)接的持久化存儲(chǔ)我截個(gè)圖拧咳，感受一下（這還只是一小部分）
用哪種語法寫SQL？
你以為存儲(chǔ)和查詢搞定就可以開寫了囚灼？你以為全天下的sql都是一樣的骆膝？并不是！
并不是所有的引擎都支持join灶体；
并不是所有的distinct都是精準(zhǔn)計(jì)算的阅签；
并不是所有的引擎都支持limit分頁；
還有蝎抽，如果處理復(fù)雜的場(chǎng)景經(jīng)常會(huì)需要自定義sql方法政钟，那如何自定義呢，寫代碼呀织中。
舉幾個(gè)簡單而常見的栗子：
見過這樣的sql嗎锥涕？
select `user`["user_id"] from tbl_test ;
見過這種操作嗎？
insert overwrite table tbl_test select * from tbl_test where id>0;
臥槽狭吼，這不會(huì)鎖死嗎层坠？hive里不會(huì)，但是不建議這樣做刁笙。
還能這么寫
from tbl_test insert overwrite table tbl_test select * where id>0;
怎么用更高效的方式寫SQL破花？
好了，全都搞定了疲吸，終于可以開始愉快地寫SQL了座每。
寫SQL的過程我用小祖剛來公司時(shí)的一句話來總結(jié)：
“臥槽，這條SQL有100多行摘悴！”
事實(shí)表峭梳，維表的數(shù)據(jù)各種join反復(fù)join，這還不算完還要再join不同時(shí)間的數(shù)據(jù)，還要#^...
不說了葱椭，寫過的人一定知道有多惡心
（此處省略100多行字）
終于寫完了捂寿，千辛萬苦來到這一步，滿心歡喜敲下回車...
時(shí)間過去1分鐘...
10分鐘...
30分鐘...
1小時(shí)...
2小時(shí)...
......
別等了孵运，這樣下去是不會(huì)有結(jié)果的秦陋。
老實(shí)看日志吧，看日志也是一門很大的學(xué)問治笨。
首先你得搞清楚這個(gè)sql是怎么運(yùn)行驳概，底層是mapReduce還是spark還是解析成了其他應(yīng)用的put、get等接口;
然后得搞清楚數(shù)據(jù)是怎么走的旷赖，有沒有發(fā)生數(shù)據(jù)傾斜顺又，怎么優(yōu)化。
同時(shí)你還得注意資源杠愧，cpu待榔、內(nèi)存、io等
最后
產(chǎn)品又來需求了流济，現(xiàn)有系統(tǒng)還無法實(shí)現(xiàn)锐锣，上面四步再折騰一遍...
