背景

YARN作為Hadoop的資源管理系統(tǒng)，負(fù)責(zé)Hadoop集群上計(jì)算資源的管理和作業(yè)調(diào)度。

美團(tuán)的YARN以社區(qū)2.7.1版本為基礎(chǔ)構(gòu)建分支。目前在YARN上支撐離線業(yè)務(wù)、實(shí)時(shí)業(yè)務(wù)以及機(jī)器學(xué)習(xí)業(yè)務(wù)。

• 離線業(yè)務(wù)主要運(yùn)行的是Hive on MapReduce， Spark SQL為主的數(shù)據(jù)倉庫作業(yè)。
• 實(shí)時(shí)業(yè)務(wù)主要運(yùn)行Spark Streaming，F(xiàn)link為主的實(shí)時(shí)流計(jì)算作業(yè)。
• 機(jī)器學(xué)習(xí)業(yè)務(wù)主要運(yùn)行TensorFlow，MXNet，MLX(美團(tuán)點(diǎn)評(píng)自研的大規(guī)模機(jī)器學(xué)習(xí)系統(tǒng))等計(jì)算作業(yè)。

YARN面臨高可用、擴(kuò)展性、穩(wěn)定性的問題很多。其中擴(kuò)展性上遇到的最嚴(yán)重的，是集群和業(yè)務(wù)規(guī)模增長帶來的調(diào)度器性能問題。從業(yè)務(wù)角度來看，假設(shè)集群1000臺(tái)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)提供100個(gè)CPU的計(jì)算能力。每個(gè)任務(wù)使用1個(gè)CPU，平均執(zhí)行時(shí)間1分鐘。集群在高峰期始終有超過10萬CPU的資源需求。集群的調(diào)度器平均每分鐘只能調(diào)度5萬的任務(wù)。從分鐘級(jí)別觀察，集群資源使用率是50000/(100*1000)=0.5，那么集群就有50%的計(jì)算資源因?yàn)檎{(diào)度能力的問題而無法使用。

隨著集群規(guī)模擴(kuò)大以及業(yè)務(wù)量的增長，集群調(diào)度能力會(huì)隨著壓力增加而逐漸下降。假設(shè)調(diào)度能力依然保持不變，每分鐘調(diào)度5萬個(gè)任務(wù)，按照5000臺(tái)節(jié)點(diǎn)的規(guī)模計(jì)算，如果不做任何優(yōu)化改進(jìn)，那么集群資源使用率為：50000/(100*5000) = 10%，剩余的90%的機(jī)器資源無法被利用起來。

這個(gè)問題解決后，集群在有空余資源的情況下，作業(yè)資源需求可以快速得到滿足，集群的計(jì)算資源得到充分地利用。

下文會(huì)逐步將Hadoop YARN調(diào)度系統(tǒng)的核心模塊展開說明，揭開上述性能問題的根本原因，提出系統(tǒng)化的解決方案，最終Hadoop YARN達(dá)到支撐單集群萬級(jí)別節(jié)點(diǎn)，支持并發(fā)運(yùn)行數(shù)萬作業(yè)的調(diào)度能力。

整體架構(gòu)

YARN架構(gòu)

YARN負(fù)責(zé)作業(yè)資源調(diào)度，在集群中找到滿足業(yè)務(wù)的資源，幫助作業(yè)啟動(dòng)任務(wù)，管理作業(yè)的生命周期。

資源抽象

YARN在cpu，memory這兩個(gè)資源維度對(duì)集群資源做了抽象。 

class Resource{ 
  int cpu;   //cpu核心個(gè)數(shù) 
  int memory-mb; //內(nèi)存的MB數(shù) 
} 

作業(yè)向YARN申請(qǐng)資源的請(qǐng)求是：List[ResourceRequest] 

class ResourceRequest{ 
  int numContainers; //需要的container個(gè)數(shù) 
  Resource capability;//每個(gè)container的資源 
} 

YARN對(duì)作業(yè)響應(yīng)是：List[Container] 

class Container{ 
  ContainerId containerId; //YARN全局唯一的container標(biāo)示 
  Resource capability;  //該container的資源信息 
  String nodeHttpAddress; //該container可以啟動(dòng)的NodeManager的hostname 
} 

YARN調(diào)度架構(gòu) 

名詞解釋

• ResourceScheduler是YARN的調(diào)度器，負(fù)責(zé)Container的分配。
• AsyncDispatcher是單線程的事件分發(fā)器，負(fù)責(zé)向調(diào)度器發(fā)送調(diào)度事件。
• ResourceTrackerService是資源跟蹤服務(wù)，主要負(fù)責(zé)接收處理NodeManager的心跳信息。
• ApplicationMasterService是作業(yè)的RPC服務(wù)，主要負(fù)責(zé)接收處理作業(yè)的心跳信息。
• AppMaster是作業(yè)的程序控制器，負(fù)責(zé)跟YARN交互獲取/釋放資源。

調(diào)度流程

1. 作業(yè)資源申請(qǐng)過程：AppMaster通過心跳告知YARN資源需求(List[ResourceRequest])，并取回上次心跳之后，調(diào)度器已經(jīng)分配好的資源(List[Container])。
2. 調(diào)度器分配資源流程是：Nodemanager心跳觸發(fā)調(diào)度器為該NodeManager分配Container。

資源申請(qǐng)和分配是異步進(jìn)行的。ResourceScheduler是抽象類，需要自行實(shí)現(xiàn)。社區(qū)實(shí)現(xiàn)了公平調(diào)度器(FairScheduler)和容量調(diào)度器(CapacityScheduler)。美團(tuán)點(diǎn)評(píng)根據(jù)自身的業(yè)務(wù)模式的特點(diǎn)，采用的是公平調(diào)度器。

公平調(diào)度器

作業(yè)的組織方式

在公平調(diào)度器中，作業(yè)(App)是掛載如下圖的樹形隊(duì)列的葉子。 

隊(duì)列結(jié)構(gòu)

核心調(diào)度流程 

1. 調(diào)度器鎖住FairScheduler對(duì)象，避免核心數(shù)據(jù)結(jié)構(gòu)沖突。
2. 調(diào)度器選取集群的一個(gè)節(jié)點(diǎn)(node)，從樹形隊(duì)列的根節(jié)點(diǎn)ROOT開始出發(fā)，每層隊(duì)列都會(huì)按照公平策略選擇一個(gè)子隊(duì)列，最后在葉子隊(duì)列按照公平策略選擇一個(gè)App，為這個(gè)App在node上找一塊適配的資源。

對(duì)于每層隊(duì)列進(jìn)行如下流程：

1. 隊(duì)列預(yù)先檢查：檢查隊(duì)列的資源使用量是否已經(jīng)超過了隊(duì)列的Quota
2. 排序子隊(duì)列/App：按照公平調(diào)度策略，對(duì)子隊(duì)列/App進(jìn)行排序
3. 遞歸調(diào)度子隊(duì)列/App

例如，某次調(diào)度的路徑是ROOT -> ParentQueueA -> LeafQueueA1 -> App11，這次調(diào)度會(huì)從node上給App11分配Container。

偽代碼 

class FairScheduler{ 
  /* input：NodeId 
   *  output：Resource 表示分配出來的某個(gè)app的一個(gè)container的資源量 
   *  root 是樹形隊(duì)列Queue的根 
   */ 
  synchronized Resource attemptScheduling(NodeId node){ 
    root.assignContainer(NodeId); 
  } 
} 
 
class Queue{ 
  Resource assignContainer(NodeId node){ 
    if(! preCheck(node) ) return;  //預(yù)先檢查 
      sort(this.children);  //排序 
    if(this.isParent){ 
      for(Queue q: this.children) 
        q.assignContainer(node);  //遞歸調(diào)用 
    }else{ 
      for(App app: this.runnableApps) 
        app.assignContainer(node); 
    } 
  } 
} 
 
class App{ 
  Resource assignContainer(NodeId node){ 
    ...... 
  } 
} 

公平調(diào)度器架構(gòu)

公平調(diào)度器是一個(gè)多線程異步協(xié)作的架構(gòu)，而為了保證調(diào)度過程中數(shù)據(jù)的一致性，在主要的流程中加入了FairScheduler對(duì)象鎖。其中核心調(diào)度流程是單線程執(zhí)行的。這意味著Container分配是串行的，這是調(diào)度器存在性能瓶頸的核心原因。 

• scheduler Lock：FairScheduler對(duì)象鎖
• AllocationFileLoaderService：負(fù)責(zé)公平策略配置文件的熱加載，更新隊(duì)列數(shù)據(jù)結(jié)構(gòu)
• Continuous Scheduling Thread：核心調(diào)度線程，不停地執(zhí)行上節(jié)的核心調(diào)度流程
• Update Thread：更新隊(duì)列資源需求，執(zhí)行Container搶占流程等
• Scheduler Event Dispatcher Thread: 調(diào)度器事件的處理器，處理App新增，App結(jié)束，node新增，node移除等事件

性能評(píng)估

上文介紹了公平調(diào)度器的架構(gòu)，在大規(guī)模的業(yè)務(wù)壓力下，這個(gè)系統(tǒng)存在性能問題。從應(yīng)用層的表現(xiàn)看，作業(yè)資源需求得不到滿足。從系統(tǒng)模塊看，多個(gè)模塊協(xié)同工作，每個(gè)模塊多多少少都存在性能問題。如何評(píng)估系統(tǒng)性能已經(jīng)可以滿足線上業(yè)務(wù)的需求?如何評(píng)估系統(tǒng)的業(yè)務(wù)承載能力?我們需要找到一個(gè)系統(tǒng)的性能目標(biāo)。因此在談性能優(yōu)化方案之前，需要先說一說調(diào)度系統(tǒng)性能評(píng)估方法。

一般來說，在線業(yè)務(wù)系統(tǒng)的性能是用該系統(tǒng)能夠承載的QPS和響應(yīng)的TP99的延遲時(shí)間來評(píng)估，而調(diào)度系統(tǒng)與在線業(yè)務(wù)系統(tǒng)不同的是：調(diào)度系統(tǒng)的性能不能用RPC(ResourceManager接收NodeManager和AppMaster的RPC請(qǐng)求)的響應(yīng)延遲來評(píng)估。原因是：這些RPC調(diào)用過程跟調(diào)度系統(tǒng)的調(diào)度過程是異步的，因此不論調(diào)度性能多么差，RPC響應(yīng)幾乎不受影響。同理，不論RPC響應(yīng)多么差，調(diào)度性能也幾乎不受影響。

業(yè)務(wù)指標(biāo)-有效調(diào)度

首先從滿足業(yè)務(wù)需求角度分析調(diào)度系統(tǒng)的業(yè)務(wù)指標(biāo)。調(diào)度系統(tǒng)的業(yè)務(wù)目標(biāo)是滿足業(yè)務(wù)資源需求。指標(biāo)是：有效調(diào)度(validSchedule)。在生產(chǎn)環(huán)境，只要validSchedule達(dá)標(biāo)，我們就認(rèn)為目前調(diào)度器是滿足線上業(yè)務(wù)需求的。

定義validSchedulePerMin表示某一分鐘的調(diào)度性能達(dá)標(biāo)的情況。達(dá)標(biāo)值為1，不達(dá)標(biāo)值為0。 

validPending = min(queuePending, QueueMaxQuota) 
if  (usage / total  > 90% || validPending == 0):   validSchedulePerMin = 1 //集群資源使用率高于90%，或者集群有效資源需求為0，這時(shí)調(diào)度器性能達(dá)標(biāo)。 
if (validPending > 0 &&  usage / total < 90%) : validSchedulePerMin = 0;//集群資源使用率低于90%，并且集群存在有效資源需求，這時(shí)調(diào)度器性能不達(dá)標(biāo)。 

• validPending表示集群中作業(yè)有效的資源需求量
• queuePending表示隊(duì)列中所有作業(yè)的資源需求量
• QueueMaxQuota表示該隊(duì)列資源最大限額
• usage表示集群已經(jīng)使用的資源量
• tatal表示集群總體資源

設(shè)置90%的原因是：資源池中的每個(gè)節(jié)點(diǎn)可能都有一小部分資源因?yàn)闊o法滿足任何的資源需求，出現(xiàn)的資源碎片問題。這個(gè)問題類似linux內(nèi)存的碎片問題。由于離線作業(yè)的任務(wù)執(zhí)行時(shí)間非常短，資源很快可以得到回收。在離線計(jì)算場(chǎng)景，調(diào)度效率的重要性遠(yuǎn)遠(yuǎn)大于更精確地管理集群資源碎片，因此離線調(diào)度策略暫時(shí)沒有考慮資源碎片的問題。

validSchedulePerDay表示調(diào)度性能每天的達(dá)標(biāo)率。 validSchedulePerDay = ΣvalidSchedulePerMin /1440

目前線上業(yè)務(wù)規(guī)模下，業(yè)務(wù)指標(biāo)如下： validSchedulePerMin > 0.9; validSchedulePerDay > 0.99

系統(tǒng)性能指標(biāo)-每秒調(diào)度Container數(shù)

調(diào)度系統(tǒng)的本質(zhì)是為作業(yè)分配Container，因此提出調(diào)度系統(tǒng)性能指標(biāo)CPS–每秒調(diào)度Container數(shù)。在生產(chǎn)環(huán)境，只要validSchedule達(dá)標(biāo)，表明目前調(diào)度器是滿足線上業(yè)務(wù)需求的。而在測(cè)試環(huán)境，需要關(guān)注不同壓力條件下的CPS，找到當(dāng)前系統(tǒng)承載能力的上限，并進(jìn)一步指導(dǎo)性能優(yōu)化工作。

CPS是與測(cè)試壓力相關(guān)的，測(cè)試壓力越大，CPS可能越低。從上文公平調(diào)度器的架構(gòu)可以看到，CPS跟如下信息相關(guān)：

• 集群總體資源數(shù);集群資源越多，集群可以并發(fā)運(yùn)行的的Container越多，對(duì)調(diào)度系統(tǒng)產(chǎn)生越大的調(diào)度壓力。目前每臺(tái)物理機(jī)的cpu、memory資源量差距不大，因此集群總體資源數(shù)主要看集群的物理機(jī)節(jié)點(diǎn)個(gè)數(shù)。
• 集群中正在運(yùn)行的App數(shù);作業(yè)數(shù)越多，需要調(diào)度的信息越多，調(diào)度壓力越大。
• 集群中的隊(duì)列個(gè)數(shù);隊(duì)列數(shù)越多，需要調(diào)度的信息越多，調(diào)度壓力越大。
• 集群中每個(gè)任務(wù)的執(zhí)行時(shí)間;任務(wù)執(zhí)行時(shí)間越短會(huì)導(dǎo)致資源釋放越快，那么動(dòng)態(tài)產(chǎn)生的空閑資源越多，對(duì)調(diào)度系統(tǒng)產(chǎn)生的壓力越大。

