本文主要談及大數據系統如何做系統迭代，以及大規模系統因為其大規模沒有可能搭建對等的測試環境，需要進行在線測試方面的內容，更有在線測試需要的必要條件等等。

阿里巴巴大數據計算平臺需要每天不間斷的跑在上萬臺機器集群上，上面承擔阿里核心分析計算任務，有著很高的可靠性和SLA的要求，但是我們同時需要持續不斷提高系統的性能，降低成本，提供更多功能來滿足日益增長的業務需求，這樣就要求持續不斷的升級正在服務的系統。如何能夠保證系統迭代中系統的高可用性對于阿里大數據計算平臺是個很大的挑戰。本次我們主要分享在大規模計算平臺中發布迭代中挑戰和阿里在MaxCompute系統中的解決方案。

MaxCompute

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

整個系統存儲幾百個EP的數據，每天處理***的任務量，具備上萬臺單集群，具有多集群跨地域的規模。我們內部有8000多個開發數據工程師，在這個平臺上進行數據開發，性能上我們做社區的兩倍，成本是Amazon的三分之一。

MaxCompute整體架構如圖所示，最下層為分布式的存儲系統和調度系統來統一的管理所有集群的資源，包括CPU、內存磁盤，在此上有一層執行引擎來支撐不同種的運算方式。我們提供統一的語言讓數據工程師能夠無縫的在多種計算方式進行整合，我們同時也提供兼容開源接口去對接外面現有的生態。

我們要把MaxCompute打造成一個數據計算的服務，而不是解決方案。所謂服務，首先需要提供統一的數倉，打通不用應用用戶中的數據訪問， 打破阿里內部各個部門的數據壁壘，使得所有的數據匯集到一點，可以去跨地跨部門訪問這些數據，讓數據在一起產生一些化學反應，從而把相關的數據關聯起來，挖掘出數據背后的價值;再者需要提供一個365(天)x24(小時)的高可靠，高可用的，共享的大數據計算服務，以此來做到細粒度的統一的資源調度，使得各種業務之間能夠做到相互資源填補從而做到低成本，高使用效率;***服務的方式能夠讓用戶從運維、監控中解放出來，把這些工作交給計算系統來完成，從而大大降低使用大數據計算服務的門檻。而相對應的解決方案，則僅僅提供大數據的計算系統的安裝包，用戶需要自己去找相應的資源拉起，需要自己搭建運維和監控系統，需要自己管理平臺升級等等工作。而這些用戶定義的集群(或者是虛擬機組成集群)往往是割裂的，并不能將各個用戶數據匯聚在一起進行更大范圍的計算。

MaxCompute持續改進和發布中的挑戰

MaxCompute需要是不間斷的服務，所以從高可用的角度，我們希望系統***沒有更新，因為更新就有風險，這樣才能更好持續不斷的服務客戶，能夠提供給計算任務的用戶四個九甚至十個九的可靠性。但是我們業務是在不停的成長，對于計算平臺每天都會有新的需求，需要計算平臺跟著發展，同時業務的成長速度遠遠快于機器采購的系統，這也推動我們的系統一定要持續提高其核心性能，從而能夠去匹配業務的成長。因為以上兩個理由，逼著計算平臺需要持續不斷的去變更。更加困難是計算平臺有別于其他服務，其他服務基本上狠心節點是單機的，通過負載平衡等手段把某些流量切到新的機器上進行驗證即可，但是計算平臺跑的都是分布式的運算，有的任務需要用到是成千上萬臺機器，并且計算節點的耦合是比較緊密的，所以不能通過傳統的負載平衡等手段來驗證新版本。再者因為計算平臺管理上萬臺機器，壞的變更產生的破壞是巨大的。所以我們怎么才能做到穩定和變更的平衡呢，如何能夠控制變革的風險對于一個計算平臺的成功是非常重要的。

打個比方，我們就像一個以高速飛行的飛機，在飛行的過程中我們需要保證安全和穩定，同時需要給飛行引擎換一個更加強大的引擎，能夠飛得更高和更快。在大數據計算上面，我們的挑戰具體有哪些呢?然后我們會談談阿里在處理這些挑戰采取的解決辦法。

