Apache YARN(Yet Another Resource Negotiator)是一個(gè)Hadoop集群資源管理系統(tǒng)拯刁。YARN是在Hadoop 2引入的，用以改善MapReduce的表現(xiàn)前计。但是它也足夠勝任其它的分布式計(jì)算框架。

YARN提供了一些能被請求調(diào)用的APIs枢析，并處理集群資源叼旋。但是通常用戶不會(huì)直接調(diào)用這些APIs，而是調(diào)用由分布計(jì)算框架提供的更高級別的APIs。這些更高級別的APIs基于YARN建立灾炭，并對用戶隱藏了資源管理的細(xì)節(jié)茎芋。圖4-1說明了這個(gè)情景，并顯示了一些分布式計(jì)算框架(MapReduce,Spark等等)作為YARN應(yīng)用位于集群計(jì)算層(YARN)和存儲(chǔ)層之上(HDFS和Hbase)蜈出。

圖4-1:YARN應(yīng)用

圖4-1框架表示的應(yīng)用層之上還有一層應(yīng)用田弥，如Pig,Hive和Crunch。它們都運(yùn)行在MapReduce,Spark或Tez(或同時(shí)三者)之上铡原，并不和YARN直接交互偷厦。

這一章節(jié)帶領(lǐng)大家過一遍YARN的特性，為理解第四部分章節(jié)的內(nèi)容(包括一些分布式處理框架)打下基礎(chǔ)燕刻。

YARN應(yīng)用運(yùn)行分析

YARN通過兩種一直運(yùn)行的守護(hù)進(jìn)程來提供它的核心服務(wù)只泼。一種是資源管理器(一個(gè)集群一個(gè)),管理集群中所有資源的使用，另一種是節(jié)點(diǎn)管理器酌儒，在所有節(jié)點(diǎn)上運(yùn)行辜妓，啟動(dòng)或監(jiān)控容器枯途。容器會(huì)使用分配的有限資源的集合(內(nèi)存忌怎，CPU等)執(zhí)行應(yīng)用特定的進(jìn)程。取決于YARN是如何配置的酪夷，容器可以是一個(gè)Unix進(jìn)程榴啸，也可以是一個(gè)Linux cgroup(control groups)。圖4-2顯示了YARN怎么樣運(yùn)行應(yīng)用的晚岭。

圖4-2:YARN怎么樣運(yùn)行應(yīng)用

為了運(yùn)行基于YARN的應(yīng)用鸥印，客戶端必須與資源管理器(resource manager)通信，請求它運(yùn)行一個(gè)應(yīng)用主進(jìn)程(圖4-2步驟1)坦报。資源管理器然后尋找能夠在容器中啟動(dòng)這個(gè)應(yīng)用主進(jìn)程的節(jié)點(diǎn)管理器(步驟2a和2b)库说。應(yīng)用啟動(dòng)后，具體能夠做什么取決于應(yīng)用本身片择。它可以在它所在的容器中簡單地執(zhí)行一個(gè)計(jì)算然后將結(jié)果返回給客戶端潜的。或者它可以向資源管理器請求更多的容器(步驟3)字管，以便運(yùn)行分布式計(jì)算(步驟4a和4b)啰挪。后者是MapReduce YARN應(yīng)用所做的事，我們將會(huì)在"一個(gè)MapRedue作業(yè)運(yùn)行分析"小節(jié)中詳細(xì)地學(xué)習(xí)嘲叔。

從圖4-2我們注意到亡呵，YARN本身不提供任何方法讓應(yīng)用各部分(客戶端，主進(jìn)程硫戈，進(jìn)程)間進(jìn)行通信锰什。大多數(shù)特殊的YARN應(yīng)用使用遠(yuǎn)程調(diào)用的形式(例如Hadoop的RPC)，將更新的狀態(tài)和結(jié)果傳遞回客戶端，但是這不是正常情況歇由。

資源請求

YARN對于資源請求的形式要求比較靈活卵牍。某個(gè)請求，請求多個(gè)容器沦泌，可以對每一個(gè)容器都指定需要的計(jì)算機(jī)硬件資源(內(nèi)存糊昙，CPU等)，并能夠指定位置限定的一些容器谢谦。

位置對于一些分布式的數(shù)據(jù)處理算法能夠充分高效地使用集群帶寬是很重要的释牺。所以YARN允許應(yīng)用指定它請求的容器的位置。位置限定可以指定位于某個(gè)特定的節(jié)點(diǎn)或機(jī)架回挽，或者集群中任意位置(比如:不在機(jī)架上的)的容器没咙。

有時(shí)，并不能夠滿足位置限定的條件千劈，這種情況下祭刚，要未不分配任何位置，要未墙牌，選擇放寬限定條件涡驮。例如，指定了某個(gè)節(jié)點(diǎn)喜滨，但是不可能在這個(gè)節(jié)點(diǎn)上啟動(dòng)容器(因?yàn)槠渌萜髡谒厦孢\(yùn)行)捉捅，那么YARN將會(huì)嘗試啟動(dòng)位于相同機(jī)架上的其它節(jié)點(diǎn)上的容器，或者其它節(jié)點(diǎn)也不可用時(shí)虽风，就啟動(dòng)集群中任意一個(gè)節(jié)點(diǎn)上的容器棒口。

啟動(dòng)一個(gè)容器處理HDFS塊(比方說，執(zhí)行MapReduce中的一個(gè)map任務(wù))辜膝，通常情況下无牵，應(yīng)用會(huì)請求保存了塊三個(gè)復(fù)本的那個(gè)節(jié)點(diǎn)，或者保存了這些復(fù)本的機(jī)架中的某個(gè)節(jié)點(diǎn)厂抖，如果以上都失敗了茎毁，就選擇集群中任意一個(gè)節(jié)點(diǎn)上的容器。

