快手超大規模集羣調度優化實踐

圖片



導讀:隨着公司業務的快速發展,離線計算集羣規模和提交的做業量持續增加,如何支撐超大規模集羣,如何知足不一樣場景的調度需求成爲必需要解決的問題。基於以上問題,快手大數據團隊基於YARN作了大量的定製和優化,支撐了不一樣場景下的資源調度需求。多線程

今天的介紹會圍繞下面四點展開:架構

  • 調度相關背景及快手數據規模與場景併發

  • 快手調度器Kwai scheduler介紹app

  • 多調度場景優化介紹框架

  • 其餘工做&將來規劃機器學習

01快手數據規模場景ide

1. 快手數據規模oop

目前快手離線計算單集羣數萬臺機器,每日處理數百P數據量,百萬級別做業,對大數據存儲,計算,調度有很是大的挑戰。首先介紹下快手大數據架構體系技術棧。性能

2. 快手大數據體系架構介紹學習

圖片

快手大數據架構底層採用hdfs/hbase構建數據存儲層,用於支撐海量數據的存儲;上層是YARN資源調度層,實現百萬級別的做業和任務調度;再上層是各類計算引擎構成的執行層,如Flink、MR、SPARK,PRESTO,TensorFlow等計算框架用於執行業務的計算任務,最上層屬於應用層如FLink做業託管平臺,機器學習平臺,以及SQL提交平臺,面向用戶提供服務。本次分享的YARN屬於資源調度層,用於把計算引擎的Task快速調度到合適的機器上。

3. YARN資源調度系統介紹

YARN背景介紹:

圖片

YARN是Apache Hadoop旗下的頂級項目,Hadoop 2.0發佈時引入,主要用於解決hadoop1.0面臨的集羣調度性能和擴展性問題。經過把集羣資源管理和做業資源管理拆分紅ResourceManager和ApplicationMaster兩個組件,實現調度架構從單級架構向二級架構的轉變,提高了集羣性能。YARN專一於集羣資源管理和調度,包含ResourceManager和NodeManager兩個核心組件;ResourceManager負責集羣資源管理和分配;NodeManager在每臺機器上部署,負責管理所在機器上資源。

YARN調度器演進過程:

圖片

原生YARN在調度過程當中,先選擇一個節點,並對隊列進行排序,遞歸從root隊列找到最優的葉子隊列,再對葉子隊列中運行的app進行排序,選出app在這個節點上調度資源。隨着集羣規模增加和隊列數目的增長,調度耗時愈來愈長,調度吞吐成爲制約集羣規模的主要瓶頸。爲提高調度吞吐,調度器的發展經歷了三個階段:第一階段經過心跳觸發調度過程,實現比較簡單,但心跳處理邏輯和調度邏輯在同一個線程,調度和心跳處理邏輯會相互影響。第二階段將調度邏輯剝離到單獨的線程以下降調度和心跳邏輯耦合性,從而提高了調度性能;但調度邏輯和心跳處理共享一把大鎖,而且調度過程當中對隊列排序佔據大量時間,總體性能提高有限。第三階段引入全局調度器的概念,能夠併發對隊列資源進行調度,最終經過統一的commit過程保證調度結果一致性。多線程併發調度能夠提高調度性能,但沒有解決調度過程當中排序耗時過多問題,而且引入的多線程調度,會損害調度結果的公平性。

快手基於fair scheduler 單線程調度版本,不斷優化單線程調度的性能,但因爲單線程調度的侷限性,在集羣節點接近萬臺規模時,集羣性能出現瓶頸;上線自研的kwai scheduler調度器後,在集羣調度性能上有極大的提高,目前單集羣規模已達數萬臺,同時在調度策略方面,支持可插拔的調度架構,方便擴展新的調度策略。

02Kwai scheduler調度器介紹

kwai scheduler主要用於解決調度性能問題以及調度策略擴展性問題。性能方面,傳統的調度器一次只能調度一個task,而且在調度過程當中須要對全部隊列以及APP進行排序,有很大的資源開銷;kwai scheduler採用多線程併發批量調度模式,一輪能夠調度數十萬個task。在調度策略方面,傳統的調度器先選擇節點再選擇APP,難以擴充新調度策略。kwai scheduler先選擇 APP再選擇節點,從而APP能夠看到全部節點信息,經過對節點進行過濾與打分排序,能夠針對不一樣場景擴展不一樣的調度策略。

