回歸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)。