一個(gè)YARN容器可以在它運(yùn)行時(shí)的任意時(shí)間發(fā)起資源請求验游。例如充岛，一個(gè)應(yīng)用可以預(yù)先發(fā)起所需所有資源的請求，也可以以一種更加動(dòng)態(tài)的途徑耕蝉，即當(dāng)應(yīng)用有更改時(shí)崔梗，再動(dòng)態(tài)地請求更多資源。

Spark采取了第一種途徑垒在，在集群中啟動(dòng)固定數(shù)量的執(zhí)行器(“參看在YARN上的Spark ”章節(jié))蒜魄。另一方面，MapReduce會(huì)采取這兩種途徑。執(zhí)行map任務(wù)時(shí)會(huì)預(yù)先請求所有容器谈为，執(zhí)行reduce任務(wù)的容器不會(huì)立即啟動(dòng)旅挤，會(huì)在后面啟動(dòng)。而且伞鲫，如果有任何任務(wù)處理失敗了粘茄，將會(huì)請求額外的容器重新執(zhí)行失敗的任務(wù)。

應(yīng)用的生命周期

一個(gè)YARN應(yīng)用的生命周期可以千差萬別秕脓，從幾秒的短命應(yīng)用到可以運(yùn)行數(shù)天甚至數(shù)月的長期應(yīng)用柒瓣。可行的應(yīng)用歸類是根據(jù)應(yīng)用與作業(yè)之間的映射關(guān)系而不是應(yīng)用運(yùn)行的時(shí)間來進(jìn)行分類吠架。最簡單的情況是每一個(gè)作業(yè)對應(yīng)一個(gè)應(yīng)用芙贫，MapReduce任務(wù)采取的就是這個(gè)途徑。

第二個(gè)模式是每一個(gè)工作流運(yùn)行一個(gè)應(yīng)用或多個(gè)作業(yè)(可能是不相關(guān)的作業(yè))運(yùn)行一個(gè)應(yīng)用傍药。這種途徑比第一個(gè)途徑更高效磺平，因?yàn)閼?yīng)用容器可以被多個(gè)作業(yè)共用，也可以緩存多個(gè)作業(yè)產(chǎn)生的中間數(shù)據(jù)拐辽。Spark就是一個(gè)使用這種模式的例子拣挪。

第三個(gè)模式是被不同用戶共享的長生命周期應(yīng)用。這種應(yīng)用經(jīng)常是以某種配合的角色發(fā)揮作用薛训。例如Apache Slider就有一個(gè)長期運(yùn)行的應(yīng)用管理器媒吗，這個(gè)應(yīng)用管理器作用是啟動(dòng)集群中的其它應(yīng)用仑氛。Impala通過這個(gè)途徑來提供一個(gè)代理應(yīng)用乙埃，用于響應(yīng)Impala實(shí)體機(jī)的資源請求。通過使用這種"一直運(yùn)行"的應(yīng)用管理器锯岖，用戶可以獲得低延遲響應(yīng)介袜，因?yàn)楫?dāng)用戶查詢時(shí)不需要啟動(dòng)一個(gè)新的應(yīng)用管理器了。

構(gòu)建YARN應(yīng)用

從頭開始寫一個(gè)YARN應(yīng)用是相當(dāng)復(fù)雜地出吹，但是大多數(shù)情況不必要遇伞。因?yàn)榭梢允褂靡粋€(gè)已經(jīng)存在的應(yīng)用，進(jìn)行調(diào)整以適應(yīng)自己地需求捶牢。例如鸠珠，如果你對有向無環(huán)圖(DAG)感興趣，那么Spark或者Tez是合適的秋麸，或者對流式處理感興趣渐排，Spark，Samza或者Storm是合適的灸蟆。

有很多工程用于簡化構(gòu)建一個(gè)YARN應(yīng)用時(shí)的操作驯耻。早先提到的Apache Slider讓現(xiàn)有的分布式應(yīng)用運(yùn)行在YARN上成為可能。用戶可以在集群上運(yùn)行他們自己的應(yīng)用(例如HBase)而不影響其它用戶，不同的用戶可以運(yùn)行同一個(gè)應(yīng)用不同的版本可缚。Slider能夠改變應(yīng)用運(yùn)行的節(jié)點(diǎn)數(shù)量霎迫，掛起和恢復(fù)運(yùn)行某個(gè)應(yīng)用。

Apache Twill與Slider相似帘靡，但除了以上功能知给，另外還可以提供一個(gè)簡單的編程模型，可以開發(fā)基于YARN的分布式應(yīng)用描姚。Twill允許你定義實(shí)現(xiàn)了Java Runnable接口的集群進(jìn)程炼鞠，然后在集群的YARN容器中運(yùn)行它們。Twill還提供實(shí)時(shí)日志(記錄可執(zhí)行進(jìn)程的事件以流形式返回客戶端)和命令消息(將客戶端的命令發(fā)送給可執(zhí)行進(jìn)程)轰胁。

當(dāng)以上選擇都不能滿足要求時(shí)谒主，例如需要開發(fā)一個(gè)能夠進(jìn)行復(fù)雜時(shí)間調(diào)度的YARN應(yīng)用。那么YARN工程中有一個(gè)分布式的shell應(yīng)用可以做為如何開發(fā)YARN應(yīng)用的例子赃阀，它演示了如何使用YARN APIs在客戶端霎肯、應(yīng)用管理器與YARN守護(hù)進(jìn)程之間交互通信。

YARN與MapReduce 1比較

在Hadoop最初版本(版本1或更早)中的MapReduce有時(shí)被稱為"MapReduce 1"榛斯，以和MapReduce 2區(qū)分開观游。MapReduce 2是Hadoop 2或之后的版本，它使用了YARN驮俗。

