Fuxi2.0—飛天大資料平台排程系統全面更新，首次亮相2019雙十一

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

随着阿裡經濟體和阿裡雲業務需求（尤其是雙十一）的不斷豐富，伏羲的内涵也不斷擴大，從單一的資源排程器（對标開源系統的YARN）擴充成大資料的核心排程服務，覆寫資料排程（Data Placement）、資源排程（Resouce Management）、計算排程（Application Manager）、和本地微（自治）排程等多個領域，并在每一個細分領域緻力于打造超越業界主流的差異化能力。

過去十年來，伏羲在技術能力上每年都有新的進展和突破，2013年5K，2015年Sortbenchmark世界冠軍，2017年超大規模離在/在離線混部能力，2019年的 Yugong 釋出并且論文被VLDB2019接受等。随着 Fuxi 2.0 首次亮相2019雙11，今年飛天大資料平台在混部側支援和基線保障2個方面均順利完成了目标。其中，混部支援了雙十一 60%線上交易洪峰的流量，超大規模混部排程符合預期。在基線保障方面，單日資料處理 970PB，較去年增長超過60%。在千萬級别的作業上，不需要使用者額外調優，基本做到了無人工幹預的系統自動化。

新的挑戰

随着業務和資料的持續高速增長，MaxCompute 雙十一的作業量和計算資料量每年的增速都保持在60%以上 。

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

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

1. 超大規模計算場景下，以及資源緊張的情況下，如何進一步提升平台的整體性能，來應對業務的持續高速增長。
2. 雙十一會給MaxCompute帶來全方面超壓力的極端場景，如幾億條的熱點key、上千倍的資料膨脹等，這對叢集磁盤IO的穩定性、資料檔案讀寫性能、長尾作業重跑等各方面都是挑戰。
3. 近千萬量級作業的規模下，如何做到靈活、可靠、高效的分布式作業排程執行。
4. 以及對高優先級作業（如重要業務基線）的資源保障手段。
5. 今年也是雲上叢集首次參與雙十一，并且開始支援混部。

如何應對挑戰

為了應對上述挑戰，與往年相比，除了正常的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兩部分，下面簡要介紹其中部分優化設計：

1. 架構結構合理劃分: Runtime Streamline 和fuxi sdk 解耦，Runtime 負責資料處理邏輯，Fuxi SDK 負責底層資料流傳輸。代碼可維護性，功能可擴張性，性能調優空間都顯著增強。
2. 支援 GraySort 模式: Streamline Writer 端隻分組不排序，邏輯簡單，省去資料記憶體拷貝開銷以及相關耗時操作，Reader 端對全量資料排序。整體資料處理流程 Pipeline 更加高效，性能顯著提升。
3. 支援 Adaptive 模式: StreamlineReader支援不排序和排序模式切換，來支援一些 AdaptiveOperator 的需求，并且不會産生額外的 IO 開銷，回退代價小，Adaptive 場景優化效果顯著。
4. CPU 計算效率優化: 對耗時計算子產品重新設計 CPU 緩存優化的資料結構和算法，通過減少 cache miss，減少函數調用開銷，減少 cpu cache thrashing，提升 cache 的有效使用率等手段，來提升運算效率。
5. IO 優化：支援多種壓縮算法和 Adaptive 壓縮方式，并重新設計 Shuffle 傳輸資料的存儲格式，有效減少傳輸的 IO 量。
6. 記憶體優化: 對于 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進行搶占配置預期）。