例如，集群1000個(gè)節(jié)點(diǎn)，同時(shí)運(yùn)行1000個(gè)App，這些App分布在500個(gè)Queue上，每個(gè)App的每個(gè)Container執(zhí)行時(shí)間是1分鐘。在這樣的壓力條件下，調(diào)度系統(tǒng)在有大量資源需求的情況下，每秒可以調(diào)度1000個(gè)Container。那么在這個(gè)條件下，調(diào)度系統(tǒng)的CPS是1000/s。

調(diào)度壓力模擬器

在線上環(huán)境中，我們可以通過觀察上文提到的調(diào)度系統(tǒng)的指標(biāo)來看當(dāng)前調(diào)度性能是否滿足業(yè)務(wù)需求。但我們做了一個(gè)性能優(yōu)化策略，不能直接到在線上環(huán)境去實(shí)驗(yàn)，因此我們必須有能力在線下環(huán)境驗(yàn)證調(diào)度器的性能是滿足業(yè)務(wù)需求的，之后才能把實(shí)驗(yàn)有效的優(yōu)化策略推廣到線上環(huán)境。

那我們?cè)诰€下也搭建一套跟線上規(guī)模一樣的集群，是否就可以進(jìn)行調(diào)度器性能優(yōu)化的分析和研究呢?理論上是可以的，但這需要大量的物理機(jī)資源，對(duì)公司來說是個(gè)巨大的成本。因此我們需要一個(gè)調(diào)度器的壓力模擬器，在不需要大量物理機(jī)資源的條件下，能夠模擬YARN的調(diào)度過程。

