2019年，是阿里巴巴第11個雙11。眾所周知，阿里的電商在線體系經(jīng)過多年發(fā)展，可以支持峰值超過每秒50幾萬筆交易。但鮮有人知的是，海量的交易，創(chuàng)造了海量的數(shù)據(jù)，爆炸性的數(shù)據(jù)量激增，給狂歡過后的大數(shù)據(jù)處理，帶來了大難題。

今年雙11，阿里巴巴MaxCompute大數(shù)據(jù)云數(shù)倉服務，單日數(shù)據(jù)吞吐量接近EB級別，任務數(shù)達到千萬級，而我們所有重保高優(yōu)先級任務，卻都做到了按時產(chǎn)出；同時，我們還通過在離線混部，承載了交易系統(tǒng)的65%的峰值交易。這很大程度上，得益于全新亮相的MaxCompute調(diào)度系統(tǒng)Fuxi2.0。分布式大數(shù)據(jù)處理，最大的問題之一是，如何在數(shù)萬節(jié)點間有效交換，傳輸海量的數(shù)據(jù)，確保內(nèi)存、磁盤、網(wǎng)絡硬件的最高效使用，但又不會因為硬件高負載而出現(xiàn)軟硬件故障，導致無效運行。另一個問題是，數(shù)據(jù)在真正被計算處理前，我們并不知道真實的數(shù)據(jù)分布情況，導致靜態(tài)生成的執(zhí)行計劃很糟糕，我們需要動態(tài)根據(jù)實時輸入、或中間生成的數(shù)據(jù)，調(diào)整執(zhí)行計劃，方能最優(yōu)。而這正是本文要解決的雙11大數(shù)據(jù)處理的問題之二。本文干貨滿滿，希望能對大家的大數(shù)據(jù)處理幫助一二。

伏羲（Fuxi）是十年前創(chuàng)立飛天平臺時的三大服務之一（分布式存儲 Pangu，分布式計算 MaxCompute（內(nèi)部代號ODPS），分布式調(diào)度 Fuxi），當時的設計初衷是為了解決大規(guī)模分布式資源的調(diào)度問題（本質(zhì)上是多目標的最優(yōu)匹配問題）。目前Fuxi 2.0是MaxCompute內(nèi)置的調(diào)度系統(tǒng)。

過去十年來，伏羲在技術能力上每年都有新的進展和突破，2013年5K，2015年Sortbenchmark世界冠軍，2017年超大規(guī)模離在/在離線混部能力，2019年的 Yugong 發(fā)布并且論文被VLDB2019接受等。

隨著 Fuxi 2.0 首次亮相2019雙11，今年飛天大數(shù)據(jù)平臺在混部側(cè)支持和基線（需要重保的高優(yōu)先級作業(yè)）保障2個方面均順利完成了目標。其中，混部支持了雙十一 60%在線交易洪峰的流量，超大規(guī)模混部調(diào)度符合預期。在基線保障方面，單日數(shù)據(jù)處理 970PB，較去年增長超過60%。在千萬級別的作業(yè)上，不需要用戶額外調(diào)優(yōu)，基本做到了無人工干預的系統(tǒng)自動化。

伏羲（Fuxi）是十年前創(chuàng)立飛天平臺時的三大服務之一（分布式存儲 Pangu，分布式計算 ODPS，分布式調(diào)度 Fuxi），當時的設計初衷是為了解決大規(guī)模分布式資源的調(diào)度問題（本質(zhì)上是多目標的最優(yōu)匹配問題）。

隨著阿里經(jīng)濟體和阿里云業(yè)務需求（尤其是雙十一）的不斷豐富，伏羲的內(nèi)涵也不斷擴大，從單一的資源調(diào)度器（對標開源系統(tǒng)的YARN）擴展成大數(shù)據(jù)的核心調(diào)度服務，覆蓋數(shù)據(jù)調(diào)度（Data Placement）、資源調(diào)度（Resouce Management）、計算調(diào)度（Application Manager）、和本地微（自治）調(diào)度等多個領域，并在每一個細分領域致力于打造超越業(yè)界主流的差異化能力。

新的挑戰(zhàn)

隨著業(yè)務和數(shù)據(jù)的持續(xù)高速增長，MaxCompute 雙十一的作業(yè)量和計算數(shù)據(jù)量每年的增速都保持在60%以上 。

2019雙十一，MaxCompute 日計算數(shù)據(jù)量規(guī)模已接近EB級，作業(yè)量也到了千萬量級，在如此大規(guī)模和資源緊張的情況下，要確保雙十一穩(wěn)定運行，所有重要基線作業(yè)按時產(chǎn)出壓力相當之大。

