摘要： 回顧大數據技術領域大事件，最早可追溯到06年Hadoop的正式啟動，而環顧四下，圍繞著數據庫及數據處理引擎，業內充斥著各種各樣的大數據技術。在云棲社區2017在線技術峰會大數據技術峰會上，阿里云大數據計算平臺架構師林偉做了題為《MaxCompute的大腦：基于代價的優化器》的分享，為大家分享阿里巴巴大數據計算服務的大腦——基于代價的優化器的設計和架構。

更多精彩內容參見云棲社區大數據頻道https://yq.aliyun.com/big-data；此外，通過Maxcompute及其配套產品，低廉的大數據分析僅需幾步，詳情訪問https://www.aliyun.com/product/odps。

摘要：回顧大數據技術領域大事件，最早可追溯到06年Hadoop的正式啟動，而環顧四下，圍繞著數據庫及數據處理引擎，業內充斥著各種各樣的大數據技術。這是個技術人的好時代，僅數據庫領域熱門DB就有300+，圍繞著Hadoop生態圈的大數據處理技術更是繁花似錦。在云棲社區2017在線技術峰會大數據技術峰會上，阿里云大數據計算平臺架構師林偉做了題為《MaxCompute的大腦：基于代價的優化器》的分享，為大家分享阿里巴巴大數據計算服務的大腦——基于代價的優化器的設計和架構。

MaxCompute簡介

大數據計算服務(MaxCompute)是一種快速、完全托管的PB/EB級數據倉庫解決方案，MaxCompute具備萬臺服務器擴展能力和跨地域容災能力，是阿里巴巴內部核心大數據平臺，承擔了集團內部絕大多數的計算任務，支撐每日百萬級作業規模。MaxCompute向用戶提供了完善的數據導入方案以及多種經典的分布式計算模型，能夠更快速的解決用戶海量數據計算問題，有效降低企業成本，并保障數據安全。

MaxCompute架構

MaxCompute基本的體系結構如上圖所示，最底層就是在物理機器之上打造的提供統一存儲的盤古分布式文件存儲系統；在盤古之上一層就是伏羲分布式調度系統，這一層將包括CPU、內存、網絡以及磁盤等在內的所有計算資源管理起來；再上一層就是統一的執行引擎也就是MaxCompute執行引擎；而在執行引擎之上會打造各種各樣的運算模式，比如流計算、圖計算、離線處理、內存計算以及機器學習等等；在這之上還會有一層相關的編程語言，也就是MaxCompute語言；在語言上面希望為各應用方能夠提供一個很好的平臺，讓數據工程師能夠通過平臺開發相關的應用，并使得應用能夠快速地在分布式場景里面得到部署運行。

MaxCompute的研發思路

MaxCompute的研發思路主要分為以下四個方面：

高性能、低成本和大規模。希望打造的MaxCompute平臺能夠提運算的高性能，盡可能降低用戶的使用成本，并且在規模上面能夠達到萬臺機器以及多集群的規模。

穩定性，服務化。希望MaxCompute平臺能夠提供穩定性和服務化的方式，使得用戶不用過多地考慮分布式應用的難度，而只需要注重于用戶需要進行什么樣的計算，讓系統本身服務于用戶，并能夠提供穩定性，服務化的接口。

易用性，服務于數據開發者。希望MaxCompute平臺是易用的，并且能夠很方便地服務于數據開發工程師，不需要數據工程師對于分布式的場景進行很深的理解，而只要關注于需要用這些數據進行什么樣的運算就可以，接下來就是由MaxCompute平臺幫助數據開發工程師高效并且低成本地執行自己的想法。

多功能。希望MaxCompute能夠具有更多的功能，不僅僅是支持流計算、圖計算、批處理和機器學習等，而希望更多種類的計算能夠在MaxCompute平臺上得到更好的支持。

MaxCompute的大腦——優化器

