快手超大規(guī)模集群調(diào)度優(yōu)化實踐

1. 離線ETL場景

離線場景下如何保障核心作業(yè)的SLA是比較核心的問題。在快手，核心作業(yè)和普通作業(yè)在同一個隊列中，通過完善作業(yè)分級保障能力和異常節(jié)點規(guī)避能力，保障核心作業(yè)的SLA。

離線ETL場景中經(jīng)常會遇到以下情況以及相應的優(yōu)化方案：

① 其他隊列作業(yè)大量占據(jù)資源不釋放

通過優(yōu)化隊列間資源搶占來解決這個問題。為防止搶占影響過大，默認情況下只有高優(yōu)先級核心作業(yè)觸發(fā)搶占，并且會限制每輪搶占的最大資源量。搶占過程中根據(jù)作業(yè)優(yōu)先級，饑餓等待時間等條件動態(tài)計算每個隊列可以搶占的資源量，從而把資源傾斜給優(yōu)先級更高，饑餓等待時間更長的作業(yè)。

② 隊列內(nèi)低優(yōu)先級作業(yè)占據(jù)大量資源不釋放

在生產(chǎn)場景下如果低優(yōu)先級作業(yè)占用大量資源不釋放，導致優(yōu)先級比較高的任務無法獲取到足夠資源，從而導致產(chǎn)出延遲。為解決這個問題提出基于虛擬隊列來保障高優(yōu)先級作業(yè)產(chǎn)出。所謂虛擬隊列，是在物理隊列下，按照一定邏輯規(guī)則（比如優(yōu)先級）抽象出的邏輯隊列。每個虛擬隊列有一定的資源配額，并且會觸發(fā)物理隊列內(nèi)部的搶占，從而解決上面的問題。

③ 低優(yōu)先級作業(yè)占據(jù)app solt不釋放

為方便AppSlot資源的管理，抽象出minApp概念，如果App啟動時，隊列running App小于minApp，將會立刻啟動App，不會受限于父隊列的maxRunningApp，這樣在隊列層面保障有可預期的app slot。但同樣存在一個問題，隊列內(nèi)部低優(yōu)先級作業(yè)占據(jù)大量AppSlot不釋放，導致高優(yōu)先級作業(yè)啟動延遲。為此提出了App Slot搶占功能。如下圖所示，如果發(fā)現(xiàn)高優(yōu)先級作業(yè)（P0）長時間pending不能啟動，掃描隊列內(nèi)runningApp，選擇低優(yōu)先級作業(yè)進入睡眠模式（不再調(diào)度新task，極端情況下回收task）從而釋放出slot資源，保障高優(yōu)先級作業(yè)能及時啟動。

④ 回溯作業(yè)影響生產(chǎn)作業(yè)

回溯作業(yè)的特點在于大量提交多個作業(yè)，如果不加控制可能會影響生產(chǎn)作業(yè)的產(chǎn)出。主要方案是限制回溯作業(yè)最大資源量和最大運行APP數(shù)目，將影響控制在一定的范圍以內(nèi)。但是限制最大資源量和運行數(shù)目導致大量回溯作業(yè)在yarn處于pending狀態(tài)，對yarn有比較大的壓力，通過與上游調(diào)度系統(tǒng)打通，反壓上層工作流調(diào)度系統(tǒng)，阻止新提交的回溯作業(yè)，從而減輕了YARN負載。對于已經(jīng)提交到y(tǒng)arn上的作業(yè)，會限制每個隊列最大pending app個數(shù)，從而保障總體pending app數(shù)目可控。

⑤ 高優(yōu)先級作業(yè)大塊資源請求不能及時滿足

原有的Reserve機制中，調(diào)度器可以reserve一批節(jié)點，不再調(diào)度新task，等待節(jié)點上自然釋放資源。如果被reserve節(jié)點資源長時間不釋放，如何處理？針對這個場景開發(fā)了reserve搶占功能，用于搶占reserve節(jié)點上的低優(yōu)先級的container，從而保障節(jié)點上有足夠的空閑資源啟動高優(yōu)先級作業(yè)。

⑥ 規(guī)避異常節(jié)點，避免核心作業(yè)長尾

通過采集節(jié)點物理指標，task失敗率，task運行速度，以及shuffle失敗率等，將此節(jié)點標記為異常節(jié)點，不再調(diào)度新Task。從而盡量減少異常節(jié)點的影響范圍，規(guī)避其導致的Task長尾，失敗問題。

2. Adhoc即時查詢場景

AdHoc場景主要著力于提升每個用戶的查詢體驗。

通過虛擬隊列技術，從user維度來劃分虛擬隊列，實現(xiàn)基于user公平的資源的分配，配合基于user的資源搶占，從而避免大量資源被某一個用戶占用，導致其他用戶長時間得不到資源。

3. 機器學習訓練場景

機器學習訓練場景下，資源需求呈現(xiàn)all or nothing特點，在隊列資源緊張時，如果基于yarn原生的公平調(diào)度方式，為每個app分配部分資源，容易產(chǎn)生資源分配死鎖問題。為此我們采用APP輪轉(zhuǎn)調(diào)度策略，采用類似FIFO策略，保障頭部APP（頭部會動態(tài)變化，輪轉(zhuǎn)策略名稱的由來）的資源需求，避免死鎖問題。

4. Flink實時作業(yè)場景

FLink實時場景下，主要介紹故障發(fā)生時，如何盡量減少故障的影響范圍，以及如何快速恢復故障作業(yè)：

• 通過cpu均衡調(diào)度，避免機器cpu熱點。

• 通過AM失敗節(jié)點規(guī)避機制，避免調(diào)度到AM失敗機器。

• NM掛起（不調(diào)度新Task，介于RUNNING和LOST狀態(tài)）機制，防止NM異常退出導致Task失敗。

• 基于Hawk秒級發(fā)現(xiàn)節(jié)點宕機，快速進行作業(yè)恢復。

雖然可以基于Hawk秒級發(fā)現(xiàn)節(jié)點宕機，但作業(yè)恢復過程可能需要幾分鐘（申請資源，下載jar包，job recover等）。我們通過資源冗余分配策略，優(yōu)化掉其中資源申請和下載jar包過程，最終實現(xiàn)秒級作業(yè)恢復。