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

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

伏羲（Fuxi）是十年前創立飛天平臺時的三大服務之一（分布式存儲 Pangu，分布式計算 MaxCompute（內部代號ODPS），分布式調度 Fuxi），當時的設計初衷是為了解決大規模分布式資源的調度問題（本質上是多目標的最優匹配問題）。目前Fuxi 2.0是MaxCompute內置的調度系統。

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

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

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

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

新的挑戰

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

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

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

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

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

近千萬量級作業的規模下，如何做到敏捷、可靠、高效的分布式作業調度執行。

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

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

如何應對挑戰？

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

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

StreamlineX + Shuffle Service

挑戰

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

Streamline 與 Shuffle Service 概述

★ Streamline

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

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

★ Shuffle Service?

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

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

StreamlineX + Shuffle Service關鍵技術

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

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

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

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

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

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

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

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

內存優化: 對于 Streamline Writer 和 Reader 內存分配更加合理，會根據實際數據量來按需分配內存，盡可能減少可能產生的 Dump 操作。

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

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

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

Shuffle Service 主要功能有：

• agent merge：徹底解決傳統磁盤shuffle模式中的碎片讀問題；
• 靈活的異常處理機制：相較于傳統磁盤shuffle模式，在應對壞境異常時更加穩定高效；
• 數據動態調度：運行時為任務選擇最合適的shuffle數據來源
• 內存&PreLaunch對準實時的支持：性能與network shuffle相當的情況下，資源消耗更少。

StreamlineX + Shuffle Service雙十一線上成果

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

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

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

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

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

★?StreamlineX+Shuffle Service 展望

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

DAG 2.0

挑戰

雙十一大促場景下，除了數據洪峰和超過日常作業的規模，數據的分布與特點也與平常大不相同。這種特殊的場景對分布式作業的調度執行框架提出了多重挑戰，包括：

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

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

DAG 2.0 概述

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

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

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

DAG 2.0 關鍵技術

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

★? 完善的錯誤處理能力

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

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

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

★?靈活的動態邏輯圖執行策略：Conditional join

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

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

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

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

DAG 2.0 雙十一線上成果

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

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

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

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

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

★? DAG 2.0 展望

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

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

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

資源調度的交互式搶占

挑戰

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

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

交互式搶占概述

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

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

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

雙十一線上成果

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

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

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

?

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

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

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。