理想情況下，我們應(yīng)用對(duì)Yarn資源的請(qǐng)求應(yīng)該立刻得到滿足，但現(xiàn)實(shí)情況資源往往是有限的，特別是在一個(gè)很繁忙的集群，一個(gè)應(yīng)用資源的請(qǐng)求經(jīng)常需要等待一段時(shí)間才能的到相應(yīng)的資源。在Yarn中，負(fù)責(zé)給應(yīng)用分配資源的就是Scheduler。其實(shí)調(diào)度本身就是一個(gè)難題，很難找到一個(gè)完美的策略可以解決所有的應(yīng)用場(chǎng)景。為此，Yarn提供了多種調(diào)度器和可配置的策略供我們選擇。YARN架構(gòu)如下:

ResourceManager（RM）：負(fù)責(zé)對(duì)各NM上的資源進(jìn)行統(tǒng)一管理和調(diào)度，將AM分配空閑的Container運(yùn)行并監(jiān)控其運(yùn)行狀態(tài)。對(duì)AM申請(qǐng)的資源請(qǐng)求分配相應(yīng)的空閑Container。主要由兩個(gè)組件構(gòu)成：調(diào)度器（Scheduler）和應(yīng)用程序管理器（Applications Manager）。
調(diào)度器（Scheduler）：調(diào)度器根據(jù)容量、隊(duì)列等限制條件（如每個(gè)隊(duì)列分配一定的資源，最多執(zhí)行一定數(shù)量的作業(yè)等），將系統(tǒng)中的資源分配給各個(gè)正在運(yùn)行的應(yīng)用程序。調(diào)度器僅根據(jù)各個(gè)應(yīng)用程序的資源需求進(jìn)行資源分配，而資源分配單位是Container，從而限定每個(gè)任務(wù)使用的資源量。Scheduler不負(fù)責(zé)監(jiān)控或者跟蹤應(yīng)用程序的狀態(tài)，也不負(fù)責(zé)任務(wù)因?yàn)楦鞣N原因而需要的重啟（由ApplicationMaster負(fù)責(zé)）。總之，調(diào)度器根據(jù)應(yīng)用程序的資源要求，以及集群機(jī)器的資源情況，為用程序分配封裝在Container中的資源。調(diào)度器是可插拔的，例如CapacityScheduler、FairScheduler。（PS：在實(shí)際應(yīng)用中，只需要簡(jiǎn)單配置即可）
應(yīng)用程序管理器（Application Manager）：應(yīng)用程序管理器負(fù)責(zé)管理整個(gè)系統(tǒng)中所有應(yīng)用程序，包括應(yīng)用程序提交、與調(diào)度器協(xié)商資源以啟動(dòng)AM、監(jiān)控AM運(yùn)行狀態(tài)并在失敗時(shí)重新啟動(dòng)等，跟蹤分給的Container的進(jìn)度、狀態(tài)也是其職責(zé)。ApplicationMaster是應(yīng)用框架，它負(fù)責(zé)向ResourceManager協(xié)調(diào)資源，并且與NodeManager協(xié)同工作完成Task的執(zhí)行和監(jiān)控。MapReduce就是原生支持的一種框架，可以在YARN上運(yùn)行Mapreduce作業(yè)。有很多分布式應(yīng)用都開發(fā)了對(duì)應(yīng)的應(yīng)用程序框架，用于在YARN上運(yùn)行任務(wù)，例如Spark，Storm等。如果需要，我們也可以自己寫一個(gè)符合規(guī)范的YARN application。
NodeManager（NM）：NM是每個(gè)節(jié)點(diǎn)上的資源和任務(wù)管理器。它會(huì)定時(shí)地向RM匯報(bào)本節(jié)點(diǎn)上的資源使用情況和各個(gè)Container的運(yùn)行狀態(tài)；同時(shí)會(huì)接收并處理來自AM的Container 啟動(dòng)/停止等請(qǐng)求。ApplicationMaster（AM）：用戶提交的應(yīng)用程序均包含一個(gè)AM，負(fù)責(zé)應(yīng)用的監(jiān)控，跟蹤應(yīng)用執(zhí)行狀態(tài)，重啟失敗任務(wù)等。
Container：是YARN中的資源抽象，它封裝了某個(gè)節(jié)點(diǎn)上的多維度資源，如內(nèi)存、CPU、磁盤、網(wǎng)絡(luò)等，當(dāng)AM向RM申請(qǐng)資源時(shí)，RM為AM返回的資源便是用Container 表示的。YARN會(huì)為每個(gè)任務(wù)分配一個(gè)Container且該任務(wù)只能使用該Container中描述的資源。

1. Yarn調(diào)度器介紹

1.1. FIFO (先進(jìn)先出調(diào)度器)

FIFO Scheduler把應(yīng)用按提交的順序排成一個(gè)隊(duì)列，這是一個(gè)先進(jìn)先出隊(duì)列，在進(jìn)行資源分配的時(shí)候，先給隊(duì)列中最頭上的應(yīng)用進(jìn)行分配資源，待最頭上的應(yīng)用需求滿足后再給下一個(gè)分配，以此類推。FIFO Scheduler是最簡(jiǎn)單也是最容易理解的調(diào)度器，也不需要任何配置，但它并不適用于共享集群。大的應(yīng)用可能會(huì)占用所有集群資源，這就導(dǎo)致其它應(yīng)用被阻塞。在共享集群中，更適合采用Capacity Scheduler或Fair Scheduler，這兩個(gè)調(diào)度器都允許大任務(wù)和小任務(wù)在提交的同時(shí)獲得一定的系統(tǒng)資源。下面“Yarn調(diào)度器對(duì)比圖”展示了這幾個(gè)調(diào)度器的區(qū)別，從圖中可以看出，在FIFO 調(diào)度器中，小任務(wù)會(huì)被大任務(wù)阻塞。

1.2. Capacity (容量調(diào)度器)

yarn-site.xml中默認(rèn)配置的資源調(diào)度器。而對(duì)于Capacity調(diào)度器，有一個(gè)專門的隊(duì)列用來運(yùn)行小任務(wù)，但是為小任務(wù)專門設(shè)置一個(gè)隊(duì)列會(huì)預(yù)先占用一定的集群資源，這就導(dǎo)致大任務(wù)的執(zhí)行時(shí)間會(huì)落后于使用FIFO調(diào)度器時(shí)的時(shí)間。用這個(gè)資源調(diào)度器，就可以配置yarn資源隊(duì)列，這個(gè)后面后介紹用到。

1.3. Fair (公平調(diào)度器)

Fair調(diào)度器的設(shè)計(jì)目標(biāo)是為所有的應(yīng)用分配公平的資源（對(duì)公平的定義可以通過參數(shù)來設(shè)置）。在上面的“Yarn調(diào)度器對(duì)比圖”展示了一個(gè)隊(duì)列中兩個(gè)應(yīng)用的公平調(diào)度；當(dāng)然，公平調(diào)度在也可以在多個(gè)隊(duì)列間工作。舉個(gè)例子，假設(shè)有兩個(gè)用戶A和B，他們分別擁有一個(gè)隊(duì)列。當(dāng)A啟動(dòng)一個(gè)job而B沒有任務(wù)時(shí)，A會(huì)獲得全部集群資源；當(dāng)B啟動(dòng)一個(gè)job后，A的job會(huì)繼續(xù)運(yùn)行，不過一會(huì)兒之后兩個(gè)任務(wù)會(huì)各自獲得一半的集群資源。如果此時(shí)B再啟動(dòng)第二個(gè)job并且其它job還在運(yùn)行，則它將會(huì)和B的第一個(gè)job共享B這個(gè)隊(duì)列的資源，也就是B的兩個(gè)job會(huì)用于四分之一的集群資源，而A的job仍然用于集群一半的資源，結(jié)果就是資源最終在兩個(gè)用戶之間平等的共享。在Fair調(diào)度器中，我們不需要預(yù)先占用一定的系統(tǒng)資源，F(xiàn)air調(diào)度器會(huì)為所有運(yùn)行的job動(dòng)態(tài)的調(diào)整系統(tǒng)資源。當(dāng)?shù)谝粋€(gè)大job提交時(shí)，只有這一個(gè)job在運(yùn)行，此時(shí)它獲得了所有集群資源；當(dāng)?shù)诙€(gè)小任務(wù)提交后，F(xiàn)air調(diào)度器會(huì)分配一半資源給這個(gè)小任務(wù)，讓這兩個(gè)任務(wù)公平的共享集群資源。
a) 公平調(diào)度器，就是能夠共享整個(gè)集群的資源
b) 不用預(yù)先占用資源，每一個(gè)作業(yè)都是共享的
c) 每當(dāng)提交一個(gè)作業(yè)的時(shí)候，就會(huì)占用整個(gè)資源。如果再提交一個(gè)作業(yè)，那么第一個(gè)作業(yè)就會(huì)分給第二個(gè)作業(yè)一部分資源，第一個(gè)作業(yè)也就釋放一部分資源。再提交其他的作業(yè)時(shí)，也同理。。。。也就是說每一個(gè)作業(yè)進(jìn)來，都有機(jī)會(huì)獲取資源。

1.4. Fair Scheduler與Capacity Scheduler區(qū)別

資源公平共享：在每個(gè)隊(duì)列中，F(xiàn)air Scheduler可選擇按照FIFO、Fair或DRF策略為應(yīng)用程序分配資源。Fair策略即平均分配，默認(rèn)情況下，每個(gè)隊(duì)列采用該方式分配資源
支持資源搶占：當(dāng)某個(gè)隊(duì)列中有剩余資源時(shí)，調(diào)度器會(huì)將這些資源共享給其他隊(duì)列，而當(dāng)該隊(duì)列中有新的應(yīng)用程序提交時(shí)，調(diào)度器要為它回收資源。為了盡可能降低不必要的計(jì)算浪費(fèi)，調(diào)度器采用了先等待再?gòu)?qiáng)制回收的策略，即如果等待一段時(shí)間后尚有未歸還的資源，則會(huì)進(jìn)行資源搶占；從那些超額使用資源的隊(duì)列中殺死一部分任務(wù)，進(jìn)而釋放資源
負(fù)載均衡：Fair Scheduler提供了一個(gè)基于任務(wù)數(shù)的負(fù)載均衡機(jī)制，該機(jī)制盡可能將系統(tǒng)中的任務(wù)均勻分配到各個(gè)節(jié)點(diǎn)上。此外，用戶也可以根據(jù)自己的需求設(shè)計(jì)負(fù)載均衡機(jī)制
調(diào)度策略靈活配置：Fiar Scheduler允許管理員為每個(gè)隊(duì)列單獨(dú)設(shè)置調(diào)度策略（當(dāng)前支持FIFO、Fair或DRF三種）
提高小應(yīng)用程序響應(yīng)時(shí)間：由于采用了最大最小公平算法，小作業(yè)可以快速獲取資源并運(yùn)行完成

2.Yarn調(diào)度器配置

yarn資源調(diào)度器是在yarn-site.xml中配置。

2.1. Fair Scheduler

Fair Scheduler的配置選項(xiàng)包括兩部分:
一部分在yarn-site.xml中，主要用于配置調(diào)度器級(jí)別的參數(shù)
一部分在一個(gè)自定義配置文件（默認(rèn)是fair-scheduler.xml）中，主要用于配置各個(gè)隊(duì)列的資源量、權(quán)重等信息。

2.1.1 yarn-site.xml

yarn-site.xml介紹

