阿里吳永明：高可用大資料計算服務如何持續釋出和演進！

【IT168 專稿】本文根據吳永明老師在2018年5月10日【第九屆中國資料庫技術大會】現場演講內容整理而成。

講師簡介： 

吳永明，阿里巴巴高階技術專家。阿里巴巴通用大資料計算平臺MaxCompute（原ODPS） 框架架構負責人。主要專注於大資料技術領域，對高可用分散式系統設計開發有多年經驗。先後研發過阿里巴巴機器學習平臺線上預測系統和通用大資料計算平臺框架系統。

摘要：

服務化是大資料計算平臺的發展趨勢，其有效地降低了使用者使用大資料的門檻和成本。但服務化一方面要求大資料計算平臺要7x24小時高可靠、高可用、不間斷地服務使用者；另一方面隨著大資料計算平臺業務的增長，對於計算平臺會不停地有新的需求，要計算平臺跟著發展，從而能夠去匹配業務的成長，這就要求服務持續迭代釋出和演進提供更豐富的功能、更好的效能等。新的釋出和演進對於服務來說是影響到穩定性、高可用的關鍵風險點，因此對於海量大資料服務來說如何處理和平衡好兩者至關重要，也是業內公認的挑戰難題。

分享大綱：

1、阿里巴巴大資料計算服務背景介紹

2、大資料計算服務演進面臨的挑戰

3、阿里巴巴的應對措施和解決方案

正文：

1、阿里巴巴大資料計算服務背景介紹

阿里巴巴的大資料計算服務平臺叫MaxCompute，原名ODPS。通俗來講，這就相當於阿里巴巴內部的Spark或者Hadoop平臺。但是，MaxCompute與其他平臺有一些不同之處。首先，MaxCompute完全是阿里巴巴內部團隊自研的，從分散式儲存系統、分散式排程系統到分散式協調服務，包括其上的各類計算框架全都是阿里自研的；其二，這是一個完全託管的PB/EB級資料倉儲服務；其三，MaxCompute目前支援的機器規模可達到幾萬臺，支撐了阿里內部90%以上的計算以及95%以上的儲存，具備萬臺伺服器擴充套件能力和跨地域容災能力，是阿里巴巴內部旗艦級大資料計算平臺，支撐每日百萬級作業規模。當然，MaxCompute不僅服務於阿里內部，同樣也對外開放，可有效降低企業成本並保障資料安全。

在技術層面，MaxCompute的架構與眾多大資料體系架構圖類似（如下圖所示），最底層是分散式儲存系統—盤古，功能類似於HDFS；其上是分散式排程系統—伏羲，功能類似於Yarn。 

 

基於這兩大基礎系統，我們在上面搭建了MaxCompute引擎，我們的整體定位是一個通用的大資料計算平臺，所以支援典型的批處理、圖計算、流計算、機器學習等場景。再往上，我們會向使用者提供一些MaxCompute語言，說白了就是常用的SQL。此外，我們還會提供Spark API、Beam API、Hive API等常用API。在這個龐大、複雜的系統中，最關鍵的核心計算應用是什麼呢？ 

 

如上圖，整個架構中最關鍵、最核心的還是SQL應用，畢竟這是目前企業內部最通用的應用模式，其開發門檻並不像MapReduce之類的那麼高，這也是SQL應用在MaxCompute上佔了80%到90%的原因之一。上圖主要顯示了SQL應用在MaxCompute上的執行原理，MaxCompute SQL Script在FrontEnd接收之後經Compiler、Optimizer然後生成一個Runtime執行器，基本是這三大流程。

2、大資料計算服務演進過程面臨的挑戰

接下來，我主要介紹大資料計算服務相關配置資訊以及我們在這個過程中遇到的一些挑戰。目前，企業做大資料計算服務主要有兩大套路，一是根據大資料的發行版本或者開原始碼進行修改，當然可能還需要自己搭建和維護叢集。二是直接選擇成熟商用並開放的解決方案，這就將自己搭建和維護叢集的成本進行了轉移。隨著時代的發展，第二種方式越來越受歡迎，企業對於服務化的接納程度逐漸升高。

