回歸SQL是當(dāng)前大數(shù)據(jù)計(jì)算語法的一個(gè)發(fā)展傾向。在Hadoop體系中，現(xiàn)在已經(jīng)很少有人會(huì)自己從頭來寫MapReduce代碼了，PIG Latin也處于被淘汰的邊緣，而HIve卻始終堅(jiān)挺;即使是Spark上，也在更多地使用Spark SQL，而Scala反而少很多。其它一些新的大數(shù)據(jù)計(jì)算體系一般也將SQL作為***的計(jì)算語法，經(jīng)過幾年時(shí)間的混戰(zhàn)之后，現(xiàn)在SQL又逐步拿回了主動(dòng)權(quán)。

這個(gè)現(xiàn)象，大概有這么兩個(gè)原因：

1. 實(shí)在沒什么別的好用

關(guān)系數(shù)據(jù)庫過于普及，程序員對(duì)SQL相當(dāng)熟悉，甚至思維習(xí)慣都是SQL式的。SQL用來做一些常規(guī)查詢也比較簡(jiǎn)單，雖然用于處理復(fù)雜的過程計(jì)算或有序運(yùn)算并不方便，但其它那些替代技術(shù)也好不到哪里去，碰到SQL難寫的運(yùn)算一樣要寫和UDF相當(dāng)?shù)膹?fù)雜代碼，反正都是麻煩，還不如繼續(xù)用SQL。

2. 大數(shù)據(jù)廠商的鼎力支持

大數(shù)據(jù)的技術(shù)本質(zhì)是高性能，而SQL是性能比拼的關(guān)鍵陣地。比性能要面對(duì)同樣的運(yùn)算才有意義，過于專門和復(fù)雜的運(yùn)算涉及的影響因素太多，不容易評(píng)估出大數(shù)據(jù)平臺(tái)本身的能力。而SQL有國際標(biāo)準(zhǔn)的TPC系列，所有用戶都看得懂，這樣就有明確的可比性，廠商也會(huì)把性能優(yōu)化的重點(diǎn)放在SQL上。

一

那么，回歸SQL好嗎?特別地，我們說，大數(shù)據(jù)的技術(shù)本質(zhì)是高性能，回歸并優(yōu)化SQL對(duì)提高計(jì)算性能有多大幫助?

那要看是什么運(yùn)算!

對(duì)于比較簡(jiǎn)單的查詢，特別是多維分析式的查詢，用SQL確實(shí)是不錯(cuò)的。這種運(yùn)算被傳統(tǒng)數(shù)據(jù)庫廠商研究了幾十年，實(shí)踐出很多行之有效的優(yōu)化手段。而Hadoop這種新型大數(shù)據(jù)平臺(tái)，正好可以實(shí)習(xí)和實(shí)施這些經(jīng)驗(yàn)，在性能上就更容易超越其它語法體系。

但是，對(duì)于更常見的過程性計(jì)算，SQL并不好用，不僅是開發(fā)困難，代碼要寫很長(zhǎng)，而且對(duì)于提高性能也很難有什么幫助。

什么是過程性計(jì)算呢?就是一步寫不出來，需要多次分步運(yùn)算，特別是與數(shù)據(jù)次序相關(guān)的運(yùn)算。

我們舉幾個(gè)例子來看：

• 股票連續(xù)3天上漲后再漲1天的概率和平均漲幅，按所屬板塊和時(shí)間段分類對(duì)比
• 與去年同期的收入銷售額對(duì)比分析，要考慮到節(jié)假日的影響
• 一周內(nèi)累計(jì)登錄時(shí)長(zhǎng)超過一小時(shí)的用戶占比，但要除去登錄時(shí)長(zhǎng)小于1分鐘的誤操作情況
• 信用卡在最近三個(gè)月內(nèi)最長(zhǎng)連續(xù)消費(fèi)的天數(shù)分布情況，考慮實(shí)施連續(xù)消費(fèi)10天后積分三倍的促銷活動(dòng)
• ……

(為了便于理解，這些例子已經(jīng)做了簡(jiǎn)化，實(shí)際情況的運(yùn)算還要復(fù)雜很多)

二

對(duì)于過程性運(yùn)算，用SQL寫出來的難度就很大，經(jīng)常還必須要寫UDF才能完成。如果SQL寫都寫不出來，那么指望優(yōu)化SQL來提高性能也就無從談起了。有時(shí)候能用SQL勉強(qiáng)寫出來，代碼也會(huì)相當(dāng)復(fù)雜，而復(fù)雜SQL的優(yōu)化效果是很差的，在嵌套幾層之后，數(shù)據(jù)庫引擎也會(huì)暈掉，不知道如何優(yōu)化。

舉一個(gè)以前舉過的簡(jiǎn)單例子，在1億條記錄中取***的前10名，SQL本身沒有集合數(shù)據(jù)類型，理論上會(huì)用比較笨的辦法，先排序再找前10名。但好一點(diǎn)的數(shù)據(jù)庫引擎都能優(yōu)化這件事，碰到這樣的SQL語句不會(huì)真地去做大排序。但是，如果這個(gè)運(yùn)算寫到了分組或者子查詢里面(寫法會(huì)不一樣了)，數(shù)據(jù)庫引擎就未必能識(shí)別出來再做優(yōu)化了。

三

提高這些復(fù)雜運(yùn)算的性能，指望計(jì)算平臺(tái)的自動(dòng)優(yōu)化是靠不住的，根本手段還要靠編寫出高性能的算法。象過程運(yùn)算中還常常需要保存中間結(jié)果以復(fù)用，SQL需要用臨時(shí)表，多了IO操作就會(huì)影響性能，這都不是引擎優(yōu)化能解決的事情，必須要去改寫計(jì)算過程。

事實(shí)上，提高性能的本質(zhì)實(shí)際上還是降低開發(fā)難度。軟件無法提高硬件的性能，只能想辦法設(shè)計(jì)復(fù)雜度更低的算法，而如果能夠快速低成本地實(shí)現(xiàn)這些算法，那就可以達(dá)到提高性能的目標(biāo)。如果語法體系難以甚至沒辦法描述高性能算法，必須迫使程序員采用復(fù)雜度較高的算法，那也就很難再提高性能了。顯然，優(yōu)化SQL運(yùn)算幾乎無助于降低它的開發(fā)難度，SQL語法體系就是那樣，無論怎樣優(yōu)化它的性能，開發(fā)難度并不會(huì)改變，很多高性能算法仍然實(shí)現(xiàn)不了，也就難以實(shí)質(zhì)性地提高運(yùn)算性能。

編寫UDF在許多場(chǎng)景時(shí)確實(shí)能提高性能，但一方面開發(fā)難度很大，另一方面這是程序員硬寫的，也不能利用到SQL引擎的優(yōu)化能力。而且經(jīng)常并不能將完整運(yùn)算都寫成UDF，只能使用計(jì)算平臺(tái)提供的接口，仍然要在SQL框架使用它的數(shù)據(jù)類型，這樣還是會(huì)限制高性能算法的實(shí)現(xiàn)。