YARN 是Hadoop新版中的資源控制框架。本文旨在深入剖析ResourceManager的調(diào)度器，探討三種調(diào)度器的設(shè)計(jì)側(cè)重，最后給出一些配置建議和參數(shù)解釋。 本文分析基于CDH4.2.1。調(diào)度器這個(gè)部分目前還在快速變化之中。例如，CPU資源分配等特性在不就的將來(lái)就會(huì)加入。

YARN是Hadoop新版中的資源控制框架。本文旨在深入剖析ResourceManager的調(diào)度器，探討三種調(diào)度器的設(shè)計(jì)側(cè)重，最后給出一些配置建議和參數(shù)解釋。

本文分析基于CDH4.2.1。調(diào)度器這個(gè)部分目前還在快速變化之中。例如，CPU資源分配等特性在不就的將來(lái)就會(huì)加入。

為了方便查閱源代碼，原代碼位置使用[類名:行號(hào)]方式表示。

名詞解釋：

ResourceManager：以下簡(jiǎn)稱RM。YARN的中控模塊，負(fù)責(zé)統(tǒng)一規(guī)劃資源的使用。

NodeManager:以下簡(jiǎn)稱NM。YARN的資源結(jié)點(diǎn)模塊，負(fù)責(zé)啟動(dòng)管理container。

ApplicationMaster:以下簡(jiǎn)稱AM。YARN中每個(gè)應(yīng)用都會(huì)啟動(dòng)一個(gè)AM，負(fù)責(zé)向RM申請(qǐng)資源，請(qǐng)求NM啟動(dòng)container，并告訴container做什么事情。

Container：資源容器。YARN中所有的應(yīng)用都是在container之上運(yùn)行的。AM也是在container上運(yùn)行的，不過(guò)AM的container是RM申請(qǐng)的。

1.RM中的調(diào)度器

ResourceManager是YARN資源控制框架的中心模塊，負(fù)責(zé)集群中所有的資源的統(tǒng)一管理和分配。它接收來(lái)自NM的匯報(bào)，建立AM，并將資源派送給AM。整體的RM的框架可以參考：RM總體架構(gòu)

?

最初的hadoop的版本只有FifoScheduler（先進(jìn)先出調(diào)度器）。當(dāng)Hadoop集群在大規(guī)模使用的時(shí)候，如何整合資源和分配資源就是一個(gè)迫切的需求。對(duì)此，Yahoo!和facebook先后開(kāi)發(fā)了CapacityScheduler（容量調(diào)度器）和FairScheduler（公平調(diào)度器）。在新版本中，這兩個(gè)調(diào)度器在保持核心算法的基礎(chǔ)上，也被重新開(kāi)發(fā)了一次。（實(shí)際上所有整個(gè)YARN的代碼都是重寫(xiě)的…）

2.調(diào)度器的接口

首先來(lái)了解一下調(diào)度器的工作方式和對(duì)外暴露的接口：[ResourceScheduler:36]

一個(gè)完整的調(diào)度器在內(nèi)存中都會(huì)維護(hù)一個(gè)隊(duì)列，應(yīng)用，NM，Container的關(guān)系。同時(shí)，一個(gè)調(diào)度器也是一個(gè)事件處理器，通過(guò)RM的異步的事件調(diào)用機(jī)制知曉外部的發(fā)生的事情。要跟外部交互也要發(fā)送相應(yīng)的事件。調(diào)度器一共要處理6個(gè)調(diào)度事件。

除了這6個(gè)事件，還有一個(gè)函數(shù)會(huì)在AM跟RM心跳的時(shí)候會(huì)被調(diào)用。[YARNScheduler：105]

Allocation allocate(ApplicationAttemptId appAttemptId,List ask,List release);

AM會(huì)告訴調(diào)度器一些資源申請(qǐng)的請(qǐng)求和已經(jīng)使用完的container的列表，然后獲取到已經(jīng)在NODE_UPDATE分配給這個(gè)應(yīng)用的container的分配。

