大資料不就是寫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等
最後
產品又來需求了,現有系統還無法實現,上面四步再折騰一遍...