社區(qū)提供了開源調(diào)度器的壓力模擬工具–Scheduler Load Simulater(SLS)。 

如上圖，左側(cè)是開源SLS的架構(gòu)圖，整體都在一個(gè)進(jìn)程中，ResourceManager模塊里面有一個(gè)用線程模擬的Scheduler。App和NM(NodeManager)都是由線程模擬。作業(yè)資源申請(qǐng)和NM節(jié)點(diǎn)心跳采用方法調(diào)用。

開源架構(gòu)存在的問題有：

• 模擬大規(guī)模APP和NM需要開啟大量的線程，導(dǎo)致調(diào)度器線程和NM/App的模擬線程爭(zhēng)搶cpu資源，影響調(diào)度器的評(píng)估。
• SLS的Scheduler Wapper中加入了不合理的邏輯，嚴(yán)重影響調(diào)度器的性能。
• SLS為了通用性考慮，沒有侵入FairScheduler的調(diào)度過程獲取性能指標(biāo)，僅僅從外圍獲取了Queue資源需求，Queue資源使用量，App資源需求，App資源使用量等指標(biāo)。這些指標(biāo)都不是性能指標(biāo)，無法利用這些指標(biāo)分析系統(tǒng)性能瓶頸。

針對(duì)存在的問題，我們進(jìn)行了架構(gòu)改造。右側(cè)是改造后的架構(gòu)圖，從SLS中剝離Scheduler Wapper的模擬邏輯，用真實(shí)的ResourceManager代替。SLS僅僅負(fù)責(zé)模擬作業(yè)的資源申請(qǐng)和節(jié)點(diǎn)的心跳匯報(bào)。ResourceManager是真實(shí)的，線上生產(chǎn)環(huán)境和線下壓測(cè)環(huán)境暴露的指標(biāo)是完全一樣的，因此線上線下可以很直觀地進(jìn)行指標(biāo)對(duì)比。