MaxCompute每天都有***作業， 如何能夠保證新的功能不會造成線上故障?

MaxCompute從***天就強調安全性，如何處理可測性和安全性之間的矛盾?

MaxCompute Playback

在阿里內部，絕大部分計算任務是批處理任務，批處理的基本流程是用戶會用我們的語言寫一個分布式關系代數的查詢優化，通過前端提交到后端，通過編譯器和優化器，生成物理執行計劃會和后端的執行引擎進行綁定，在調度到后面萬臺規模集群進行計算。

編譯器Playback工具是什么呢?我們每天有***的jobs，每天都在變，在有新功能的時候，往往需要增強我們的語言，比如支持一些迭代計算的語法，又比如提供新的UDF。再者我們內在要有非常強大的需求驅動，需要持續不斷的提高優化器的表達能力，性能優化水平，從而滿足業務迅速發展的需要。如何能夠保證升級過程中沒有大的Regression?如果我們采用人工的方式一個個用戶任務去驗證我們新的計算引擎，就算都是專家，可以2分鐘看出是否有風險，那也需要要近4年的時間。那怎么辦呢?我們的方案是利用我們自己大規模運算平臺的并行運算能力來驗證兼容性測試，將編譯查詢作為一個MaxCompute的UDF，然后執行一個并行DAG執行來并行執行上百萬查詢的編譯優化，然后在智能分析結果得到新功能的潛在風險。

那么如何能夠做到自我驗證的呢?這里有個前提條件就是我們需要對編譯器進行相應的改造。

使得編譯器符合基于AST的Visitor模型，經過編譯變成一個AST的語法樹，然后我們會一遍一遍的去遍歷這個樹，給這個樹的節點綁定信息或者進行變換。在正常的編譯過程中，我們要進行語法的分析，類型綁定，語義分析， 元數據統計數據綁定，然后生成邏輯計劃交給優化器進行優化。這個是一個非常標準的編譯器的模型。通過這種模式我們可以非常方便加入我們自定義的插件，使得可以我們在編譯的過程去收集一些信息，這些信息可以用做后面進一步展開的統計分析。

上圖是具體自我驗證的過程

利用MaxCompute本身靈活數據處理語言來構造分析任務;

利用MaxCompute本身超大規模計算能力來并行分析海量用戶任務;

利用MaxCompute靈活的UDF支持且良好的隔離方案，在UDF中拉起待測的編譯器進行編譯，之后再進行詳細的結果分析;

整個過程都在MaxCompute完善的安全體系保護下，保障用戶的知識產權不會泄露給開發同學。

那么，我們日常做了什么事情呢?

非常簡單，我們會進行新版本的驗證，job有些會編譯不過;我們也會精確制導找到觸發新的優化規則的query，驗證其查詢優化是否符合預期;***我們會在語義層面做整體的數據分析，比如說我們會發現有一個API，這個API我們想下線掉，怎么知道這個業務有多少人在用，我們對相應的用戶發warning推動用戶下線過時的語法，我們需要你們用新的更好的一個API改造原有的任務，而且，可以對query整體進行分析來確定下一步開發的重點，還有評估在這個查詢優化下面的優化提高程度等等，有了這個系統，任何我們的開發，在去驗證這么大規模的時候，利用的就是我們背后大數據的分析能力。

MaxCompute Flighting

MaxCompute Playback解決了對于大量job在優化和編譯的時候，我們能夠快速的進行驗證和比對。那么，如何保證MaxCompute優化器和運行器是正確執行的，如何避免在快速迭代中的正確性問題，從而避免重大的事故，同時需要保證數據的安全性?

傳統的方式是線下搭建一個對等測試集群來驗證，在我們的大數據下面是行不通的。原因在于：***，我們是一個大數據的場景，要測試集群調度或者scalability等方面的改進往往需要建立一個相同規模的測試集群，浪費巨大;第二，測試集群沒有相應的任務負載，在測試集群中可以跑一個測試用例，但是想把生產集群里面水位線達到非常高，將幾萬臺機器上跑的任務復制到集群里面，根本就做不了，因為消耗的資源是非常驚人的，沒有辦法復制全部的負載，只能一個一個任務去看，無法構造對應測試場景;***，數據安全問題，我們需要脫敏的方式從生產集群拖數據到測試集群里測，脫敏處理很容易人為疏忽，造成數據泄露風險，同時脫敏數據不等于用戶數據，可能違背用戶程序的期望，從而造成用戶程序崩潰，從而達不到測試的目的，同時整個測試過程冗長，把數據拷貝過來再搭環境做測試，這樣嚴重影響了整個開發的效率，所以是不理想的一種方式。

