分享嘉賓：陳武 虎牙 大資料架構師
編輯整理：楊哲 達州銀行
出品平臺：DataFunTalk
導讀：
今天為大家介紹虎牙的離線作業排程系統，以及如何透過基線排程實現成本最佳化。主要包括以下幾大部分：
排程系統的定位及發展
系統設計
基線排程的關鍵實現
未來發展
——
01
排程系統的定位及發展
1. 定位
離線計算排程系統的定位，從它的名字上可以看出，是在離線計算場景範圍內的開發平臺。
首先要解決的問題是開發階段的便捷高效，開發人員不用關心工程、環境上的問題；其次是要解決開發過程中的管理問題，比如版本控制、許可權控制等。
開發完成上線之後，來到運維階段。我們期望以資料驅動，實現自動運維，無需研發人員介入，實現故障自動定因或者進一步故障自愈。
通常離線計算處理的資料量都比較大，如何進行成本最佳化，也是我們要考慮的問題。
2. 發展歷程
基於上述定位，虎牙的離線排程系統經歷瞭如下的發展歷程。
早在2018年，排程系統就已經存在了，而且運行了3年左右。這個時期的排程平臺，已經解決了開發階段的問題，實現了視覺化的計算任務開發、版本控制、多人協作等功能。當時我們的任務量，每天接近10w以上，任務量也算是比較大的。
接下來2019-2020年，我們主要做的是成本側的最佳化。比如基線排程梳理，多機房融合雲排程，任務治理等工作。
2021年開始，我們開始在智慧運維方向進行了一些探索，包括故障自動分析，甚至自動自愈等。
未來我們將在智慧數倉方向上做進一步探索。
3. 收益
經過上述發展歷程後，我們對成本進行了全面的評估。
因為離線任務排程任務對於資源的需求集中在凌晨0點到9點，剩餘的時間都比較空閒。經過我們調整最佳化後，可以看到虎牙的yarn叢集利用率24小時的分佈情況，在0-20點的20個小時中，整體的利用率都比較平均，時間維度上利用率可以達到90%。SLA也一直保持在90%以上。怎麼理解這個利用率呢？如果整個計算任務執行完成需要1w臺機器的算力佔用持續9個小時，那麼將同樣的計算任務平均分配到20個小時只需要5000臺機器的算力。
我們是如何實現這樣的成本最佳化的呢？接下來將為大家介紹我們的系統設計。
——
02
系統設計
1. 整體介紹
首先整體介紹一下虎牙排程系統。下圖是排程產品的一個縮影。
排程系統強調任務流程之間的邏輯關係，致力於完成一個任務排程有向無環圖（DAG）的配置，在資料庫中會保留這樣的邏輯，甚至在執行或者程式碼中也會嵌入這些邏輯關係，勢必會造成跨流程依賴的問題。
我們的排程系統是強調對任務的分類分配，淡化任務邏輯關係的關注。透過對任務各方面資訊的採集，在後臺根據這些資訊將任務進行算力優先順序編排。
綠色框部分是一些任務外掛，比如hive，SparkSql等。
下面的可執行頻次，就是一個Crontab表示式，來指定任務執行的週期。
再往下是配置任務依賴，相當於DAG的流程編排，這個稍後會詳細說明。
下面是重要程度，是制定任務的算力優先順序，這個直接影響到整個的任務編排。
高階屬性，包括設定任務調到哪一類介面機去跑、它的重試次數等。
最後是一些監控類的設定。
2. 時間依賴
下面詳細介紹時間依賴的設計。
市面上對於時間週期性的任務，通常採取窮舉法來實現，比如一個任務每3個小時執行，那麼會把這個任務所有執行的時間點計算窮舉出來（即0點、3點、6點。。。）。我們的做法是抽象出時間跨度的概念（類似於Oracle定時任務Job裡面指定頻率的概念），同樣每三個小時執行表達為（0+3），即從0點開始間隔為3小時。
第二個不同是我們的任務觸發是完全基於事件驅動的
。上游任務只需要發出自身執行完成訊號，觸發下游的任務進行依賴檢測。下游收到出發後，自行根據配置的依賴項去檢測，是否具備執行條件。
比如A任務跨度為一天，間隔為15分鐘，B任務的依賴是A任務全天的執行完成。當A任務的全部計劃執行完成後，會去觸發B任務，B會檢測A任務當天所有任務執行完成後才會開始執行。
3. 部署架構
我們整個任務排程流程是：
首先任務排程中心去資料庫中獲取任務的基本資訊，然後根據不同的任務型別生成任務的例項分配到不同的介面機（Agent），最後由介面機將任務例項提交到Yarn執行。
我們的介面機（Agent）是部署在分散式檔案系統上的，而且是無狀態的，方便伸縮。
——
03
基線排程的關鍵實踐
前面我們已經介紹了排程平臺的整體情況，接下來介紹我們如何在此基礎上既保障使用者的SLA，又提高Yarn的利用率。
1. 成本最佳化三板斧
SLA的定義和管理
：我們要確保成本最佳化不能影響使用者使用，用SLA指導成本最佳化的極限，避免過度最佳化。
降低資源消耗在時段上的過度集中
：因為離線計算多集中於0-9點，所以我們要讓算力盡量平攤到各時段。
降低叢集的安全buffer容量
：buffer容量不能過大，要在合理的範圍內。
2. SLA定義
如何讓使用者滿意，我們總結了三個方面改善：
需求開發週期長，通常是由資料產品開發和需求分析的同事來解決；
資料效果/資料質量問題通常是業務口徑或者資料治理的問題；
同一個定時任務完成時間不穩定，任務準時率低，由排程平臺來掌控，是很好的SLA指標。
如何根據任務準時率定義SLA？如果讓使用者定義所有任務的準時期望是不現實的，只需要定義使用者自己關心的末端任務的準時期望，剩餘沒有定義的我們預設為當天24點之前。
我們設計了按重要度區分的準時基線供使用者選擇，公司級、一級部門、二級部門來定義任務的優先順序，同時需要部門領導進行稽核，確認SLA的真實性、合理性。
完成準時基線配置後，可以很好地量化平臺的SLA指標。我們會跟業務部門共同承擔這個指標，因為通常故障原因有可能是任務程式碼的原因，也有可能是平臺的原因。
基於準時率SLA的成本打法有如下幾種：
優計算：
透過最佳化ETL過程，提升計算引擎效率。這種方式不在於排程平本身。
調期望：
找到並幹掉一些使用者不太合理的準時期望，調整期望時間。
擴算力：
增加算力投入，提升計算能力。
挪任務：
利用任務優先順序，對任務執行時間進行調整，有限保障重要任務。
3. 算力平攤
哪些任務的優先順序高？如何保證把算力優先給到更高優先順序的任務？
首先定義任務優先順序
。使用者在任務鏈的末端節點設定了準時期望，那麼上游任務的準時期望怎麼設定？假設我們已經知道所有任務節點執行的真實時長，根據末端節點的準時期望可以遞迴倒推出所有任務的最晚開始時間。
有些任務提交到Yarn集群后，需要等待分配資源，有些任務直接就可以開始計算，那麼任務執行的真實時長我們怎麼衡量？將等待資源時間從整體任務鏈執行時間中減去，就得到真實時間。
Yarn佇列中的容量排程一般採用先進先出策略執行，對於週期跑數是沒有問題的，但是生產環節比較複雜，會有臨時跑數任務和緊急跑數任務。這種情況使用先進先出策略不太合適。比如有個很大的任務正在執行，臨時出現一個小任務必須等待大任務執行完成後才能得到資源。所以我們針對臨時和緊急跑數任務採用公平策略來排程。另外對於緊急跑數的任務，需要將任務挪到優先順序高的佇列中執行。
同時要注意排程側配置反壓策略，透過監控yarn叢集的繁忙程度，並控制排程側的任務提交節奏。
4. 安全buffer容量
這樣配置完成後，整個yarn叢集要多大才夠，或者說所有任務配置完成後，需要預留多少buffer容量？如果遇到突發情況，buffer不夠的情況下，如何快速提升算力？
我們設計了一個算力擴縮容模型，有三條算力配置基線。無限算力是所有任務提交後立即得到資源執行；保底算力是保障任務準時率的下限；真實算力是在保底算力之上加上一定的預留算力。
對於虎牙來說，寒暑假或者大型賽事期間，突發大量算力缺口。我們採用雲作為快速擴容手段。如何將計算任務分配到不同機房執行？我們採用瞭如下方法。
首先對日常任務的DAG執行圖進行分塊裁剪，形成多個成塊的任務組，分發到不同的機房執行；其次將IO小的任務，動態分配到各個機房執行，填充大型任務執行的空隙。
這樣我們就做到了將Yarn叢集的利用率提高到90%以上。
——
04
未來發展
接下來我們對排程平臺的規劃主要是智慧方向。比如說任務運維智慧化、任務異常自動定因等。另外是智慧數倉方向，ETL鏈路上90%的任務自動生成，使用者只需要關注業務邏輯，不再關心計算鏈路和計算任務。資料的儲存生命週期都由平臺管理。
——
05
問答
Q：離線任務時段和實時任務時段怎麼分配比較好？
A：分不同的Yarn佇列，用先進先出策略處理週期性任務；公平策略應對臨時緊急任務。
Q：DAG工作流編排可以再說明一下麼？
A：就是在傳統的工作流編排基礎上附加上時間屬性。
Q：是根據確認資料在哪個叢集來確定任務提交的叢集嗎？
A：是。因為我們用剪輯演算法切分任務DAG形成任務塊，提前知道此任務塊應該在哪個機房執行。對於IO小的是不用過多考慮的，就是動態分配。
Q：算力的預估是怎麼做的，是預先執行還是記錄了歷史算力消耗，再次提交的時候進行了重新分配？
A：是基於歷史每一天任務，在不缺算力的情況下，執行的真實時長的平均數、中位數進行預估。考慮到存在一定的誤差，配置算力時結合任務重要程度，進行一些擴大算力配置。
Q：排程中，任務的計算成本時怎麼衡量？是否有任務和表的血緣關係？任務成本會平攤到每個表嗎？
A：任務的成本沒有分攤到表，是根據Yarn的佇列進行分攤的，因為我們的佇列是根據部門對應設定的。任務和表的血緣是有的，我們會自動的解析sql，獲取到欄位級的血緣關係。
Q：多機房的計算資源是一套Yarn叢集統一管理還是多套？
A：Yarn叢集可以理解為獨立的多套，透過排程平臺做路由將任務分發到不同的機房執行。
今天的分享就到這裡，謝謝大家。
閱讀更多技術乾貨文章，請關注
微信公眾號“DataFunTalk”
。
分享嘉賓：
關於我們：
DataFun：
專注於大資料、人工智慧技術應用的分享與交流。發起於2017年，在北京、上海、深圳、杭州等城市舉辦超過100+線下和100+線上沙龍、論壇及峰會，已邀請超過2000位專家和學者參與分享。其公眾號 DataFunTalk 累計生產原創文章700+，百萬+閱讀，14萬+精準粉絲。
歡迎轉載分享評論，轉載請私信。