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

這個現象，大概有這么兩個原因：

1. 實在沒什么別的好用

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

2. 大數據廠商的鼎力支持

大數據的技術本質是高性能，而SQL是性能比拼的關鍵陣地。比性能要面對同樣的運算才有意義，過于專門和復雜的運算涉及的影響因素太多，不容易評估出大數據平臺本身的能力。而SQL有國際標準的TPC系列，所有用戶都看得懂，這樣就有明確的可比性，廠商也會把性能優化的重點放在SQL上。

一

那么，回歸SQL好嗎?特別地，我們說，大數據的技術本質是高性能，回歸并優化SQL對提高計算性能有多大幫助?

那要看是什么運算!

對于比較簡單的查詢，特別是多維分析式的查詢，用SQL確實是不錯的。這種運算被傳統數據庫廠商研究了幾十年，實踐出很多行之有效的優化手段。而Hadoop這種新型大數據平臺，正好可以實習和實施這些經驗，在性能上就更容易超越其它語法體系。

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

什么是過程性計算呢?就是一步寫不出來，需要多次分步運算，特別是與數據次序相關的運算。

我們舉幾個例子來看：

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

(為了便于理解，這些例子已經做了簡化，實際情況的運算還要復雜很多)

二

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

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

三

提高這些復雜運算的性能，指望計算平臺的自動優化是靠不住的，根本手段還要靠編寫出高性能的算法。象過程運算中還常常需要保存中間結果以復用，SQL需要用臨時表，多了IO操作就會影響性能，這都不是引擎優化能解決的事情，必須要去改寫計算過程。

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

編寫UDF在許多場景時確實能提高性能，但一方面開發難度很大，另一方面這是程序員硬寫的，也不能利用到SQL引擎的優化能力。而且經常并不能將完整運算都寫成UDF，只能使用計算平臺提供的接口，仍然要在SQL框架使用它的數據類型，這樣還是會限制高性能算法的實現。