有一件重要的事情懂缕，那就是舊的和新的MapReduce APIs與MapReduce1和MapReduce2并不是一回事。APIs是面向用戶王凑，客戶端的搪柑，決定了你如何寫MapReduce程序(參看附錄D)，然而MapReduce1和2僅僅是運(yùn)行MapReduce程序不同的方法索烹。舊的和新的MapReduce APIs都可以在MapReduce1和2中運(yùn)行工碾。

在MapReduce1中，有兩種控制作業(yè)執(zhí)行過程的守護(hù)進(jìn)程百姓，一種是jobtracker渊额，一種是一個(gè)或多個(gè)tasktracker。jobtracker組合系統(tǒng)中需要運(yùn)行的所有作業(yè)垒拢，然后分配運(yùn)行在tasktracker上的任務(wù)旬迹。Tasktracker執(zhí)行任務(wù)，并將進(jìn)度報(bào)告發(fā)送給jobtracker求类，jobtracker將會(huì)保存每一個(gè)作業(yè)的整個(gè)進(jìn)度奔垦。如果一個(gè)任務(wù)失敗了，jobtracker將會(huì)在另一個(gè)tasktracker上啟動(dòng)它仑嗅。

在MapReduce1中宴倍，jobtracker既關(guān)心作業(yè)的調(diào)度(匹配tasktracker與task)张症，又關(guān)心任務(wù)的進(jìn)度(跟蹤任務(wù)，重啟失敗的任務(wù)鸵贬，顯示任務(wù)俗他，記錄任務(wù)，例如維護(hù)任務(wù)數(shù))阔逼。相對地兆衅，在YARN中，這些責(zé)任由不同的實(shí)體處理：資源管理器和應(yīng)用管理器(一個(gè)MapReduce作業(yè)一個(gè)應(yīng)用管理器)嗜浮。jobtracker還需要存儲(chǔ)已經(jīng)完成的作業(yè)的歷史記錄羡亩。當(dāng)然也可以單獨(dú)運(yùn)行一個(gè)歷史記錄服務(wù)來給jobtracker減負(fù)。在YARN中危融，具有相同角色的是時(shí)間線服務(wù)畏铆，它存儲(chǔ)應(yīng)用的歷史記錄。

在YARN應(yīng)用中吉殃，與tasktracker等效的是節(jié)點(diǎn)管理器辞居。MapReduce1與YARN的功能映射關(guān)系如表4-1所示:

設(shè)計(jì)YARN的目的是解決MapReduce 1的一些局限性瓦灶。使用YARN有如下好處：

• 擴(kuò)展性
  YARN可以運(yùn)行在比MapReduce 1更大的集群上。當(dāng)達(dá)到4000節(jié)點(diǎn)或4000個(gè)任務(wù)時(shí)抱完，MapReduce 1就達(dá)到了瓶頸贼陶。因?yàn)閖obtracker必須要管理作業(yè)和任務(wù)。YARN通過使用分開的資源管理與應(yīng)用管理的結(jié)構(gòu)克服了這個(gè)限制巧娱，YARN設(shè)計(jì)的目的是能擴(kuò)展到10000個(gè)節(jié)點(diǎn)和100000個(gè)任務(wù)碉怔。

• 高可用性
  HA(High availability 高可用)是當(dāng)正在服務(wù)的實(shí)體機(jī)故障時(shí)，通過復(fù)制所需的狀態(tài)和數(shù)據(jù)到另外一臺(tái)實(shí)體機(jī)上家卖，執(zhí)行所需的工作眨层，繼續(xù)提供服務(wù)來實(shí)現(xiàn)的庙楚。然而jobtracker內(nèi)存中大量快速地改變復(fù)雜的狀態(tài)(例如上荡，每幾秒鐘每一個(gè)task狀態(tài)就會(huì)更新一次)使HA應(yīng)用到j(luò)obtracker變得非常困難。
  YARN通過將jobtracker的功能分解到資源管理器和應(yīng)用管理器馒闷，使服務(wù)高度可用變成了一個(gè)可以分開克服的問題酪捡。那就是為資源管理器提供HA，然后為YARN應(yīng)用(以每一個(gè)應(yīng)用為基礎(chǔ)單位)提供HA纳账。實(shí)際小逛薇，Hadoop 2支持MapReduce作業(yè)中的資源 管理器和應(yīng)用管理器HA。YARN中的故障恢復(fù)將在第7章"故障"小節(jié)中詳細(xì)講解疏虫。

• 實(shí)用性
  在MapReduce 1中永罚，每個(gè)tasktracker通過一個(gè)位置固定啤呼，大小固定的"槽"中配置，槽分為map槽和reduce槽呢袱。map槽只能用于運(yùn)行map任務(wù)官扣，相應(yīng)的，reduce槽只能用于reduce任務(wù)羞福。
  在YARN中惕蹄，一個(gè)節(jié)點(diǎn)管理器管理一個(gè)資源池，而不是數(shù)量固定的指定的槽治专。YARN上的運(yùn)行的MapReduce不會(huì)出現(xiàn)由于集群中僅僅有map槽卖陵，reduce任務(wù)必須等待的情況。這種情況可能發(fā)生在MapReduce 1中.YARN中张峰，如果運(yùn)行任務(wù)時(shí)泪蔫，資源可得，那么應(yīng)用就應(yīng)該能夠使用它們喘批。
  而且鸥滨，YARN中的資源是精細(xì)化管理的，所以應(yīng)用可以請求它所需要的資源谤祖，而不必請求一個(gè)槽婿滓。對于某些特殊的任務(wù)來說，槽太大的話粥喜，會(huì)造成資源浪費(fèi)凸主，太小的話，造成任務(wù)失敗额湘。

