Hadoop Yarn調度器的選擇和使用

1、引言

Yarn在Hadoop的生態系統中擔任了資源管理和任務調度的角色。在討論其構造器以前先簡單瞭解一下Yarn的架構。

上圖是Yarn的基本架構，其中ResourceManager是整個架構的核心組件，它負責整個集羣中包括內存、CPU等資源的管理；ApplicationMaster負責應用程序在整個生命週期的任務調度；NodeManager負責本節點上資源的供給和隔離；Container能夠抽象的當作是運行任務的一個容器。本文討論的調度器是在ResourceManager組建中進行調度的，接下來就一塊兒研究一下包括FIFO調度器、Capacity調度器、Fair調度器在內的三個調度器。

2、FIFO調度器

上圖爲FIFO調度器的執行過程示意圖。FIFO調度器也就是平時所說的先進先出（First In First Out）調度器。FIFO調度器是Hadoop最先應用的一種調度策略，能夠簡單的將其理解爲一個Java隊列，它的含義在於集羣中同時只能有一個做業在運行。將全部的Application按照提交時候的順序來執行，只有當上一個Job執行完成以後後面的Job纔會按照隊列的順序依次被執行。FIFO調度器以集羣資源獨佔的方式來運行做業，這樣的好處是一個做業能夠充分利用全部的集羣資源，可是對於運行時間短，重要性高或者交互式查詢類的MR做業就要等待排在序列前的做業完成才能被執行，這也就致使了若是有一個很是大的Job在運行，那麼後面的做業將會被阻塞。所以，雖然單一的FIFO調度實現簡單，可是對於不少實際的場景並不能知足要求。這也就催發了Capacity調度器和Fair調度器的出現。

3、Capacity調度器

上圖是Capacity調度器的執行過程示意圖。Capacity調度器也就是平常說的容器調度器。能夠將它理解成一個個的資源隊列。這個資源隊列是用戶本身去分配的。例如由於工做所須要把整個集羣分紅了AB兩個隊列，A隊列下面還能夠繼續分，好比將A隊列再分爲1和2兩個子隊列。那麼隊列的分配就能夠參考下面的樹形結構：
—A[60%]
|—A.1[40%]
|—A.2[60%]
—B[40%]
上述的樹形結構能夠理解爲A隊列佔用整個資源的60%，B隊列佔用整個資源的40%。A隊列裏面又分了兩個子隊列，A.1佔據40%，A.2佔據60%，也就是說此時A.1和A.2分別佔用A隊列的40%和60%的資源。雖然此時已經具體分配了集羣的資源，可是並非說A提交了任務以後只能使用它被分配到的60%的資源，而B隊列的40%的資源就處於空閒。只要是其它隊列中的資源處於空閒狀態，那麼有任務提交的隊列可使用空閒隊列所分配到的資源，使用的多少是依據配來決定。參數的配置會在後文中提到。
Capacity調度器具備如下的幾個特性：

1. 層次化的隊列設計，這種層次化的隊列設計保證了子隊列可使用父隊列設置的所有資源。這樣經過層次化的管理，更容易合理分配和限制資源的使用。

2. 容量保證，隊列上都會設置一個資源的佔比，這樣能夠保證每一個隊列都不會佔用整個集羣的資源。

3. 安全，每一個隊列又嚴格的訪問控制。用戶只能向本身的隊列裏面提交任務，並且不能修改或者訪問其餘隊列的任務。

4. 彈性分配，空閒的資源能夠被分配給任何隊列。當多個隊列出現爭用的時候，則會按照比例進行平衡。

5. 多租戶租用，經過隊列的容量限制，多個用戶就能夠共享同一個集羣，同事保證每一個隊列分配到本身的容量，提升利用率。

6. 操做性，Yarn支持動態修改調整容量、權限等的分配，能夠在運行時直接修改。還提供給管理員界面，來顯示當前的隊列情況。管理員能夠在運行時，添加一個隊列；可是不能刪除一個隊列。管理員還能夠在運行時暫停某個隊列，這樣能夠保證當前的隊列在執行過程當中，集羣不會接收其餘的任務。若是一個隊列被設置成了stopped，那麼就不能向他或者子隊列上提交任務了。

7. 基於資源的調度，協調不一樣資源需求的應用程序，好比內存、CPU、磁盤等等。

相關參數的配置：

1. capacity：隊列的資源容量（百分比）。 當系統很是繁忙時，應保證每一個隊列的容量獲得知足，而若是每一個隊列應用程序較少，可將剩餘資源共享給其餘隊列。注意，全部隊列的容量之和應小於100。

2. maximum-capacity：隊列的資源使用上限（百分比）。因爲存在資源共享，所以一個隊列使用的資源量可能超過其容量，而最多使用資源量可經過該參數限制。（這也是前文提到的關於有任務運行的隊列能夠佔用的資源的最大百分比）

3. user-limit-factor：每一個用戶最多可以使用的資源量（百分比）。好比，假設該值爲30，則任什麼時候刻，每一個用戶使用的資源量不能超過該隊列容量的30%。

