img

BQ

Hadoop/Java

边城

软件就是驱动世界,改造世界

欢迎来到边城客栈

Hadoop-Yarn-01-容量调度原理使用和配置

| 阅读：次

前言

 Hadoop在近些年被越来越多的人认为Hadoop将死,其实并不然,Hadoop已经不仅仅代表HDFS、Yarn、MapReduce。他代表了整个大数据的生态圈，即使是HDFS由于元数据过大问题，越来越多的云平台推出了对象存储。但是Hadoop三剑客中的Yarn地位自始至终都是无法撼动的。Yarn作为Hadoop中非常关键的一部分，有很多新出现的非常火的计算框架譬如Spark、Flink、Xleaning.都提供了Spark on Yarn，Flink on Yarn。在Yarn上调度。
提到调度，自然而然的我们就会想到调度算法，机器的CPU，内存，GPU，需要有一个程序去分配他们，去调度他们 ，这时我们的Yarn调度算法就显得尤为重要了。
   采用的Yarn调度算法有容量调度、FIFO调度、公平调度。这里我们大概说一下，并不是说哪一种算法就好，仅仅说不同的场景需要不同的调度算法配合。当然了容量调度在这几种算法中是最负责的也是最强大的。下文我们展开说一下。

优点&缺点

  1. 缺点：配置复杂
  2. 优点：可结合Yarn Node Label 使用(公平调度不支持)
  3. 优点：Apache Ranger 可以配合容量调度管理队列(公平调度不支持)
  4. 优点：调度可以更加灵活弹性

调度预览

​ 队列以root开头，以树的方式分配其子节点。root子节点可以成为叶子结点。叶子节点又可以划分出来子节点

结构图如下：

容量调度原理

1、 资源计算方式切换

    默认情况下Yarn调度资源时，仅仅考虑内存的调度，在特定的场景，比如某个spark任务程序，内存占用非常高，但是其CPU占用率极低。导致剩余的vcore无法使用，造成资源浪费。
  我们可以更换Yarn 资源计算器从`org.apache.hadoop.yarn.util.resource.DefaultResourseCalculator`调整为`DominantResourceCalculator`.

2、 容量配置和队列层级设计

    容量调度器中，ROOT为根节点，其中ROOT下可以有多个子队列，在各层级上所有队列的百分比之和必须等于100百分比之和必须等于100。每个队列的容量都可以配置最大容量比率和最小容量比率。最小容量指的是集群中所有资源用尽的时候，队列预期可以使用的容量(说白话的意思是 应该给我的最低保障，但是别人可以借用的)，最大容量指的是弹性容量，在其他人的队列资源没有被使用的时候你可以临时借用的资源。
  • 图例如下【这里我们不提抢占】

如上图：注意 在root这一层级中，我们可以看得到 20%+40%+40%=100% 这个为强制要求，如果不等于100% 刷新队列直接报错。我们同时也可以观察到super这一层级的队列中，40%+60%=100% 。

3、 最小资源比例限制

    在使用yarn资源使用中，经常遇到一个用户独占一个队列，其他任务只能等待该用户独占的队列。严重影响SLA,以及用户的体验。在同一个队列中Yarn可以限制单个用户可使用的资源量。 每个用户的使用资源量会在一个最小值和最大值之间浮动，例如设置如果为3，单个用户可以使用队列最低配置的3倍，如果设置为1，单个用户可以使用队列最低配置的1倍，如果设置为0.25单个用户只能使用最小资源的0.25倍。

图例如下:

容量调度各项配置详解

容量调度配置详解(不包含抢占)：

**yarn.scheduler.capacity..queues**

配置队列的子队列有哪些，值为queue-name1,queue-name2,queue-name3,举例root队列下有子队列a,b,c.配置为 yarn.scheduler.capacity.root.queues:a,b,c

yarn.scheduler.capacity.resource-calculator

资源计算方式，默认为仅仅考虑内存org.apache.hadoop.yarn.util.resource.DefaultResourseCalculator,如果切换为DominantResourceCalculator则会计算内存和CPU.

yarn.scheduler.capacity..capacity

