試想一下，你現在所在的公司有一個hadoop的集群。但是A項目組經常做一些定時的BI報表，B項目組則經常使用一些軟件做一些臨時需求。那么他們肯定會遇到同時提交任務的場景，這個時候到底如何分配資源滿足這兩個任務呢？是先執行A的任務，再執行B的任務，還是同時跑兩個？
如果你存在上述的困惑，可以多了解一些yarn的資源調度器。
在Yarn框架中，調度器是一塊很重要的內容。有了合適的調度規則，就可以保證多個應用可以在同一時間有條不紊的工作。最原始的調度規則就是FIFO，即按照用戶提交任務的時間來決定哪個任務先執行，但是這樣很可能一個大任務獨占資源，其他的資源需要不斷的等待。也可能一堆小任務占用資源，大任務一直無法得到適當的資源，造成飢餓。所以FIFO雖然很簡單，但是並不能滿足我們的需求。
yarn默認還提供了兩種調度規則，capacity和fair share。本篇就主要介紹下capacity調度器：
什么是capacity調度器
Capacity調度器說的通俗點，可以理解成一個個的資源隊列。這個資源隊列是用戶自己去分配的。比如我大體上把整個集群分成了AB兩個隊列，A隊列給A項目組的人來使用。B隊列給B項目組來使用。但是A項目組下面又有兩個方向，那么還可以繼續分，比如專門做BI的和做實時分析的。那么隊列的分配就可以參考下面的樹形結構：
root
------a[60%]
|---a.bi[40%]
|---a.realtime[60%]
------b[40%]
a隊列占用整個資源的60%，b隊列占用整個資源的40%。a隊列里面又分了兩個子隊列，一樣也是2:3分配。
雖然有了這樣的資源分配，但是並不是說a提交了任務，它就只能使用60%的資源，那40%就空閑着。只要資源實在空閑狀態，那么a就可以使用100%的資源。但是一旦b提交了任務，a就需要在釋放資源后，把資源還給b隊列，直到ab平衡在3:2的比例。
粗粒度上資源是按照上面的方式進行，在每個隊列的內部，還是按照FIFO的原則來分配資源的。
特性
capacity調度器具有以下的幾個特性：
- 層次化的隊列設計，這種層次化的隊列設計保證了子隊列可以使用父隊列設置的全部資源。這樣通過層次化的管理，更容易合理分配和限制資源的使用。
- 容量保證，隊列上都會設置一個資源的占比，這樣可以保證每個隊列都不會占用整個集群的資源。
- 安全，每個隊列又嚴格的訪問控制。用戶只能向自己的隊列里面提交任務，而且不能修改或者訪問其他隊列的任務。
- 彈性分配，空閑的資源可以被分配給任何隊列。當多個隊列出現爭用的時候，則會按照比例進行平衡。
- 多租戶租用，通過隊列的容量限制，多個用戶就可以共享同一個集群，同事保證每個隊列分配到自己的容量，提高利用率。
- 操作性，yarn支持動態修改調整容量、權限等的分配，可以在運行時直接修改。還提供給管理員界面，來顯示當前的隊列狀況。管理員可以在運行時，添加一個隊列；但是不能刪除一個隊列。管理員還可以在運行時暫停某個隊列，這樣可以保證當前的隊列在執行過程中，集群不會接收其他的任務。如果一個隊列被設置成了stopped，那么就不能向他或者子隊列上提交任務了。
- 基於資源的調度，協調不同資源需求的應用程序，比如內存、CPU、磁盤等等。
關於調度器的配置
配置調度器
在ResourceManager中配置它要使用的調度器，配置方式是修改conf/yarn-site.xml，設置屬性：
yarn.resourcemanager.scheduler.class
=>
org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler
配置隊列
調度器的核心就是隊列的分配和使用了，修改conf/capacity-scheduler.xml可以配置隊列。
Capacity調度器默認有一個預定義的隊列——root,所有的隊列都是它的子隊列。隊列的分配支持層次化的配置，使用.來進行分割，比如yarn.scheduler.capacity.<queue-path>.queues.
下面是配置的樣例，比如root下面有三個子隊列:
<property>
<name>yarn.scheduler.capacity.root.queues</name>
<value>a,b,c</value>
<description>The queues at the this level (root is the root queue).
</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.a.queues</name>
<value>a1,a2</value>
<description>The queues at the this level (root is the root queue).
</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.b.queues</name>
<value>b1,b2,b3</value>
<description>The queues at the this level (root is the root queue).
</description>
</property>
隊列屬性
- yarn.scheduler.capacity.
.capacity
它是隊列的資源容量占比(百分比)。系統繁忙時，每個隊列都應該得到設置的量的資源；當系統空閑時，該隊列的資源則可以被其他的隊列使用。同一層的所有隊列加起來必須是100%。
- yarn.scheduler.capacity.
.maximum-capacity
隊列資源的使用上限。由於系統空閑時，隊列可以使用其他的空閑資源，因此最多使用的資源量則是該參數控制。默認是-1，即禁用。
- yarn.scheduler.capacity.
.minimum-user-limit-percent
每個任務占用的最少資源。比如，你設置成了25%。那么如果有兩個用戶提交任務，那么每個任務資源不超過50%。如果3個用戶提交任務，那么每個任務資源不超過33%。如果4個用戶提交任務，那么每個任務資源不超過25%。如果5個用戶提交任務，那么第五個用戶需要等待才能提交。默認是100，即不去做限制。
- yarn.scheduler.capacity.
.user-limit-factor
每個用戶最多使用的隊列資源占比，如果設置為50.那么每個用戶使用的資源最多就是50%。
運行和提交應用限制
- yarn.scheduler.capacity.maximum-applications / yarn.scheduler.capacity.
.maximum-applications
設置系統中可以同時運行和等待的應用數量。默認是10000.
- yarn.scheduler.capacity.maximum-am-resource-percent / yarn.scheduler.capacity.
.maximum-am-resource-percent
設置有多少資源可以用來運行app master，即控制當前激活狀態的應用。默認是10%。
隊列管理
- yarn.scheduler.capacity.
.state
隊列的狀態，可以使RUNNING或者STOPPED.如果隊列是STOPPED狀態，那么新應用不會提交到該隊列或者子隊列。同樣，如果root被設置成STOPPED，那么整個集群都不能提交任務了。現有的應用可以等待完成，因此隊列可以優雅的退出關閉。
- yarn.scheduler.capacity.root.
.acl_submit_applications
訪問控制列表ACL控制誰可以向該隊列提交任務。如果一個用戶可以向該隊列提交，那么也可以提交任務到它的子隊列。
- yarn.scheduler.capacity.root.
.acl_administer_queue
設置隊列的管理員的ACL控制，管理員可以控制隊列的所有應用程序。同樣，它也具有繼承性。
注意：ACL的設置是user1,user2 group1,group2這種格式。如果是*則代表任何人。空格表示任何人都不允許。默認是*.
其他屬性
- yarn.scheduler.capacity.resource-calculator
資源計算方法，默認是org.apache.hadoop.yarn.util.resource.DefaultResourseCalculator,它只會計算內存。DominantResourceCalculator則會計算內存和CPU。
- yarn.scheduler.capacity.node-locality-delay
調度器嘗試進行調度的次數。一般都是跟集群的節點數量有關。默認40（一個機架上的節點數）
一旦設置完這些隊列屬性，就可以在web ui上看到了。可以訪問下面的連接：
xxx:8088/scheduler
修改隊列配置
如果想要修改隊列或者調度器的配置，可以修改
vi $HADOOP_CONF_DIR/capacity-scheduler.xml
修改完成后，需要執行下面的命令：
$HADOOP_YARN_HOME/bin/yarn rmadmin -refreshQueues
注意：
- 隊列不能被刪除，只能新增。
- 更新隊列的配置需要是有效的值
- 同層級的隊列容量限制想加需要等於100%。