4. maximum-applications ：集羣或者隊列中同時處於等待和運行狀態的應用程序數目上限，這是一個強限制，一旦集羣中應用程序數目超過該上限，後續提交的應用程序將被拒絕，默認值爲 10000。全部隊列的數目上限可經過參數yarn.scheduler.capacity.maximum-applications設置（可看作默認值），而單個隊列可經過參數yarn.scheduler.capacity..maximum- applications設置適合本身的值。

5. maximum-am-resource-percent：集羣中用於運行應用程序 ApplicationMaster的資源比例上限，該參數一般用於限制處於活動狀態的應用程序數目。該參數類型爲浮點型，默認是0.1，表示10%。全部隊列的ApplicationMaster資源比例上限可經過參數yarn.scheduler.capacity. maximum-am-resource-percent設置（可看作默認值），而單個隊列可經過參數 yarn.scheduler.capacity.. maximum-am-resource-percent設置適合本身的值。

6. state ：隊列狀態能夠爲STOPPED或者 RUNNING，若是一個隊列處於STOPPED狀態，用戶不能夠將應用程序提交到該隊列或者它的子隊列中，相似的，若是ROOT隊列處於STOPPED 狀態，用戶不能夠向集羣中提交應用程序，但正在運行的應用程序仍能夠正常運行結束，以便隊列能夠優雅地退出。

7. acl_submit_applications：限定哪些Linux用戶/用戶組可向給定隊列中提交應用程序。須要注意的是，該屬性具備繼承性，即若是一個用戶能夠向某個隊列中提交應用程序，則它能夠向它的全部子隊列中提交應用程序。配置該屬性時，用戶之間或用戶組之間用「，」分割，用戶和用戶組之間用空格分割，好比「user1, user2 group1,group2」。

8. acl_administer_queue：爲隊列指定一個管理員，該管理員可控制該隊列的全部應用程序，好比殺死任意一個應用程序等。一樣，該屬性具備繼承性，若是一個用戶能夠向某個隊列中提交應用程序，則它能夠向它的全部子隊列中提交應用程序。

4、Fair調度器

上圖是Fair調度器在一個隊列中的執行過程示意圖。Fair調度器也就是平常說的公平調度器。Fair調度器是一個隊列資源分配方式，在整個時間線上，全部的Job平均的獲取資源。默認狀況下，Fair調度器只是對內存資源作公平的調度和分配。當集羣中只有一個任務在運行時，那麼此任務會佔用整個集羣的資源。當其餘的任務提交後，那些釋放的資源將會被分配給新的Job，因此每一個任務最終都能獲取幾乎同樣多的資源。

公平調度器也能夠在多個隊列間工做，如上圖所示，例若有兩個用戶A和B，他們分別擁有一個隊列。當A啓動一個Job而B沒有任務提交時，A會得到所有集羣資源；當B啓動一個Job後，A的任務會繼續運行，不過隊列A會慢慢釋放它的一些資源，一下子以後兩個任務會各自得到一半的集羣資源。若是此時B再啓動第二個Job而且其它任務也還在運行時，那麼它將會和B隊列中的的第一個Job共享隊列B的資源，也就是隊列B的兩個Job會分別使用集羣四分之一的資源，而隊列A的Job仍然會使用集羣一半的資源，結果就是集羣的資源最終在兩個用戶之間平等的共享。　　
相關參數的配置：

1. yarn.scheduler.fair.allocation.file： 「allocation」文件的位置，「allocation」文件是一個用來描述queue以及它們的屬性的配置文件。這個文件必須爲格式嚴格的xml文件。若是爲相對路徑，那麼將會在classpath下查找此文件(conf目錄下)。默認值爲「fair-scheduler.xml」。

2. yarn.scheduler.fair.user-as-default-queue：是否將與allocation有關的username做爲默認的queue name，當queue name沒有指定的時候。若是設置成false(且沒有指定queue name) 或者沒有設定，全部的jobs將共享「default」 queue。默認值爲true。

3. yarn.scheduler.fair.preemption：是否使用「preemption」(優先權，搶佔)，默認爲fasle，在此版本中此功能爲測試性的。

4. yarn.scheduler.fair.assignmultiple：是在容許在一個心跳中，發送多個container分配信息。默認值爲false。

5. yarn.scheduler.fair.max.assign：若是assignmultuple爲true，那麼在一次心跳中，最多發送分配container的個數。默認爲-1，無限制。

6. yarn.scheduler.fair.locality.threshold.node：一個float值，在0~1之間，表示在等待獲取知足node-local條件的containers時，最多放棄不知足node-local的container的機會次數，放棄的nodes個數爲集羣的大小的比例。默認值爲-1.0表示不放棄任何調度的機會。

7. yarn.scheduler.fair.locality.threashod.rack：同上，知足rack-local。

8. yarn.scheduler.fair.sizebaseweight：是否根據application的大小(Job的個數)做爲權重。默認爲false，若是爲true，那麼複雜的application將獲取更多的資源。

5、總結

若是業務邏輯比較簡單或者剛接觸Hadoop的時候建議使用FIFO調度器；若是須要控制部分應用的優先級同時又想要充分利用集羣資源的狀況下，建議使用Capacity調度器；若是想要多用戶或者多隊列公平的共享集羣資源，那麼就選用Fair調度器。但願你們可以根據業務所需選擇合適的調度器。

文章首發於Cobub微信公衆號和Cobub官網