應屆生小祖參加了個需求分析會回來後跟我說被產品懟了一句：
"不就是寫SQL嗎，要那麼久嗎"
我去，欺負我小弟，這我肯定不能忍呀，於是我寫了一篇文章發在了公司的wiki
貼出來給大家看看，省略了一些敏感的內容。當然內部版言辭也會溫和一點，嘻嘻
在哪裡寫SQL？
這個問題高級點的問法是用哪種SQL引擎？
SparkSQL、Hive、Phoenix、Drill、Impala、Presto、Druid、Kylin （這裡的SQL引擎是廣義的，大家不必鑽牛角尖）
我用一句話概括下這幾個東西，先不管你們現在看不看得懂：
- Hive：把sql解析後用MapReduce跑
- SparkSQL：把sql解析後用Spark跑，比hive快點
- Phoenix：一個繞過了MapReduce運行在HBase上的SQL框架
- Drill/Impala/Presto 交互式查詢,都是類似google Dremel的東西，區別這裡就不說了
- Druid/Kylin olap預計算系統
這就涉及到更多的問題了，對這些組件不熟悉的同學可能調研過程就得花上一個多月。
比如需求是實時計算還是離線分析？
數據是增量數據還是靜態數據？
數據量有多大？
能容忍多長的響應時間？
總之，功能、性能、穩定性、運維難度、開發難度這些都是要考慮的
對哪裡的數據執行SQL？
你以為選完引擎就可以開寫了？too naive！
上面提到的大部分工具都僅僅是查詢引擎，存儲呢？
“啥，為啥還要管存儲？”
不管存儲，那是要把PB級的數據存在mysql是吧...
關係型數據庫像mysql這種，查詢引擎和存儲是緊耦合的，這其實是有助於優化性能的，你不能把它們拆分開來。
而大數據系統SQL引擎一般都是獨立於數據存儲系統，獲得了更大的靈活性。這都是出於數據量和性能的考慮。
這涉及到的問題就更多了。先要搞清楚引擎支持對接哪些存儲，怎麼存查詢起來方便高效。
可以對接的持久化存儲我截個圖，感受一下（這還只是一小部分）
用哪種語法寫SQL？
你以為存儲和查詢搞定就可以開寫了？你以為全天下的sql都是一樣的？並不是！
並不是所有的引擎都支持join；
並不是所有的distinct都是精準計算的；
並不是所有的引擎都支持limit分頁；
還有，如果處理複雜的場景經常會需要自定義sql方法，那如何自定義呢，寫代碼呀。
舉幾個簡單而常見的栗子：
見過這樣的sql嗎？
select `user`["user_id"] from tbl_test ;
見過這種操作嗎？
insert overwrite table tbl_test select * from tbl_test where id>0;
臥槽，這不會鎖死嗎？hive裡不會，但是不建議這樣做。
還能這麼寫
from tbl_test insert overwrite table tbl_test select * where id>0;
怎麼用更高效的方式寫SQL？
好了，全都搞定了，終於可以開始愉快地寫SQL了。
寫SQL的過程我用小祖剛來公司時的一句話來總結：
“臥槽，這條SQL有100多行！”
事實表，維表的數據各種join反覆join，這還不算完還要再join不同時間的數據，還要$#@%^$#^...
不說了，寫過的人一定知道有多噁心
（此處省略100多行字）
終於寫完了，千辛萬苦來到這一步，滿心歡喜敲下回車...
時間過去1分鐘...
10分鐘...
30分鐘...
1小時...
2小時...
......
別等了，這樣下去是不會有結果的。
老實看日誌吧，看日誌也是一門很大的學問。
首先你得搞清楚這個sql是怎麼運行，底層是mapReduce還是spark還是解析成了其他應用的put、get等接口;
然後得搞清楚數據是怎麼走的，有沒有發生數據傾斜，怎麼優化。
同時你還得注意資源，cpu、內存、io等
最後
產品又來需求了，現有系統還無法實現，上面四步再折騰一遍...
閱讀更多 程序員小新人學習 的文章