我們采取線上驗證測試，我們把99%的資源去跑線上的作業，把原來用于測試的機器并入到生產集群里面，通過調度器的能力，把1%的機器資源提供給程序員可以自己提交一個私有版本，把這1%的資源用于測試任務。

那么，線上進行測試和驗證的前提條件是什么?

資源隔離。我們需要做到很好的資源隔離，因為我們不希望線上的測試影響到線上生產作業的可靠性。我們在系統資源隔離上做了很多的工作，在CPU、內存上，我們加強cgroup實現，能夠支撐更多更靈活資源控制;在磁盤上統一的管理下面的磁盤，并且提供存儲上優先級控制;在Network萬兆網上，我們加強流量的控制等等。當然這里1%其實是個彈性的，假設我們沒有測試任務，1%的資源也會用于線上的任務，從而能夠充分利用我們的資源。

安全性，我們需要完善多租戶支持，和用戶數據安全管理，使得提交測試任務的系統開發者不能觸碰到用戶的數據。并且我們這些測試任務的結果也會落盤，而是直接對接后面的MD5等自動化驗證手段進行結果對比，確保任務正確性。

通過這種方式，相比傳統方式我們能夠更加保護用戶的數據，因為不需要人工干預進行數據脫敏，從而避免人為犯錯的可能同時這種方式***程度復制真實場景，能夠可靠地進行執行性能等分析，因為所有的背景噪音是一模一樣的，能夠很好的驗證我們在調度上，規模上各種改進的效果。

調度器優化

在線調試新的調度算法會造成環境改變，從而難以評估。往往在分布式場景里面，我們會有以下的幾個經驗：

不可測性。在線上改了一個算法，拿新的任務調到線上，就改變了負載，因為和老的不一樣，在對比的時候，新的調度算法已經改了負載均衡，會有一系列的影響，***會發現要觀察這個行為已經影響去觀察的東西的本身，這是調度的不可測性。

少數者光環。我們往往會發現一種現象，當新的調度器漸漸成為主流，優化性能越來越差，這往往是性能提高主要因為新的優化器對比老優化器具有不公平競爭的關系。

那么如何驗證新的調度算法。在分布式場景里面怎么做到新算法的調優，將線上workload記錄下來進行模擬器進行模擬，因為workload是線上用老的方法記錄下來，再跑新的算法的時候，所有的workload都是有先后關系的，變化前面一個就會變成后面一個，這個偏差誤差就會越來越寬，甚至有時候方向性的判斷都不能給你。所以我們也是采用flighting的方式在線上進行驗證，但是為了避免少數者光環這個問題，我們需要先把新的調度器調整參數使得其和老調度器能夠公平的使用資源，然后在進行驗證。等到新的優化器成為主體后在來調整剩下這些。

MaxCompute灰度上線、細粒度回滾

上面我們談了怎么運用并行分析能力驗證查詢器和優化器，以及怎么用flighting的工具去驗證線上執行，執行時候怎么能保證產生正確結果和怎么去驗證調度器的算法。這些步驟都做完，我們就要發布了，為了控制上線風險，我們支持非常細粒的灰度發布，當發現危險在不用人工干預的情況下迅速回滾。我們先把任務里面按照重要程度進行分級，然后通過一定的比例去用新版本，如果中間出現了任何問題迅速回零。

有了這幾個技術，整體的開發流程分為開發、回歸和上線。所有的開發工程師可以自己進行線上的認證，自己提交私有版本，也不會影響線上的版本，利用1%的線上資源可以做這個flighting。驗證完就可以做回歸測試，我們的發布過程中會用灰度發布來控制上線的風險，開發人員可以等上個版本的回歸發布時，開始下一個版本的研發，這樣才能迅速的做到快速迭代，使得大數據的分布式平臺，做到持續的發布和演化。