第45期:大數(shù)據(jù)計算語法的SQL化
回歸SQL是當前大數(shù)據(jù)計算語法的一個發(fā)展傾向。在Hadoop體系中,現(xiàn)在已經(jīng)很少有人會自己從頭來寫MapReduce代碼了,PIG Latin也處于被淘汰的邊緣,而HIve卻始終堅挺;即使是Spark上,也在更多地使用Spark SQL,而Scala反而少很多。其它一些新的大數(shù)據(jù)計算體系一般也將SQL作為***的計算語法,經(jīng)過幾年時間的混戰(zhàn)之后,現(xiàn)在SQL又逐步拿回了主動權(quán)。
這個現(xiàn)象,大概有這么兩個原因:
1. 實在沒什么別的好用
關(guān)系數(shù)據(jù)庫過于普及,程序員對SQL相當熟悉,甚至思維習慣都是SQL式的。SQL用來做一些常規(guī)查詢也比較簡單,雖然用于處理復雜的過程計算或有序運算并不方便,但其它那些替代技術(shù)也好不到哪里去,碰到SQL難寫的運算一樣要寫和UDF相當?shù)膹碗s代碼,反正都是麻煩,還不如繼續(xù)用SQL。
2. 大數(shù)據(jù)廠商的鼎力支持
大數(shù)據(jù)的技術(shù)本質(zhì)是高性能,而SQL是性能比拼的關(guān)鍵陣地。比性能要面對同樣的運算才有意義,過于專門和復雜的運算涉及的影響因素太多,不容易評估出大數(shù)據(jù)平臺本身的能力。而SQL有國際標準的TPC系列,所有用戶都看得懂,這樣就有明確的可比性,廠商也會把性能優(yōu)化的重點放在SQL上。
一
那么,回歸SQL好嗎?特別地,我們說,大數(shù)據(jù)的技術(shù)本質(zhì)是高性能,回歸并優(yōu)化SQL對提高計算性能有多大幫助?
那要看是什么運算!
對于比較簡單的查詢,特別是多維分析式的查詢,用SQL確實是不錯的。這種運算被傳統(tǒng)數(shù)據(jù)庫廠商研究了幾十年,實踐出很多行之有效的優(yōu)化手段。而Hadoop這種新型大數(shù)據(jù)平臺,正好可以實習和實施這些經(jīng)驗,在性能上就更容易超越其它語法體系。
但是,對于更常見的過程性計算,SQL并不好用,不僅是開發(fā)困難,代碼要寫很長,而且對于提高性能也很難有什么幫助。
什么是過程性計算呢?就是一步寫不出來,需要多次分步運算,特別是與數(shù)據(jù)次序相關(guān)的運算。
我們舉幾個例子來看:
- 股票連續(xù)3天上漲后再漲1天的概率和平均漲幅,按所屬板塊和時間段分類對比
- 與去年同期的收入銷售額對比分析,要考慮到節(jié)假日的影響
- 一周內(nèi)累計登錄時長超過一小時的用戶占比,但要除去登錄時長小于1分鐘的誤操作情況
- 信用卡在最近三個月內(nèi)最長連續(xù)消費的天數(shù)分布情況,考慮實施連續(xù)消費10天后積分三倍的促銷活動
- ……
(為了便于理解,這些例子已經(jīng)做了簡化,實際情況的運算還要復雜很多)
二
對于過程性運算,用SQL寫出來的難度就很大,經(jīng)常還必須要寫UDF才能完成。如果SQL寫都寫不出來,那么指望優(yōu)化SQL來提高性能也就無從談起了。有時候能用SQL勉強寫出來,代碼也會相當復雜,而復雜SQL的優(yōu)化效果是很差的,在嵌套幾層之后,數(shù)據(jù)庫引擎也會暈掉,不知道如何優(yōu)化。
舉一個以前舉過的簡單例子,在1億條記錄中取***的前10名,SQL本身沒有集合數(shù)據(jù)類型,理論上會用比較笨的辦法,先排序再找前10名。但好一點的數(shù)據(jù)庫引擎都能優(yōu)化這件事,碰到這樣的SQL語句不會真地去做大排序。但是,如果這個運算寫到了分組或者子查詢里面(寫法會不一樣了),數(shù)據(jù)庫引擎就未必能識別出來再做優(yōu)化了。
三
提高這些復雜運算的性能,指望計算平臺的自動優(yōu)化是靠不住的,根本手段還要靠編寫出高性能的算法。象過程運算中還常常需要保存中間結(jié)果以復用,SQL需要用臨時表,多了IO操作就會影響性能,這都不是引擎優(yōu)化能解決的事情,必須要去改寫計算過程。
事實上,提高性能的本質(zhì)實際上還是降低開發(fā)難度。軟件無法提高硬件的性能,只能想辦法設計復雜度更低的算法,而如果能夠快速低成本地實現(xiàn)這些算法,那就可以達到提高性能的目標。如果語法體系難以甚至沒辦法描述高性能算法,必須迫使程序員采用復雜度較高的算法,那也就很難再提高性能了。顯然,優(yōu)化SQL運算幾乎無助于降低它的開發(fā)難度,SQL語法體系就是那樣,無論怎樣優(yōu)化它的性能,開發(fā)難度并不會改變,很多高性能算法仍然實現(xiàn)不了,也就難以實質(zhì)性地提高運算性能。
編寫UDF在許多場景時確實能提高性能,但一方面開發(fā)難度很大,另一方面這是程序員硬寫的,也不能利用到SQL引擎的優(yōu)化能力。而且經(jīng)常并不能將完整運算都寫成UDF,只能使用計算平臺提供的接口,仍然要在SQL框架使用它的數(shù)據(jù)類型,這樣還是會限制高性能算法的實現(xiàn)。