在雙十一獨特的大促場景下，2019雙11的挑戰(zhàn)主要來自以下幾個方面：

超大規(guī)模計算場景下，以及資源緊張的情況下，如何進一步提升平臺的整體性能，來應對業(yè)務的持續(xù)高速增長。

雙十一會給MaxCompute帶來全方面超壓力的極端場景，如幾億條的熱點key、上千倍的數(shù)據(jù)膨脹等，這對集群磁盤IO的穩(wěn)定性、數(shù)據(jù)文件讀寫性能、長尾作業(yè)重跑等各方面都是挑戰(zhàn)。

近千萬量級作業(yè)的規(guī)模下，如何做到敏捷、可靠、高效的分布式作業(yè)調(diào)度執(zhí)行。

以及對高優(yōu)先級作業(yè)（如重要業(yè)務基線）的資源保障手段。

今年也是云上集群首次參與雙十一，并且開始支持混部。

如何應對挑戰(zhàn)？

為了應對上述挑戰(zhàn)，與往年相比，除了常規(guī)的HBO等調(diào)整之外，飛天大數(shù)據(jù)平臺加速了過去1-2年中技術積累成果的上線，尤其是 Fuxi 2.0 首次亮相雙十一，最終在單日任務量近千萬、單日計算量近千PB的壓力下，保障了基線全部按時產(chǎn)出。

• 在平臺性能優(yōu)化方面，對于挑戰(zhàn)#1和#2，StreamlineX + Shuffle Service 根據(jù)實時數(shù)據(jù)特征自動智能化匹配高效的處理模式和算法，挖掘硬件特性深度優(yōu)化IO，內(nèi)存，CPU等處理效率，在減少資源使用的同時，讓全量SQL平均處理速度提升將近20%，出錯重試率下降至原來的幾十分之一，大大提了升MaxCompute 平臺整體效能。
• 在分布式作業(yè)調(diào)度執(zhí)行方面，對于挑戰(zhàn)#3，DAG 2.0?提供了更敏捷的調(diào)度執(zhí)行能力,和全面去阻塞能力，能為大規(guī)模的MR作業(yè)帶來近50%的性能提升。同時DAG動態(tài)框架的升級，也為分布式作業(yè)的調(diào)度執(zhí)行帶來了更靈活的動態(tài)能力，能根據(jù)數(shù)據(jù)的特點進行作業(yè)執(zhí)行過程中的動態(tài)調(diào)整。
• 在資源保障方面，為應對挑戰(zhàn)#4，Fuxi 對高優(yōu)先級作業(yè) （主要是高優(yōu)先級作業(yè)）采取了更嚴格、更細粒度的資源保障措施，如資源調(diào)度的交互式搶占功能，和作業(yè)優(yōu)先級保障管控等。目前線上最高優(yōu)先級的作業(yè)基本能在90s內(nèi)搶占到資源。
• 其他如業(yè)務調(diào)優(yōu)支持等：如業(yè)務數(shù)據(jù)壓測配合，與作業(yè)調(diào)優(yōu)等。

StreamlineX + Shuffle Service

挑戰(zhàn)

上面提到今年雙十一數(shù)據(jù)量翻倍接近EB級，作業(yè)量接近千萬，整體資源使用也比較緊張，通過以往經(jīng)驗分析，雙十一影響最關鍵的模塊就是Streamline (在其他數(shù)據(jù)處理引擎也被稱為Shuffle或Exchange)，各種極端場景層出不窮，并發(fā)度超過5萬以上的Task，多達幾億條的熱點Key，單Worker數(shù)據(jù)膨脹上千倍等全方位覆蓋的超壓力數(shù)據(jù)場景，都將極大影響Streamline模塊的穩(wěn)定運行，從而對集群磁盤IO的穩(wěn)定性，數(shù)據(jù)文件讀寫性能，機器資源競搶性能，長尾Worker PVC（Pipe Version Control，提供了某些特定情況下作業(yè)失敗重跑的機制）重跑等各方面產(chǎn)生影響，任何一個狀況沒有得到及時的自動化解決，都有可能導致基線作業(yè)破線引發(fā)故障。

Streamline 與 Shuffle Service 概述

★ Streamline

在其他OLAP或MPP系統(tǒng)中，也有類似組件被稱為Shuffle或Exchange，在MaxCompute SQL中該組件涉及的功能更加完善，性能更優(yōu)，主要包含但不限于分布式運行的Task之間數(shù)據(jù)序列化，壓縮，讀寫傳輸，分組合并，排序等操作。

SQL中一些耗時算子的分布式實現(xiàn)基本都需要用到這個模塊，比如join，groupby，window等等，因此它絕對是CPU，memory，IO等資源的消耗大戶，在大部分作業(yè)中運行時間占比整個sql運行時間30%以上，一些大規(guī)模作業(yè)甚至可以達到60%以上，這對于MaxCompute SQL日均近千萬任務量，日均處理數(shù)據(jù)接近EB級的服務來說，性能每提升1個多百分點，節(jié)省的機器資源都是以上千臺計，因此對該組件的持續(xù)重構優(yōu)化一直是MaxCompute SQL團隊性能提升指標的重中之重。今年雙十一應用的SLX就是完全重寫的高性能Streamline架構。

★ Shuffle Service?

在MaxCompute SQL中，它主要用于管理全集群所有作業(yè)Streamline數(shù)據(jù)的底層傳輸方式和物理分布。調(diào)度到不同機器上成千上萬的Worker需要通過精準的數(shù)據(jù)傳遞，才能協(xié)作完成整體的任務。在服務MaxCompute這樣的數(shù)據(jù)大戶時，能否高效、穩(wěn)定地完成每天10萬臺機器上千萬量級worker間傳輸幾百PB數(shù)據(jù)量的數(shù)據(jù)shuffle工作，很大意義上決定了集群整體的性能和資源利用效率。

Shuffle Service放棄了以磁盤文件為基礎的主流shuffle文件存儲方式，突破了機械硬盤上文件隨機讀的性能和穩(wěn)定性短板；基于shuffle數(shù)據(jù)動態(tài)調(diào)度的思想，令shuffle流程成為了作業(yè)運行時實時優(yōu)化的數(shù)據(jù)流向、排布和讀取的動態(tài)決策。對準實時作業(yè)，通過解構DAG上下游調(diào)度相比network shuffle性能相當，資源消耗降低50%+。

StreamlineX + Shuffle Service關鍵技術

★ StreamlineX (SLX) 架構與優(yōu)化設計

SLX邏輯功能架構如圖所示，主要包含了SQL runtime層面的數(shù)據(jù)處理邏輯重構優(yōu)化，包括優(yōu)化數(shù)據(jù)處理模式，算法性能提升，內(nèi)存分配管理優(yōu)化，挖掘硬件性能等各方面來提升計算性能，而且底座結合了全新設計的負責數(shù)據(jù)傳輸?shù)腇uxi ShuffleService服務來優(yōu)化IO讀寫以及Worker容錯性等方面，讓SLX在各種數(shù)據(jù)模式以及數(shù)據(jù)規(guī)模下都能夠有很好的性能提升和高效穩(wěn)定的運行。

SQL Runtime SLX主要包含Writer和Reader兩部分，下面簡要介紹其中部分優(yōu)化設計：

框架結構合理劃分: Runtime Streamline 和fuxi sdk 解耦，Runtime 負責數(shù)據(jù)處理邏輯，Fuxi SDK 負責底層數(shù)據(jù)流傳輸。代碼可維護性，功能可擴張性，性能調(diào)優(yōu)空間都顯著增強。

支持 GraySort 模式: Streamline Writer 端只分組不排序，邏輯簡單，省去數(shù)據(jù)內(nèi)存拷貝開銷以及相關耗時操作，Reader 端對全量數(shù)據(jù)排序。整體數(shù)據(jù)處理流程 Pipeline 更加高效，性能顯著提升。

支持 Adaptive 模式: StreamlineReader支持不排序和排序模式切換，來支持一些 AdaptiveOperator 的需求，并且不會產(chǎn)生額外的 IO 開銷，回退代價小，Adaptive 場景優(yōu)化效果顯著。

CPU 計算效率優(yōu)化: 對耗時計算模塊重新設計 CPU 緩存優(yōu)化的數(shù)據(jù)結構和算法，通過減少 cache miss，減少函數(shù)調(diào)用開銷，減少 cpu cache thrashing，提升 cache 的有效利用率等手段，來提升運算效率。

IO 優(yōu)化：支持多種壓縮算法和 Adaptive 壓縮方式，并重新設計 Shuffle 傳輸數(shù)據(jù)的存儲格式，有效減少傳輸?shù)?IO 量。

內(nèi)存優(yōu)化: 對于 Streamline Writer 和 Reader 內(nèi)存分配更加合理，會根據(jù)實際數(shù)據(jù)量來按需分配內(nèi)存，盡可能減少可能產(chǎn)生的 Dump 操作。

根據(jù)以往雙十一的經(jīng)驗，11月12日凌晨基線任務數(shù)據(jù)量大幅增加，shuffle過程會受到巨大的挑戰(zhàn)，這通常也是造成當天基線延遲的主要原因，下面列出了傳統(tǒng)磁盤shuffle的主要問題：