細(xì)粒度監(jiān)控指標(biāo)

利用調(diào)度壓力模擬器進(jìn)行壓測(cè)，觀察到validSchedule不達(dá)標(biāo)，但依然不清楚性能瓶頸到底在哪里。因此需要細(xì)粒度指標(biāo)來確定性能的瓶頸點(diǎn)。由于調(diào)度過程是單線程的，因此細(xì)粒度指標(biāo)獲取的手段是侵入FairScheduler，在調(diào)度流程中采集關(guān)鍵函數(shù)每分鐘的時(shí)間消耗。目標(biāo)是找到花費(fèi)時(shí)間占比最多的函數(shù)，從而定位系統(tǒng)瓶頸。例如：在preCheck函數(shù)的前后加入時(shí)間統(tǒng)計(jì)，就可以收集到調(diào)度過程中preCheck消耗的時(shí)間。

基于以上的思路，我們定義了10多個(gè)細(xì)粒度指標(biāo)，比較關(guān)鍵的指標(biāo)有：

• 每分鐘父隊(duì)列preCheck時(shí)間
• 每分鐘父隊(duì)列排序時(shí)間
• 每分鐘子隊(duì)列preCheck時(shí)間
• 每分鐘子隊(duì)列排序時(shí)間
• 每分鐘為作業(yè)分配資源的時(shí)間
• 每分鐘因?yàn)樽鳂I(yè)無資源需求而花費(fèi)的時(shí)間

關(guān)鍵優(yōu)化點(diǎn)

第一次做壓測(cè)，給定的壓力就是當(dāng)時(shí)線上生產(chǎn)環(huán)境峰值的壓力情況(1000節(jié)點(diǎn)、1000作業(yè)并發(fā)、500隊(duì)列、單Container執(zhí)行時(shí)間40秒)。經(jīng)過優(yōu)化后，調(diào)度器性能提升，滿足業(yè)務(wù)需求，之后通過預(yù)估業(yè)務(wù)規(guī)模增長來調(diào)整測(cè)試壓力，反復(fù)迭代地進(jìn)行優(yōu)化工作。

下圖是性能優(yōu)化時(shí)間線，縱軸為調(diào)度性能CPS。 

優(yōu)化排序比較函數(shù)

在核心調(diào)度流程中，第2步是排序子隊(duì)列。觀察細(xì)粒度指標(biāo)，可以很清楚地看到每分鐘調(diào)度流程總共用時(shí)50秒，其中排序時(shí)間占用了30秒，占了最大比例，因此首先考慮優(yōu)化排序時(shí)間。

排序本身用的快速排序算法，已經(jīng)沒有優(yōu)化空間。進(jìn)一步分析排序比較函數(shù)，發(fā)現(xiàn)排序比較函數(shù)的時(shí)間復(fù)雜度非常高。

計(jì)算復(fù)雜度最高的部分是：需要獲取隊(duì)列/作業(yè)的資源使用情況(resourceUsage)。原算法中，每2個(gè)隊(duì)列進(jìn)行比較，需要獲取resourceUsage的時(shí)候，程序都是現(xiàn)場(chǎng)計(jì)算。計(jì)算方式是遞歸累加該隊(duì)列下所有作業(yè)的resourceUsage。這造成了巨大的重復(fù)計(jì)算量。

優(yōu)化策略：將現(xiàn)場(chǎng)計(jì)算優(yōu)化為提前計(jì)算。

提前計(jì)算算法：當(dāng)為某個(gè)App分配了一個(gè)Container(資源量定義為containerResource)，那么遞歸調(diào)整父隊(duì)列的resourceUsage，讓父隊(duì)列的resourceUsage += containerResource。當(dāng)釋放某個(gè)App的一個(gè)Container，同樣的道理，讓父隊(duì)列resourceUsage -= containerResource。 利用提前計(jì)算算法，隊(duì)列resourceUsage的統(tǒng)計(jì)時(shí)間復(fù)雜度降低到O(1)。