<!–?scheduler?start?–>
<property>
????<name>yarn.resourcemanager.scheduler.classname>
????<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairSchedulervalue>
????<description>配置Yarn使用的調(diào)度器插件類名；Fair Scheduler對(duì)應(yīng)的是：org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairSchedulerdescription>
property>
<property>
????<name>yarn.scheduler.fair.allocation.filename>
????<value>/etc/hadoop/conf/fair-scheduler.xmlvalue>
????<description>配置資源池以及其屬性配額的XML文件路徑（本地路徑）description>
property>
<property>
????<name>yarn.scheduler.fair.preemptionname>
????<value>truevalue>
????<description>開啟資源搶占,default?is?Truedescription>
property>
<property>
????<name>yarn.scheduler.fair.user-as-default-queuename>
????<value>truevalue>
????<description>設(shè)置成true，當(dāng)任務(wù)中未指定資源池的時(shí)候，將以用戶名作為資源池名。這個(gè)配置就實(shí)現(xiàn)了根據(jù)用戶名自動(dòng)分配資源池。default is Truedescription>
property>
<property>
????<name>yarn.scheduler.fair.allow-undeclared-poolsname>
????<value>falsevalue>
????<description>是否允許創(chuàng)建未定義的資源池。如果設(shè)置成true，yarn將會(huì)自動(dòng)創(chuàng)建任務(wù)中指定的未定義過的資源池。設(shè)置成false之后，任務(wù)中指定的未定義的資源池將無效，該任務(wù)會(huì)被分配到default資源池中。,default is Truedescription>
property>
<!–?scheduler?end?–>

2.1.2 fair-scheduler.xml

假設(shè)在生產(chǎn)環(huán)境Yarn中，總共有四類用戶需要使用集群，production、spark、default、streaming。為了使其提交的任務(wù)不受影響，我們?cè)赮arn上規(guī)劃配置了四個(gè)資源池，分別為production,spark,default,streaming。并根據(jù)實(shí)際業(yè)務(wù)情況，為每個(gè)資源池分配了相應(yīng)的資源及優(yōu)先級(jí)等,default用于開發(fā)測(cè)試目的.
ResourceManager上fair-scheduler.xml配置如下：


<allocations>
????<queue?name="root">
????????<aclSubmitApps>aclSubmitApps>
????????<aclAdministerApps>aclAdministerApps>
????????<queue?name="production">
????????????<minResources>8192mb,8vcoresminResources>
????????????<maxResources>419840mb,125vcoresmaxResources>
????????????<maxRunningApps>60maxRunningApps>
????????????<schedulingMode>fairschedulingMode>
????????????<weight>7.5weight>
????????????<aclSubmitApps>*aclSubmitApps>
????????????<aclAdministerApps>productionaclAdministerApps>
????????queue>
????????<queue?name="spark">
????????????<minResources>8192mb,8vcoresminResources>
????????????<maxResources>376480mb,110vcoresmaxResources>
????????????<maxRunningApps>50maxRunningApps>
????????????<schedulingMode>fairschedulingMode>
????????????<weight>1weight>
????????????<aclSubmitApps>*aclSubmitApps>
????????????<aclAdministerApps>sparkaclAdministerApps>
????????queue>
????????<queue?name="default">
????????????<minResources>8192mb,8vcoresminResources>
????????????<maxResources>202400mb,20vcoresmaxResources>
????????????<maxRunningApps>20maxRunningApps>
????????????<schedulingMode>FIFOschedulingMode>
????????????<weight>0.5weight>
????????????<aclSubmitApps>*aclSubmitApps>
????????????<aclAdministerApps>*aclAdministerApps>
????????queue>
????????<queue?name="streaming">
????????????<minResources>8192mb,8vcoresminResources>
????????????<maxResources>69120mb,16vcoresmaxResources>
????????????<maxRunningApps>20maxRunningApps>
????????????<schedulingMode>fairschedulingMode>
????????????<aclSubmitApps>*aclSubmitApps>
????????????<weight>1weight>
????????????<aclAdministerApps>streamingaclAdministerApps>
????????queue>
????queue>
????<user?name="production">
????????
????????<maxRunningApps>100maxRunningApps>
????user>
????<user?name="default">
????????
????????<maxRunningApps>10maxRunningApps>
????user>

????
????<userMaxAppsDefault>50userMaxAppsDefault>
????
????<queuePlacementPolicy>
????????<rule?name="specified"/>?
????????<rule?name="primaryGroup"?create="false"?/>
????????<rule?name="secondaryGroupExistingQueue"?create="false"?/>
????????<rule?name="default"?queue="default"/>
????queuePlacementPolicy>
allocations>

參數(shù)介紹:

minResources:最少資源保證量，設(shè)置格式為“X mb, Y vcores”，當(dāng)一個(gè)隊(duì)列的最少資源保證量未滿足時(shí)，它將優(yōu)先于其他同級(jí)隊(duì)列獲得資源，對(duì)于不同的調(diào)度策略（后面會(huì)詳細(xì)介紹），最少資源保證量的含義不同，對(duì)于fair策略，則只考慮內(nèi)存資源，即如果一個(gè)隊(duì)列使用的內(nèi)存資源超過了它的最少資源量，則認(rèn)為它已得到了滿足；對(duì)于drf策略，則考慮主資源使用的資源量，即如果一個(gè)隊(duì)列的主資源量超過它的最少資源量，則認(rèn)為它已得到了滿足。
maxResources:最多可以使用的資源量，fair scheduler會(huì)保證每個(gè)隊(duì)列使用的資源量不會(huì)超過該隊(duì)列的最多可使用資源量。
maxRunningApps:最多同時(shí)運(yùn)行的應(yīng)用程序數(shù)目。通過限制該數(shù)目，可防止超量Map Task同時(shí)運(yùn)行時(shí)產(chǎn)生的中間輸出結(jié)果撐爆磁盤。
weight:資源池權(quán)重,主要用在資源共享之時(shí)，weight越大，拿到的資源越多。比如一個(gè)pool中有20GB內(nèi)存用不了，這時(shí)候可以共享給其他pool，其他每個(gè)pool拿多少，就是由權(quán)重決定的
aclSubmitApps:可向隊(duì)列中提交應(yīng)用程序的Linux用戶或用戶組列表，默認(rèn)情況下為“*”，表示任何用戶均可以向該隊(duì)列提交應(yīng)用程序。需要注意的是，該屬性具有繼承性，即子隊(duì)列的列表會(huì)繼承父隊(duì)列的列表。配置該屬性時(shí)，用戶之間或用戶組之間用“，”分割，用戶和用戶組之間用空格分割，比如“user1, user2 group1,group2”。
aclAdministerApps:允許管理任務(wù)的用戶名和組；一個(gè)隊(duì)列的管理員可管理該隊(duì)列中的資源和應(yīng)用程序，比如可殺死任意應(yīng)用程序。
minSharePreemptionTimeout ：最小共享量搶占時(shí)間。如果一個(gè)資源池在該時(shí)間內(nèi)使用的資源量一直低于最小資源量，則開始搶占資源。
schedulingMode/schedulingPolicy：隊(duì)列采用的調(diào)度模式，可以是fifo、fair或者drf。
管理員也可為單個(gè)用戶添加maxRunningJobs屬性限制其最多同時(shí)運(yùn)行的應(yīng)用程序數(shù)目。此外，管理員也可通過以下參數(shù)設(shè)置以上屬性的默認(rèn)值：
userMaxJobsDefault：用戶的maxRunningJobs屬性的默認(rèn)值。
defaultMinSharePreemptionTimeout ：隊(duì)列的minSharePreemptionTimeout屬性的默認(rèn)值。
defaultPoolSchedulingMode：隊(duì)列的schedulingMode屬性的默認(rèn)值。
fairSharePreemptionTimeout：公平共享量搶占時(shí)間。如果一個(gè)資源池在該時(shí)間內(nèi)使用資源量一直低于公平共享量的一半，則開始搶占資源。
這樣，每個(gè)用戶組下的用戶提交任務(wù)時(shí)候，會(huì)到相應(yīng)的資源池中，而不影響其他業(yè)務(wù)。隊(duì)列的層次是通過嵌套
元素實(shí)現(xiàn)的。所有的隊(duì)列都是root隊(duì)列的孩子，即使沒有配到元素里。Fair調(diào)度器中的隊(duì)列有一個(gè)權(quán)重屬性（這個(gè)權(quán)重就是對(duì)公平的定義），并把這個(gè)屬性作為公平調(diào)度的依據(jù)。在這個(gè)例子中，當(dāng)調(diào)度器分配集群7.5,1,1,0.5資源給production,spark,streaming,default時(shí)便視作公平,這里的權(quán)重并不是百分比。注意，對(duì)于在沒有配置文件時(shí)按用戶自動(dòng)創(chuàng)建的隊(duì)列，它們?nèi)杂袡?quán)重并且權(quán)重值為1。每個(gè)隊(duì)列內(nèi)部仍可以有不同的調(diào)度策略。隊(duì)列的默認(rèn)調(diào)度策略可以通過頂級(jí)元素進(jìn)行配置，如果沒有配置，默認(rèn)采用公平調(diào)度。盡管是Fair調(diào)度器，其仍支持在隊(duì)列級(jí)別進(jìn)行FIFO調(diào)度。每個(gè)隊(duì)列的調(diào)度策略可以被其內(nèi)部的元素覆蓋，在上面這個(gè)例子中，default隊(duì)列就被指定采用fifo進(jìn)行調(diào)度，所以，對(duì)于提交到default隊(duì)列的任務(wù)就可以按照FIFO規(guī)則順序的執(zhí)行了。需要注意，spark,production,streaming,default之間的調(diào)度仍然是公平調(diào)度。每個(gè)隊(duì)列可配置最大、最小資源占用數(shù)和最大可運(yùn)行的應(yīng)用的數(shù)量。