• 碎片讀：一個典型的2k*1k shuffle pipe在上游每個mapper處理256MB數(shù)據(jù)時，一個mapper寫給一個reducer的數(shù)據(jù)量平均為256KB，而從HDD磁盤上一次讀小于256KB這個級別的數(shù)據(jù)量是很不經(jīng)濟的，高iops低throughput嚴重影響作業(yè)性能。
• 穩(wěn)定性：由于HDD上嚴重的碎片讀現(xiàn)象，造成reduce input階段較高的出錯比率，觸發(fā)上游重跑生成shuffle數(shù)據(jù)更是讓作業(yè)的執(zhí)行時間成倍拉長。

Shuffle Service徹底解決了以上問題。經(jīng)過此次雙11的考驗，結果顯示線上集群的壓力瓶頸已經(jīng)從之前的磁盤，轉(zhuǎn)移到CPU資源上。雙十一當天基線作業(yè)執(zhí)行順暢，集群整體運行持續(xù)保持穩(wěn)定。

Shuffle Service 主要功能有：

• agent merge：徹底解決傳統(tǒng)磁盤shuffle模式中的碎片讀問題；
• 靈活的異常處理機制：相較于傳統(tǒng)磁盤shuffle模式，在應對壞境異常時更加穩(wěn)定高效；
• 數(shù)據(jù)動態(tài)調(diào)度：運行時為任務選擇最合適的shuffle數(shù)據(jù)來源
• 內(nèi)存&PreLaunch對準實時的支持：性能與network shuffle相當?shù)那闆r下，資源消耗更少。

StreamlineX + Shuffle Service雙十一線上成果

為了應對上面挑戰(zhàn)，突破現(xiàn)有資源瓶頸，一年多前MaxCompute SQL就啟動性能持續(xù)極限優(yōu)化項目，其中最關鍵之一就是StreamlineX (SLX)項目，它完全重構了現(xiàn)有的Streamline框架，從合理設計高擴展性架構，數(shù)據(jù)處理模式智能化匹配，內(nèi)存動態(tài)分配和性能優(yōu)化，Adaptive算法匹配，CPU Cache訪問友好結構設計，基于 Fuxi Shuffle Service 服務優(yōu)化數(shù)據(jù)讀寫IO和傳輸?shù)雀鞣矫孢M行重構優(yōu)化升級后的高性能框架。

至雙十一前，日均95%以上彈內(nèi)SQL作業(yè)全部采用SLX，90%以上的Shuffle流量來自SLX，0故障，0回退的完成了用戶透明無感知的熱升級，在保證平穩(wěn)上線的基礎上，SLX在性能和穩(wěn)定性上超預期提升效果在雙十一當天得到充分體現(xiàn)，基于線上全量高優(yōu)先級基線作業(yè)進行統(tǒng)計分析：

• 在性能方面，全量準實時SQL作業(yè)e2e運行速度提升15%+，全量離線作業(yè)的Streamline模塊Throughput(GB/h)提升100%
• 在IO讀寫穩(wěn)定性方面，基于FuxiShuffleService服務，整體集群規(guī)模平均有效IO讀寫Size提升100%+，磁盤壓力下降20%+；
• 在作業(yè)長尾和容錯上，作業(yè)Worker發(fā)生PVC的概率下降到僅之前的幾十分之一；
• 在資源優(yōu)先級搶占方面，ShuffleService保障高優(yōu)先級作業(yè)shuffle 數(shù)據(jù)傳輸比低優(yōu)先級作業(yè)降低25%+；

正是這些超預期優(yōu)化效果，MaxCompaute 雙十一當天近千萬作業(yè)，涉及到近10萬臺服務器節(jié)省了近20%左右的算力，而且針對各種極端場景也能智能化匹配最優(yōu)處理模式，做到完全掌控未來數(shù)據(jù)量不斷增長的超大規(guī)模作業(yè)的穩(wěn)定產(chǎn)出。

上面性能數(shù)據(jù)統(tǒng)計是基于全量高優(yōu)先級作業(yè)的一個平均結果，實際上SLX在很多大規(guī)模數(shù)據(jù)場景下效果更加顯著，比如在線下tpch和tpcds 10TB測試集資源非常緊張的場景下，SQL e2e運行速度提升近一倍，Shuffle模塊提升達2倍。

★?StreamlineX+Shuffle Service 展望

高性能SLX框架經(jīng)過今年雙十一大考覺不是一個結束，而是一個開始，后續(xù)我們還會不斷的完善功能，打磨性能。比如持續(xù)引入高效的排序，編碼，壓縮等算法來Adaptive匹配各種數(shù)據(jù)Parttern，根據(jù)不同數(shù)據(jù)規(guī)模結合ShuffleService智能選擇高效數(shù)據(jù)讀寫和傳輸模式，RangePartition優(yōu)化，內(nèi)存精準控制，熱點模塊深度挖掘硬件性能等各方向持續(xù)發(fā)力，不斷節(jié)省公司成本，技術上保持大幅領先業(yè)界產(chǎn)品。

DAG 2.0

挑戰(zhàn)

雙十一大促場景下，除了數(shù)據(jù)洪峰和超過日常作業(yè)的規(guī)模，數(shù)據(jù)的分布與特點也與平常大不相同。這種特殊的場景對分布式作業(yè)的調(diào)度執(zhí)行框架提出了多重挑戰(zhàn)，包括：

• 處理雙十一規(guī)模的數(shù)據(jù)，單個作業(yè)規(guī)模超過數(shù)十萬計算節(jié)點，并有超過百億的物理邊連接。在這種規(guī)模的作業(yè)上要保證調(diào)度的敏捷性，需要實現(xiàn)全調(diào)度鏈路overhead的降低以及無阻塞的調(diào)度。
• 在基線時段集群異常繁忙，各個機器的網(wǎng)絡/磁盤/CPU/內(nèi)存等等各個方面均會收到比往常更大的壓力，從而造成的大量的計算節(jié)點異常。而分布式調(diào)度計算框架在這個時候，不僅需要能夠及時監(jiān)測到邏輯計算節(jié)點的異常進行最有效的重試，還需要能夠智能化的及時判斷/隔離/預測可能出現(xiàn)問題的物理機器，確保作業(yè)在大的集群壓力下依然能夠正確完成。
• 面對與平常特點不同的數(shù)據(jù)，許多平時的執(zhí)行計劃在雙十一場景上可能都不再適用。這個時候調(diào)度執(zhí)行框架需要有足夠的智能性，來選擇合理的物理執(zhí)行計劃；以及足夠的動態(tài)性，來根據(jù)實時數(shù)據(jù)特點對作業(yè)的方方面面做出及時的必要調(diào)整。這樣才能避免大量的人工干預和臨時人肉運維。

今年雙十一，適逢計算平臺的核心調(diào)度執(zhí)行框架全新架構升級- DAG 2.0正在全面推進上線，DAG 2.0 很好的解決了上述幾個挑戰(zhàn)。

DAG 2.0 概述

現(xiàn)代分布式系統(tǒng)作業(yè)執(zhí)行流程，通常通過一個有向無環(huán)圖(DAG)來描述。DAG調(diào)度引擎，是分布式系統(tǒng)中唯一需要和幾乎所有上下游(資源管理，機器管理，計算引擎, shuffle組件等等)交互的組件，在分布式系統(tǒng)中起了重要的協(xié)調(diào)管理，承上啟下作用。作為計算平臺各種上層計算引擎(MaxCompute, PAI等)的底座，伏羲的DAG組件在過去十年支撐了上層業(yè)務每天數(shù)百萬的分布式作業(yè)運行，以及數(shù)百PB的數(shù)據(jù)處理。而在計算引擎本身能力不斷增強，作業(yè)種類多樣化的背景下，對DAG架構的動態(tài)性，靈活性，穩(wěn)定性等多個方面都提出了更高的需求。在這個背景下，伏羲團隊啟動了DAG 2.0架構升級。引入了一個，在代碼和功能層面，均是全新的DAG引擎，來更好的支持計算平臺下個十年的發(fā)展。

這一全新的架構，賦予了DAG更敏捷的調(diào)度執(zhí)行能力，并在分布式作業(yè)執(zhí)行的動態(tài)性，靈活性等方面帶來了質(zhì)的提升，在與上層計算引擎緊密結合后，能提供更準確的動態(tài)執(zhí)行計劃調(diào)整能力，從而為支持各種大規(guī)模作業(yè)提供了更好的保障。例如在最簡單的MR作業(yè)測試中，DAG 2.0調(diào)度系統(tǒng)本身的敏捷度和整個處理流程中的全面去阻塞能力, 能為大規(guī)模的MR作業(yè)(10萬并發(fā))帶來將近50%的性能提升。而在更接近線上SQL workload特點的中型（1TB TPCDS）作業(yè)中，調(diào)度能力的提升能帶來20%+的e2e時間縮短。

DAG 2.0的架構設計中結合了過去10年支持集團內(nèi)外各種計算任務的經(jīng)驗，系統(tǒng)的對實時機器管理框架，backup instance策略以及容錯機制等方面進行了考慮和設計，為支持線上多種多樣的實際集群環(huán)境打下了重要基礎。而另一挑戰(zhàn)是，2.0架構要在日常數(shù)百萬分布式作業(yè)的體量上做到完全的上線，在飛行中換引擎。從FY20財年初開始，DAG2.0推進線上升級，至今已經(jīng)實現(xiàn)了在MaxCompute離線作業(yè)，PAI平臺Tensorflow CPU/GPU作業(yè)等每天數(shù)百萬作業(yè)的完全覆蓋。并經(jīng)過項目組所有成員的共同努力，在雙十一當天交出了一份滿意的答卷。