優(yōu)化效果：排序相關(guān)的細(xì)粒度指標(biāo)耗時(shí)明顯下降。 

紅框中的指標(biāo)表示每分鐘調(diào)度器用來做隊(duì)列/作業(yè)排序的時(shí)間。從圖中可以看出，經(jīng)過優(yōu)化，排序時(shí)間從每分鐘30G(30秒)下降到5G(5秒)以內(nèi)。

優(yōu)化作業(yè)跳過時(shí)間

從上圖看，優(yōu)化排序比較函數(shù)后，藍(lán)色的線有明顯的增加，從2秒增加到了20秒。這條藍(lán)線指標(biāo)含義是每分鐘調(diào)度器跳過沒有資源需求的作業(yè)花費(fèi)的時(shí)間。從時(shí)間占比角度來看，目前優(yōu)化目標(biāo)是減少這條藍(lán)線的時(shí)間。

分析代碼發(fā)現(xiàn)，所有隊(duì)列/作業(yè)都會(huì)參與調(diào)度。但其實(shí)很多隊(duì)列/作業(yè)根本沒有資源需求，并不需要參與調(diào)度。因此優(yōu)化策略是：在排序之前，從隊(duì)列的Children中剔除掉沒有資源需求的隊(duì)列/作業(yè)。

優(yōu)化效果：這個(gè)指標(biāo)從20秒下降到幾乎可以忽略不計(jì)。詳細(xì)代碼參考：YARN-3547 

這時(shí)，從上圖中可以明顯看到有一條線呈現(xiàn)上升趨勢(shì)，并且這個(gè)指標(biāo)占了整個(gè)調(diào)度時(shí)間的最大比例。這條線對(duì)應(yīng)的指標(biāo)含義是確定要調(diào)度的作業(yè)后，調(diào)度器為這個(gè)作業(yè)分配出一個(gè)Container花費(fèi)的時(shí)間。這部分邏輯平均執(zhí)行一次的時(shí)間在0.02ms以內(nèi)，并且不會(huì)隨著集群規(guī)模、作業(yè)規(guī)模的增加而增加,因此暫時(shí)不做進(jìn)一步優(yōu)化。

隊(duì)列并行排序優(yōu)化

從核心調(diào)度流程可以看出，分配每一個(gè)Container，都需要進(jìn)行隊(duì)列的排序。排序的時(shí)間會(huì)隨著業(yè)務(wù)規(guī)模增加(作業(yè)數(shù)、隊(duì)列數(shù)的增加)而線性增加。

架構(gòu)思考：對(duì)于公平調(diào)度器來說，排序是為了實(shí)現(xiàn)公平的調(diào)度策略，但資源需求是時(shí)時(shí)刻刻變化的，每次變化，都會(huì)引起作業(yè)資源使用的不公平。即使分配每一個(gè)Container時(shí)都進(jìn)行排序，也無法在整個(gè)時(shí)間軸上達(dá)成公平策略。

例如，集群有10個(gè)cpu，T1時(shí)刻，集群只有一個(gè)作業(yè)App1在運(yùn)行，申請(qǐng)了10個(gè)cpu，那么集群會(huì)把這10個(gè)cpu都分配給App1。T2時(shí)刻(T2 > T1)，集群中新來一個(gè)作業(yè)App2，這時(shí)集群已經(jīng)沒有資源了，因此無法為App2分配資源。這時(shí)集群中App1和App2對(duì)資源的使用是不公平的。從這個(gè)例子看，僅僅通過調(diào)度的分配算法是無法在時(shí)間軸上實(shí)現(xiàn)公平調(diào)度。

目前公平調(diào)度器的公平策略是保證集群在某一時(shí)刻資源調(diào)度的公平。在整個(gè)時(shí)間軸上是需要搶占策略來補(bǔ)充達(dá)到公平的目標(biāo)。 因此從時(shí)間軸的角度考慮，沒有必要在分配每一個(gè)Container時(shí)都進(jìn)行排序。

綜上分析，優(yōu)化策略是排序過程與調(diào)度過程并行化。要點(diǎn)如下：

