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

一

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

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

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

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

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

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

二

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

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

三

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

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