队列资源容量的百分比，用浮点数表示(如12.5)或者是作为绝对资源队列的最小容量。在各层级上所有 队列的百分比之和必须等于100。但是，如果配置的是绝对资源值，则子队列的绝对资源之和可能小于 其父队列的绝对资源容量。在有空闲资源的情况，队列中的应用程序可能会消耗比队列容量更多的资源， 这样可以使得队列具有弹性。这个参数对应 Yarn web页面中队列信息的 Absolute Configured Capacity。

yarn.scheduler.capacity..user-limit-factor

这个参数的含义是允许单个用户最多可获取的队列资源的倍数。默认值为1，确保单个用户无论集群有多空闲，永远不会占用超过队列配置的资源，即yarn.scheduler.capacity..capacity的值， 该参数是一个浮点值。按照这个理解，当把这个参数设置为超过1时，用户可以使用的资源将超过队列配置的资源，但应该不能超过队列配置的最大资源，否则最大资源的配置就没有意义了；如果这个参数的值小于1时，用户可以使用的资源将低于队列配置的资源。对应 Yarn web页面中队列信息的 Configured user limit Factor,默认为1

yarn.scheduler.capacity..minimum-user-limit-percent

对用户使用队列的最小资源比例进行限制，或者说是对每个用户最低使用资源的保障（百分比）。任何时刻，一个队列中每个用户可使用的资源量均有一定的限制。 当一个队列中同时有多个用户提交应用程序时， 每个用户的使用资源量会在一个最小值和最大值之间浮动，其中，最小值就是该参数指定的值，而最大值 取决于提交应用程序的用户数。比如，假设minimum-user-limit-percent为25。当两个用户向该队列 提交应用程序时，每个用户可使用资源量不能超过50%，如果三个用户提交应用程序，则每个用户可使用资 源量不能超多33%，如果四个或者更多用户提交应用程序，则每个用户可用资源量不能超过25%。默认值是100，表示的是对用户使用的最小资源比例不进行限制。这个参数对应 Yarn web页面中队列信息的 Configured Minimum User Limit Percent。在实际使用中，一直没有明白该参数是怎么发挥作用的， 只知道该参数会,对应Yarn web页面中队列信息的 Max Applications Per User 的值产生影响。

yarn.scheduler.capacity..maximum-capacity

这个参数配置为允许单个用户最多能获取的队列资源（即yarn.scheduler.capacity..capacity的值）的倍数，值是一个浮点值。也就是说如果把这个参数设置为大于1时，用户使用的资源可以超过队列资源。比如，假设该值为0.5，则任何时刻，单个用户使用的资源量不能超过该队列容量的50%；如果该值为2.0，则单个用户使用的最多资源量可以是该队列容量的200%，但无论配置为多大都不能超过队列的最大资源（即yarn.scheduler.capacity..maximum-capacity的值）。默认值为1，确保单个用户无论集群有多空闲，永远不会占用超过队列配置的资源量。默认是-1，即禁用这个参数对应 Yarn web页面中队列信息的 Configured User Limit Factor。

yarn.scheduler.capacity..maximum-applications

集群或者队列中同时处于running和pending状态的应用程序数目上限，这是一个强限制，一旦集群中应用程序数目超过该上限，后续提交的应用程序将被拒绝，默认值为10000。整个root队列的数目上限可通过参数yarn.scheduler.capacity.maximum-applications设置（可看做默认值），单个队列可通过参数 yarn.scheduler.capacity..maximum-applications 单独设置自己的值。如果不单独设置，那么对应队列的maximum-applications会按照资源占比计算。如某个队列的资源占比是15%，那么它的maximum-applications就是10000 * 15 % = 1500。在实际使用中发现，如果队列使用了绝对资源格式配置，则单独指定的方式不会生效，只会根据队列资源占比来计算。

yarn.scheduler.capacity..state

队列状态可以为STOPPED或者RUNNING，如果一个队列处于STOPPED状态，用户不可以将应用程序提交到该队列或者它的子队列中，类似的，如果ROOT队列处于STOPPED状态，用户不可以向集群中提交应用程序，但正在运行的应用程序仍可以正常运行结束，以便队列可以优雅地退出。这个参数对应 Yarn web页面中队列信息的 Queue State。

yarn.scheduler.capacity.root..acl_submit_applications