可以看到調(diào)度器接受資源的申請(qǐng)和分配資源這個(gè)動(dòng)作是異步的。

3.資源分配模型?

無(wú)論FifoScheduler，CapacityScheduler和FairScheduler的核心資源分配模型都是一樣的。

調(diào)度器維護(hù)一群隊(duì)列的信息。用戶可以向一個(gè)或者多個(gè)隊(duì)列提交應(yīng)用。每次NM心跳的時(shí)候，調(diào)度器，根據(jù)一定的規(guī)則選擇一個(gè)隊(duì)列，再在隊(duì)列上選擇一個(gè)應(yīng)用，嘗試在這個(gè)應(yīng)用上分配資源。不過(guò)，因?yàn)橐恍﹨?shù)限制了分配失敗，就會(huì)繼續(xù)選擇下一個(gè)應(yīng)用。在選擇了一個(gè)應(yīng)用之后，這個(gè)應(yīng)用對(duì)應(yīng)也會(huì)有很多的資源申請(qǐng)的請(qǐng)求。調(diào)度器會(huì)優(yōu)先匹配本地資源是申請(qǐng)請(qǐng)求，其次是同機(jī)架的，最后的任意機(jī)器的。

總的來(lái)說(shuō)，3種調(diào)度器就是在回答如何選擇一個(gè)隊(duì)列，在一個(gè)隊(duì)列上如何選擇一個(gè)應(yīng)用的問(wèn)題。

當(dāng)然，實(shí)際上，比起簡(jiǎn)單的FifoScheduler。CapacityScheduler和FairScheduler還有更多新奇好玩的特性。

4.調(diào)度器比較

我們先比較下3種調(diào)度器。

簡(jiǎn)單總結(jié)下：

FifoScheduler：最簡(jiǎn)單的調(diào)度器，按照先進(jìn)先出的方式處理應(yīng)用。只有一個(gè)隊(duì)列可提交應(yīng)用，所有用戶提交到這個(gè)隊(duì)列?？梢葬槍?duì)這個(gè)隊(duì)列設(shè)置ACL。沒(méi)有應(yīng)用優(yōu)先級(jí)可以配置。

CapacityScheduler：可以看作是FifoScheduler的多隊(duì)列版本。每個(gè)隊(duì)列可以限制資源使用量。但是，隊(duì)列間的資源分配以使用量作排列依據(jù)，使得容量小的隊(duì)列有競(jìng)爭(zhēng)優(yōu)勢(shì)。集群整體吞吐較大。延遲調(diào)度機(jī)制使得應(yīng)用可以放棄，夸機(jī)器或者夸機(jī)架的調(diào)度機(jī)會(huì)，爭(zhēng)取本地調(diào)度。

FairScheduler：多隊(duì)列，多用戶共享資源。特有的客戶端創(chuàng)建隊(duì)列的特性，使得權(quán)限控制不太完美。根據(jù)隊(duì)列設(shè)定的最小共享量或者權(quán)重等參數(shù)，按比例共享資源。延遲調(diào)度機(jī)制跟CapacityScheduler的目的類似，但是實(shí)現(xiàn)方式稍有不同。資源搶占特性，是指調(diào)度器能夠依據(jù)公平資源共享算法，計(jì)算每個(gè)隊(duì)列應(yīng)得的資源，將超額資源的隊(duì)列的部分容器釋放掉的特性。

5.本地優(yōu)化與延遲調(diào)度

我們解釋一下什么是本地優(yōu)化和延遲調(diào)度。