• 多用性
  從某些方面來說卿吐，YARN最大的優(yōu)勢是它使Hadoop能夠使用除了MapReduce其它類型的分布式應(yīng)用。MapReduce僅僅是其中一個(gè)YARN應(yīng)用锋华。

  用戶甚至能夠在同一個(gè)集群中運(yùn)行不同版本的MapReduce應(yīng)用嗡官。這就使得升級MapReduce變得更加容易管理。(注意毯焕，MapReduce中的某些部分衍腥，例如作業(yè)歷史記錄服務(wù)器，shuffle處理器和YARN本身仍然需要整個(gè)集群一起升級纳猫。)

既然Hadoop 2被廣泛使用婆咸，而且是最新的穩(wěn)定版本邮屁。這本書中剩余部分內(nèi)容中"MapReduce"指的就是"MapReduce 2"但壮。第7章將會(huì)詳細(xì)地講解MapReduce如何運(yùn)行在YARN之上得哆。

YARN中的調(diào)度計(jì)劃

理想情況下宣肚，一個(gè)YARN應(yīng)用的請求應(yīng)該立刻響應(yīng)痹仙。然而的畴，現(xiàn)實(shí)情況是灰嫉，資源是有限的扼倘，而且集群繁忙時(shí)，應(yīng)用經(jīng)常需要等待直到它的部分請求得到滿足需五。YARN調(diào)度器的工作就是根據(jù)一些既定的規(guī)則給應(yīng)用分配資源起趾。調(diào)度通常是一個(gè)困難的問題，沒有一個(gè)最好的規(guī)則警儒。這也就是為什么YARN提供調(diào)度器和可配置規(guī)則兩種選擇的原因训裆。我們接下來詳細(xì)看看。

調(diào)度器

YARN中有三種調(diào)度器：FIFO調(diào)度器蜀铲，容量調(diào)度器和公平調(diào)度器边琉。FIFO調(diào)度器將應(yīng)用放在一個(gè)隊(duì)列中，按照它們提交的順序運(yùn)行它們(先進(jìn)记劝，先出)变姨。隊(duì)列中第一個(gè)應(yīng)用的請求首先滿足。一旦它的請求被滿足了之后厌丑，就服務(wù)隊(duì)列中下一個(gè)應(yīng)用定欧，依次類推。

FIFO的優(yōu)點(diǎn)是容易理解怒竿，而且不需要配置砍鸠。但是它不適合資源共享的集群。一般大的應(yīng)用會(huì)用到集群中所有資源耕驰，如果使用FIFO爷辱，每一個(gè)應(yīng)用必須要按序等待。在資源共享的集群中朦肘，最好使用容量調(diào)度器或者公平調(diào)度器饭弓。二者都會(huì)使那些運(yùn)行時(shí)間長的作業(yè)能夠在合理時(shí)間內(nèi)完成，而且也使得用戶在執(zhí)行少量的臨時(shí)的并發(fā)查詢時(shí)媒抠，能夠在合理的時(shí)間內(nèi)返回結(jié)果弟断。

調(diào)度器之間的區(qū)別如圖4-3所示，我們可以看到趴生，F(xiàn)IFO調(diào)度模式(i)下阀趴，小的作業(yè)必須要等待大的作業(yè)完成之后才能執(zhí)行。

在容量調(diào)度模式(ii)下,一個(gè)分開的專用的隊(duì)列允許小的作業(yè)一提交就能夠執(zhí)行冲秽。這是以整個(gè)集群的可利用空間為代價(jià)的舍咖，因?yàn)樾枰獮檫@個(gè)專用隊(duì)列預(yù)留空間。這也意味著大的作業(yè)比使用FIFO調(diào)度完成的晚锉桑。

在公平調(diào)度模式(iii)下，不需要預(yù)留一定數(shù)量的空間窍株。因?yàn)樗鼤?huì)動(dòng)態(tài)的平衡所有運(yùn)行的作業(yè)所需的空間資源民轴。第一個(gè)(大)作業(yè)啟動(dòng)后(目前是集群中唯一運(yùn)行的作業(yè))攻柠，它會(huì)獲取集群中所有的資源，當(dāng)?shù)诙€(gè)(小)作業(yè)啟動(dòng)后后裸，它將把一半資源分配給第二個(gè)作業(yè)瑰钮。這樣，每一個(gè)作業(yè)都能分到相同數(shù)量的資源微驶。

注意到浪谴，第二個(gè)作業(yè)啟動(dòng)到它接收到所分的資源有一定的延遲。因?yàn)楸仨毜却Y源從第一個(gè)作業(yè)使用的容器中釋放出來后才能使用因苹。在小作業(yè)完成苟耻，并不再請求資源后，大的作業(yè)又將使用集群中所有的資源扶檐。這個(gè)模式造成集群的高占用空間和小作業(yè)及時(shí)的完成凶杖。

圖4-3對比了這三個(gè)調(diào)試器基本操作。接下來的兩部分款筑，我們將學(xué)習(xí)容量和公平調(diào)度器中一些高級的配置智蝠。

圖4-3:分別在FIFO(i)，容量(ii)奈梳，公平調(diào)度(iii)模式下運(yùn)行一個(gè)大作業(yè)和一個(gè)小作業(yè)的集群空間使用量

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

容量調(diào)度器允許按照組織的行形式共享Hadoop集群資源杈湾，每一個(gè)組織都分配了總集群資源中的一部分資源。每一個(gè)組織都設(shè)一個(gè)專用的隊(duì)列攘须∶兀可以配置隊(duì)列使用集群中指定的部分資源。隊(duì)列也許可以進(jìn)一步按層級劃分阻课，使得每一個(gè)組織可以將它的資源分配給不同組的用戶叫挟。在隊(duì)列中，應(yīng)用按照FIFO規(guī)則進(jìn)行調(diào)度限煞。