MaxComputer最初的定位就不僅僅是一個簡單的系統，而是要做服務並開放給使用者使用，因此提供365（天）X24（小時）的高可靠、高可用共享大資料計算服務是必要的。此外，我們需要自主把控服務內部引擎以及各種關鍵技術，在滿足客戶各種需求的情況下進一步降低成本，提高效率。

在持續改進和釋出過程中，我們總結了遇到的挑戰並給出了應對方案。我們所面臨的主要挑戰如下：一是每天都有百萬級的作業，整個升級過程必須保證足夠平穩安全，使用者應該是無感知的；其次，我們需要保證新版本的穩定性；然後，效能層面不能出現回退；最後，出現問題時，我們需要快速止損。二是處理測試和資料安全之間的矛盾，資料安全對企業而言至關重要，在平時的計算服務中，資料安全性不會受到很大影響，最容易出現問題的往往是測試環節。

3、阿里巴巴的應對措施和解決方案 

針對上述兩大類問題，我們提出了相應的解決方案，主要開發了三大工具：一是MaxCompute Playback；二是MaxCompute Flighting；三是MaxCompute灰度上線。

3.1 MaxCompute Playback工作原理介紹

首先是Playback工具，該工具主要用來檢測編譯器和優化器是否存在問題。在系統不斷向前演進的同時，編譯器、優化器以及Runtime均屬於核心功能，所以我們需要重點檢測。如果我們需要新增新功能，通常做法是寫一條簡單的SQL語句進行檢測，驗證最終結果是否符合預期來判斷新功能是否存在問題，但這種方式可覆蓋的測試範圍非常有限，無法覆蓋客戶所有可能的使用情況。在我們的系統中，每天會有幾百萬個job且每天都在變化，人工分析的話每個script需要兩分鐘，時間上根本不允許，因此我們需要利用大資料計算平臺的運算能力自我驗證新的編譯優化器。

接下來具體說一下MaxCompute編譯器Playback的原理，這是一個基於AST的編譯器，整體採用Visitor模型（如下圖）。

 

使用Visitor模型的好處在於我們可以根據需要一遍遍更改各個資料，進而驗證整體功能是否存在問題。從上圖的SQL語句依次向後可以看出，整個編譯器呈現樹狀結構，對應於最後一列的各個階段。當然，這還不足以解決上述提到的測試覆蓋面較低的問題，畢竟每天幾百萬的作業不可能光靠人工校驗。對大資料系統而言，資料量一定不是問題，這也是大資料系統最初誕生的原因——處理大規模複雜計算任務。 

 

我們的解決思路是使用Playback Sql Script構造分析任務，如果我需要驗證某個功能是否有問題，我可以將前一天的幾百萬作業抓取出來放到新版的編譯器和優化器之中執行，將最終跑出來的結果用Visitor模型進行驗證，如果有問題，我就寫到最終的結果報告中；如果沒有問題，我就可以通過該方法大規模提高測試覆蓋面。

通過這種自我驗證，我可以利用MaxCompute靈活的UDF支援且良好的隔離方案，在UDF中拉起待測的編譯器進行編譯，之後再進行詳細的結果分析。整個過程都在MaxCompute完善的安全體系保護之下，保障使用者的智慧財產權。

此外，我也可以精確得知道新的優化規則的特點，其實說白了就是哪些作業使用了發行的新功能，精確制導找到觸發新的優化規則的query，驗證其查詢優化是否符合預期。 另外，我們在語義上也對使用者查詢進行了整體資料分析，對相應使用者發warning推動使用者下線過時的語法；對query整體進行分析來確定下一步開發的重點；評估新版本在查詢優化在執行計劃上的提高程度。

3.2 MaxCompute Flighting工作原理介紹

接下來說一下我們開發的第二個工具——Flighting工具。Flighting工具主要用於驗證Runtime理念以及在新功能加入之後，保證MaxCompute執行器正確執行並保證資料的安全性。

在介紹Flighting工具的工作原理之前，我們先來討論一些傳統做法。如果我們需要驗證Runtime執行器新新增的某項功能，傳統的做法通常是搭建一個測試叢集，在上線之前先測試將各種坑都踩一遍，否則根本達不到測試效果。但是，用測試叢集來驗證存在三方面的問題：