Hadoop是構(gòu)建在以hdfs為基礎(chǔ)的文件系統(tǒng)之上的。YARN所運(yùn)行的應(yīng)用的絕大部分輸入都是hdfs上的文件。而hdfs上的文件的是分塊多副本存儲(chǔ)的。假設(shè)文件系統(tǒng)的備份因子是3。則每一個(gè)文件塊都會(huì)在3個(gè)機(jī)器上有副本。在YARN運(yùn)行應(yīng)用的時(shí)候，AM會(huì)將輸入文件進(jìn)行切割，然后，AM向RM申請(qǐng)的container來(lái)運(yùn)行task來(lái)處理這些被切割的文件段。

假如輸入文件在ABC三個(gè)機(jī)器上有備份，那如果AM申請(qǐng)到的container在這3個(gè)機(jī)器上的其中一個(gè)，那這個(gè)task就無(wú)須從其它機(jī)器上傳輸要處理的文件段，節(jié)省網(wǎng)絡(luò)傳輸。這就是Hadoop的本地優(yōu)化。所以Hadoop的文件備份數(shù)量除了和數(shù)據(jù)安全有關(guān)，還對(duì)應(yīng)用運(yùn)行效率有莫大關(guān)系。

YARN的實(shí)現(xiàn)本地優(yōu)化的方式是AM給RM提交的資源申請(qǐng)的時(shí)候，會(huì)同時(shí)發(fā)送本地申請(qǐng)，機(jī)架申請(qǐng)和任意申請(qǐng)。然后，RM的匹配這些資源申請(qǐng)的時(shí)候，會(huì)先匹配本地申請(qǐng)，再匹配機(jī)架申請(qǐng)，最后才匹配任意申請(qǐng)。關(guān)于AM資源申請(qǐng)機(jī)制可以參考：ContainerAlloctor分析

而延遲調(diào)度機(jī)制，就是調(diào)度器在匹配本地申請(qǐng)失敗的時(shí)候，匹配機(jī)架申請(qǐng)或者任意申請(qǐng)成功的時(shí)候，允許略過(guò)這次的資源分配，直到達(dá)到延遲調(diào)度次數(shù)上限。CapacityScheduler和FairScheduler在延遲調(diào)度上的實(shí)現(xiàn)稍有不同，前者的調(diào)度次數(shù)是根據(jù)規(guī)則計(jì)算的，后者的調(diào)度次數(shù)通過(guò)配置指定的，但實(shí)際的含義是一樣的。

6.參數(shù)配置

要徹底理解各個(gè)參數(shù)配置中關(guān)系，就不能忽略掉調(diào)度器的調(diào)度算法和調(diào)度細(xì)節(jié)。

6.1.調(diào)度器的集群配置

以下是和調(diào)度器密切相關(guān)的集群配置

6.2. 容量調(diào)度器

容量調(diào)度器(CapacityScheduler)，由Yahoo！最初開(kāi)發(fā)，被設(shè)計(jì)出來(lái)使得hadoop應(yīng)用能夠被多用戶使用，且最大化整個(gè)集群資源的吞吐量。

6.2.1. 容量調(diào)度器的配置

在hadoop集群配置中啟動(dòng)容量調(diào)度器之后，調(diào)度器會(huì)從classpath中加載capacity-scheduler.xml文件，完成容量調(diào)度器的初始化。總結(jié)起來(lái)有如下特性：

1) 動(dòng)態(tài)更新配置:容量調(diào)度器的配置文件在運(yùn)行時(shí)可以隨時(shí)重新加載來(lái)調(diào)整分配參數(shù)。除非重啟ResourceManager，否則隊(duì)列只能添加不能刪除，但是允許關(guān)閉。修改配置文件后，使用以下命令可以刷新配置。

yarn rmadmin -refreshQueues?

2) 樹(shù)形組織隊(duì)列:容量調(diào)度器的隊(duì)列是按照樹(shù)形結(jié)構(gòu)組織的。根隊(duì)列只有一個(gè)root隊(duì)列。子隊(duì)列分享父隊(duì)列的資源。每個(gè)隊(duì)列設(shè)定一個(gè)容量值代表可使用父隊(duì)列的容量值，容量值會(huì)影響隊(duì)列的排序。父隊(duì)列的所有子隊(duì)列的容量相加一定是100，否則加載失敗。還有一個(gè)最大容量值表示子隊(duì)列絕對(duì)不會(huì)超過(guò)的使用上限。

