試想一下,你如今所在的公司有一個hadoop的集羣。可是A項目組常常作一些定時的BI報表,B項目組則常用一些軟件作一些臨時需求。那麼他們確定會遇到同時提交任務的場景,這個時候到底如何分配資源知足這兩個任務呢?是先執行A的任務,再執行B的任務,仍是同時跑兩個?html
若是你存在上述的困惑,能夠多瞭解一些yarn的資源調度器。node
在Yarn框架中,調度器是一塊很重要的內容。有了合適的調度規則,就能夠保證多個應用能夠在同一時間有條不紊的工做。最原始的調度規則就是FIFO,即按照用戶提交任務的時間來決定哪一個任務先執行,可是這樣極可能一個大任務獨佔資源,其餘的資源須要不斷的等待。也可能一堆小任務佔用資源,大任務一直沒法獲得適當的資源,形成飢餓。因此FIFO雖然很簡單,可是並不能知足咱們的需求。web
yarn默認還提供了兩種調度規則,capacity和fair share。本篇就主要介紹下capacity調度器:apache
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分配。app
雖然有了這樣的資源分配,可是並非說a提交了任務,它就只能使用60%的資源,那40%就空閒着。只要資源實在空閒狀態,那麼a就可使用100%的資源。可是一旦b提交了任務,a就須要在釋放資源後,把資源還給b隊列,直到ab平衡在3:2的比例。框架
粗粒度上資源是按照上面的方式進行,在每一個隊列的內部,仍是按照FIFO的原則來分配資源的。oop
capacity調度器具備如下的幾個特性:ui
在ResourceManager中配置它要使用的調度器,配置方式是修改conf/yarn-site.xml,設置屬性:this
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>
它是隊列的資源容量佔比(百分比)。系統繁忙時,每一個隊列都應該獲得設置的量的資源;當系統空閒時,該隊列的資源則能夠被其餘的隊列使用。同一層的全部隊列加起來必須是100%。
隊列資源的使用上限。因爲系統空閒時,隊列可使用其餘的空閒資源,所以最多使用的資源量則是該參數控制。默認是-1,即禁用。
每一個任務佔用的最少資源。好比,你設置成了25%。那麼若是有兩個用戶提交任務,那麼每一個任務資源不超過50%。若是3個用戶提交任務,那麼每一個任務資源不超過33%。若是4個用戶提交任務,那麼每一個任務資源不超過25%。若是5個用戶提交任務,那麼第五個用戶須要等待才能提交。默認是100,即不去作限制。
每一個用戶最多使用的隊列資源佔比,若是設置爲50.那麼每一個用戶使用的資源最多就是50%。
設置系統中能夠同時運行和等待的應用數量。默認是10000.
設置有多少資源能夠用來運行app master,即控制當前激活狀態的應用。默認是10%。
隊列的狀態,可使RUNNING或者STOPPED.若是隊列是STOPPED狀態,那麼新應用不會提交到該隊列或者子隊列。一樣,若是root被設置成STOPPED,那麼整個集羣都不能提交任務了。現有的應用能夠等待完成,所以隊列能夠優雅的退出關閉。
訪問控制列表ACL控制誰能夠向該隊列提交任務。若是一個用戶能夠向該隊列提交,那麼也能夠提交任務到它的子隊列。
設置隊列的管理員的ACL控制,管理員能夠控制隊列的全部應用程序。一樣,它也具備繼承性。
注意:ACL的設置是user1,user2 group1,group2
這種格式。若是是*
則表明任何人。空格
表示任何人都不容許。默認是*
.
資源計算方法,默認是org.apache.hadoop.yarn.util.resource.DefaultResourseCalculator
,它只會計算內存。DominantResourceCalculator
則會計算內存和CPU。
調度器嘗試進行調度的次數。通常都是跟集羣的節點數量有關。默認40(一個機架上的節點數)
一旦設置完這些隊列屬性,就能夠在web ui上看到了。能夠訪問下面的鏈接:
xxx:8088/scheduler
若是想要修改隊列或者調度器的配置,能夠修改
vi $HADOOP_CONF_DIR/capacity-scheduler.xml
修改完成後,須要執行下面的命令:
$HADOOP_YARN_HOME/bin/yarn rmadmin -refreshQueues
注意: