本篇教程探讨了大数据技术 Yarn——Capacity调度器概念以及配置，希望阅读本篇文章以后大家有所收获，帮助大家对大数据技术的理解更加深入。

<

试想一下，你现在所在的公司有一个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..queues.
下面是配置的样例，比如root下面有三个子队列:

  yarn.scheduler.capacity.root.queues
  a,b,c
  The queues at the this level (root is the root queue).
  



  yarn.scheduler.capacity.root.a.queues
  a1,a2
  The queues at the this level (root is the root queue).
  



  yarn.scheduler.capacity.root.b.queues
  b1,b2,b3
  The queues at the this level (root is the root queue).
  

队列属性

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%。

   

本文由职坐标整理发布，学习更多的大数据技术相关知识，请关注职坐标大技术云计算大技术技术频道！