大數據不就是寫SQL嗎?

應屆生小祖參加了個需求分析會回來後跟我說被產品懟了一句：

"不就是寫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等

最後

產品又來需求了，現有系統還沒法實現，上面四步再折騰一遍...

推薦閱讀

大數據須要學什麼？
zookeeper-操做與應用場景-《每日五分鐘搞定大數據》
zookeeper-架構設計與角色分工-《每日五分鐘搞定大數據》
zookeeper-paxos與一致性-《每日五分鐘搞定大數據》
zookeeper-zab協議-《每日五分鐘搞定大數據》