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

伏羲（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，提供了某些特定情況下作業失敗重跑的機制）重跑等各方面產生影響，任何一個狀況沒有得到及時的自動化解決，都有可能導致基線作業破線引發故障。

在其他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架構。

在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倍。

高效能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上實現了一套基於血緣回溯的主動容錯策略（如下圖），這樣的智慧血緣回溯，能夠避免了層層試探，層層重跑，在叢集壓力較大時，能夠有效的節約執行時間，避免資源浪費。

分散式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完備的動態圖排程和執行能力上，都能得到較好的解決，相關功能正在排期上線中。

一個典型的例子是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歷年雙十一大促的穩定執行提供了強有力的保障。

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

互動式搶佔概述

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

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

通過效能優化，放寬了高優先順序每輪處理的SU限制個數互動式搶佔超時後強制回收預留的低優先順序資源，對於優先啟動的、佔據大量資源、instance執行時間較長的低優先順序作業，需要強制回收資源。採用預留外的資源供給高優先順序資源，可以通過預留外的其他資源為互動式搶佔的SU繼續分配資源，同時抵消對應的互動式搶佔部分。雙十一線上成果

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

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

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