试想一下,你如今所在的公司有一个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
注意: