票選最美雲上大資料暨大資料技術峰會上，阿裡雲飛天一部計算平台進階專家無庸為大家帶來題為“高可用大資料計算服務如何持續釋出和演進”的演講。本文先對maxcompute架構進行了介紹，接着重點介紹在大資料計算服務下，高可用服務持續改進和釋出的工具，包括playback工具、flighting工具和灰階上線、細粒度復原等。
以下是精彩内容整理：
maxcompute
大資料計算服務(maxcompute)是一種快速、完全托管的pb/eb級資料倉庫服務。具備萬台伺服器擴充能力和跨地域容災能力，是阿裡巴巴内部核心大資料計算平台，支撐每日百萬級作業規模。
maxcompute是一種統一的大資料計算平台，maxcompute向使用者提供了完善的資料導入方案以及多種經典的分布式計算模型，比如sql、圖計算、流計算和機器學習等，能夠更快速的解決使用者海量資料計算問題，有效降低企業成本，并保障資料安全。
maxcompute不隻對阿裡集團内部使用者開放，也向外部開放。天貓、淘寶、螞蟻金服等都在使用maxcompute，maxcompute是阿裡集團内部最關鍵的大資料平台，目前，maxcompute機器已經有五萬多台，資料表是百萬級以上，開發者有8000多個，性能上是hadoop2倍等，從資料上可以感受到maxcompute是名副其實的海量大資料平台，在業内能處理的資料量以及計算能力也是處于領先地位的。
maxcompute底層是由阿裡自主開發的盤古分布式存儲系統和伏羲分布式排程系統組成，在此基礎上，我們也開發了maxcompute執行引擎，maxcompute是統一的大資料計算平台，既能支援傳統經典的批處理，也支援流計算、圖計算、記憶體計算以及機器學習等，從這個角度來看，maxcompute與spark定位非常相似；在此之上，maxcompute支援靈活的語言，為了讓使用者能夠無縫接入maxcompute，我們也支援開源系統好多的api，包括spark api和hive api等。
<b>批處理計算</b><b></b>
目前，對于阿裡巴巴甚至業界來說，sql類型的批處理是最經典最廣泛的應用了，sql批處理的流程如下：
使用者送出一條類似sql的腳本到maxcompute後，maxcompute會對sql腳本進行編譯并優化，然後用runtime運作。
大資料計算服務
maxcompute要做大資料計算的服務，并不像業界開源的hadoop、spark提供一套解決方案，我們需要提供一個365（天）x24（小時）的高可靠，高可用的共享大資料計算服務。
那麼，有什麼好處呢？它可以：
–
使用門檻大大降低，使用者不用關心運維更新等
共享細粒度使用資源，進而做到低成本，高效率
大資料計算服務強調穩定性，與持續發展之間存在天然的沖突。在一個穩定運作的大資料計算服務上改進和釋出新功能就像“空中換車”，在高速飛行的飛機上替換引擎而同時要保持平穩飛行，其中的挑戰難度可想而知。
<b>持續改進和釋出中的挑戰</b><b></b>
maxcompute每天都有百萬級作業。如何能夠平穩安全，使用者無感覺的釋出新的功能？如何保證新版本的穩定性，沒有bug，沒有性能的回退？出現問題後如何能夠快速止損等等？
面對外部使用者，在測試時如何保證資料安全可靠呢？
針對以上挑戰，我們提出在高可用服務下持續改進和釋出了以下技術手段來克服：
– maxcompute playback工具
– maxcompute flighting工具
– maxcompute灰階上線，細粒度復原
<b>編譯器</b><b>playback</b><b>工具</b><b></b>
maxcompute目前主流的仍然是sql類型應用，其中非常關鍵的子產品就是編譯優化器，我們需要快速提高我們編譯器、優化器的表達能力，以及性能優化水準。
那麼，如何能夠保證更新過程中沒有大的regression？
每天有100萬+個job，每天都在變化，如果人工分析的話，每個script僅需要2分鐘，需要91人年，這是不現實的，是以，我們開發了編譯器playback工具。
playback工具用來解決編譯器和優化器的測試驗證功能，利用大資料計算平台的運算能力來自我驗證新的編譯優化器。
具體原理如下：
基于maxcompute強大而靈活的編譯擴充能力，編譯器基于ast的編譯器模型，使用了經典的visitor模式。sql腳本送出到系統後會将sql腳本轉化成抽象文法樹，正常情況下的文法驗證和分析等實作了标準的visitor，visitor對應于ast的驗證等擴充性是非常好的，除了标準的visitor加入後，還可以加入一些有針對性的檢查驗證抽象文法樹的新visitor，将這些visitor加到文法樹上，就可以驗證新的編譯器和優化器生成出來的各種各樣的産出是否ok，以此來驗證新的編譯器和優化器的能力。
<b>自我驗證</b><b></b>
整個驗證過程如下：
1.
當使用者送出一條sql腳本發給maxcompute，利用maxcompute本身靈活資料處理語言來構造分析任務；
2.
利用maxcompute本身超大規模計算能力來并行分析海量使用者任務，将一段時間使用者作業抽出；
3.
利用maxcompute靈活的udf支援且良好的隔離方案，在udf中拉起待測的編譯器進行編譯，之後再進行詳細的結果分析。
整個過程都在maxcompute完善的安全體系保護下，保障使用者的知識産權。
playback工具還有其它很豐富的作用，比如：
進行新版本的驗證
精确制導找到觸發新的優化規則的query，驗證其查詢優化是否符合預期
在語義層面對于query進行整體資料分析
對相應的使用者發warning推動使用者下線過時的文法
對query整體進行分析來确定下一步開發的重點
評估新版本在查詢優化在執行計劃上的提高程度
<b>flighting </b><b>工具</b><b></b>
除了編譯器和優化器外，另外有一個關鍵子產品就是執行器。那麼，如何保證maxcompute運作器是正确執行的？避免在快速疊代中的正确性問題，進而避免重大的事故？同時，如何保證資料的安全性呢？
傳統方式驗證運作器，最經典的是用測試叢集來驗證，該方式驗證的缺點如下：
浪費巨大
排程或者scalability等方面的改進往往需要建立一個相同規模的測試叢集
沒有相應的任務負載，無法構造對應場景
資料安全問題，使得我們需要脫敏的方式從生産叢集拖資料
容易人為疏忽，造成資料洩露風險
脫敏資料可能造成使用者程式crash，并且往往不能反映使用者運作場景
整個測試過程冗長，不能達到測試的目的
是以我們引入了flighting工具來做測試和驗證，将99% 機器資源使用線上版本運作生産作業，1% 機器資源用來為程式員上載的測試版本進行驗證。
<b>資源隔離</b>
那麼，怎麼保證測試驗證的作業不去影響線上生産的作業呢？這就需要我們完善資源隔離，具體包括：
cpu/memory: 增強cgroup，任務優先級
disk：統一的存儲管理，存儲的優先級
network：scalable traffic control
quota管理
是以我們能夠在保障線上核心業務需求情況下進行flighting的測試。
<b>資料安全</b>
從資料安全角度來說，我們的測試不需要人工幹預進行資料脫敏；flighting的任務的結果不落盤，而是直接對接分析任務産生測試報告：
– 結果正确性：md5計算，浮點等不确定性類型的處理
執行性能的分析：straggler，data-skew，schedule quality
<b>灰階上線</b><b></b>
sql的關鍵子產品如編譯優化和執行都可以得到有效測試和驗證，接下來就可以上線了，上線時也會有很大風險，是以，我們實行灰階上線。按照任務的重要性進行分級，支援細粒度釋出，并且支援瞬時復原，控制風險到最小。
開發新功能後做回歸，回歸後釋出，開始時往往有新功能後，就進行驗證，如果新功能是針對編譯器、優化器，就用playback驗證，針對runtime就用flighting驗證，所有測試驗證結束後，就到灰階釋出階段，直到所有任務百分百釋出上線後，我們就認為這一次開發疊代是成功的，以此類推，不停的向前演進，既能保證服務可靠穩定運作的同時，将我們的性能提升，以滿足使用者的各種需求。