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