3) 隊(duì)列應(yīng)用限制:隊(duì)列可以設(shè)定最大提交的應(yīng)用數(shù)量和AM占用資源的百分比。AM占用資源的百分比這個(gè)配置是用來(lái)計(jì)算隊(duì)列的最大活躍應(yīng)用數(shù)量。這里有個(gè)小問(wèn)題。調(diào)度器中最大活躍應(yīng)用數(shù)量=AM占用資源的百分比*隊(duì)列最大可使用資源量/最小的container分配額度。但是我們?cè)趍apred-site.xml中會(huì)配置AM的內(nèi)存額度會(huì)比最小container分配額度大，造成最大活躍應(yīng)用數(shù)量虛高（可以理解，如果YARN加入不同的計(jì)算框架,AM的分配會(huì)不一致，所以這里使用最小container分配額度來(lái)計(jì)算。但是，如果是這樣的話，應(yīng)該直接計(jì)算AM的內(nèi)存使用量來(lái)控制）。

4) 用戶參數(shù)限制:用戶可以提交應(yīng)用到多個(gè)隊(duì)列。不同隊(duì)列間用戶的應(yīng)用運(yùn)行情況，不相互影響。用戶在隊(duì)列中最大可占用資源受兩個(gè)參數(shù)控制，一個(gè)是單用戶占據(jù)隊(duì)列的百分比上限，一個(gè)是單用戶內(nèi)存使用上限。具體參看下面的參數(shù)表。

5）資源分配選擇:不同隊(duì)列之間，按照隊(duì)列的資源使用比排序。同一隊(duì)列中的應(yīng)用按照應(yīng)用id排序，也就是先進(jìn)先出。

6）延遲調(diào)度:當(dāng)調(diào)度次數(shù)小于本地延遲調(diào)度次數(shù)的時(shí)候不接受機(jī)架調(diào)度。本地延遲調(diào)度次數(shù)，由yarn.scheduler.capacity.node-locality-delay配置，默認(rèn)是-1，不開(kāi)啟延遲調(diào)度。官方文檔中沒(méi)有提及這個(gè)參數(shù)。而任意調(diào)度的延遲調(diào)度上限是應(yīng)用申請(qǐng)的機(jī)器的數(shù)量，不能配置。

6.2.2. 容量調(diào)度器的參數(shù)計(jì)算關(guān)系

?容量調(diào)度器通過(guò)各種的資源參數(shù)限制，來(lái)控制整體的資源分布。搞清楚容量調(diào)度器上的參數(shù)關(guān)系，也就基本理解了容量調(diào)度器了。

在RM的管理界面中，你會(huì)看到很多參數(shù)

?

?以下是容量調(diào)度器中的各種參數(shù)定義和計(jì)算關(guān)系：