一是浪費巨大，排程或者scalability等方面的改進往往需要建立一個相同規模的測試叢集，如果線上可以達到一萬臺機器，線下測試時自然需要達到同樣的叢集數量，否則根本無法達到測試效果。

二是沒有相應的任務負載，無法構造對應場景。線上上的實際執行場景中，我們的CPU、記憶體等資源通常都非常滿，各種髒資料很容易出現，但線下往往很難達到這個效果；

三是資料安全問題，我們需要脫敏的方式從生產叢集拖資料。在測試過程中，人為製造資料既簡單又測不到位，如果從生產運營庫里拉資料，我們必須解決資料安全問題。整個過程很容易因為人為疏忽造成資料洩露；脫敏資料可能造成使用者程式crash，並且往往不能反映使用者執行場景；整個測試過程冗長，不能達到測試目的。

既然使用線下叢集資料進行測試如此麻煩，那我們不如直接使用線上資料進行測試，所以我們的思路是把99%的機器資源用來做線上版本執行生產作業，把1%的資源用來跑程式設計師上載的測試版本進行驗證，如下圖所示： 

 

通過這種方式，我們解決了很多問題，比如我們不需要再搭建額外的測試叢集，雖然99%的機器資源供給線上使用者使用，但這部分機器資源不可能一直處於忙碌狀態，因此相比於單獨搭建測試叢集，這種方式在成本上還是有所節省的。此外，由於該測試所承受的叢集負載以及壓力完全來源於線上，所以該結果具備較高可信度。

這種方式聽起來似乎不錯，但實施難度較高，首要做好的就是資源隔離，畢竟測試與真正的生產跑在同一個叢集中，如果做不好資源隔離，生產方面很容易出現問題。在CPU/Memory層面，我們需要增強cgroup，劃分任務優先順序；在Disk層面，我們需要進行統一的儲存管理，並劃分儲存優先順序；在Network層面是Scalable Traffic Control （萬兆網）；最後是Quota管理，對資源進行人為干預。我們要在能夠保障線上核心業務需求不受影響的情況下進行flighting測試。

為了提高測試的覆蓋面，我們會主動抓取使用者制定好的新資料以及各種SQL指令碼，放到新的Runtime執行器中執行，並將最終結果與真正生產環境中的Runtime執行器跑出來的資料進行對比，如果結果一致，則證明新功能沒有問題。整個過程不需要人工干預進行資料脫敏，因為這些資料在機器裡面都是自動化完成的。Flighting的任務結果也不落盤，而是直接對接分析任務產生測試報告，我們可以驗證結果的正確性，比如MD5計算，浮點等不確定性型別的處理，也可以對執行效能進行分析，比如straggler，data-skew。

3.3 MaxCompute灰度上線機制工作原理介紹

接下來介紹灰度上線機制。前兩大功能一是為了解決編譯器及優化器的問題，二是為了解決執行器Runtime的問題，一旦這些測試工作完成，我們就有機會上線了。灰度上線的工作原理是根據任務的重要性進行分級，比如最關鍵的任務等級為1，次關鍵任務等級為2，非關鍵任務等級為3,；每一級都可細粒度進行釋出，並且支援瞬時回滾，可將風險控制到最小，比如上線時從等級為3的非關鍵任務開始，如果該等級任務在進度條完成10%時出現故障，我們可瞬時回滾並重新執行，只有當前等級任務的進度條顯示為100%時才會進入下一等級，當所有等級均顯示為100%之時，則表示上線成功。 

 

因此，總結整個持續開發驗證以及迭代過程（如下圖）。開發階段，我們需要Playback和Flighting進行驗證和測試，如果沒有問題，我們就會進入灰度上線層面。

 

在整個流程中，兩個Sprint之間其實是存在部分交集的，所有迴歸工作則是通過自動化的方式完成。兩個Sprint交替進行讓整個過程以流水線的形式向前推進，提高了整個開發上線過程的效率。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31077337/viewspace-2212554/，如需轉載，請註明出處，否則將追究法律責任。