限定哪些Linux用户/用户组可向给定队列中提交应用程序。需要注意的是，该属性具有继承性，即如果一个用户可以向某个队列中提交应用程序，则它可以向它的所有子队列中提交应用程序。配置该属性时，用户之间或组之间用“，”分割，用户和用户组之间用空格分割，比如“user1,user2 group1,group2”。

yarn.scheduler.capacity.root..acl_administer_queue

为队列指定一个管理员，该管理员可控制该队列的所有应用程序，比如杀死任意一个应用程序等。如果该属性的ACL未指定则从其父队列继承。

yarn.scheduler.capacity.queue-mappings

用户到队列的绑定，该配置可以将用户或组映射到指定的队列。用户可以映射一个单独的用户或者一个用户列表到队列。语法为：[u or g]:[name]:[queue_name][,next_mapping]*。这里，u或者g表是映射是针对用户还是组。 u表示用户，g表示组。name 表示用户名或者组名。要指定提交应用程序的用户，可以用%user表示。 queue_name表示应用程序映射的队列名称。如果要指定队列名称与用户名称相同，可以用%user表示。 如果要指定队列名称与用户所属的primary组名相同，可以用%primary_group表示。举例： yarn.scheduler.capacity.queue-mappings: u:chehuida:chehuida,u:graduate:graduate,u:dingran:dingran, u:sunshine:sunshine,u:ruizai:ruizai,u:dadi:dadi,u:zheyang:zheyang,u:autobole:autobole,u:yiqi:yiqi,u:yiqi:weima

yarn.scheduler.capacity..user-settings..weight

此浮点值用于计算队列中用户的用户限制资源值。该值将使每个用户的权重大于或小于队列中的其他用户。例如，如果用户A在队列中 收到的资源比用户B和C多50%，则用户A的此属性将设置为1.5。用户B和C将设置为默认值1.0。也就说同一队列中权重越大的用户获得的资源将会越多。

yarn.scheduler.capacity.root..default-application-priority

每个叶子队列均由管理员提供默认优先级。队列的默认优先级将用于所有未指定优先级的申请, 将任务移至其他队列时，不会更改应用程序的优先级。

yarn.scheduler.capacity.root..default-application-priority

默认应用程序优先级用于没有指定优先级的任何提交的应用程序。

优先级修改

yarn-site.xml配置文件配置

yarn.cluster.max-application-priority

优先级大于此设置的所有提交的应用程序都将其优先级重置为yarn.cluster.max-application-priority值。

Yarn web 页面相关参数

Used Capacity：实际使用资源占分配资源的比例

Absolute Used Capacity：实际使用资源占整个集群的资源比例

Absolute Capacity：分配资源占比

Absolute Max Capacity：最大分配资源占比

容量调度配置样例

业务场景，现在需要

① root层级新建6个队列，其中包括default队列，Hadoop队列，product队列，dev队列，super队列，tenants队列。10%+20%+10%+20%+20%+20%=100%，达到root层级的100%

  • default队列最低分配root的10%,最大为10%*2， 管理员为hadoop
  • hadoop队列最低分配root的20%,最大为20%*3.5 管理员为hadoop
  • product队列最低分配root的10%,最大为10%*5 管理员为hadoop
  • dev队列最低分配root的20%,最大为20%*1 管理员为hadoop
  • super队列最低分配root的20%,最大为20%*5 管理员为hadoop
  • tenants队列最低分配root的20%,最大为20%*4 管理员为hadoop

② tenants层级新建10个队列，其中包括chehuida，dingran,dadi,graduate,sunshine,ruizai,zheyang,autobole,yiqi,weima。10%*10(个租户)=100%，达到tenants队列的100%

  • chehuida队列最低分配tenants的10%,最大为10%4, 占整个集群的最低为20%10%，最大为10%420% 管理员为chehuida
  • dingran队列最低分配tenants的10%,最大为10%4, 占整个集群的最低为20%10%，最大为10%420% 管理员为dingran
  • dadi队列最低分配tenants的10%,最大为10%4, 占整个集群的最低为20%10%，最大为10%420% 管理员为dadi
  • graduate队列最低分配tenants的10%,最大为10%4, 占整个集群的最低为20%10%，最大为10%420% 管理员为graduate
  • sunshine队列最低分配tenants的10%,最大为10%4, 占整个集群的最低为20%10%，最大为10%420% 管理员为sunshine
  • ruizai队列最低分配tenants的10%,最大为10%4, 占整个集群的最低为20%10%，最大为10%420% 管理员为ruizai
  • zheyang队列最低分配tenants的10%,最大为10%4, 占整个集群的最低为20%10%，最大为10%420% 管理员为zheyang
  • autobole队列最低分配tenants的10%,最大为10%4, 占整个集群的最低为20%10%，最大为10%420% 管理员为autobole
  • yiqi队列最低分配tenants的10%,最大为10%4, 占整个集群的最低为20%10%，最大为10%420% 管理员为yiqi
  • weima队列最低分配tenants的10%,最大为10%4, 占整个集群的最低为20%10%，最大为10%420% 管理员为weima

图例如下：

配置如下：

yarn.scheduler.capacity.root.queues: default,hadoop,super,dev,product,tenants
yarn.scheduler.capacity.root.default.capacity: 10
yarn.scheduler.capacity.root.default.maximum-capacity: 100
yarn.scheduler.capacity.root.default.user-limit-factor: 2
yarn.scheduler.capacity.root.default.state: RUNNING
yarn.scheduler.capacity.root.default.acl_administer_queue: hadoop
 
yarn.scheduler.capacity.root.hadoop.capacity: 20
yarn.scheduler.capacity.root.hadoop.maximum-capacity: 100
yarn.scheduler.capacity.root.hadoop.user-limit-factor: 3.5
yarn.scheduler.capacity.root.hadoop.state: RUNNING
yarn.scheduler.capacity.root.hadoop.acl_administer_queue: hadoop
 
yarn.scheduler.capacity.root.product.capacity: 10
yarn.scheduler.capacity.root.product.maximum-capacity: 100
yarn.scheduler.capacity.root.product.user-limit-factor: 5
yarn.scheduler.capacity.root.product.state: RUNNING
yarn.scheduler.capacity.root.product.acl_administer_queue: hadoop
 
yarn.scheduler.capacity.root.dev.capacity: 20
yarn.scheduler.capacity.root.dev.maximum-capacity: 100
yarn.scheduler.capacity.root.dev.user-limit-factor: 1
yarn.scheduler.capacity.root.dev.state: RUNNING
yarn.scheduler.capacity.root.dev.acl_administer_queue: hadoop
 
yarn.scheduler.capacity.root.super.capacity: 20
yarn.scheduler.capacity.root.super.maximum-capacity: 100
yarn.scheduler.capacity.root.super.user-limit-factor: 5
yarn.scheduler.capacity.root.super.state: RUNNING
yarn.scheduler.capacity.root.super.acl_administer_queue: hadoop
 
yarn.scheduler.capacity.root.tenants.capacity: 20
yarn.scheduler.capacity.root.tenants.maximum-capacity: 100
yarn.scheduler.capacity.root.tenants.user-limit-factor: 4
yarn.scheduler.capacity.root.tenants.queues: chehuida,graduate,dingran,sunshine,ruizai,dadi,zheyang,autobole,yiqi,weima
 
yarn.scheduler.capacity.root.tenants.chehuida.capacity: 10
yarn.scheduler.capacity.root.tenants.chehuida.maximum-capacity: 100
yarn.scheduler.capacity.root.tenants.chehuida.user-limit-factor: 4
yarn.scheduler.capacity.root.tenants.chehuida.state: RUNNING
yarn.scheduler.capacity.root.tenants.chehuida.acl_administer_queue: chehuida
 
yarn.scheduler.capacity.root.tenants.dingran.capacity: 10
yarn.scheduler.capacity.root.tenants.dingran.maximum-capacity: 100
yarn.scheduler.capacity.root.tenants.dingran.user-limit-factor: 4
yarn.scheduler.capacity.root.tenants.dingran.state: RUNNING
yarn.scheduler.capacity.root.tenants.dingran.acl_administer_queue: dingran
 
