一、引言
Yarn在Hadoop的生態(tài)系統(tǒng)中擔(dān)任了資源管理和任務(wù)調(diào)度的角色。在討論其構(gòu)造器之前先簡單了解一下Yarn的架構(gòu)。
上圖是Yarn的基本架構(gòu)，其中ResourceManager是整個架構(gòu)的核心組件，它負(fù)責(zé)整個集群中包括內(nèi)存、CPU等資源的管理；ApplicationMaster負(fù)責(zé)應(yīng)用程序在整個生命周期的任務(wù)調(diào)度；NodeManager負(fù)責(zé)本節(jié)點上資源的供給和隔離；Container可以抽象的看成是運行任務(wù)的一個容器。本文討論的調(diào)度器是在ResourceManager組建中進(jìn)行調(diào)度的，接下來就一起研究一下包括FIFO調(diào)度器、Capacity調(diào)度器、Fair調(diào)度器在內(nèi)的三個調(diào)度器。
二、FIFO調(diào)度器
上圖為FIFO調(diào)度器的執(zhí)行過程示意圖。FIFO調(diào)度器也就是平時所說的先進(jìn)先出（First In First Out）調(diào)度器。FIFO調(diào)度器是Hadoop最早應(yīng)用的一種調(diào)度策略，可以簡單的將其理解為一個Java隊列，它的含義在于集群中同時只能有一個作業(yè)在運行。將所有的Application按照提交時候的順序來執(zhí)行，只有當(dāng)上一個Job執(zhí)行完成之后后面的Job才會按照隊列的順序依次被執(zhí)行。FIFO調(diào)度器以集群資源獨占的方式來運行作業(yè)，這樣的好處是一個作業(yè)可以充分利用所有的集群資源，但是對于運行時間短，重要性高或者交互式查詢類的MR作業(yè)就要等待排在序列前的作業(yè)完成才能被執(zhí)行，這也就導(dǎo)致了如果有一個非常大的Job在運行，那么后面的作業(yè)將會被阻塞。因此，雖然單一的FIFO調(diào)度實現(xiàn)簡單，但是對于很多實際的場景并不能滿足要求。這也就催發(fā)了Capacity調(diào)度器和Fair調(diào)度器的出現(xiàn)。
三、Capacity調(diào)度器
上圖是Capacity調(diào)度器的執(zhí)行過程示意圖。Capacity調(diào)度器也就是日常說的容器調(diào)度器。可以將它理解成一個個的資源隊列。這個資源隊列是用戶自己去分配的。例如因為工作所需要把整個集群分成了AB兩個隊列，A隊列下面還可以繼續(xù)分，比如將A隊列再分為1和2兩個子隊列。那么隊列的分配就可以參考下面的樹形結(jié)構(gòu)：
---A[60%]
|---A.1[40%]
|---A.2[60%]
---B[40%]
上述的樹形結(jié)構(gòu)可以理解為A隊列占用整個資源的60%，B隊列占用整個資源的40%。A隊列里面又分了兩個子隊列，A.1占據(jù)40%，A.2占據(jù)60%，也就是說此時A.1和A.2分別占用A隊列的40%和60%的資源。雖然此時已經(jīng)具體分配了集群的資源，但是并不是說A提交了任務(wù)之后只能使用它被分配到的60%的資源，而B隊列的40%的資源就處于空閑。只要是其它隊列中的資源處于空閑狀態(tài)，那么有任務(wù)提交的隊列可以使用空閑隊列所分配到的資源，使用的多少是依據(jù)配來決定。參數(shù)的配置會在后文中提到。
Capacity調(diào)度器具有以下的幾個特性：
1.層次化的隊列設(shè)計，這種層次化的隊列設(shè)計保證了子隊列可以使用父隊列設(shè)置的全部資源。這樣通過層次化的管理，更容易合理分配和限制資源的使用。
2.容量保證，隊列上都會設(shè)置一個資源的占比，這樣可以保證每個隊列都不會占用整個集群的資源。
3.安全，每個隊列又嚴(yán)格的訪問控制。用戶只能向自己的隊列里面提交任務(wù)，而且不能修改或者訪問其他隊列的任務(wù)。
4.彈性分配，空閑的資源可以被分配給任何隊列。當(dāng)多個隊列出現(xiàn)爭用的時候，則會按照比例進(jìn)行平衡。
5.多租戶租用，通過隊列的容量限制，多個用戶就可以共享同一個集群，同事保證每個隊列分配到自己的容量，提高利用率。
6.操作性，Yarn支持動態(tài)修改調(diào)整容量、權(quán)限等的分配，可以在運行時直接修改。還提供給管理員界面，來顯示當(dāng)前的隊列狀況。管理員可以在運行時，添加一個隊列；但是不能刪除一個隊列。管理員還可以在運行時暫停某個隊列，這樣可以保證當(dāng)前的隊列在執(zhí)行過程中，集群不會接收其他的任務(wù)。如果一個隊列被設(shè)置成了stopped，那么就不能向他或者子隊列上提交任務(wù)了。
7.基于資源的調(diào)度，協(xié)調(diào)不同資源需求的應(yīng)用程序，比如內(nèi)存、CPU、磁盤等等。
相關(guān)參數(shù)的配置：
（1）capacity：隊列的資源容量（百分比）。 當(dāng)系統(tǒng)非常繁忙時，應(yīng)保證每個隊列的容量得到滿足，而如果每個隊列應(yīng)用程序較少，可將剩余資源共享給其他隊列。注意，所有隊列的容量之和應(yīng)小于100。
（2）maximum-capacity：隊列的資源使用上限（百分比）。由于存在資源共享，因此一個隊列使用的資源量可能超過其容量，而最多使用資源量可通過該參數(shù)限制。（這也是前文提到的關(guān)于有任務(wù)運行的隊列可以占用的資源的最大百分比）
（3）user-limit-factor：每個用戶最多可使用的資源量（百分比）。比如，假設(shè)該值為30，則任何時刻，每個用戶使用的資源量不能超過該隊列容量的30%。
（4）maximum-applications：集群或者隊列中同時處于等待和運行狀態(tài)的應(yīng)用程序數(shù)目上限，這是一個強(qiáng)限制，一旦集群中應(yīng)用程序數(shù)目超過該上限，后續(xù)提交的應(yīng)用程序?qū)⒈痪芙^，默認(rèn)值為10000。所有隊列的數(shù)目上限可通過參數(shù)yarn.scheduler.capacity.maximum-applications設(shè)置（可看做默認(rèn)值），而單個隊列可通過參數(shù)yarn.scheduler.capacity..maximum- applications設(shè)置適合自己的值。
（5）maximum-am-resource-percent：集群中用于運行應(yīng)用程序ApplicationMaster的資源比例上限，該參數(shù)通常用于限制處于活動狀態(tài)的應(yīng)用程序數(shù)目。該參數(shù)類型為浮點型，默認(rèn)是0.1，表示10%。所有隊列的ApplicationMaster資源比例上限可通過參數(shù)yarn.scheduler.capacity. maximum-am-resource-percent設(shè)置（可看做默認(rèn)值），而單個隊列可通過參數(shù)yarn.scheduler.capacity..
maximum-am-resource-percent設(shè)置適合自己的值。
（6）state：隊列狀態(tài)可以為STOPPED或者RUNNING，如果一個隊列處于STOPPED狀態(tài)，用戶不可以將應(yīng)用程序提交到該隊列或者它的子隊列中，類似的，如果ROOT隊列處于STOPPED狀態(tài)，用戶不可以向集群中提交應(yīng)用程序，但正在運行的應(yīng)用程序仍可以正常運行結(jié)束，以便隊列可以優(yōu)雅地退出。
（7）acl_submit_applications：限定哪些Linux用戶/用戶組可向給定隊列中提交應(yīng)用程序。需要注意的是，該屬性具有繼承性，即如果一個用戶可以向某個隊列中提交應(yīng)用程序，則它可以向它的所有子隊列中提交應(yīng)用程序。配置該屬性時，用戶之間或用戶組之間用“，”分割，用戶和用戶組之間用空格分割，比如“user1, user2 group1,group2”。
（8）acl_administer_queue：為隊列指定一個管理員，該管理員可控制該隊列的所有應(yīng)用程序，比如殺死任意一個應(yīng)用程序等。同樣，該屬性具有繼承性，如果一個用戶可以向某個隊列中提交應(yīng)用程序，則它可以向它的所有子隊列中提交應(yīng)用程序。
四、Fair調(diào)度器
上圖是Fair調(diào)度器在一個隊列中的執(zhí)行過程示意圖。Fair調(diào)度器也就是日常說的公平調(diào)度器。Fair調(diào)度器是一個隊列資源分配方式，在整個時間線上，所有的Job平均的獲取資源。默認(rèn)情況下，F(xiàn)air調(diào)度器只是對內(nèi)存資源做公平的調(diào)度和分配。當(dāng)集群中只有一個任務(wù)在運行時，那么此任務(wù)會占用整個集群的資源。當(dāng)其他的任務(wù)提交后，那些釋放的資源將會被分配給新的Job，所以每個任務(wù)最終都能獲取幾乎一樣多的資源。
公平調(diào)度器也可以在多個隊列間工作，如上圖所示，例如有兩個用戶A和B，他們分別擁有一個隊列。當(dāng)A啟動一個Job而B沒有任務(wù)提交時，A會獲得全部集群資源；當(dāng)B啟動一個Job后，A的任務(wù)會繼續(xù)運行，不過隊列A會慢慢釋放它的一些資源，一會兒之后兩個任務(wù)會各自獲得一半的集群資源。如果此時B再啟動第二個Job并且其它任務(wù)也還在運行時，那么它將會和B隊列中的的第一個Job共享隊列B的資源，也就是隊列B的兩個Job會分別使用集群四分之一的資源，而隊列A的Job仍然會使用集群一半的資源，結(jié)果就是集群的資源最終在兩個用戶之間平等的共享。
相關(guān)參數(shù)的配置：
（1）yarn.scheduler.fair.allocation.file： “allocation”文件的位置，“allocation”文件是一個用來描述queue以及它們的屬性的配置文件。這個文件必須為格式嚴(yán)格的xml文件。如果為相對路徑，那么將會在classpath下查找此文件(conf目錄下)。默認(rèn)值為“fair-scheduler.xml”。
（2）yarn.scheduler.fair.user-as-default-queue：是否將與allocation有關(guān)的username作為默認(rèn)的queue name，當(dāng)queue name沒有指定的時候。如果設(shè)置成false(且沒有指定queue name)或者沒有設(shè)定，所有的jobs將共享“default”queue。默認(rèn)值為true。
（3）yarn.scheduler.fair.preemption：是否使用“preemption”(優(yōu)先權(quán)，搶占)，默認(rèn)為fasle，在此版本中此功能為測試性的。
（4）yarn.scheduler.fair.assignmultiple：是在允許在一個心跳中，發(fā)送多個container分配信息。默認(rèn)值為false。
（5）yarn.scheduler.fair.max.assign：如果assignmultuple為true，那么在一次心跳中，最多發(fā)送分配container的個數(shù)。默認(rèn)為-1，無限制。
（6）yarn.scheduler.fair.locality.threshold.node：一個float值，在0~1之間，表示在等待獲取滿足node-local條件的containers時，最多放棄不滿足node-local的container的機(jī)會次數(shù)，放棄的nodes個數(shù)為集群的大小的比例。默認(rèn)值為-1.0表示不放棄任何調(diào)度的機(jī)會。
（7）yarn.scheduler.fair.locality.threashod.rack：同上，滿足rack-local。
（8）yarn.scheduler.fair.sizebaseweight：是否根據(jù)application的大小(Job的個數(shù))作為權(quán)重。默認(rèn)為false，如果為true，那么復(fù)雜的application將獲取更多的資源。
五、總結(jié)
如果業(yè)務(wù)邏輯比較簡單或者剛接觸Hadoop的時候建議使用FIFO調(diào)度器；如果需要控制部分應(yīng)用的優(yōu)先級同時又想要充分利用集群資源的情況下，建議使用Capacity調(diào)度器；如果想要多用戶或者多隊列公平的共享集群資源，那么就選用Fair調(diào)度器。希望大家能夠根據(jù)業(yè)務(wù)所需選擇合適的調(diào)度器。
本文原創(chuàng)首發(fā)于Cobub官網(wǎng)，如需轉(zhuǎn)載請注明出處！
Cobub Razor是一款開源 移動應(yīng)用數(shù)據(jù)統(tǒng)計分析 工具。
歡迎對開源項目感興趣的小伙伴加入Cobub開源社區(qū)QQ：194022996。