DAG 2.0 關鍵技術

能取得上述線上結果，和DAG2.0眾多的技術創(chuàng)新密不可分，受篇幅限制，這里主要選取和雙11運行穩(wěn)定性相關的兩個方面做重點介紹。

★? 完善的錯誤處理能力

在分布式環(huán)境中由于機器數(shù)量巨大，單機發(fā)生故障的概率非常高，因此容錯能力是調(diào)度系統(tǒng)的一個重要能力。為了更好的管理機器狀態(tài)，提前發(fā)現(xiàn)故障機器并進行主動歸并，DAG2通過完整的機器狀態(tài)管理，完善了機器錯誤的處理能力：

如上圖所示，DAG2將機器分為多個狀態(tài)。并根據(jù)一系列不同的指標來觸發(fā)在不同狀態(tài)之間的轉(zhuǎn)換。對于不同狀態(tài)的機器，根據(jù)其健康程度，進行主動規(guī)避，計算任務遷移，以及計算任務主動重跑等操作。將機器問題造成的作業(yè)運行時間拉長，甚至作業(yè)失敗的可能性降到最低。

另一方面，在一個DAG上，當下游讀取數(shù)據(jù)失敗時，需要觸發(fā)上游的重跑，而在發(fā)生嚴重機器問題時，多個任務的鏈式重跑，會造成作業(yè)的長時間延遲，對于基線作業(yè)的及時產(chǎn)出造成嚴重影響。DAG2.0上實現(xiàn)了一套基于血緣回溯的主動容錯策略（如下圖），這樣的智能血緣回溯，能夠避免了層層試探，層層重跑，在集群壓力較大時，能夠有效的節(jié)約運行時間，避免資源浪費。

★?靈活的動態(tài)邏輯圖執(zhí)行策略：Conditional join

分布式SQL中，map join是一個比較常見的優(yōu)化，其實現(xiàn)原理對小表避免shuffle，而是直接將其全量數(shù)據(jù)broadcast到每個處理大表的分布式計算節(jié)點上，通過在內(nèi)存中直接建立hash表，完成join操作。

Map join優(yōu)化能大量減少額外shuffle和排序開銷并避免shuffle過程中可能出現(xiàn)的數(shù)據(jù)傾斜，提升作業(yè)運行性能。但是其局限性也同樣顯著：如果小表無法fit進單機內(nèi)存，那么在試圖建立內(nèi)存中的hash表時就會因為OOM而導致整個分布式作業(yè)的失敗。所以雖然map join在正確使用時，可以帶來較大的性能提升，但實際上優(yōu)化器在產(chǎn)生map join的plan時需要偏保守，導致錯失了很多優(yōu)化機會。而即便是如此，依然沒有辦法完全避免map join OOM的問題。

基于DAG 2.0的動態(tài)邏輯圖執(zhí)行能力，MaxCompute支持了開發(fā)的conditional join功能：在對于join使用的算法無法被事先確定時，允許優(yōu)化器提供一個conditional DAG，這樣的DAG同時包括使用兩種不同join的方式對應的不同執(zhí)行計劃支路。在實際執(zhí)行時，AM根據(jù)上游產(chǎn)出數(shù)據(jù)量，動態(tài)選擇一條支路執(zhí)行(plan A or plan B)。這樣子的動態(tài)邏輯圖執(zhí)行流程，能夠保證每次作業(yè)運行時都能根據(jù)實際作業(yè)數(shù)據(jù)特性，選擇最優(yōu)的執(zhí)行計劃，詳見下圖：

出于對上線節(jié)奏把控的考慮，雙十一期間conditional join尚未覆蓋高優(yōu)先級作業(yè)。雙十一期間，我們也看到了重要基線上由于數(shù)據(jù)膨脹導致Mapjoin hint失效，作業(yè)OOM需要臨時調(diào)參；以及因為Mapjoin未能被正確選中，而導致作業(yè)未能選中優(yōu)化執(zhí)行計劃而延遲完成的情況。在conditional join在重要基線上線后，能夠有效的避免這一情況，讓基線的產(chǎn)出更加流暢。

DAG 2.0 雙十一線上成果

雙十一作為阿里集團所有技術線的大考，對于DAG2.0這一全新的組件，同樣是一個重要的考驗，也是DAG2線上升級的一個重要的里程碑：