1. 基於集羣狀態作全局批量調度

圖片

Kwai scheduler總體架構如上圖所示,ResouceManager中RPC層和事件處理層基本保持不變,主要改動點是將調度邏輯作一個總體的剝離替換原先的fair scheduler調度。每次調度過程當中拉取集羣狀態作鏡像,基於集羣鏡像併發批量調度,調度完成後,將調度結果推送回去。App能夠經過原有的心跳接口獲取調度container。

2. Kwai scheduler 調度流程

圖片

Kwai scheduler 基於集羣鏡像(節點的資源使用狀況;隊列的最小資源和最大資源量,以及當前資源使用量,APP資源使用量和資源需求量等)進行資源的預分配,計算出每一個APP能夠在這一輪調度中分配多少資源。APP根據預先分配到的資源量,併發去競爭節點上的空閒資源,若是競爭成功,完成APP的資源調度過程。

APP資源調度過程當中,能夠根據不一樣場景爲 APP配置不一樣的調度策略,根據調度策略過濾節點並計算每一個節點分數,選出分數最高節點嘗試進行資源分配。調度過程當中基本都是CPU密集操做,避免了鎖的干擾(不一樣APP競爭節點資源時有輕量的自旋鎖),有很是高的性能。而且不一樣的APP能夠多線程併發調度,具有很好的擴展性。

3. Kwai scheduler 調度策略

圖片

Kwai scheduler 調度策略主要實現filter和score接口。filter接口用於過濾節點,score根據節點信息,爲節點進行打分,而後選出最優節點進行調度。好比APP task打散策略,根據每一個節點分配的APP資源量,對節點進行打分,節點上分配的APP資源量越多,節點分數越低,從而把APP的task在集羣範圍內打散到不一樣的節點。

4. Kwai scheduler調度線上效果

Kwai scheduler 上線後,支撐單集羣數萬臺機器,1萬+做業同時運行,天天調度吞吐量峯值5w/s+,資源分配率93%+,同時支持不一樣的調度場景。

03調度場景優化

1. 離線ETL場景

離線場景下如何保障核心做業的SLA是比較核心的問題。在快手,核心做業和普通做業在同一個隊列中,經過完善做業分級保障能力和異常節點規避能力,保障核心做業的SLA。

離線ETL場景中常常會遇到如下狀況以及相應的優化方案:

① 其餘隊列做業大量佔據資源不釋放

經過優化隊列間資源搶佔來解決這個問題。爲防止搶佔影響過大,默認狀況下只有高優先級核心做業觸發搶佔,而且會限制每輪搶佔的最大資源量。搶佔過程當中根據做業優先級,飢餓等待時間等條件動態計算每一個隊列能夠搶佔的資源量,從而把資源傾斜給優先級更高,飢餓等待時間更長的做業。

② 隊列內低優先級做業佔據大量資源不釋放

在生產場景下若是低優先級做業佔用大量資源不釋放,致使優先級比較高的任務沒法獲取到足夠資源,從而致使產出延遲。爲解決這個問題提出基於虛擬隊列來保障高優先級做業產出。所謂虛擬隊列,是在物理隊列下,按照必定邏輯規則(好比優先級)抽象出的邏輯隊列。每一個虛擬隊列有必定的資源配額,而且會觸發物理隊列內部的搶佔,從而解決上面的問題。

③ 低優先級做業佔據app solt不釋放

爲方便AppSlot資源的管理,抽象出minApp概念,若是App啓動時,隊列running App小於minApp,將會馬上啓動App,不會受限於父隊列的maxRunningApp,這樣在隊列層面保障有可預期的app slot。但一樣存在一個問題,隊列內部低優先級做業佔據大量AppSlot不釋放,致使高優先級做業啓動延遲。爲此提出了App Slot搶佔功能。以下圖所示,若是發現高優先級做業(P0)長時間pending不能啓動,掃描隊列內runningApp,選擇低優先級做業進入睡眠模式(再也不調度新task,極端狀況下回收task)從而釋放出slot資源,保障高優先級做業能及時啓動。