Fair調(diào)度器采用了一套基于規(guī)則的系統(tǒng)來確定應(yīng)用應(yīng)該放到哪個(gè)隊(duì)列。在上面的例子中，元素定義了一個(gè)規(guī)則列表，其中的每個(gè)規(guī)則會(huì)被逐個(gè)嘗試直到匹配成功。例如，上例第一個(gè)規(guī)則specified，則會(huì)把應(yīng)用放到它指定的隊(duì)列中，若這個(gè)應(yīng)用沒有指定隊(duì)列名或隊(duì)列名不存在，則說明不匹配這個(gè)規(guī)則，然后嘗試下一個(gè)規(guī)則。primaryGroup規(guī)則會(huì)嘗試把應(yīng)用放在以用戶所在的Unix組名命名的隊(duì)列中，如果沒有這個(gè)隊(duì)列，不創(chuàng)建隊(duì)列轉(zhuǎn)而嘗試下一個(gè)規(guī)則。當(dāng)前面所有規(guī)則不滿足時(shí)，則觸發(fā)default規(guī)則，把應(yīng)用放在default隊(duì)列中。
當(dāng)然，我們可以不配置queuePlacementPolicy規(guī)則，調(diào)度器則默認(rèn)采用如下規(guī)則：

<queuePlacementPolicy>
??????<rule?name="specified"?/>
??????<rule?name="user"?/>
queuePlacementPolicy>

上面規(guī)則意思是除非隊(duì)列被準(zhǔn)確的定義，否則會(huì)以用戶名為隊(duì)列名創(chuàng)建隊(duì)列。還有一個(gè)簡(jiǎn)單的配置策略可以使得所有的應(yīng)用放入同一個(gè)隊(duì)列（default），這樣就可以讓所有應(yīng)用之間平等共享集群而不是在用戶之間。這個(gè)配置的定義如下：

<queuePlacementPolicy>
?????<rule?name="default"?/>
queuePlacementPolicy>

實(shí)現(xiàn)上面功能我們還可以不使用配置文件，直接設(shè)置yarn.scheduler.fair.user-as-default-queue=false，這樣應(yīng)用便會(huì)被放入default 隊(duì)列，而不是各個(gè)用戶名隊(duì)列。另外，我們還可以設(shè)置yarn.scheduler.fair.allow-undeclared-pools=false，這樣用戶就無法創(chuàng)建隊(duì)列了。

當(dāng)一個(gè)job提交到一個(gè)繁忙集群中的空隊(duì)列時(shí)，job并不會(huì)馬上執(zhí)行，而是阻塞直到正在運(yùn)行的job釋放系統(tǒng)資源。為了使提交job的執(zhí)行時(shí)間更具預(yù)測(cè)性（可以設(shè)置等待的超時(shí)時(shí)間），F(xiàn)air調(diào)度器支持搶占。搶占就是允許調(diào)度器殺掉占用超過其應(yīng)占份額資源隊(duì)列的containers，這些containers資源便可被分配到應(yīng)該享有這些份額資源的隊(duì)列中。需要注意搶占會(huì)降低集群的執(zhí)行效率，因?yàn)楸唤K止的containers需要被重新執(zhí)行?？梢酝ㄟ^設(shè)置一個(gè)全局的參數(shù)yarn.scheduler.fair.preemption=true來啟用搶占功能。此外，還有兩個(gè)參數(shù)用來控制搶占的過期時(shí)間（這兩個(gè)參數(shù)默認(rèn)沒有配置，需要至少配置一個(gè)來允許搶占Container）：

