2016年11月18-20日sdcc 2016中國軟體開發者大會，阿裡巴巴大資料計算平台首席架構師林偉給我們帶來了“高可用的大資料計算平台如何持續釋出和演進”的演講。本文主要談及大資料系統如何做系統疊代，以及大規模系統因為其大規模沒有可能搭建對等的測試環境，需要進行線上測試方面的内容，更有線上測試需要的必要條件等等。
阿裡巴巴大資料計算平台需要每天不間斷的跑在上萬台機器叢集上，上面承擔阿裡核心分析計算任務，有着很高的可靠性和sla的要求，但是我們同時需要持續不斷提高系統的性能，降低成本，提供更多功能來滿足日益增長的業務需求，這樣就要求持續不斷的更新正在服務的系統。如何能夠保證系統疊代中系統的高可用性對于阿裡大資料計算平台是個很大的挑戰。本次我們主要分享在大規模計算平台中釋出疊代中挑戰和阿裡在maxcompute系統中的解決方案。
<b>maxcompute</b>
maxcompute（大資料計算服務）是一種快速、完全托管的pb/eb級資料倉庫解決方案，具備萬台伺服器擴充能力和跨地域容災能力，是阿裡巴巴内部核心大資料平台，支撐每日百萬級作業規模。maxcompute向使用者提供了完善的資料導入方案以及多種經典的分布式計算模型，能夠更快速的解決使用者海量資料計算問題，有效降低企業成本，并保障資料安全。
整個系統存儲幾百個ep的資料，每天處理百萬級的任務量，具備上萬台單叢集，具有多叢集跨地域的規模。我們内部有8000多個開發資料工程師，在這個平台上進行資料開發，性能上我們做社群的兩倍，成本是amazon的三分之一。
maxcompute整體架構如圖所示，最下層為分布式的存儲系統和排程系統來統一的管理所有叢集的資源，包括cpu、記憶體磁盤，在此上有一層執行引擎來支撐不同種的運算方式。我們提供統一的語言讓資料工程師能夠無縫的在多種計算方式進行整合，我們同時也提供相容開源接口去對接外面現有的生态。
我們要把maxcompute打造成一個資料計算的服務，而不是解決方案。所謂服務，首先需要提供統一的數倉，打通不用應用使用者中的資料通路， 打破阿裡内部各個部門的資料壁壘，使得所有的資料彙集到一點，可以去跨地跨部門通路這些資料，讓資料在一起産生一些化學反應，進而把相關的資料關聯起來，挖掘出資料背後的價值；再者需要提供一個365（天）x24（小時）的高可靠，高可用的，共享的大資料計算服務，以此來做到細粒度的統一的資源排程，使得各種業務之間能夠做到互相資源填補進而做到低成本，高使用效率；最後服務的方式能夠讓使用者從運維、監控中解放出來，把這些工作交給計算系統來完成，進而大大降低使用大資料計算服務的門檻。而相對應的解決方案，則僅僅提供大資料的計算系統的安裝包，使用者需要自己去找相應的資源拉起，需要自己搭建運維和監控系統，需要自己管理平台更新等等工作。而這些使用者定義的叢集（或者是虛拟機組成叢集）往往是割裂的，并不能将各個使用者資料彙聚在一起進行更大範圍的計算。
<b>maxcompute持續改進和釋出中的挑戰</b>
maxcompute需要是不間斷的服務，是以從高可用的角度，我們希望系統最好沒有更新，因為更新就有風險，這樣才能更好持續不斷的服務客戶，能夠提供給計算任務的使用者四個九甚至十個九的可靠性。但是我們業務是在不停的成長，對于計算平台每天都會有新的需求，需要計算平台跟着發展，同時業務的成長速度遠遠快于機器采購的系統，這也推動我們的系統一定要持續提高其核心性能，進而能夠去比對業務的成長。因為以上兩個理由，逼着計算平台需要持續不斷的去變更。更加困難是計算平台有别于其他服務，其他服務基本上狠心節點是單機的，通過負載平衡等手段把某些流量切到新的機器上進行驗證即可，但是計算平台跑的都是分布式的運算，有的任務需要用到是成千上萬台機器，并且計算節點的耦合是比較緊密的，是以不能通過傳統的負載平衡等手段來驗證新版本。再者因為計算平台管理上萬台機器，壞的變更産生的破壞是巨大的。是以我們怎麼才能做到穩定和變更的平衡呢，如何能夠控制變革的風險對于一個計算平台的成功是非常重要的。
打個比方，我們就像一個以高速飛行的飛機，在飛行的過程中我們需要保證安全和穩定，同時需要給飛行引擎換一個更加強大的引擎，能夠飛得更高和更快。在大資料計算上面，我們的挑戰具體有哪些呢？然後我們會談談阿裡在處理這些挑戰采取的解決辦法。
maxcompute每天都有百萬級作業， 如何能夠保證新的功能不會造成線上故障？
maxcompute從第一天就強調安全性，如何處理可測性和安全性之間的沖突？
<b>maxcompute playback</b>
在阿裡内部，絕大部分計算任務是批處理任務，批處理的基本流程是使用者會用我們的語言寫一個分布式關系代數的查詢優化，通過前端送出到後端，通過編譯器和優化器，生成實體執行計劃會和後端的執行引擎進行綁定，在排程到後面萬台規模叢集進行計算。
編譯器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整體進行分析來确定下一步開發的重點，還有評估在這個查詢優化下面的優化提高程度等等，有了這個系統，任何我們的開發，在去驗證這麼大規模的時候，利用的就是我們背後大資料的分析能力。
<b>maxcompute flighting</b>
maxcompute playback解決了對于大量job在優化和編譯的時候，我們能夠快速的進行驗證和比對。那麼，如何保證maxcompute優化器和運作器是正确執行的，如何避免在快速疊代中的正确性問題，進而避免重大的事故，同時需要保證資料的安全性？
傳統的方式是線下搭建一個對等測試叢集來驗證，在我們的大資料下面是行不通的。原因在于：第一，我們是一個大資料的場景，要測試叢集排程或者scalability等方面的改進往往需要建立一個相同規模的測試叢集，浪費巨大；第二，測試叢集沒有相應的任務負載，在測試叢集中可以跑一個測試用例，但是想把生産叢集裡面水位線達到非常高，将幾萬台機器上跑的任務複制到叢集裡面，根本就做不了，因為消耗的資源是非常驚人的，沒有辦法複制全部的負載，隻能一個一個任務去看，無法構造對應測試場景；最後，資料安全問題，我們需要脫敏的方式從生産叢集拖資料到測試叢集裡測，脫敏處理很容易人為疏忽，造成資料洩露風險，同時脫敏資料不等于使用者資料，可能違背使用者程式的期望，進而造成使用者程式崩潰，進而達不到測試的目的，同時整個測試過程冗長，把資料拷貝過來再搭環境做測試，這樣嚴重影響了整個開發的效率，是以是不理想的一種方式。
我們采取線上驗證測試，我們把99%的資源去跑線上的作業，把原來用于測試的機器并入到生産叢集裡面，通過排程器的能力，把1%的機器資源提供給程式員可以自己送出一個私有版本，把這1%的資源用于測試任務。
那麼，線上進行測試和驗證的前提條件是什麼？
資源隔離。我們需要做到很好的資源隔離，因為我們不希望線上的測試影響到線上生産作業的可靠性。我們在系統資源隔離上做了很多的工作，在cpu、記憶體上，我們加強cgroup實作，能夠支撐更多更靈活資源控制；在磁盤上統一的管理下面的磁盤，并且提供存儲上優先級控制；在network萬兆網上，我們加強流量的控制等等。當然這裡1%其實是個彈性的，假設我們沒有測試任務，1%的資源也會用于線上的任務，進而能夠充分利用我們的資源。
安全性，我們需要完善多租戶支援，和使用者資料安全管理，使得送出測試任務的系統開發者不能觸碰到使用者的資料。并且我們這些測試任務的結果也會落盤，而是直接對接後面的md5等自動化驗證手段進行結果對比，確定任務正确性。
通過這種方式，相比傳統方式我們能夠更加保護使用者的資料，因為不需要人工幹預進行資料脫敏，進而避免人為犯錯的可能同時這種方式最大程度複制真實場景，能夠可靠地進行執行性能等分析，因為所有的背景噪音是一模一樣的，能夠很好的驗證我們在排程上，規模上各種改進的效果。
<b>排程器優化</b>
線上調試新的排程算法會造成環境改變，進而難以評估。往往在分布式場景裡面，我們會有以下的幾個經驗：
不可測性。線上上改了一個算法，拿新的任務調到線上，就改變了負載，因為和老的不一樣，在對比的時候，新的排程算法已經改了負載均衡，會有一系列的影響，最後會發現要觀察這個行為已經影響去觀察的東西的本身，這是排程的不可測性。
少數者光環。我們往往會發現一種現象，當新的排程器漸漸成為主流，優化性能越來越差，這往往是性能提高主要因為新的優化器對比老優化器具有不公平競争的關系。
那麼如何驗證新的排程算法。在分布式場景裡面怎麼做到新算法的調優，将線上workload記錄下來進行模拟器進行模拟，因為workload是線上用老的方法記錄下來，再跑新的算法的時候，所有的workload都是有先後關系的，變化前面一個就會變成後面一個，這個偏差誤差就會越來越寬，甚至有時候方向性的判斷都不能給你。是以我們也是采用flighting的方式線上上進行驗證，但是為了避免少數者光環這個問題，我們需要先把新的排程器調整參數使得其和老排程器能夠公平的使用資源，然後在進行驗證。等到新的優化器成為主體後在來調整剩下這些。
<b>maxcompute灰階上線、細粒度復原</b>
上面我們談了怎麼運用并行分析能力驗證查詢器和優化器，以及怎麼用flighting的工具去驗證線上執行，執行時候怎麼能保證産生正确結果和怎麼去驗證排程器的算法。這些步驟都做完，我們就要釋出了，為了控制上線風險，我們支援非常細粒的灰階釋出，當發現危險在不用人工幹預的情況下迅速復原。我們先把任務裡面按照重要程度進行分級，然後通過一定的比例去用新版本，如果中間出現了任何問題迅速回零。
有了這幾個技術，整體的開發流程分為開發、回歸和上線。所有的開發工程師可以自己進行線上的認證，自己送出私有版本，也不會影響線上的版本，利用1%的線上資源可以做這個flighting。驗證完就可以做回歸測試，我們的釋出過程中會用灰階釋出來控制上線的風險，開發人員可以等上個版本的回歸釋出時，開始下一個版本的研發，這樣才能迅速的做到快速疊代，使得大資料的分布式平台，做到持續的釋出和演化。
<b>林偉：</b>阿裡巴巴大資料計算平台首席架構師，10多年在大資料領域的開發經驗，原微軟大資料平台cosmos/scope的核心開發人員。現在在阿裡巴巴負責大資料計算平台（maxcompute)架構組。該系統目前支撐了阿裡巴巴、螞蟻金服叢集絕大多數計算任務。林偉同時在國際一流odsi、nsdi、sigmod會議上多次發表論文。