1. 調(diào)度過程不再進(jìn)行排序的步驟。
2. 獨(dú)立的線程池處理所有隊(duì)列的排序，其中每個(gè)線程處理一個(gè)隊(duì)列的排序。
3. 排序之前，通過深度克隆隊(duì)列/作業(yè)中用于排序部分的信息，保證排序過程中隊(duì)列/作業(yè)的數(shù)據(jù)結(jié)構(gòu)不變。 

優(yōu)化效果如下：

隊(duì)列排序效率：利用線程池對(duì)2000個(gè)隊(duì)列進(jìn)行一次排序只需要5毫秒以內(nèi)(2ms-5ms)，在一秒內(nèi)至少可以完成200次排序，對(duì)業(yè)務(wù)完全沒有影響。

在并行運(yùn)行1萬作業(yè)，集群1.2萬的節(jié)點(diǎn)，隊(duì)列個(gè)數(shù)2000，單Container執(zhí)行時(shí)間40秒的壓力下，調(diào)度CPS達(dá)到5萬，在一分鐘內(nèi)可以將整個(gè)集群資源打滿，并持續(xù)打滿。 

上圖中，15:26分，pending值是0，表示這時(shí)集群目前所有的資源需求已經(jīng)被調(diào)度完成。15:27分，resourceUsage達(dá)到1.0，表示集群資源使用率為100%，集群沒有空閑資源。pending值達(dá)到4M(400萬 mb的內(nèi)存需求)是因?yàn)闆]有空閑資源導(dǎo)致的資源等待。

穩(wěn)定上線的策略

線下壓測(cè)的結(jié)果非常好，最終要上到線上才能達(dá)成業(yè)務(wù)目標(biāo)。然而穩(wěn)定上線是有難度的，原因：

• 線上環(huán)境和線下壓測(cè)環(huán)境中的業(yè)務(wù)差別非常大。線下沒問題，上線不一定沒問題。
• 當(dāng)時(shí)YARN集群只有一個(gè)，那么調(diào)度器也只有一個(gè)，如果調(diào)度器出現(xiàn)異常，是整個(gè)集群的災(zāi)難，導(dǎo)致整個(gè)集群不可用。

除了常規(guī)的單元測(cè)試、功能測(cè)試、壓力測(cè)試、設(shè)置報(bào)警指標(biāo)之外，我們根據(jù)業(yè)務(wù)場(chǎng)景提出了針對(duì)集群調(diào)度系統(tǒng)的上線策略。

在線回滾策略

離線生產(chǎn)的業(yè)務(wù)高峰在凌晨，因此凌晨服務(wù)出現(xiàn)故障的概率是最大的。而凌晨RD同學(xué)接到報(bào)警電話，執(zhí)行通常的服務(wù)回滾流程(回滾代碼，重啟服務(wù))的效率是很低的。并且重啟期間，服務(wù)不可用，對(duì)業(yè)務(wù)產(chǎn)生了更長的不可用時(shí)間。因此我們針對(duì)調(diào)度器的每個(gè)優(yōu)化策略都有參數(shù)配置。只需要修改參數(shù)配置，執(zhí)行配置更新命令，那么在不重啟服務(wù)的情況下，就可以改變調(diào)度器的執(zhí)行邏輯，將執(zhí)行邏輯切換回優(yōu)化前的流程。

這里的關(guān)鍵問題是：系統(tǒng)通過配置加載線程更新了調(diào)度器某個(gè)參數(shù)的值，而調(diào)度線程也同時(shí)在按照這個(gè)參數(shù)值進(jìn)行工作。在一次調(diào)度過程中可能多次查看這個(gè)參數(shù)的值，并且根據(jù)參數(shù)值來執(zhí)行相應(yīng)的邏輯。調(diào)度線程在一次調(diào)度過程中觀察到的參數(shù)值發(fā)生變化，就會(huì)導(dǎo)致系統(tǒng)異常。

處理辦法是通過復(fù)制資源的方式，避免多線程共享資源引起數(shù)據(jù)不一致的問題。調(diào)度線程在每次調(diào)度開始階段，先將當(dāng)前所有性能優(yōu)化參數(shù)進(jìn)行復(fù)制，確保在本次調(diào)度過程中觀察到的參數(shù)不會(huì)變更。

數(shù)據(jù)自動(dòng)校驗(yàn)策略

優(yōu)化算法是為了提升性能，但要注意不能影響算法的輸出結(jié)果，確保算法正確性。對(duì)于復(fù)雜的算法優(yōu)化，確保算法正確性是一個(gè)很有難度的工作。