minSharePreemptionTimeout
fairSharePreemptionTimeout

如果隊(duì)列在minimum share preemption timeout指定的時(shí)間內(nèi)未獲得最小的資源保障，調(diào)度器就會(huì)搶占containers。我們可以通過配置文件中的頂級(jí)元素為所有隊(duì)列配置這個(gè)超時(shí)時(shí)間；我們還可以在元素內(nèi)配置元素來為某個(gè)隊(duì)列指定超時(shí)時(shí)間。

與之類似，如果隊(duì)列在fair share preemption timeout指定時(shí)間內(nèi)未獲得平等的資源的一半（這個(gè)比例可以配置），調(diào)度器則會(huì)進(jìn)行搶占containers。這個(gè)超時(shí)時(shí)間可以通過頂級(jí)元素和元素級(jí)元素分別配置所有隊(duì)列和某個(gè)隊(duì)列的超時(shí)時(shí)間。上面提到的比例可以通過(配置所有隊(duì)列)和(配置某個(gè)隊(duì)列)進(jìn)行配置，默認(rèn)是0.5。

需要注意的是，所有客戶端提交任務(wù)的用戶和用戶組的對(duì)應(yīng)關(guān)系，需要維護(hù)在ResourceManager上，ResourceManager在分配資源池時(shí)候，是從ResourceManager上讀取用戶和用戶組的對(duì)應(yīng)關(guān)系的，否則就會(huì)被分配到default資源池。在日志中出現(xiàn)”UserGroupInformation: No groups available for user”類似的警告。而客戶端機(jī)器上的用戶對(duì)應(yīng)的用戶組無關(guān)緊要。

每次在ResourceManager上新增用戶或者調(diào)整資源池配額后，需要執(zhí)行下面的命令刷新使其生效.
yarn rmadmin -refreshQueues yarn rmadmin -refreshUserToGroupsMappings
動(dòng)態(tài)更新只支持修改資源池配額，如果是新增或減少資源池，則需要重啟Yarn集群.

Fair Scheduer各資源池配置及使用情況，在ResourceManager的WEB監(jiān)控頁(yè)面上也可以看到: http://ResourceManagerHost:8088/cluster/scheduler

2.2 Capacity 配置

hadoop2.7默認(rèn)使用的是Capacity Scheduler容量調(diào)度器
yarn-site.xml

<property>
??<name>yarn.resourcemanager.scheduler.classname>
??<value>org.apache.hadoop.yarn.server.resourcemanager.capacity.CapacitySchedulervalue>
property>

Capacity 調(diào)度器允許多個(gè)組織共享整個(gè)集群，每個(gè)組織可以獲得集群的一部分計(jì)算能力。通過為每個(gè)組織分配專門的隊(duì)列，然后再為每個(gè)隊(duì)列分配一定的集群資源，這樣整個(gè)集群就可以通過設(shè)置多個(gè)隊(duì)列的方式給多個(gè)組織提供服務(wù)了。除此之外，隊(duì)列內(nèi)部又可以垂直劃分，這樣一個(gè)組織內(nèi)部的多個(gè)成員就可以共享這個(gè)隊(duì)列資源了，在一個(gè)隊(duì)列內(nèi)部，資源的調(diào)度是采用的是先進(jìn)先出(FIFO)策略。

一個(gè)job可能使用不了整個(gè)隊(duì)列的資源。然而如果這個(gè)隊(duì)列中運(yùn)行多個(gè)job，如果這個(gè)隊(duì)列的資源夠用，那么就分配給這些job，如果這個(gè)隊(duì)列的資源不夠用了呢？其實(shí)Capacity調(diào)度器仍可能分配額外的資源給這個(gè)隊(duì)列，這就是“彈性隊(duì)列”(queue elasticity)的概念。

