YARN中FIFO、Capacity以及Fari調度器的詳細介紹

時間 2019-11-07

標籤 yarn fifo capacity 以及 fari 調度詳細介紹欄目 Hadoop 简体版

原文原文鏈接

（1）FIFO Scheduler

將全部的Applications放到隊列中，先按照做業的優先級高低、再按照到達時間的前後，爲每一個app分配資源。若是第一個app須要的資源被知足了，若是還剩下了資源而且知足第二個app須要的資源，那麼就爲第二個app分配資源，and so on。html

優勢：簡單，不須要配置。算法

缺點：不適合共享集羣。若是有大的app須要不少資源，那麼其餘app可能會一直等待。apache

一個例子

上圖的示例：有一個很大的job1，它先提交，而且佔據了所有的資源。那麼job2提交時發現沒有資源了，則job2必須等待job1執行結束，才能得到資源執行。app

配置

FIFO Scheduler不須要配置負載均衡

（2）Capacity Scheduler

CapacityScheduler用於一個集羣（集羣被多個組織共享）中運行多個Application的狀況，目標是最大化吞吐量和集羣利用率。ide

CapacityScheduler容許將整個集羣的資源分紅多個部分，每一個組織使用其中的一部分，即每一個組織有一個專門的隊列，每一個組織的隊列還能夠進一步劃分紅層次結構（Hierarchical Queues），從而容許組織內部的不一樣用戶組的使用。
每一個隊列內部，按照FIFO的方式調度Applications。當某個隊列的資源空閒時，能夠將它的剩餘資源共享給其餘隊列。oop

if there is more than one job in the queue and there are idle resources available, then the Capacity Scheduler may allocate the spare resources to jobs in the queue, even if that causes the queue’s capacity to be exceeded This behavior is known as queue elasticity.ui

配置

CapacityScheduler的配置文件etc/hadoop/capacity-scheduler.xmlspa

說明：root隊列下面有兩個隊列，分別爲prod（40%的容量，即便用40%的集羣資源）和dev（60%的容量，最大的75% -> 說明即便prod隊列空閒了，那麼dev最多隻能使用75%的集羣資源。這樣就能夠保證prod中添加新的apps時立刻可使用25%的資源）。server

除了隊列的容量和層次，還能夠指定單個用戶或者應用被分配的資源大小、同時能夠運行的app數量、隊列的ACLs。

能夠指定app要放在哪一個隊列中。若是不指定，app將會被放在名字是 default的隊列中。

CapacityScheduler的隊列名字必須是層次結構最後的名字，好比eng。不能是root.dev.eng或者dev.eng。

一個例子

上圖的示例：有一個專門的隊列容許小的apps提交以後可以儘快執行，注意到job1先提交，先執行時並無佔用系統的所有資源（假如job1須要100G內存，可是整個集羣只有100G內存，那麼只分配給job1 80G），而是保留了一部分的系統資源。

（3）Fair Scheduler　

FairScheduler容許應用在一個集羣中公平地共享資源。默認狀況下FairScheduler的公平調度只基於內存，也能夠配置成基於memory and CPU。當集羣中只有一個app時，它獨佔集羣資源。當有新的app提交時，空閒的資源被新的app使用，這樣最終每一個app就會獲得大約相同的資源。能夠爲不一樣的app設置優先級，決定每一個app佔用的資源百分比。FairScheduler可讓短的做業在合理的時間內完成，而沒必要一直等待長做業的完成。

Fair Sharing： Scheduler將apps組織成queues，將資源在這些queues之間公平分配。默認狀況下，全部的apps都加入到名字爲「default「的隊列中。app也能夠指定要加入哪一個隊列中。隊列內部的默認調度策略是基於內存的共享策略，也能夠配置成FIFO和multi-resource with Dominant Resource Fairness

Minimum Sharing：FairScheduller提供公平共享，還容許指定minimum shares to queues，從而保證全部的用戶以及Apps都能獲得足夠的資源。若是有的app用不了指定的minimum的資源，那麼能夠將超出的資源分給別的app使用。

FairScheduler默認讓全部的apps都運行，可是也能夠經過配置文件小智每一個用戶以及每一個queue運行的apps的數量。這是針對一個用戶一次提交hundreds of apps產生大量中間結果數據或者大量的context-switching的狀況。

一個例子

示例1：大的任務job1提交併執行，佔用了集羣的所有資源，開始執行。以後小的job2執行時，得到系統一半的資源，開始執行。所以每一個job能夠公平地使用系統的資源。當job2執行完畢，而且集羣中沒有其餘的job加入時，job1又能夠得到所有的資源繼續執行。

注意：job2提交以後並不能立刻就獲取到集羣一半的資源，由於job2必須等待job1釋放containers。

一個例子

示例2：兩個用戶A和B。A提交job1時集羣內沒有正在運行的app，所以job1獨佔集羣中的資源。用戶B的job2提交時，job2在job1釋放一半的containers以後，開始執行。job2還沒執行完的時候，用戶B提交了job3，job2釋放它佔用的一半containers以後，job3得到資源開始執行。

配置：

使用FairScheduler須要修改yarn-size.xml文件，建立allocation file，列出存在的隊列和各自的 weights and capacities

prod和dev的權重也能夠設置成2和3。

dev下的兩個sub-queue沒有指定權重，則爲1:1。

在設置權重時，須要考慮default queue和用戶命名的queue的權重，這些沒有在xml文件中指定，可是它們的權重都是1.

隊列還能夠被配置minimum maximum Resources以及能夠運行的最大的apps的數量

FairScheduler支持preemption（搶佔），當queue佔用的資源大於它應得的，那麼調度器能夠殺掉queue對應的containers，將yarn.scheduler.fair.preemption設置成true便可。

FairScheduler和CapacityScheduler的異同

相同：

（1）以隊列劃分資源

（2）設定最低保證和最大使用上限

（3）在某個隊列空閒時能夠將資源共享給其餘隊列。

不一樣：

（1）Fair Scheduler隊列內部支持多種調度策略，包括FIFO、Fair（隊列中的N個做業，每一個得到該隊列1 / N的資源）、DRF（Dominant Resource Fairness）（多種資源類型e.g. CPU，內存的公平資源分配策略）

（2）Fair Scheduler支持資源搶佔。當隊列中有新的應用提交時，系統調度器理應爲它回收資源，可是考慮到共享的資源正在進行計算，因此調度器採用先等待再強制回收的策略，即等待一段時間後入股仍沒有得到資源，那麼從使用共享資源的隊列中殺死一部分任務

（3）Fair Scheduler中有一個基於任務數量的負載均衡機制，該機制儘量將系統中的任務分配到各個節點

（4）Fair Scheduler能夠爲每一個隊列單獨設置調度策略（FIFO Fair DRF）

（5）Fair Scheduler因爲能夠採用Fair算法，所以可使得小應用快速得到資源，避免了餓死的狀況。

Hierarchical queues with pluggable policies

FairScheduler支持層次隊列（hierarchical queues），全部隊列都從root隊列開始，root隊列的孩子隊列公平地共享可用的資源。孩子隊列再把可用資源公平地分配給他們的孩子隊列。apps可能只會在葉子隊列被調度。此外，用戶能夠爲每一個隊列設置不一樣的共享資源的策略，內置的隊列策略包括 FifoPolicy, FairSharePolicy (default), and DominantResourceFairnessPolicy。

用戶能夠經過繼承org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy實現本身定義的策略。