495 阿裏雲技術社區[雲棲]

MaxCompute 2.0的NewSQL演進之路

10月14日，2017杭州雲棲大會·阿裏雲大數據計算服務（MaxCompute）專場，阿裏巴巴計算平台架構師林偉分享了主題《MaxCompute2.0的NewSQL演進之路》，介紹阿裏雲大數據計算服務MaxCompute 2.0在NewSQL上所做的優化和實踐工作。

DT時代，越來越多的企業應用數據步入雲端，NewSQL也成為業內越來越熱的話題，它可以幫助用戶通過編程接口良好地訪問和存儲數據。本文將介紹阿裏雲MaxCompute應用NewSQL的背景、關鍵技術解讀等內容。

f166ebdee02a845c37a1e551e4fdad7f27cb65c7

背景

提到NewSQL就會不可避免地談到SQL。上世紀80、90年代，大家會提到的數據處理、數據庫一般就是指DataBase應用。DataBase是一個關係型數據庫，有很強的結構和語義，任何人在寫查詢語言時都可以做快速交互式查詢。但是隨著互聯網的快速發展，大量數據的產生，傳統DataBase逐漸麵臨著一係列的挑戰。

首先是橫向擴展性較差；互聯網環境下，傳統DataBase對於結構化、非結構化數據，語音、視頻數據的支持比較落後，造成不夠靈活；容錯能力弱，分布式環境下要求建立數據中心來負載大量數據，這就需要強容錯的能力。因此，SQL的大數據能力難以滿足潮流的發展，也就帶來了NoSQL的誕生，用於處理非結構化數據。

NoSQL是非關係型數據庫，弱語義，很靈活，並且支持非結構、半結構和結構數據，橫向擴展性較強，能夠很好地Scala。此外，NoSQL提供強大的UDF，在map和reduce處理數據時，UDF能夠定義key、value，而且接口可以很好地支持非關係型運算，靈活性很高。並且所有的計算節點都是獨立的，所以容錯能力也很強。可以看出NoSQL的大數據能力明顯強於SQL，也因此誕生了穀歌BigTable，MapReduce等大數據係統。

阿裏雲推出的NewSQL，就是想要結合SQL和NoSQL的優勢。

NewSQL

NewSQL的原則是想要回歸關係型數據庫。做NoSQL時，程序員需要分別寫map、reduce、value等等是什麼，因此難以闡述清晰自己所做的工作，隻有給到所有的coding細節才能了解。回歸關係型，就是希望工程師描述的不是怎麼去做（即How），而是在做什麼（即What），別人讀到SQL時就能明確工作內容。

NewSQL具有強大的係統優化能力，通過強大的優化器能夠整合多個功能，從而使得係統自適應生產高效物理執行計劃。此外，NewSQL還致力於NoSQL特性的支持，包括非結構、強大的UDF集合、分布式支持等等。

但是很顯然，從SQL變成NoSQL，再從NoSQL回到NewSQL，必然會麵臨一係列的問題：一方麵，程序員不可能及時感受到數據和環境的變化，很容易造成數據傾斜的問題；另一方麵，計算越來越複雜，上下遊的壁壘下程序員不可能很快地分析出全局最優的執行計劃；同時，計算需要能夠分享知識，缺乏高層次強語義的語言則會阻礙這種分享；而且共享的資源環境下，單個程序員是缺乏係統全局觀的。

a0fbc47bc16b8e3194185981ddcfcc3e041b4ead

在圖中的三個場景下，NewSQL其實都做到了很好地自適應。雖然希望程序員能夠很好地描述自己所做的工作，但是因為缺乏靈活性，還是需要通過UDF在高層次語義上獲取很好的平衡，使係統優化做到高性能、高智能、自適應的能力。

事實上，目前的整個行業都在朝著這個方向行進，比如微軟提供Dryad引擎的同時，也提供Scope做優化工作；DataBricks在Spark之外也提供SparkSQL用於加快迭代；Hadoop更是經曆了從MapReduce到Hive再到Hive2.0的升級；Google在MapReduce外也在力推具有SQL語義的Spanner。阿裏雲的MaxCompute1.0也在向MaxCompute2.0邁進，讓係統幫助優化。