在正常的操作中，Capacity調(diào)度器不會(huì)強(qiáng)制釋放Container，當(dāng)一個(gè)隊(duì)列資源不夠用時(shí)，這個(gè)隊(duì)列只能獲得其它隊(duì)列釋放后的Container資源。當(dāng)然，我們可以為隊(duì)列設(shè)置一個(gè)最大資源使用量，以免這個(gè)隊(duì)列過多的占用空閑資源，導(dǎo)致其它隊(duì)列無法使用這些空閑資源，這就是”彈性隊(duì)列”需要權(quán)衡的地方。

假設(shè)我們有如下層次的隊(duì)列：

root
├──?prod
└──?dev
????├──?eng
????└──?science

下面是一個(gè)簡(jiǎn)單的Capacity調(diào)度器的配置文件，文件名為capacity-scheduler.xml。在這個(gè)配置中，在root隊(duì)列下面定義了兩個(gè)子隊(duì)列prod和dev，分別占40%和60%的容量。需要注意，一個(gè)隊(duì)列的配置是通過屬性yarn.sheduler.capacity..指定的，代表的是隊(duì)列的繼承樹，如root.prod隊(duì)列，一般指capacity和maximum-capacity。


<configuration>
????<property>
????????<name>yarn.scheduler.capacity.root.queues(/&eae)
????????<value>prod,devvalue>
????property>
????<property>
????????<name>yarn.scheduler.capacity.root.dev.queuestta*e>?
????????<value>eng,sciencevalue>
????property>
????<property>
????????<name>yarn.scheduler.capacity.root.prod.capacityname>
????????<value>40value>
????property>
????<property>
????????<name>yarn.scheduler.capacity.root.dev.capacityname>
????????<value?>60value>
????property>
????<property>
????????<name>yarn.scheduler.capacity.root.dev.maximuin-capacityname>
????????<value>75value>
????property>
????<property>
????????<name>yarn.scheduler.capacity.root.dev.eng.capacityname>
????????<value?>50value>
????property>
????<property>
????????<name>yarn.scheduler.capacity.root.dev.science.capacityname>
????????<value?>50value>
????property>
configuration>

我們可以看到，dev隊(duì)列又被分成了eng和science兩個(gè)相同容量的子隊(duì)列。dev的maximum-capacity屬性被設(shè)置成了75%，所以即使prod隊(duì)列完全空閑dev也不會(huì)占用全部集群資源，也就是說，prod隊(duì)列仍有25%的可用資源用來應(yīng)急。我們注意到，eng和science兩個(gè)隊(duì)列沒有設(shè)置maximum-capacity屬性，也就是說eng或science隊(duì)列中的job可能會(huì)用到整個(gè)dev隊(duì)列的所有資源（最多為集群的75%）。而類似的，prod由于沒有設(shè)置maximum-capacity屬性，它有可能會(huì)占用集群全部資源。Capacity容器除了可以配置隊(duì)列及其容量外，我們還可以配置一個(gè)用戶或應(yīng)用可以分配的最大資源數(shù)量、可以同時(shí)運(yùn)行多少應(yīng)用、隊(duì)列的ACL認(rèn)證等。

關(guān)于隊(duì)列的設(shè)置，這取決于我們具體的應(yīng)用。比如，在MapReduce中，我們可以通過mapreduce.job.queuename屬性指定要用的隊(duì)列。如果隊(duì)列不存在，我們?cè)谔峤蝗蝿?wù)時(shí)就會(huì)收到錯(cuò)誤。如果我們沒有定義任何隊(duì)列，所有的應(yīng)用將會(huì)放在一個(gè)default隊(duì)列中。

注意：對(duì)于Capacity調(diào)度器，我們的隊(duì)列名必須是隊(duì)列樹中的最后一部分，如果我們使用隊(duì)列樹則不會(huì)被識(shí)別。比如，在上面配置中，我們使用prod和eng作為隊(duì)列名是可以的，但是如果我們用root.dev.eng或者dev.eng是無效的。

2.3 FIFO Scheduler

yarn-site.xml文件

<property>
??<name>yarn.resourcemanager.scheduler.classname>
??<value>org.apache.hadoop.yarn.server.resourcemanager.fifo.FifoSchedulervalue>
property>