• 雙11當天，DAG2.0覆蓋支持線上80%+project。截至目前已完成全面上線，日均支持幾百萬的離線作業(yè)執(zhí)行。對于signature相同的基線作業(yè)，DAG 2.0下instance 運行的overhead開銷有1到2倍的降低。
• 雙11當天，使用DAG 2.0的高優(yōu)先級基線在雙十一數(shù)據(jù)洪峰下，沒有任何人工干預的前提下，未發(fā)生任何作業(yè)失敗重跑。其中，DAG2.0提供的實時機器管理，backup instance策略等智能容錯機制發(fā)揮了重要作用。
• 支持開發(fā)環(huán)境中近百萬量級作業(yè)，在作業(yè)平均規(guī)模更大的前提下，雙11期間毫秒級(執(zhí)行時間小于1s的作業(yè))分布作業(yè)占比相比1.0提升20%+。新框架上更高效的資源流轉(zhuǎn)率也帶來了資源利用率的明顯提升：等待在線資源超時而回退的在線作業(yè)比例降低了將近50%。
• DAG 2.0還支持了PAI引擎，為雙十一期間的搜索、推薦等業(yè)務的模型提前訓練提供了有力的支持。雙十一前PAI平臺的所有TensorFlow CPU/GPU作業(yè)，就已經(jīng)全量遷移到DAG 2.0上，其更有效的容錯和資源使用的提升，保證了各條業(yè)務線上模型的及時產(chǎn)出。

除了基礎提升調(diào)度能力提升帶來的性能紅利外，DAG2在動態(tài)圖亮點功能上也完成了新的突破。包括增強Dynamic Parrellism， LIMIT優(yōu)化， Conditional Join等動態(tài)圖功能完成上線或者正在上線推動中。

其中Conditional Join一方面保證了優(yōu)化的執(zhí)行計劃能盡可能的被選用，同時也保證了不會因為錯誤選擇而帶來OOM導致作業(yè)失敗，通過運行時數(shù)據(jù)統(tǒng)計來動態(tài)決定是否使用Mapjoin，保證更加準確決策。

雙十一前在集團內(nèi)部做了灰度上線，線上日均生效的conditionl節(jié)點10萬+，其中應用Map join的節(jié)點占比超過了90%，0 OOM發(fā)生。推廣的過程中我們也收到了各個BU多個用戶的真實反饋，使用conditional join后，因為能選擇最優(yōu)的執(zhí)行計劃，多個場景上作業(yè)的運行時間，都從幾個小時降低到了30分鐘以下。

★? DAG 2.0 展望

在雙十一值班的過程中，我們依然看到了大促場景下因為不同的數(shù)據(jù)分布特點，數(shù)據(jù)的傾斜/膨脹對于分布式作業(yè)整體的完成時間影響非常大。而這些問題在DAG 2.0完備的動態(tài)圖調(diào)度和運行能力上，都能得到較好的解決，相關功能正在排期上線中。

一個典型的例子是dynamic partition insert的場景，在某個高優(yōu)先級作業(yè)的場景上，一張重要的業(yè)務表直接采用動態(tài)分區(qū)的方式導入數(shù)據(jù)導致表文件數(shù)過多，后續(xù)基線頻繁訪問該表讀取數(shù)據(jù)導致pangu master持續(xù)被打爆，集群處于不可用狀態(tài)。采用DAG2.0的Adaptive Shuffle功能之后，線下驗證作業(yè)運行時間由30+小時降低到小于30分鐘，而產(chǎn)生的文件數(shù)相比于關閉reshuffle的方式降低了一個數(shù)量級，在保障業(yè)務數(shù)據(jù)及時產(chǎn)出的前提下，能極大緩解pangu master的壓力。動態(tài)分區(qū)場景在彈內(nèi)生產(chǎn)和公共云生產(chǎn)都有廣闊的應用場景，隨著Adaptive Shuffle的上線，dynamic insert將是第一個解決的比較徹底的數(shù)據(jù)傾斜場景。

此外，DAG2.0也持續(xù)探索其他數(shù)據(jù)傾斜(data skew)的處理，例如join skew等，相信隨著在2.0上更多優(yōu)化功能的開發(fā)，我們的執(zhí)行引擎能做到更動態(tài)，更智能化，包括數(shù)據(jù)傾斜問題在內(nèi)的一眾線上痛點問題，將可以得到更好的解決。今天最好的表現(xiàn)，是明天最低的要求。我們相信明年的雙十一，在面對更大的數(shù)據(jù)處理量時，計算平臺的雙十一保障能夠更加的自動化，通過分布式作業(yè)運行中的動態(tài)化調(diào)整，在更少人工干預的前提下完成。

資源調(diào)度的交互式搶占