正如我們在圖4-3看到的那樣抹恳，單個(gè)作業(yè)不能使用超過它所在隊(duì)列容量的資源。然而署驻，如果隊(duì)列中的作業(yè)超過一個(gè)奋献，并且有空閑的資源，那么容量調(diào)度器也許會(huì)將剩余的資源分配給這個(gè)隊(duì)列中的作業(yè)旺上，即使會(huì)超出隊(duì)列的容量(應(yīng)分配的資源)^[1]瓶蚂，這就是所熟知的"彈性隊(duì)列"。

正常操作時(shí)宣吱，容量調(diào)度器不會(huì)強(qiáng)制地殺死作業(yè)來回收容器^[2]窃这，所以如果一個(gè)隊(duì)列由于缺少請求而容量不夠，然后增加請求征候，如果其它隊(duì)列中作業(yè)完成杭攻，有資源從容器中釋放出來祟敛，隊(duì)列將會(huì)占用其它隊(duì)列的資源。通過配置隊(duì)列的最大容量可以限制隊(duì)列不占用其它隊(duì)列太多資源兆解。但這是以隊(duì)列的彈性為代價(jià)馆铁，當(dāng)然，通過不斷嘗試與錯(cuò)誤锅睛，應(yīng)該能找到一個(gè)合理的平衡點(diǎn)埠巨。

假設(shè)隊(duì)列層級如下面這樣:

示例4-1顯示了一個(gè)容量調(diào)度器配置文件，這個(gè)配置文件叫做capacity-scheduler.xml现拒。對應(yīng)于上面的層級辣垒，在root隊(duì)列下定義了兩個(gè)隊(duì)列，prod,dev具练，分別占40%和60%的資源乍构。注意，可以通過屬性yarn.scheduler.capacity.<queue-path>.<sub-property> 來配置隊(duì)列特殊的屬性扛点。<queue-path>是隊(duì)列的層級路徑(以點(diǎn)分隔)哥遮，例如root.prod。

示例:4-1:容量調(diào)度器的基本配置文件
<?xml version="1.0"?>
<configuration>
  <property>
    <name>yarn.scheduler.capacity.root.queues</name>
    <value>prod,dev</value>
 </property>
 <property>
   <name>yarn.scheduler.capacity.root.dev.queues</name>
   <value>eng,science</value>
</property>
<property>
    <name>yarn.scheduler.capacity.root.prod.capacity</name>
    <value>40</value>
</property>
<property>
    <name>yarn.scheduler.capacity.root.dev.capacity</name>
    <value>60</value> 
 </property>
 <property>
    <name>yarn.scheduler.capacity.root.dev.maximum-capacity</name>
    <value>75</value>
 </property>
 <property>
     <name>yarn.scheduler.capacity.root.dev.eng.capacity</name>
     <value>50</value>
 </property>
 <property>
   <name>yarn.scheduler.capacity.root.dev.science.capacity</name>
    <value>50</value>
 </property>
</configuration>

正如你看到的那樣陵究，dev隊(duì)列進(jìn)一步分成了相同大小的eng和science隊(duì)列眠饮。所以當(dāng)prod隊(duì)列空閑的時(shí)候，dev隊(duì)列沒有使用集群所有的資源铜邮，它最大的使用資源設(shè)置為75%仪召。換句話說，prod隊(duì)列總是有25%資源可以立即使用松蒜。因?yàn)槠渌?duì)列沒有設(shè)置最大資源扔茅，eng或者science隊(duì)列中的作業(yè)可以使用dev隊(duì)列所有的資源(最多占集群的75%)，或者對于prod隊(duì)列來說秸苗，實(shí)際可使用集群所有資源召娜。

除了配置隊(duì)列的層級以及容量，還可以控制一個(gè)用戶或應(yīng)用可以分配的資源最大數(shù)量惊楼，同時(shí)可以運(yùn)行的應(yīng)用數(shù)玖瘸，隊(duì)列的ACLs控制(權(quán)限控制)。詳細(xì)說明請參考Hadoop: Capacity Scheduler檀咙。

隊(duì)列指定
指定應(yīng)用放在哪個(gè)隊(duì)列是在應(yīng)用端進(jìn)行指定的雅倒。例如，在MapReduce
中弧可，你將屬性mapreduce.job.queue.name的值設(shè)置為你想存放的隊(duì)列的名字蔑匣。如果指定的隊(duì)列名不存在，將會(huì)在提交作業(yè)時(shí)報(bào)出錯(cuò)誤。如果沒有指定隊(duì)列殖演，則應(yīng)用會(huì)放在叫做default的隊(duì)列中氧秘。

對于容量調(diào)度器而言年鸳，隊(duì)列名稱是層級結(jié)構(gòu)最后一級的名字趴久，全路徑名稱將不識(shí)別。所以搔确，拿先前的配置例子來講彼棍，prod和eng這樣寫沒問題，但root.dev.eng和dev.eng就不行膳算。

公平調(diào)度器的配置

公平調(diào)度器試著使所有正運(yùn)行的應(yīng)用得到相同的資源座硕。圖4-3顯示了在同一個(gè)隊(duì)列中應(yīng)用是怎么樣平均分配資源的。然而涕蜂，對于多個(gè)隊(duì)列华匾，仍然可以平均分配，下面將加以說明机隙。

在公平調(diào)度器上下文中蜘拉，隊(duì)列和池可以互換使用，意思是一樣的

圖4-4:用戶隊(duì)列間的資源分配

啟用公平調(diào)度器
使用哪個(gè)調(diào)度器是通過yarn.resourcemanager.scheduler.class屬性決定的。默認(rèn)是容量調(diào)度器(在有些hadoop分布式系統(tǒng)，例如CDH中湃交，默認(rèn)是使用公平調(diào)度器)熟空。通過在yarn-site.xml配置文件中配置yarn.resourcemanager.scheduler.class來改變默認(rèn)的調(diào)度器，它的值是調(diào)度器的全路徑類名:org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler搞莺。