關鍵技術

為了實現SQL和NoSQL的平衡，一些關鍵技術需要了解。

支持非結構，半結構和結構化數據

互聯網環境下，用戶需要提供Serialize/Deserialize函數動態進行非結構到結構化的轉換，從而提取出結構化的數據進行運算。由於傳統DB的局限性，還需要支持用戶自定義類型，豐富UDF功能，方便編程和語言的交互。用戶還需要自定義分區，從而能夠有效連接上下遊，實現輸入、輸出與其他互聯網應用相連。

47b40edd3670b13fd60cf26abe1b1cbe19f14caa

需要有強大的DAG執行圖

這是為了突破MapReduce的束縛，從而進行循環迭代展開為DAG。而且需要有非對稱圖表達，從而支持複雜的物理執行計劃。這樣優化器才能產生高效Plan，使語言變得完整。

57ce8a9d7c2772d1e81adc8fac6b4b13d98d27d5

最重要的是完整的用戶自定義函數體係

完整的UDF集合能使得關係型退化為函數型語言，可以構造任意的DAG執行計劃，在語言上靈活互動，因此提供了：Serialize/Deserialize、多路Join函數、聚合處理函數、Processor完備分區函數（支持Hash/Range/Direct Hash）等等。

強大的優化器

強大的優化器可以提供存儲過程的支持，從單一語句到成千上萬的存儲過程。NoSQL是函數型編程，能構建非常複雜的圖，傳統DB則是一條條語句提交上來，造成job分享效果較差。強大的優化器能夠寫出更加複雜的查詢存儲過程，從而使得邏輯執行計劃非常龐大，優化空間更大，需要更先進的優化器，並且從RuleBased Opt慢慢演變成CostBased Opt。

4a21fa9a0aeda0c822eb81234aaf194921b60f26

ac55b6ca8cf2faf1e5c4b6aec2db8c6e7276a186

此外，想要優化器有別於單機場景，就需要考慮分布式。比如說Non-SQL場景下的眾多UDF擴展，包括數據、用戶、運算上的擴展，可以幫助用戶生成非常好的Plan。

ba07f3f835890ef2c2cd205d86b472ba4a5ac74a

下圖展示了一個有趣的例子，關於優化器與用戶自定義函數（UDF）的結合效果。

85c05815e3c26f97d51909a8be6e2398a43b53c9

左邊是沒有UDF的效果，這種情況下優化性能較低，無法感知UDF的輸出特性，從而產生低效的物理執行計劃。右邊則實現了UDF和優化器的良好互動，能夠全局優化，有效和用戶交互理解UDF的特性，使黑盒變成了灰盒。

實際例子

9b3bfa3cb40711237facb32f99758b2aed3369c1

圖中的應用大大減輕了分布式Cost，並且做到了靈活性和優化性的平衡。其實UDF的一些特性是值得用戶去思考的：

a.Row-wise？單調函數？

b.某些column不變（pass through）？

c.保持分片？保持排序？

d.Selectivity，data distribution of output等等。

和單機SQL不同的是分布式場景的優化。大量NoSQL的用戶自定義函數、分布式場景中各種動態環境（分配worker的拓撲結構、Failure Region的分布）等因素下，想要做到編譯時優化和運行時優化的平衡，就要求強大的引擎來進行運行時優化：選擇分區數目，邊界；選擇Join方式；高效的Datashuffle方式。

總結

NewSQL的原則是整合NoSQL和OldSQL的優勢，幫助開發工作者提高開發效率，實現交互式運算。通過強大的係統優化能力，希望成功地做到高可用、高可解釋、高性能、大規模以及高自適應，從而帶來整個MaxCompute生態的繁榮。

72ccf7c58bf501387a3ef37b75f08db7ad005013