當前的大數(shù)據(jù)平臺在處理結(jié)構(gòu)化數(shù)據(jù)時大都仍然以提供SQL語法為主流。兼容SQL的好處是很明顯的，SQL的應(yīng)用非常廣泛，會SQL的程序員很多，如果繼續(xù)采用SQL則可以避免許多學(xué)習(xí)成本。支持SQL的前端軟件也很多，使用SQL的大數(shù)據(jù)平臺很容易融入這個現(xiàn)成的生態(tài)圈中。大數(shù)據(jù)平臺打算替代的傳統(tǒng)數(shù)據(jù)庫也是SQL語法的，這樣兼容性會很好，移植成本相對較低。

一

但繼續(xù)使用SQL也有缺點，***的問題就是難以獲得大數(shù)據(jù)計算最需要的高性能。

我們在前面的文章中提到過，SQL中缺乏一些必要的數(shù)據(jù)類型和運算定義，這使得某些高性能算法無法描述，只能寄希望于計算引擎在工程上的優(yōu)化。傳統(tǒng)商業(yè)數(shù)據(jù)庫經(jīng)過幾十年的發(fā)展，優(yōu)化經(jīng)驗已經(jīng)相當豐富，但即使這樣仍有許多場景難以被優(yōu)化，理論層面的問題確實很難在工程層面解決。而新興的大數(shù)據(jù)平臺在優(yōu)化方面的經(jīng)驗還遠遠不如傳統(tǒng)數(shù)據(jù)庫，算法上不占優(yōu)，就只能靠集群更多的機器獲得性能提升。另外，SQL還是一種描述性語言，不擅長指定執(zhí)行路徑，而想獲得高性能常常需要專門優(yōu)化的執(zhí)行路徑，這又需要增加許多特殊的修飾符來人為干預(yù)，那還不如直接用過程性語法更為直接，這也會妨礙用SQL寫出高性能的代碼。

SQL發(fā)明之初的計算機硬件能力還比較差，要保證實用性，SQL的設(shè)計必須適應(yīng)當時的硬件條件，這就導(dǎo)致了SQL很難充分利用當代計算機的硬件能力，具體來說就是大內(nèi)存、多線程和集群。SQL中的JOIN是按鍵值對應(yīng)的，而大內(nèi)存情況下其實可以直接用地址對應(yīng)，不需要計算HASH值和比對，性能可以提高很多;SQL的數(shù)據(jù)表無序，單表計算時還容易做到分段并行，多表關(guān)聯(lián)運算時一般就只能事先做好固定分段，很難做到同步動態(tài)分段，這就無法根據(jù)機器的負載臨時決定并行的線程數(shù)量;對于集群運算也是這樣，SQL在理論上不區(qū)分維表和事實表，JOIN運算簡單地定義為笛卡爾積后過濾，要實現(xiàn)大表JOIN就會不可避免地產(chǎn)生占用大量網(wǎng)絡(luò)資源的HASH Shuffle動作，在集群節(jié)點數(shù)太多時，網(wǎng)絡(luò)傳輸造成的延遲會超過節(jié)點多帶來的好處。

如果我們設(shè)計新的代數(shù)體系和運算模型，就可能克服SQL的這些缺點，一方面更好地描述高性能算法，另一方面能充分利用當前的硬件資源，從而獲得更高的性能。

不過，這樣一來，對外的接口也就不再是SQL語法了，不能再兼容以往的代碼了。

順便提一句，新的運算模型并不是指當前業(yè)內(nèi)的NoSQL，NoSQL并不是為高性能計算設(shè)計的，事實上它以犧牲計算能力為代價而換取了可橫向擴展的能力，對于復(fù)雜大數(shù)據(jù)計算的需求而言是個倒退。

二

有沒可能讓高性能和兼容性共存呢?比如采用新的內(nèi)核模型，然后基于它去解釋SQL語法，或者能將SQL代碼自動移植到新體系下。

理論上是可能的，解釋或移植SQL是有不少工作量，但并不是非常困難。不過，這樣做只能獲得語法的兼容性，并不能得到高性能。高效的代碼要針對運算模型的特征去編寫，而SQL語法中并沒有體現(xiàn)這些信息，一定要把SQL移植過來，仍然會面臨前述的工程層面優(yōu)化問題，沒辦法做得***效果。事實上，兩種均采用SQL的數(shù)據(jù)庫，要讓其特有的語法能夠互相解釋和移植，在不影響性能的前提下都是很難做到的。新興的大數(shù)據(jù)廠商都愿意提供這種可移植的技術(shù)以降低老數(shù)據(jù)庫的移植成本，但并沒有多少成功者。

三

那么，結(jié)論是什么呢?

對于中短期目標的產(chǎn)品，那么繼續(xù)采用SQL是合理的，這將有利于產(chǎn)品的快速應(yīng)用，性能主要依靠硬件能力或更大規(guī)模的集群來提升。而面向長期目標的產(chǎn)品，那就有必要采用取代關(guān)系代數(shù)體系的運算型，為獲得高性能，不能也不必再提供兼容SQL的方案了，需要忍受漫長的健全生態(tài)圈過程。