隊(duì)列配置
公平調(diào)度器在一個(gè)叫做fair-scheduler.xml的配置文件中配置息罗，這個(gè)配置文件在加載classpath指定的類時(shí)一同被加載，配置文件的名字可以通過屬性yarn.scheduler.fair.allocation.file設(shè)置才沧。每一個(gè)應(yīng)用被放在以用戶名命名的隊(duì)列中迈喉，當(dāng)用戶提交第一個(gè)應(yīng)用時(shí)，隊(duì)列就會(huì)被動(dòng)態(tài)地創(chuàng)建温圆。

在配置文件中挨摸，配置每一個(gè)隊(duì)列，可以像容量調(diào)度器一樣按照層級進(jìn)行配置岁歉。例如得运，我們可以按照我們在容量調(diào)度器中定義的那樣定義prod和dev隊(duì)列，如示例4-2锅移。

示例4-2:公平調(diào)度器的配置文件
<?xml version="1.0"?>
<allocations>
   <defaultQueueSchedulingPolicy>fair</defaultQueueSchedulingPolicy>
<queue name="prod">
  <weight>40</weight>
  <schedulingPolicy>fifo</schedulingPolicy>
</queue>
<queue name="dev">
   <weight>60</weight>
   <queue name="eng" />
   <queue name="science" />
</queue>
<queuePlacementPolicy>
   <rule name="specified" create="false" />
   <rule name="primaryGroup" create="false" />
    <rule name="default" queue="dev.eng" />
</queuePlacementPolicy>
</allocations>

隊(duì)列的層級定義通過使用嵌套的queue節(jié)點(diǎn)熔掺。所有的隊(duì)列是root隊(duì)列的子隊(duì)列，即使實(shí)現(xiàn)上沒有嵌套在root隊(duì)列節(jié)點(diǎn)下帆啃。這里瞬女，我們又將dev隊(duì)列分成eng和science兩個(gè)子隊(duì)列。

隊(duì)列可以有重量努潘，用于公平分享資源時(shí)的計(jì)算诽偷。在這個(gè)例子中，集群將prod和dev隊(duì)列按照40:60的比例分配資源疯坤，這樣分配是公平的报慕。eng和science沒有指定重量，所以它們是平均分配的压怠。重量和比例不完全一樣眠冈，這個(gè)示例中，我們使用加起來等于100的重量只是為了簡便起見菌瘫。我們也能給prod和dev隊(duì)列的重量都指定2或3.

當(dāng)設(shè)置重量的時(shí)候蜗顽，記得考慮到"默認(rèn)隊(duì)列"和動(dòng)態(tài)生成的隊(duì)列(例如那些以客戶命名的隊(duì)列)。沒有在配置文件中指定的隊(duì)列雨让，重量都是1雇盖。

這些隊(duì)列可以有不同的調(diào)度規(guī)則。默認(rèn)的規(guī)則可以通過頂級節(jié)點(diǎn)defaultQueueSchedulingPolicy設(shè)置栖忠。如果省略了這個(gè)節(jié)點(diǎn)崔挖，將使用公平調(diào)度規(guī)則贸街。不能只看它的名字是“公平”，公平調(diào)度器也支持FIFO(fifo)規(guī)則和后面將講到的優(yōu)勢資源公平規(guī)則(drf Dominant Resource Fairness)狸相。

某個(gè)特定隊(duì)列的調(diào)度規(guī)則可以通過它的schedulingPolicy屬性覆蓋薛匪。如上面的配置文件，prod隊(duì)列使用FIFO調(diào)度規(guī)則脓鹃，因?yàn)槲覀兿胍恳粋€(gè)作業(yè)按順序執(zhí)行并且能在最短的時(shí)間內(nèi)執(zhí)行完逸尖。注意一點(diǎn)的是，prod和dev隊(duì)列仍然使用公平調(diào)度規(guī)則進(jìn)行資源的劃分将谊，eng和science隊(duì)列也是一樣冷溶。

雖然沒有在以上配置文件中顯示出來渐白，但還可以配置隊(duì)列能使用的最小或最大資源空間尊浓，和隊(duì)列中最多運(yùn)行的應(yīng)用數(shù)(詳細(xì)配置參看此頁)。最小資源空間不是一個(gè)硬性限制纯衍，而是調(diào)度器用來優(yōu)先分配資源的栋齿。例如如果兩個(gè)隊(duì)列的資源都不夠，那么離最小資源分配要求差距最大的將優(yōu)先分配到資源襟诸。最小資源的設(shè)置還可用于優(yōu)先占有瓦堵，稍后將討論到。

隊(duì)列指定
公平調(diào)度器使用一定的規(guī)則來決定應(yīng)用放在哪個(gè)隊(duì)列中歌亲。如示例4-2菇用，queuePlacementPolicy節(jié)點(diǎn)包含一系列規(guī)則，系統(tǒng)將按順序嘗試每一條規(guī)則陷揪，直到匹配到一條惋鸥。第一條規(guī)則，specified指定應(yīng)用放在哪一個(gè)隊(duì)列中悍缠，如果沒有指定或指定的隊(duì)列不存在卦绣，這條規(guī)則不符合，將嘗試下一條規(guī)則飞蚓。primaryGroup規(guī)則指定應(yīng)用放在與用戶的主Unix組名相同的隊(duì)列中滤港。如果不存在這樣的隊(duì)列，則嘗試下一條規(guī)則趴拧。default規(guī)則是上面的規(guī)則都不滿足時(shí)溅漾，系統(tǒng)總是會(huì)嘗試的規(guī)則，此條規(guī)則將應(yīng)用放在dev.eng隊(duì)列中著榴。

queuePlacementPolicy節(jié)點(diǎn)整個(gè)可以省略不配置添履。如果是這樣的話，就跟指定了下面的配置是一樣的兄渺。

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

