理想情況下，我們應用對Yarn資源的請求應該立刻得到滿足，但現實情況資源往往是有限的，特別是在一個很繁忙的集群，一個應用資源的請求經常需要等待一段時間才能的到相應的資源。在Yarn中，負責給應用分配資源的就是Scheduler。其實調度本身就是一個難題，很難找到一個完美的策略可以解決所有的應用場景。為此，Yarn提供了多種調度器和可配置的策略供我們選擇。
一、調度器的選擇
在Yarn中有三種調度器可以選擇：FIFO Scheduler ，Capacity Scheduler，FairS cheduler。
FIFO Scheduler把應用按提交的順序排成一個隊列，這是一個先進先出隊列，在進行資源分配的時候，先給隊列中最頭上的應用進行分配資源，待最頭上的應用需求滿足后再給下一個分配，以此類推。
FIFO Scheduler是最簡單也是最容易理解的調度器，也不需要任何配置，但它并不適用于共享集群。大的應用可能會占用所有集群資源，這就導致其它應用被阻塞。在共享集群中，更適合采用Capacity Scheduler或Fair Scheduler，這兩個調度器都允許大任務和小任務在提交的同時獲得一定的系統資源。
下面“Yarn調度器對比圖”展示了這幾個調度器的區別，從圖中可以看出，在FIFO 調度器中，小任務會被大任務阻塞。
而對于Capacity調度器，有一個專門的隊列用來運行小任務，但是為小任務專門設置一個隊列會預先占用一定的集群資源，這就導致大任務的執行時間會落后于使用FIFO調度器時的時間。
在Fair調度器中，我們不需要預先占用一定的系統資源，Fair調度器會為所有運行的job動態的調整系統資源。如下圖所示，當第一個大job提交時，只有這一個job在運行，此時它獲得了所有集群資源；當第二個小任務提交后，Fair調度器會分配一半資源給這個小任務，讓這兩個任務公平的共享集群資源。
需要注意的是，在下圖Fair調度器中，從第二個任務提交到獲得資源會有一定的延遲，因為它需要等待第一個任務釋放占用的Container。小任務執行完成之后也會釋放自己占用的資源，大任務又獲得了全部的系統資源。最終的效果就是Fair調度器即得到了高的資源利用率又能保證小任務及時完成。
Yarn調度器對比圖:
二、Capacity Scheduler（容器調度器）的配置
2.1 容器調度介紹
Capacity 調度器允許多個組織共享整個集群，每個組織可以獲得集群的一部分計算能力。通過為每個組織分配專門的隊列，然后再為每個隊列分配一定的集群資源，這樣整個集群就可以通過設置多個隊列的方式給多個組織提供服務了。除此之外，隊列內部又可以垂直劃分，這樣一個組織內部的多個成員就可以共享這個隊列資源了，在一個隊列內部，資源的調度是采用的是先進先出(FIFO)策略。
通過上面那幅圖，我們已經知道一個job可能使用不了整個隊列的資源。然而如果這個隊列中運行多個job，如果這個隊列的資源夠用，那么就分配給這些job，如果這個隊列的資源不夠用了呢？其實Capacity調度器仍可能分配額外的資源給這個隊列，這就是“彈性隊列”(queue elasticity)的概念。
在正常的操作中，Capacity調度器不會強制釋放Container，當一個隊列資源不夠用時，這個隊列只能獲得其它隊列釋放后的Container資源。當然，我們可以為隊列設置一個最大資源使用量，以免這個隊列過多的占用空閑資源，導致其它隊列無法使用這些空閑資源，這就是”彈性隊列”需要權衡的地方。
2.2 容器調度的配置
假設我們有如下層次的隊列：
root ├── prod └── dev ├── eng └── science
下面是一個簡單的Capacity調度器的配置文件，文件名為capacity-scheduler.xml。在這個配置中，在root隊列下面定義了兩個子隊列prod和dev，分別占40%和60%的容量。需要注意，一個隊列的配置是通過屬性yarn.sheduler.capacity.<queue-path>.<sub-property>指定的，<queue-path>代表的是隊列的繼承樹，如root.prod隊列，<sub-property>一般指capacity和maximum-capacity。
我們可以看到，dev隊列又被分成了eng和science兩個相同容量的子隊列。dev的maximum-capacity屬性被設置成了75%，所以即使prod隊列完全空閑dev也不會占用全部集群資源，也就是說，prod隊列仍有25%的可用資源用來應急。我們注意到，eng和science兩個隊列沒有設置maximum-capacity屬性，也就是說eng或science隊列中的job可能會用到整個dev隊列的所有資源（最多為集群的75%）。而類似的，prod由于沒有設置maximum-capacity屬性，它有可能會占用集群全部資源。
Capacity容器除了可以配置隊列及其容量外，我們還可以配置一個用戶或應用可以分配的最大資源數量、可以同時運行多少應用、隊列的ACL認證等。
2.3 隊列的設置
關于隊列的設置，這取決于我們具體的應用。比如，在MapReduce中，我們可以通過mapreduce.job.queuename屬性指定要用的隊列。如果隊列不存在，我們在提交任務時就會收到錯誤。如果我們沒有定義任何隊列，所有的應用將會放在一個default隊列中。
注意：對于Capacity調度器，我們的隊列名必須是隊列樹中的最后一部分，如果我們使用隊列樹則不會被識別。比如，在上面配置中，我們使用prod和eng作為隊列名是可以的，但是如果我們用root.dev.eng或者dev.eng是無效的。
三、Fair Scheduler（公平調度器）的配置
3.1 公平調度
Fair調度器的設計目標是為所有的應用分配公平的資源（對公平的定義可以通過參數來設置）。在上面的“Yarn調度器對比圖”展示了一個隊列中兩個應用的公平調度；當然，公平調度在也可以在多個隊列間工作。舉個例子，假設有兩個用戶A和B，他們分別擁有一個隊列。當A啟動一個job而B沒有任務時，A會獲得全部集群資源；當B啟動一個job后，A的job會繼續運行，不過一會兒之后兩個任務會各自獲得一半的集群資源。如果此時B再啟動第二個job并且其它job還在運行，則它將會和B的第一個job共享B這個隊列的資源，也就是B的兩個job會用于四分之一的集群資源，而A的job仍然用于集群一半的資源，結果就是資源最終在兩個用戶之間平等的共享。過程如下圖所示：
3.2 啟用Fair Scheduler
調度器的使用是通過yarn-site.xml配置文件中的yarn.resourcemanager.scheduler.class參數進行配置的，默認采用Capacity Scheduler調度器。如果我們要使用Fair調度器，需要在這個參數上配置FairScheduler類的全限定名： org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler。
3.3 隊列的配置
Fair調度器的配置文件位于類路徑下的fair-scheduler.xml文件中，這個路徑可以通過yarn.scheduler.fair.allocation.file屬性進行修改。若沒有這個配置文件，Fair調度器采用的分配策略，這個策略和3.1節介紹的類似：調度器會在用戶提交第一個應用時為其自動創建一個隊列，隊列的名字就是用戶名，所有的應用都會被分配到相應的用戶隊列中。
我們可以在配置文件中配置每一個隊列，并且可以像Capacity 調度器一樣分層次配置隊列。比如，參考capacity-scheduler.xml來配置fair-scheduler：
隊列的層次是通過嵌套<queue>元素實現的。所有的隊列都是root隊列的孩子，即使我們沒有配到<root>元素里。在這個配置中，我們把dev隊列有分成了eng和science兩個隊列。
Fair調度器中的隊列有一個權重屬性（這個權重就是對公平的定義），并把這個屬性作為公平調度的依據。在這個例子中，當調度器分配集群40:60資源給prod和dev時便視作公平，eng和science隊列沒有定義權重，則會被平均分配。這里的權重并不是百分比，我們把上面的40和60分別替換成2和3，效果也是一樣的。注意，對于在沒有配置文件時按用戶自動創建的隊列，它們仍有權重并且權重值為1。
每個隊列內部仍可以有不同的調度策略。隊列的默認調度策略可以通過頂級元素<defaultQueueSchedulingPolicy>進行配置，如果沒有配置，默認采用公平調度。
盡管是Fair調度器，其仍支持在隊列級別進行FIFO調度。每個隊列的調度策略可以被其內部的<schedulingPolicy> 元素覆蓋，在上面這個例子中，prod隊列就被指定采用FIFO進行調度，所以，對于提交到prod隊列的任務就可以按照FIFO規則順序的執行了。需要注意，prod和dev之間的調度仍然是公平調度，同樣eng和science也是公平調度。
盡管上面的配置中沒有展示，每個隊列仍可配置最大、最小資源占用數和最大可運行的應用的數量。
3.4 隊列的設置
Fair調度器采用了一套基于規則的系統來確定應用應該放到哪個隊列。在上面的例子中，<queuePlacementPolicy> 元素定義了一個規則列表，其中的每個規則會被逐個嘗試直到匹配成功。例如，上例第一個規則specified，則會把應用放到它指定的隊列中，若這個應用沒有指定隊列名或隊列名不存在，則說明不匹配這個規則，然后嘗試下一個規則。primaryGroup規則會嘗試把應用放在以用戶所在的Unix組名命名的隊列中，如果沒有這個隊列，不創建隊列轉而嘗試下一個規則。當前面所有規則不滿足時，則觸發default規則，把應用放在dev.eng隊列中。
當然，我們可以不配置queuePlacementPolicy規則，調度器則默認采用如下規則：
<queuePlacementPolicy> <rule name="specified" /> <rule name="user" /> </queuePlacementPolicy>
上面規則可以歸結成一句話，除非隊列被準確的定義，否則會以用戶名為隊列名創建隊列。
還有一個簡單的配置策略可以使得所有的應用放入同一個隊列（default），這樣就可以讓所有應用之間平等共享集群而不是在用戶之間。這個配置的定義如下：
<queuePlacementPolicy> <rule name="default" /> </queuePlacementPolicy>
實現上面功能我們還可以不使用配置文件，直接設置yarn.scheduler.fair.user-as-default-queue=false，這樣應用便會被放入default 隊列，而不是各個用戶名隊列。另外，我們還可以設置yarn.scheduler.fair.allow-undeclared-pools=false，這樣用戶就無法創建隊列了。
3.5 搶占（Preemption）
當一個job提交到一個繁忙集群中的空隊列時，job并不會馬上執行，而是阻塞直到正在運行的job釋放系統資源。為了使提交job的執行時間更具預測性（可以設置等待的超時時間），Fair調度器支持搶占。
搶占就是允許調度器殺掉占用超過其應占份額資源隊列的containers，這些containers資源便可被分配到應該享有這些份額資源的隊列中。需要注意搶占會降低集群的執行效率，因為被終止的containers需要被重新執行。
可以通過設置一個全局的參數yarn.scheduler.fair.preemption=true來啟用搶占功能。此外，還有兩個參數用來控制搶占的過期時間（這兩個參數默認沒有配置，需要至少配置一個來允許搶占Container）：
- minimum share preemption timeout - fair share preemption timeout
如果隊列在minimum share preemption timeout指定的時間內未獲得最小的資源保障，調度器就會搶占containers。我們可以通過配置文件中的頂級元素<defaultMinSharePreemptionTimeout>為所有隊列配置這個超時時間；我們還可以在<queue>元素內配置<minSharePreemptionTimeout>元素來為某個隊列指定超時時間。
與之類似，如果隊列在fair share preemption timeout指定時間內未獲得平等的資源的一半（這個比例可以配置），調度器則會進行搶占containers。這個超時時間可以通過頂級元素<defaultFairSharePreemptionTimeout>和元素級元素<fairSharePreemptionTimeout>分別配置所有隊列和某個隊列的超時時間。上面提到的比例可以通過<defaultFairSharePreemptionThreshold>(配置所有隊列)和<fairSharePreemptionThreshold>(配置某個隊列)進行配置，默認是0.5。