基于以上的研發思路，MaxCompute平臺需要擁有一個更加強大的大腦，這個大腦需要更加理解用戶的數據，更加理解用戶的計算，并且更加理解用戶本身，MaxCompute的大腦需要能夠幫助用戶更加高效地優化運算，通過系統層面去理解用戶到底需要進行什么樣的運算，從而達到之前提到的各種目的，使得用戶能夠從分布式場景中脫離出來，不必去考慮如何才能使得運算高效地執行，而將這部分工作交給MaxCompute的大腦，讓它來為用戶提供更智能的平臺，這也就是MaxCompute所能夠為用戶帶來的價值。

那么MaxCompute的大腦究竟是什么呢？其實就是優化器。優化器能夠將所有信息串聯在一起，通過理解系統中數據的相關性以及用戶的企圖，并通過機器的能力去充分地分析各種各樣的環境，在分布式場景中以最高效的方式實現對于用戶運算的執行。在本次分享中以離線計算作為主要例子來對于MaxCompute的大腦——優化器進行介紹。

首先對于離線計算的概念進行簡單介紹，MaxCompute離線計算架構設計如上圖所示。在計算層面往往會存在一個類似高級語言的腳本語言，MaxCompute提供的是類SQL的腳本語言，將腳本語言通過FrontEnd提交進來，之后經過處理轉化成為邏輯執行計劃，邏輯執行計劃在Optimizer（優化器）的指導下翻譯成更加高效的物理執行計劃，并通過與Runtime的連接之后由伏羲分布式調度系統將物理執行計劃分解到運算節點上進行運算。

上述過程的核心就在于如何充分地理解用戶的核心計劃并通過優化得到高效的物理執行計劃，這樣的過程就叫做優化器Optimizer。目前開源社區內的Hive以及Spark的一些優化器基本上都是基于規則的優化器，其實對于優化器而言，單機系統上就存在這樣的分類，分成了基于規則的優化器和基于代價的優化器。

在單機場景里面，Oracle 6-9i中使用的是基于規則的優化器，在Oracle 8開始有了基于代價的優化器，而Oracle 10g則完全取代了之前基于規則的優化器；而在大數據場景里面，像Hive最開始只有基于規則的優化器，而新版的Hive也開始引入了基于代價的優化器，但是Hive中還并不是正真意義上的代價優化器。而MaxCompute則使用了完全的基于代價的優化器。那么這兩種優化器有什么區別呢？其實基于規則的優化器理論上會根據邏輯模式的識別進行規則的轉換，也就是識別出一個模式就可能觸發一個規則將執行計劃從A改成B，但是這種方式對數據不敏感，并且優化是局部貪婪的，就像爬山的人只看眼前10米的范圍內哪里是向上的，而不考慮應該先向下走才能走到更高的山頂，所以基于規則的優化器容易陷入局部優但是全局差的場景，容易受應用規則的順序而生產迥異的執行計劃，所以往往結果并不是最優的。而基于代價的優化器是通過Volcano火山模型，嘗試各種可能等價的執行計劃，然后根據數據的統計信息，計算這些等價執行計劃的“代價”，最后從中選用代價Cost最低的執行計劃，這樣可以達到全局的最優性。

這里分享一個具體的例子幫助大家理解為什么基于規則的優化器無法實現全局的最優化。上圖中的這段腳本的意思就是先在A、B和C上面做完join，join出來的結果在某一列上面進行group by操作并計算出平均值。可以將上述的查詢過程畫成樹形的邏輯執行計劃，在數據庫領域往往是bottom-up的，也就是對于邏輯計劃樹而言，葉子節點是輸入，最終的目標輸出則是根節點，所以最終的數據流向是從下向上的。可以看到在這個邏輯計劃里面，首先是對于A、B、C三個表進行join，假設Size(B)

總結

以上是生活随笔為你收集整理的MaxCompute理解数据、运算和用户的大脑：基于代价的优化器的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。