挑戰(zhàn)

FuxiMaster是fuxi的資源調(diào)度器，負責將計算資源分配給不同的計算任務。針對MaxComput超大規(guī)模計算場景下，不同應用間多樣的資源需求，過去幾年資源調(diào)度團隊對的核心調(diào)度邏輯做了極致的性能優(yōu)化，調(diào)度延時控制在了10微秒級別，集群資源的高效流轉(zhuǎn)為MaxComputer歷年雙十一大促的穩(wěn)定運行提供了強有力的保障。

而其中高先級基線作業(yè)的按時完成是雙十一大促成功的重要標志，也是資源保障中的重中之重。除了空閑資源的優(yōu)先分配，還需要對低優(yōu)先級作業(yè)占用的資源進行騰挪，在不影響集群整體利用率的前提下，快速地將資源分配給高優(yōu)先級基線作業(yè)。

交互式搶占概述

在高負載的集群，若高優(yōu)先級作業(yè)無法及時拿到資源，傳統(tǒng)的做法是通過搶占，直接殺掉低優(yōu)先級作業(yè)，然后將資源分配給高優(yōu)先級作業(yè)，這種“暴力”搶占有資源快速騰挪的特點，但搶占“殺人”也會導致用戶作業(yè)中途被殺，計算資源浪費的缺點。交互式搶占是指在明確資源從低優(yōu)先級流向高優(yōu)先級的前提下，不立即殺掉低優(yōu)先級作業(yè)，而是通過協(xié)議，讓低優(yōu)先級作業(yè)盡快在可接受的時間內(nèi)（目前是90s）快速跑完，既不浪費集群的計算資源，同時也保障了高優(yōu)先級作業(yè)的資源供給。

目前彈內(nèi)線上針對高優(yōu)先級SU（schedule unit，是資源管理的基本單位）開啟組內(nèi)交互式搶占，在大多情況下可以保障基線作業(yè)的資源供給。然而，目前即使通過交互式搶占也還會存在一些作業(yè)無法及時獲得資源的情況。例如，高優(yōu)先級交互式搶占每隔30s的觸發(fā)處理高優(yōu)先的SU數(shù)量受全局配置約束，而該段時間還存在大量其他早已經(jīng)提交進來的高優(yōu)先級SU，會導致該作業(yè)的SU被輪空。另外，交互式搶占指令發(fā)出后，需要對應instance結束后定向還這份資源，而對應的instance的運行時間都非常長，導致交互式無法及時拿回對應的資源。基于上述問題，我們進一步優(yōu)化了交互式搶占策略。交互式搶占關鍵技術針對前文提到的幾個問題，交互式搶占做了如下優(yōu)化：

• 通過性能優(yōu)化，放寬了高優(yōu)先級每輪處理的SU限制個數(shù)
• 交互式搶占超時后強制回收預留的低優(yōu)先級資源，對于優(yōu)先啟動的、占據(jù)大量資源、instance運行時間較長的低優(yōu)先級作業(yè)，需要強制回收資源。
• 采用預留外的資源供給高優(yōu)先級資源，可以通過預留外的其他資源為交互式搶占的SU繼續(xù)分配資源，同時抵消對應的交互式搶占部分。

雙十一線上成果

2019雙十一期間，面對遠超以往的數(shù)據(jù)量，所有的高優(yōu)先級作業(yè)順利按期產(chǎn)出，資源調(diào)度方面順利保障了基線資源供給，其絲般順滑程度讓整個基線保障的過程幾乎感受不到資源調(diào)度的存在。其中基線作業(yè)交互式搶占以及加速功能提供了有效的資源保障能力，及時、有效的搶占到所需資源。下文給出了某個云上集群的資源供給情況。

★? 交互式搶占加速為基線作業(yè)快速提供可用資源

從下面幾張圖中可以看到，在基線時間段(00:00 ~ 09:00), 基線作業(yè)超時拿不到資源發(fā)起交互式搶占revoke的頻率明顯高于其他時段， 這意味著通過交互式搶占加速的手段基線作業(yè)可以順利拿到所需資源。雙十一期間的線上運行情況，也證明了 在資源壓力大的情況下，高優(yōu)先級基線作業(yè)明顯通過了交互式搶占revoke獲得了資源。

?

★?基線作業(yè)的SU拿資源時間比例分布

下邊為主要幾個集群SU拿資源的時間分布 (fuxi基本調(diào)度單元)， 可以發(fā)現(xiàn)這幾個集群90%分位拿資源的時間基本都在1分鐘左右（符合線上基線作業(yè)等待資源達到90s進行搶占配置預期）。

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結

以上是生活随笔為你收集整理的读懂这本书，才算读懂阿里大数据的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。