隊(duì)列容量=yarn.scheduler.capacity..capacity/100
隊(duì)列絕對(duì)容量=父隊(duì)列的 隊(duì)列絕對(duì)容量*隊(duì)列容量?
隊(duì)列最大容量=yarn.scheduler.capacity..maximum-capacity/100?
隊(duì)列絕對(duì)最大容量=父隊(duì)列的 隊(duì)列絕對(duì)最大容量*隊(duì)列最大容量
絕對(duì)資源使用比=使用的資源/全局資源
資源使用比=使用的資源/(全局資源 * 隊(duì)列絕對(duì)容量)?
最小分配量=yarn.scheduler.minimum-allocation-mb
用戶上限=MAX(yarn.scheduler.capacity..minimum-user-limit-percent,1/隊(duì)列用戶數(shù)量)
用戶調(diào)整因子=yarn.scheduler.capacity..user-limit-factor?
最大提交應(yīng)用=yarn.scheduler.capacity..maximum-applications?
?? ?如果小于0 設(shè)置為(yarn.scheduler.capacity.maximum-applications*隊(duì)列絕對(duì)容量)
單用戶最大提交應(yīng)用=最大提交應(yīng)用*(用戶上限/100)*用戶調(diào)整因子
AM資源占比（AM可占用隊(duì)列資源最大的百分比)
?? ?=yarn.scheduler.capacity..maximum-am-resource-percent
?? ?如果為空，設(shè)置為yarn.scheduler.capacity.maximum-am-resource-percent
最大活躍應(yīng)用數(shù)量=全局總資源/最小分配量*AM資源占比*隊(duì)列絕對(duì)最大容量
單用戶最大活躍應(yīng)用數(shù)量=(全局總資源/最小分配量*AM資源占比*隊(duì)列絕對(duì)容量)*用戶上限*用戶調(diào)整因子
本地延遲分配次數(shù)=yarn.scheduler.capacity.node-locality-delay

有了這個(gè)參數(shù)計(jì)算關(guān)系，就可以根據(jù)自己想要的形態(tài)配置對(duì)應(yīng)的參數(shù)了。具體的參數(shù)配置實(shí)例這里就不累述了。

6.3. 公平調(diào)度器

公平調(diào)度器(CapacityScheduler)，由Facebook開(kāi)發(fā)，被設(shè)計(jì)出來(lái)使得hadoop應(yīng)用能夠被多用戶公平地共享整個(gè)集群資源的調(diào)度器。

6.3.1. 公平調(diào)度器的參數(shù)配置

在hadoop集群配置中啟動(dòng)公平調(diào)度器之后，調(diào)度器會(huì)從classpath中加載fair-scheduler.xml和fair-allocation.xml文件，完成公平調(diào)度器的初始化。其中fair-scheduler.xml主要描述重要特性的配置，fair-allocation.xml主要描述了具體的隊(duì)列及其參數(shù)配置?？偨Y(jié)起來(lái)有如下特性：

1) 動(dòng)態(tài)更新配置:公平調(diào)度器的fair-allocation.xml配置文件在運(yùn)行時(shí)可以隨時(shí)重新加載來(lái)調(diào)整分配參數(shù)。除非重啟ResourceManager，否則隊(duì)列只能添加不能刪除。修改fair-allocation.xml后，使用以下命令可以刷新配置。

yarn rmadmin -refreshQueues?

2) 樹(shù)形組織隊(duì)列:公平調(diào)度器的隊(duì)列是按照樹(shù)形結(jié)構(gòu)組織的。根隊(duì)列只有一個(gè)root隊(duì)列。父子隊(duì)列除了ACL參數(shù)外，其余參數(shù)都不繼承。

3) 隊(duì)列應(yīng)用參數(shù):應(yīng)用只能提交到葉子隊(duì)列。受隊(duì)列最大應(yīng)用數(shù)量限制。隊(duì)列可以設(shè)定權(quán)重，最小共享量和最大使用量。權(quán)重和最小共享量將影響在公平排序算法中的排名，從而影響資源調(diào)度傾向。隊(duì)列還可以設(shè)定最大運(yùn)行的應(yīng)用數(shù)量。

4) 用戶參數(shù)限制:一個(gè)用戶可以提交應(yīng)用到多個(gè)隊(duì)列。用戶受全局的最大可運(yùn)行數(shù)量限制。

5) 資源分配選擇:資源分配的時(shí)候，使用公平排序算法選擇要調(diào)度的隊(duì)列，然后在隊(duì)列中使用先進(jìn)先出算法或者公平排序算法選擇要調(diào)度的應(yīng)用。