yarn.scheduler.capacity.root.tenants.dadi.capacity: 10
yarn.scheduler.capacity.root.tenants.dadi.maximum-capacity: 100
yarn.scheduler.capacity.root.tenants.dadi.user-limit-factor: 4
yarn.scheduler.capacity.root.tenants.dadi.state: RUNNING
yarn.scheduler.capacity.root.tenants.dadi.acl_administer_queue: dadi
 
yarn.scheduler.capacity.root.tenants.graduate.capacity: 10
yarn.scheduler.capacity.root.tenants.graduate.maximum-capacity: 100
yarn.scheduler.capacity.root.tenants.graduate.user-limit-factor: 4
yarn.scheduler.capacity.root.tenants.graduate.state: RUNNING
yarn.scheduler.capacity.root.tenants.graduate.acl_administer_queue: graduate
 
yarn.scheduler.capacity.root.tenants.sunshine.capacity: 10
yarn.scheduler.capacity.root.tenants.sunshine.maximum-capacity: 100
yarn.scheduler.capacity.root.tenants.sunshine.user-limit-factor: 4
yarn.scheduler.capacity.root.tenants.sunshine.state: RUNNING
yarn.scheduler.capacity.root.tenants.sunshine.acl_administer_queue: sunshine
 
yarn.scheduler.capacity.root.tenants.ruizai.capacity: 10
yarn.scheduler.capacity.root.tenants.ruizai.maximum-capacity: 100
yarn.scheduler.capacity.root.tenants.ruizai.user-limit-factor: 4
yarn.scheduler.capacity.root.tenants.ruizai.state: RUNNING
yarn.scheduler.capacity.root.tenants.ruizai.acl_administer_queue: ruizai
 
yarn.scheduler.capacity.root.tenants.zheyang.capacity: 10
yarn.scheduler.capacity.root.tenants.zheyang.maximum-capacity: 100
yarn.scheduler.capacity.root.tenants.zheyang.user-limit-factor: 4
yarn.scheduler.capacity.root.tenants.zheyang.state: RUNNING
yarn.scheduler.capacity.root.tenants.zheyang.acl_administer_queue: zheyang
 
yarn.scheduler.capacity.root.tenants.autobole.capacity: 10
yarn.scheduler.capacity.root.tenants.autobole.maximum-capacity: 100
yarn.scheduler.capacity.root.tenants.autobole.user-limit-factor: 4
yarn.scheduler.capacity.root.tenants.autobole.state: RUNNING
yarn.scheduler.capacity.root.tenants.autobole.acl_administer_queue: autobole
 
yarn.scheduler.capacity.root.tenants.yiqi.capacity: 10
yarn.scheduler.capacity.root.tenants.yiqi.maximum-capacity: 100
yarn.scheduler.capacity.root.tenants.yiqi.user-limit-factor: 4
yarn.scheduler.capacity.root.tenants.yiqi.state: RUNNING
yarn.scheduler.capacity.root.tenants.yiqi.acl_administer_queue: yiqi
 
yarn.scheduler.capacity.root.tenants.weima.capacity: 10
yarn.scheduler.capacity.root.tenants.weima.maximum-capacity: 100
yarn.scheduler.capacity.root.tenants.weima.user-limit-factor: 4
yarn.scheduler.capacity.root.tenants.weima.state: RUNNING
yarn.scheduler.capacity.root.tenants.weima.acl_administer_queue: weima
 
yarn.scheduler.capacity.queue-mappings: u:chehuida:chehuida,u:graduate:graduate,u:dingran:dingran,u:sunshine:sunshine,u:ruizai:ruizai,u:dadi:dadi,u:zheyang:zheyang,u:autobole:autobole,u:yiqi:yiqi,u:yiqi:weima

总结

以上为Yarn容量调度的详细配置，当然这里没有提到保留功能,以及容量调度抢占功能,以及nodelabel功能,下一篇我会更新容量调度抢占功能,希望可以对读者起到帮助作用.

参考

  • http://hadoop.apache.org
  • https://blog.cloudera.com/yarn-capacity-scheduler/
  • https://blog.cloudera.com/better-slas-via-resource-preemption-in-yarns-capacityscheduler/
  • http://bcxw.net/article/373.html

打赏一个呗

取消

感谢您的支持，我会继续努力的!

扫码支持
扫码支持
扫码打赏，你说多少就多少

打开支付宝扫一扫，即可进行扫码打赏哦