換句話說缝龄，除非隊(duì)列顯示地聲明汰现，否則將尋找與用戶的名字相同的隊(duì)列，如果有必要叔壤，會(huì)創(chuàng)建與用戶的名稱一樣的隊(duì)列瞎饲。

另一個(gè)簡單的隊(duì)列指定規(guī)則是所有應(yīng)用指定放于相同(默認(rèn))隊(duì)列中。這樣炼绘，每個(gè)應(yīng)用都會(huì)分到相等的資源嗅战，而不是按照用戶。對應(yīng)的規(guī)則如下:

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

也可以不使用配置文件來設(shè)置規(guī)則俺亮，那就是將屬性yarn.scheduler.fair.user-as-default-queue設(shè)置為false驮捍，這樣應(yīng)用就會(huì)都進(jìn)入默認(rèn)隊(duì)列中，而不是按照用戶分的隊(duì)列中脚曾。另外东且，yarn.scheduler.fair.allow-undeclared-pools應(yīng)該設(shè)置為false，這樣用戶就不能夠在運(yùn)行時(shí)動(dòng)態(tài)創(chuàng)建隊(duì)列了本讥。

優(yōu)先占有
當(dāng)一個(gè)作業(yè)提交到一臺(tái)繁忙的集群中的一個(gè)空隊(duì)列中時(shí)珊泳，這個(gè)作業(yè)不會(huì)立即啟動(dòng)，直到資源從正在運(yùn)行在這個(gè)集群中的其它作業(yè)釋放出來后才會(huì)啟動(dòng)拷沸。為了使一個(gè)作業(yè)啟動(dòng)的時(shí)間是可預(yù)料的色查，公平調(diào)度器允許優(yōu)先占有。

優(yōu)先占有意思是調(diào)度器可以釋放那些占用的資源超過它們應(yīng)分配資源的隊(duì)列正在使用的容器撞芍，然后分配給那些不夠它們本應(yīng)該分配的資源的隊(duì)列秧了。注意優(yōu)先占有會(huì)降低整個(gè)集群的效率，因?yàn)槿萜鹘K止后序无，容器之前運(yùn)行的任務(wù)需要重新執(zhí)行验毡。

如果將屬性yarn.scheduler.fair.preemption設(shè)置為true，則會(huì)啟用整個(gè)集群的優(yōu)先占有愉镰。有兩個(gè)相關(guān)的優(yōu)先占有超時(shí)設(shè)置米罚。一個(gè)針對最小資源的，一個(gè)針對公平分配資源的丈探，都是以秒為單位录择。默認(rèn)情況下，不會(huì)設(shè)置超時(shí)碗降，所以你需要至少設(shè)置一個(gè)隘竭，以便讓可以占有容器。

如果隊(duì)列等到了超時(shí)的時(shí)間還沒到分到保證的最少資源讼渊。那么調(diào)度器也許會(huì)占其它的容器动看。通過在配置文件設(shè)置頂級屬性defaultMinSharePreemptionTimeout,可以對所有隊(duì)列設(shè)置超時(shí)的時(shí)間。如果想單獨(dú)對某個(gè)隊(duì)列設(shè)置爪幻，可以在隊(duì)列節(jié)點(diǎn)中設(shè)置minSharePreemptionTimeout菱皆。

同樣地须误，如果一個(gè)隊(duì)列占的資源不到它應(yīng)得資源的50%，這種狀態(tài)持續(xù)的時(shí)間達(dá)到了設(shè)置的公平分配的超時(shí)時(shí)間仇轻，那么調(diào)度器也會(huì)去占其它容器京痢。通過在配置文件設(shè)置頂級屬性defaultFairSharePreemptionTimeout，可以對所有隊(duì)列設(shè)置超時(shí)的時(shí)間篷店。如果想單獨(dú)對某個(gè)隊(duì)列設(shè)置祭椰，可以在隊(duì)列節(jié)點(diǎn)中設(shè)置fairSharePreemptionTimeout。隊(duì)列現(xiàn)占用的資源與應(yīng)得資源的占比默認(rèn)是0.5疲陕，我們可以通過配置屬性defaultFairSharePreemptionThreshold和fairSharePreemptionThreshold(此屬性針對單個(gè)隊(duì)列)改變方淤。

延遲調(diào)度

所有的YARN調(diào)度器盡量在請求的位置上執(zhí)行應(yīng)用。在一個(gè)繁忙的集群中蹄殃，如果應(yīng)用請求某個(gè)節(jié)點(diǎn)携茂，此時(shí)，正好其它容器正在這個(gè)節(jié)點(diǎn)上運(yùn)行窃爷。那么系統(tǒng)就不會(huì)嚴(yán)格按照請求來了邑蒋，它會(huì)在相同的機(jī)架上再找另外一個(gè)容器。然而按厘，實(shí)際上，如果等待一點(diǎn)時(shí)間(不超過幾秒)就會(huì)增加能分配到請求節(jié)點(diǎn)上容器的機(jī)率钱慢，因此逮京，也增加了集群的效率。這個(gè)特性叫做"延遲調(diào)度"束莫。容量調(diào)度器和公平調(diào)度器都支持這個(gè)特性懒棉。

YARN集群中的每一個(gè)節(jié)點(diǎn)管理器都會(huì)周期性地向資源管理器發(fā)送一個(gè)心跳(默認(rèn)1秒1次)。心跳會(huì)帶著節(jié)點(diǎn)管理器上正運(yùn)行容器的信息還有能提供給新容器的資源信息览绿，所以每一次心跳對一個(gè)應(yīng)用來說是一個(gè)潛在的調(diào)度啟用新容器的機(jī)會(huì)策严。