6) 延遲調(diào)度:每種資源申請(qǐng)的優(yōu)先級(jí)都有一個(gè)資源等級(jí)標(biāo)記。一開(kāi)始標(biāo)記都是NODE_LOCAL，只允許本地調(diào)度。如果調(diào)度機(jī)會(huì)大于NM數(shù)量乘以上界（locality.threshold.node），資源等級(jí)轉(zhuǎn)變?yōu)镽ACK_LOCAL、重置調(diào)度機(jī)會(huì)為0、接受機(jī)架調(diào)度。如果調(diào)度機(jī)會(huì)再次大于NM數(shù)量乘以上界（locality.threshold.rack），資源等級(jí)轉(zhuǎn)變?yōu)镺FF_SWITCH、重置調(diào)度機(jī)會(huì)為0、接受任意調(diào)度。詳情代碼參看[FSSchedulerApp.getAllowedLocalityLevel:470]

7) 資源搶占:調(diào)度器會(huì)使用公平資源共享算法計(jì)算每個(gè)隊(duì)列應(yīng)該得到的資源總量。如果一個(gè)隊(duì)列長(zhǎng)時(shí)間得不到應(yīng)得到的資源量，調(diào)度器可能會(huì)殺死占用掉該部分資源的容器。

這里簡(jiǎn)要描述下fair-scheduler.xml中的配置項(xiàng)：

6.3.2. 公平排序算法

公平排序算法是公平調(diào)度器的核心算法。調(diào)度器在選取哪個(gè)隊(duì)列和隊(duì)列中的哪個(gè)應(yīng)用需要優(yōu)先得到資源調(diào)度的時(shí)候使用。每個(gè)隊(duì)列或者應(yīng)用都有以下幾個(gè)供排序的參數(shù)：

1) 資源需求量。當(dāng)前隊(duì)列或者應(yīng)用希望獲得的資源的總量。

2) 最小共享量。隊(duì)列的最小共享量在配置中指定。應(yīng)用的最小共享量為0。

3) 資源使用量。當(dāng)前隊(duì)列或者應(yīng)用分配到的總資源。

4) 權(quán)值。隊(duì)列的權(quán)重值在配置中指定。在開(kāi)啟sizebasedweight特性的情況下，應(yīng)用的權(quán)重=（log2(資源需求量)）*優(yōu)先級(jí)*調(diào)整因子。優(yōu)先級(jí)當(dāng)前都是1,。當(dāng)應(yīng)用運(yùn)行超過(guò)5分鐘，調(diào)整因子為3。

排序算法的核心是兩個(gè)比較體的比較算法，具體如下：

1.計(jì)算比較體是否需要資源。即資源使用量是否小于資源需求量且小于最小共享量。
2.如果兩者都需要資源，計(jì)算資源分配比=資源使用量/Min（資源需求量，最小共享量）。資源分配比較小的優(yōu)先。
3.如果一個(gè)需要，一個(gè)不需要，需要的優(yōu)先。
4.如果兩者都不需要資源，計(jì)算使用權(quán)值比=資源使用量/權(quán)值。使用權(quán)值比較小的優(yōu)先。
5.如果2或者4中的比較相同，則先提交的優(yōu)先。

詳情代碼參看[SchedulingAlgorithms.FairShareComparator.compare:81]

6.3.3. 公平資源共享算法

公平調(diào)度器為公平地分配資源，在開(kāi)啟資源搶占的特性的情況下，可能會(huì)殺死部分運(yùn)行中的容器，釋放超額的資源。

公平調(diào)度器啟動(dòng)的時(shí)候會(huì)建立一個(gè)UpdateThread的線程，負(fù)責(zé)計(jì)算公平資源量和進(jìn)行資源搶占。其中，調(diào)度器使用了公平資源共享算法重新計(jì)算隊(duì)列的公平資源量。

名詞解釋：

資源權(quán)重比=資源獲得量/隊(duì)列權(quán)重。知道全局的資源權(quán)重比，每個(gè)隊(duì)列就可以根據(jù)自己的權(quán)值，知道自己能分配多少資源。

