導讀：隨著公司業(yè)務的快速發(fā)展，離線計算集群規(guī)模和提交的作業(yè)量持續(xù)增長，如何支撐超大規(guī)模集群，如何滿足不同場景的調度需求成為必須要解決的問題。基于以上問題，快手大數(shù)據(jù)團隊基于YARN做了大量的定制和優(yōu)化，支撐了不同場景下的資源調度需求。
今天的介紹會圍繞下面四點展開：
-
調度相關背景及快手數(shù)據(jù)規(guī)模與場景
-
快手調度器Kwai scheduler介紹
-
多調度場景優(yōu)化介紹
-
其他工作&未來規(guī)劃
1. 快手數(shù)據(jù)規(guī)模
目前快手離線計算單集群數(shù)萬臺機器，每日處理數(shù)百P數(shù)據(jù)量，百萬級別作業(yè)，對大數(shù)據(jù)存儲，計算，調度有非常大的挑戰(zhàn)。首先介紹下快手大數(shù)據(jù)架構體系技術棧。
2. 快手大數(shù)據(jù)體系架構介紹
快手大數(shù)據(jù)架構底層采用hdfs/hbase構建數(shù)據(jù)存儲層，用于支撐海量數(shù)據(jù)的存儲；上層是YARN資源調度層，實現(xiàn)百萬級別的作業(yè)和任務調度；再上層是各種計算引擎構成的執(zhí)行層，如Flink、MR、SPARK，PRESTO，TensorFlow等計算框架用于執(zhí)行業(yè)務的計算任務，最上層屬于應用層如FLink作業(yè)托管平臺，機器學習平臺，以及SQL提交平臺，面向用戶提供服務。本次分享的YARN屬于資源調度層，用于把計算引擎的Task快速調度到合適的機器上。
3. YARN資源調度系統(tǒng)介紹
YARN背景介紹：
YARN是Apache Hadoop旗下的頂級項目，Hadoop 2.0發(fā)布時引入，主要用于解決hadoop1.0面臨的集群調度性能和擴展性問題。通過把集群資源管理和作業(yè)資源管理拆分成ResourceManager和ApplicationMaster兩個組件，實現(xiàn)調度架構從單級架構向二級架構的轉變，提升了集群性能。YARN專注于集群資源管理和調度，包含ResourceManager和NodeManager兩個核心組件；ResourceManager負責集群資源管理和分配；NodeManager在每臺機器上部署，負責管理所在機器上資源。
YARN調度器演進過程：
原生YARN在調度過程中，先選擇一個節(jié)點，并對隊列進行排序，遞歸從root隊列找到最優(yōu)的葉子隊列，再對葉子隊列中運行的app進行排序，選出app在這個節(jié)點上調度資源。隨著集群規(guī)模增長和隊列數(shù)目的增加，調度耗時越來越長，調度吞吐成為制約集群規(guī)模的主要瓶頸。為提升調度吞吐，調度器的發(fā)展經(jīng)歷了三個階段：第一階段通過心跳觸發(fā)調度過程，實現(xiàn)比較簡單，但心跳處理邏輯和調度邏輯在同一個線程，調度和心跳處理邏輯會相互影響。第二階段將調度邏輯剝離到單獨的線程以降低調度和心跳邏輯耦合性，從而提升了調度性能；但調度邏輯和心跳處理共享一把大鎖，并且調度過程中對隊列排序占據(jù)大量時間，整體性能提升有限。第三階段引入全局調度器的概念，可以并發(fā)對隊列資源進行調度，最終通過統(tǒng)一的commit過程保證調度結果一致性。多線程并發(fā)調度可以提升調度性能，但沒有解決調度過程中排序耗時過多問題，并且引入的多線程調度，會損害調度結果的公平性。
快手基于fair scheduler 單線程調度版本，不斷優(yōu)化單線程調度的性能，但由于單線程調度的局限性，在集群節(jié)點接近萬臺規(guī)模時，集群性能出現(xiàn)瓶頸；上線自研的kwai scheduler調度器后，在集群調度性能上有極大的提升，目前單集群規(guī)模已達數(shù)萬臺，同時在調度策略方面，支持可插拔的調度架構，方便擴展新的調度策略。
kwai scheduler主要用于解決調度性能問題以及調度策略擴展性問題。性能方面，傳統(tǒng)的調度器一次只能調度一個task，并且在調度過程中需要對所有隊列以及APP進行排序，有很大的資源開銷；kwai scheduler采用多線程并發(fā)批量調度模式，一輪可以調度數(shù)十萬個task。在調度策略方面，傳統(tǒng)的調度器先選擇節(jié)點再選擇APP，難以擴充新調度策略。kwai scheduler先選擇 APP再選擇節(jié)點，從而APP可以看到所有節(jié)點信息，通過對節(jié)點進行過濾與打分排序，可以針對不同場景擴展不同的調度策略。
1. 基于集群狀態(tài)做全局批量調度
Kwai scheduler整體架構如上圖所示，ResouceManager中RPC層和事件處理層基本保持不變，主要改動點是將調度邏輯做一個整體的剝離替換原先的fair scheduler調度。每次調度過程中拉取集群狀態(tài)做鏡像，基于集群鏡像并發(fā)批量調度，調度完成后，將調度結果推送回去。App可以通過原有的心跳接口獲取調度container。
2. Kwai scheduler 調度流程
Kwai scheduler 基于集群鏡像（節(jié)點的資源使用情況；隊列的最小資源和最大資源量，以及當前資源使用量，APP資源使用量和資源需求量等）進行資源的預分配，計算出每個APP可以在這一輪調度中分配多少資源。APP根據(jù)預先分配到的資源量，并發(fā)去競爭節(jié)點上的空閑資源，如果競爭成功，完成APP的資源調度過程。
APP資源調度過程中，可以根據(jù)不同場景為 APP配置不同的調度策略，根據(jù)調度策略過濾節(jié)點并計算每個節(jié)點分數(shù)，選出分數(shù)最高節(jié)點嘗試進行資源分配。調度過程中基本都是CPU密集操作，避免了鎖的干擾（不同APP競爭節(jié)點資源時有輕量的自旋鎖），有非常高的性能。并且不同的APP可以多線程并發(fā)調度，具備很好的擴展性。
3. Kwai scheduler 調度策略
Kwai scheduler 調度策略主要實現(xiàn)filter和score接口。filter接口用于過濾節(jié)點，score根據(jù)節(jié)點信息，為節(jié)點進行打分，然后選出最優(yōu)節(jié)點進行調度。比如APP task打散策略，根據(jù)每個節(jié)點分配的APP資源量，對節(jié)點進行打分，節(jié)點上分配的APP資源量越多，節(jié)點分數(shù)越低，從而把APP的task在集群范圍內打散到不同的節(jié)點。
4. Kwai scheduler調度線上效果
Kwai scheduler 上線后，支撐單集群數(shù)萬臺機器，1萬+作業(yè)同時運行，每天調度吞吐量峰值5w/s+，資源分配率93%+，同時支持不同的調度場景。
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è)。
② 隊列內低優(yōu)先級作業(yè)占據(jù)大量資源不釋放
在生產(chǎn)場景下如果低優(yōu)先級作業(yè)占用大量資源不釋放，導致優(yōu)先級比較高的任務無法獲取到足夠資源，從而導致產(chǎn)出延遲。為解決這個問題提出基于虛擬隊列來保障高優(yōu)先級作業(yè)產(chǎn)出。所謂虛擬隊列，是在物理隊列下，按照一定邏輯規(guī)則（比如優(yōu)先級）抽象出的邏輯隊列。每個虛擬隊列有一定的資源配額，并且會觸發(fā)物理隊列內部的搶占，從而解決上面的問題。
③ 低優(yōu)先級作業(yè)占據(jù)app solt不釋放
為方便AppSlot資源的管理，抽象出minApp概念，如果App啟動時，隊列running App小于minApp，將會立刻啟動App，不會受限于父隊列的maxRunningApp，這樣在隊列層面保障有可預期的app slot。但同樣存在一個問題，隊列內部低優(yōu)先級作業(yè)占據(jù)大量AppSlot不釋放，導致高優(yōu)先級作業(yè)啟動延遲。為此提出了App Slot搶占功能。如下圖所示，如果發(fā)現(xiàn)高優(yōu)先級作業(yè)（P0）長時間pending不能啟動，掃描隊列內runningApp，選擇低優(yōu)先級作業(yè)進入睡眠模式（不再調度新task，極端情況下回收task）從而釋放出slot資源，保障高優(yōu)先級作業(yè)能及時啟動。
④ 回溯作業(yè)影響生產(chǎn)作業(yè)
回溯作業(yè)的特點在于大量提交多個作業(yè)，如果不加控制可能會影響生產(chǎn)作業(yè)的產(chǎn)出。主要方案是限制回溯作業(yè)最大資源量和最大運行APP數(shù)目，將影響控制在一定的范圍以內。但是限制最大資源量和運行數(shù)目導致大量回溯作業(yè)在yarn處于pending狀態(tài)，對yarn有比較大的壓力，通過與上游調度系統(tǒng)打通，反壓上層工作流調度系統(tǒng)，阻止新提交的回溯作業(yè)，從而減輕了YARN負載。對于已經(jīng)提交到y(tǒng)arn上的作業(yè)，會限制每個隊列最大pending app個數(shù)，從而保障總體pending app數(shù)目可控。
⑤ 高優(yōu)先級作業(yè)大塊資源請求不能及時滿足
原有的Reserve機制中，調度器可以reserve一批節(jié)點，不再調度新task，等待節(jié)點上自然釋放資源。如果被reserve節(jié)點資源長時間不釋放，如何處理？針對這個場景開發(fā)了reserve搶占功能，用于搶占reserve節(jié)點上的低優(yōu)先級的container，從而保障節(jié)點上有足夠的空閑資源啟動高優(yōu)先級作業(yè)。
⑥ 規(guī)避異常節(jié)點，避免核心作業(yè)長尾
通過采集節(jié)點物理指標，task失敗率，task運行速度，以及shuffle失敗率等，將此節(jié)點標記為異常節(jié)點，不再調度新Task。從而盡量減少異常節(jié)點的影響范圍，規(guī)避其導致的Task長尾，失敗問題。
2. Adhoc即時查詢場景
AdHoc場景主要著力于提升每個用戶的查詢體驗。
通過虛擬隊列技術，從user維度來劃分虛擬隊列，實現(xiàn)基于user公平的資源的分配，配合基于user的資源搶占，從而避免大量資源被某一個用戶占用，導致其他用戶長時間得不到資源。
3. 機器學習訓練場景
機器學習訓練場景下，資源需求呈現(xiàn)all or nothing特點，在隊列資源緊張時，如果基于yarn原生的公平調度方式，為每個app分配部分資源，容易產(chǎn)生資源分配死鎖問題。為此我們采用APP輪轉調度策略，采用類似FIFO策略，保障頭部APP（頭部會動態(tài)變化，輪轉策略名稱的由來）的資源需求，避免死鎖問題。
4. Flink實時作業(yè)場景
FLink實時場景下，主要介紹故障發(fā)生時，如何盡量減少故障的影響范圍，以及如何快速恢復故障作業(yè)：
-
通過cpu均衡調度，避免機器cpu熱點。
-
通過AM失敗節(jié)點規(guī)避機制，避免調度到AM失敗機器。
-
NM掛起（不調度新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è)恢復。
支持超大規(guī)模集群：
主要目標支撐十萬量級的集群規(guī)模，目前基于社區(qū)的federation方案進行改造。
Hadoop跨IDC集群建設：
受限于公司物理集群規(guī)劃，離線集群會分布在不同的IDC，如何基于有限的跨IDC帶寬，對數(shù)據(jù)和計算進行合理排布，是一個非常有挑戰(zhàn)的問題。
在離線資源混合部署：
基于在線機器的空閑資源運行離線任務，在資源調度和隔離方面有很多工作要做，目前已經(jīng)取得一定收益。
在離線資源統(tǒng)一管理：
目前YARN托管離線調度，k8s托管在線調度，如何讓資源更彈性更統(tǒng)一？我們也在做一些嘗試。
流shuffle服務建設：
shuffle過程產(chǎn)生大量大量的隨機IO，通過流shuffle服務接管MR和SPARK shuffle過程，將隨機IO轉變成順序IO，提升集群算力并減少在離線混部過程中IO影響。
大家如何有興趣或者疑問可以隨時聯(lián)系我，也歡迎考慮快手大數(shù)據(jù)架構的工作機會，一起解決更有挑戰(zhàn)的事兒。
今天的分享就到這里，謝謝大家。
免責聲明：本文內容由21ic獲得授權后發(fā)布，版權歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