當(dāng)采取延遲調(diào)度時(shí)，調(diào)度器不會(huì)簡單地使用它得到的第一次調(diào)度機(jī)會(huì)饿敲，而是等待一個(gè)指定的最大的錯(cuò)過的調(diào)度機(jī)會(huì)數(shù)妻导，如果達(dá)到了最大的錯(cuò)過的調(diào)度機(jī)會(huì)數(shù)，則會(huì)不嚴(yán)格按照請求來分配節(jié)點(diǎn)并準(zhǔn)備在下一次調(diào)度機(jī)會(huì)來時(shí)進(jìn)行調(diào)度怀各。

對于容量調(diào)度器而言倔韭，延遲調(diào)度通過yarn.scheduler.capacity.node-locality-delay屬性進(jìn)行配置，將此屬性配置成一個(gè)正整數(shù)瓢对，表示調(diào)度器錯(cuò)過的調(diào)度機(jī)會(huì)數(shù)寿酌，如果達(dá)到了調(diào)度機(jī)會(huì)數(shù)，請求的那個(gè)節(jié)點(diǎn)仍然不能啟用新容器硕蛹，則將不會(huì)按照請求來執(zhí)行而是在相同機(jī)架上尋找任意一個(gè)節(jié)點(diǎn)醇疼。

公平調(diào)度器也使用調(diào)度機(jī)會(huì)數(shù)也決定延遲硕并，然而它是用集群大小的比例來表示的。例如秧荆，將屬性yarn.scheduler.fair.locality.threshold.node設(shè)置為0.5鲤孵，意思是調(diào)度器應(yīng)該等到集群中一半的節(jié)點(diǎn)都已經(jīng)提供了調(diào)度機(jī)會(huì)了，請求還沒有滿足時(shí)辰如，將會(huì)在相同機(jī)架中尋找另外一個(gè)節(jié)點(diǎn)普监。相應(yīng)地，還有一個(gè)屬性yarn.scheduler.fair.locality.threshold.rack設(shè)置機(jī)架的閾值琉兜，達(dá)到閾值后凯正，將選擇另外一個(gè)機(jī)架，而不是請求的節(jié)點(diǎn)所在的機(jī)架豌蟋。

高占比資源公平分配

當(dāng)只需要調(diào)度一種資源時(shí)廊散，例如內(nèi)存，不管是使用容量調(diào)度器還是公平調(diào)度器都很容易分配梧疲。如果有兩個(gè)用戶的應(yīng)用需要運(yùn)行允睹，你可以通過比較兩個(gè)應(yīng)用所需要的內(nèi)存來進(jìn)行分配。然而幌氮，當(dāng)有多種類型資源時(shí)缭受，事情就會(huì)變得更復(fù)雜一些。如果一個(gè)用戶的應(yīng)用需要大量的CPU该互，但是卻需要少量的內(nèi)存米者，其它用戶需要少量CPU，卻需要大量內(nèi)存宇智，那么這兩個(gè)應(yīng)用該怎么比較呢蔓搞？

YARN框架中的調(diào)度器解決這個(gè)問題所使用的方法是看看每一個(gè)用戶的高占比資源是多少，然后使用這些高占比的資源做為集群資源占用的標(biāo)準(zhǔn)随橘。這種方法被稱為"高占比資源公平分配或簡稱DRF"^[3]喂分。下面用一個(gè)簡單的例子加以說明。

假設(shè)一個(gè)集群一共有100個(gè)CPU和10TB的內(nèi)存机蔗。應(yīng)用A申請2CPU蒲祈，300GB內(nèi)存的容器，應(yīng)用B則申請6CPU蜒车，100GB讳嘱。A請求的資源分別占集群總資源的2%,3%，所以內(nèi)存是A應(yīng)用的高占比資源酿愧，因?yàn)?%比2%大沥潭。B請求的資源分別占集群總資源的6%,1%，所以CPU是高占比資源嬉挡《鄹耄可以看出汇恤，就高占比資源而言，B應(yīng)用請求的資源是A應(yīng)用的2倍(6%vs3%)拔恰，所以在公平分配原則下因谎，B應(yīng)用分到的容器數(shù)將是A應(yīng)用分到的一半。

默認(rèn)DRF沒有啟用颜懊，所以在資源計(jì)算中财岔，僅僅只考慮內(nèi)存，不考慮CPU河爹。容量調(diào)度器通過將capacity-scheduler.xml配置文件中的屬性yarn.scheduler.capacity.resource-calculator的值配置為org.apache.hadoop.yarn.util.resource.DominantResourceCalculator來啟用DRF匠璧。

至于公平調(diào)度器，則通過在配置文件配置頂級元素QueueSchedulingPolicy的值為drf啟用DRF咸这。

延伸閱讀

這一章簡單的概括性了解了一下YARN夷恍。如果想更詳細(xì)地了解，可以看Arun C. Murthy等人寫的《Apache Hadoop YARN》這本書媳维。

本文是筆者翻譯自《OReilly.Hadoop.The.Definitive.Guide.4th.Edition》第一部分第4章酿雪，后續(xù)將繼續(xù)翻譯其它章節(jié)。雖盡力翻譯侄刽，但奈何水平有限指黎，錯(cuò)誤再所難免，如果有問題唠梨，請不吝指出袋励！希望本文對你有所幫助。

1. 如果屬性yarn.scheduler.capacity.<queue-path>.user-limit-factor值比默認(rèn)的1大当叭，則作業(yè)允許使用超過隊(duì)列容量的資源 ?

2. 然而，容量調(diào)度器可以進(jìn)行預(yù)置進(jìn)程保護(hù)盖灸， 資源管理器可以要求應(yīng)用釋放容器以平衡資源容量 ?

3. DRF是Ghodsi等人在2011年3月份發(fā)表的《高占比資源公平分配:多種資源的公平分配》這篇文章里提出來的 ?