公平資源共享算法的目的是為了每個(gè)隊(duì)列公平地使用資源，這個(gè)公平體現(xiàn)在每個(gè)隊(duì)列得到的資源比等于他們的權(quán)值比。如果只是單純地求一個(gè)資源權(quán)重比，可以直接相除。但是由于需要滿足隊(duì)列的資源分配滿足最小共享量、最大資源量這些隊(duì)列上下界的限制，權(quán)值資源比不能直接計(jì)算。

反過(guò)來(lái)，如果知道資源權(quán)重比，就可以計(jì)算出集群一共需要多少資源，而且，集群資源需求量=Fun(資源權(quán)重比)是單調(diào)的。

所以可以使用二分資源權(quán)重比的方法，計(jì)算集群資源需求量，使得集群資源需求量逼近當(dāng)前的集群資源量。

具體算法流程如下：

1.設(shè)置根隊(duì)列的公平資源量為全局資源總和
2.根隊(duì)列調(diào)用recomputeFairShares，計(jì)算公平資源量
2.1計(jì)算當(dāng)前隊(duì)列的分配量=MIN（隊(duì)列總需求，公平資源量）
2.2計(jì)算資源權(quán)重比最大值。最大值=2^n,使得Fun(最大值)>集群資源量>Fun(最大值/2)。
2.2計(jì)算資源權(quán)重比。采用二分法計(jì)算，二分法次數(shù)最多25次。每個(gè)隊(duì)列的公平資源量= （權(quán)重*權(quán)重資源比，用最小共享量修正下界，用資源需求量修正上界）
2.3設(shè)置每個(gè)子隊(duì)列的公平資源量=資源權(quán)重比*權(quán)值。
2.4各個(gè)子隊(duì)列調(diào)用recomputeFairShares，遞歸計(jì)算。

詳情代碼參看[FairScheduler:221]

6.3.4. 公平調(diào)度器的使用設(shè)計(jì)建議

隊(duì)列的最小共享量越大，在集群繁忙的時(shí)候分配到的資源就越多。但是，如果每個(gè)用戶都將最小共享量設(shè)置到最大，不利于集群間的資源共享。建議，將隊(duì)列愿意共享出來(lái)的內(nèi)存大小和隊(duì)列的權(quán)值掛鉤。含義就是，你愿意共享得越多，在整體資源分配中就越能分得更多的資源。

6.3.5. 公平調(diào)度器的全局配置

最后，我們?cè)偬嵋恍┲匾娜峙渲茫?

7.一句話總結(jié)

如果，你剛接觸Hadoop的話，F(xiàn)ifoScheduler會(huì)是個(gè)不錯(cuò)的選擇。（話說(shuō)2.0中的FifoScheduler的千年默認(rèn)調(diào)度器位置被CapacityScheduler奪走，詳情查看YARN-137）

如果，你只是想控制下部分應(yīng)用的優(yōu)先級(jí)，同時(shí)又要最大化利用集群的話，選擇CapacityScheduler吧。

如果，你想很多人公平地共享資源的話，只有FairScheduler能滿足你。

資料參考：

http://dongxicheng.org/category/mapreduce-nextgen/ 博客中關(guān)于RM，NM，AM等多個(gè)部分的敘述，不一一說(shuō)明

http://hadoop.apache.org/docs/r2.0.5-alpha/hadoop-YARN/hadoop-YARN-site/CapacityScheduler.html

http://hadoop.apache.org/docs/r2.0.5-alpha/hadoop-YARN/hadoop-YARN-site/FairScheduler.html Hadoop官方文檔中對(duì)著兩個(gè)調(diào)度器的說(shuō)明

http://www.cloudera.com/content/cloudera/en/products/cdh.html CDH4的源碼

原文地址：YARN ResourceManager調(diào)度器的分析, 感謝原作者分享。

聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com