圖片

④ 回溯做業影響生產做業

回溯做業的特色在於大量提交多個做業,若是不加控制可能會影響生產做業的產出。主要方案是限制回溯做業最大資源量和最大運行APP數目,將影響控制在必定的範圍之內。可是限制最大資源量和運行數目致使大量回溯做業在yarn處於pending狀態,對yarn有比較大的壓力,經過與上游調度系統打通,反壓上層工做流調度系統,阻止新提交的回溯做業,從而減輕了YARN負載。對於已經提交到yarn上的做業,會限制每一個隊列最大pending app個數,從而保障整體pending app數目可控。

⑤ 高優先級做業大塊資源請求不能及時知足

原有的Reserve機制中,調度器能夠reserve一批節點,再也不調度新task,等待節點上天然釋放資源。若是被reserve節點資源長時間不釋放,如何處理?針對這個場景開發了reserve搶佔功能,用於搶佔reserve節點上的低優先級的container,從而保障節點上有足夠的空閒資源啓動高優先級做業。

⑥ 規避異常節點,避免核心做業長尾

經過採集節點物理指標,task失敗率,task運行速度,以及shuffle失敗率等,將此節點標記爲異常節點,再也不調度新Task。從而儘可能減小異常節點的影響範圍,規避其致使的Task長尾,失敗問題。

2. Adhoc即時查詢場景

AdHoc場景主要着力於提高每一個用戶的查詢體驗。

經過虛擬隊列技術,從user維度來劃分虛擬隊列,實現基於user公平的資源的分配,配合基於user的資源搶佔,從而避免大量資源被某一個用戶佔用,致使其餘用戶長時間得不到資源。

圖片

3. 機器學習訓練場景

機器學習訓練場景下,資源需求呈現all or nothing特色,在隊列資源緊張時,若是基於yarn原生的公平調度方式,爲每一個app分配部分資源,容易產生資源分配死鎖問題。爲此咱們採用APP輪轉調度策略,採用相似FIFO策略,保障頭部APP(頭部會動態變化,輪轉策略名稱的由來)的資源需求,避免死鎖問題。

4. Flink實時做業場景

FLink實時場景下,主要介紹故障發生時,如何儘可能減小故障的影響範圍,以及如何快速恢復故障做業:

  • 經過cpu均衡調度,避免機器cpu熱點。

  • 經過AM失敗節點規避機制,避免調度到AM失敗機器。

  • NM掛起(不調度新Task,介於RUNNING和LOST狀態)機制,防止NM異常退出致使Task失敗。

  • 基於Hawk秒級發現節點宕機,快速進行做業恢復。

圖片

雖然能夠基於Hawk秒級發現節點宕機,但做業恢復過程可能須要幾分鐘(申請資源,下載jar包,job recover等)。咱們經過資源冗餘分配策略,優化掉其中資源申請和下載jar包過程,最終實現秒級做業恢復。

04其餘工做&將來規劃

支持超大規模集羣:

主要目標支撐十萬量級的集羣規模,目前基於社區的federation方案進行改造。

Hadoop跨IDC集羣建設:

受限於公司物理集羣規劃,離線集羣會分佈在不一樣的IDC,如何基於有限的跨IDC帶寬,對數據和計算進行合理排布,是一個很是有挑戰的問題。

在離線資源混合部署:

基於在線機器的空閒資源運行離線任務,在資源調度和隔離方面有不少工做要作,目前已經取得必定收益。

在離線資源統一管理:

目前YARN託管離線調度,k8s託管在線調度,如何讓資源更彈性更統一?咱們也在作一些嘗試。

流shuffle服務建設:

shuffle過程產生大量大量的隨機IO,經過流shuffle服務接管MR和SPARK shuffle過程,將隨機IO轉變成順序IO,提高集羣算力並減小在離線混部過程當中IO影響。

你們如何有興趣或者疑問能夠隨時聯繫我,也歡迎考慮快手大數據架構的工做機會,一塊兒解決更有挑戰的事兒。

今天的分享就到這裏,謝謝你們。

相關文章
相關標籤/搜索