在“優(yōu)化排序比較時(shí)間”的研發(fā)中，變更了隊(duì)列resourceUsage的計(jì)算方法，從現(xiàn)場(chǎng)計(jì)算變更為提前計(jì)算。那么如何保證優(yōu)化后算法計(jì)算出來的resourceUsage是正確的呢?

即使做了單元策略，功能測(cè)試，壓力測(cè)試，但面對(duì)一個(gè)復(fù)雜系統(tǒng)，依然不能有100%的把握。 另外，未來系統(tǒng)升級(jí)也可能引起這部分功能的bug。

算法變更后，如果新的resourceUsage計(jì)算錯(cuò)誤，那么就會(huì)導(dǎo)致調(diào)度策略一直錯(cuò)誤執(zhí)行下去。從而影響隊(duì)列的資源分配。會(huì)對(duì)業(yè)務(wù)產(chǎn)生巨大的影響。例如，業(yè)務(wù)拿不到原本的資源量，導(dǎo)致業(yè)務(wù)延遲。

通過原先現(xiàn)場(chǎng)計(jì)算的方式得到的所有隊(duì)列的resourceUsage一定是正確的，定義為oldResourceUsage。 算法優(yōu)化后，通過提前計(jì)算的方式得到所有隊(duì)列的resourceUsage，定義為newResourceUsage。

在系統(tǒng)中，定期對(duì)oldResourceUsage和newResourceUsage進(jìn)行比較，如果發(fā)現(xiàn)數(shù)據(jù)不一致，說明優(yōu)化的算法有bug，newResourceUsage計(jì)算錯(cuò)誤。這時(shí)系統(tǒng)會(huì)向RD發(fā)送報(bào)警通知，同時(shí)自動(dòng)地將所有計(jì)算錯(cuò)誤的數(shù)據(jù)用正確的數(shù)據(jù)替換，使得錯(cuò)誤得到及時(shí)自動(dòng)修正。

總結(jié)與未來展望

本文主要介紹了美團(tuán)點(diǎn)評(píng)Hadoop YARN集群公平調(diào)度器的性能優(yōu)化實(shí)踐。

1. 做性能優(yōu)化，首先要定義宏觀的性能指標(biāo)，從而能夠評(píng)估系統(tǒng)的性能。
2. 定義壓測(cè)需要觀察的細(xì)粒度指標(biāo)，才能清晰看到系統(tǒng)的瓶頸。
3. 工欲善其事，必先利其器。高效的壓力測(cè)試工具是性能優(yōu)化必備的利器。
4. 優(yōu)化算法的思路主要有：降低算法時(shí)間復(fù)雜度;減少重復(fù)計(jì)算和不必要的計(jì)算;并行化。
5. 性能優(yōu)化是永無止境的，要根據(jù)真實(shí)業(yè)務(wù)來合理預(yù)估業(yè)務(wù)壓力，逐步開展性能優(yōu)化的工作。
6. 代碼上線需謹(jǐn)慎，做好防御方案。

單個(gè)YARN集群調(diào)度器的性能優(yōu)化總是有限的，目前我們可以支持1萬節(jié)點(diǎn)的集群規(guī)模，那么未來10萬，100萬的節(jié)點(diǎn)我們?nèi)绾螒?yīng)對(duì)?

我們的解決思路是：基于社區(qū)的思路，設(shè)計(jì)適合美團(tuán)點(diǎn)評(píng)的業(yè)務(wù)場(chǎng)景的技術(shù)方案。社區(qū)Hadoop 3.0研發(fā)了Global Scheduling，完全顛覆了目前YARN調(diào)度器的架構(gòu)，可以極大提高單集群調(diào)度性能。我們正在跟進(jìn)這個(gè)Feature。社區(qū)的YARN Federation已經(jīng)逐步完善。該架構(gòu)可以支撐多個(gè)YARN集群對(duì)外提供統(tǒng)一的集群計(jì)算服務(wù)，由于每個(gè)YARN集群都有自己的調(diào)度器，這相當(dāng)于橫向擴(kuò)展了調(diào)度器的個(gè)數(shù)，從而提高集群整體的調(diào)度能力。我們基于社區(qū)的架構(gòu)，結(jié)合美團(tuán)點(diǎn)評(píng)的業(yè)務(wù)場(chǎng)景，正在不斷地完善美團(tuán)點(diǎn)評(píng)的YARN Federation。

作者簡介

世龍、廷穩(wěn)，美團(tuán)用戶平臺(tái)大數(shù)據(jù)與算法部研發(fā)工程師。