目录
1.为什么要用资源调度队列Capacity Scheduler
1.为什么要用资源调度队列Capacity Scheduler
当有很多任务，实时任务，定时任务，重要的应用，不重要的任务，又或各个部门使用统一hadoop集群，那么你就要考虑资源调度的配置了，因为你不可能让一个任务把计算机资源占完，而不处理很重要紧急的程序。本文档大部分借鉴官方文档的配置描述。
本文档描述了Hadoop的一个可插拔调度程序capacityscheduler，它允许多个用户安全地共享一个大集群，这样他们的应用程序就可以在分配的容量限制下及时分配资源。
CapacityScheduler旨在以一种对操作员友好的方式将Hadoop应用程序作为共享多用户集群运行，同时最大限度地提高集群的吞吐量和利用率。
传统情况下，每个组织都有自己的私有计算资源集群，这些资源具有足够的容量来满足组织在峰值或近峰值条件下的SLA（服务可靠性）。这通常会导致管理多个独立集群（每个组织一个）的平均利用率和开销低。在组织之间共享集群是运行大型Hadoop安装的一种经济有效的方式，因为这允许他们在不创建私有集群的情况下获得规模经济的好处。但是，组织担心共享集群，因为他们担心其他人使用对其SLA至关重要的资源。
Capacity Scheduler容量调度程序设计是为允许共享一个大型集群，同时为每个组织提供容量保证。核心思想是Hadoop集群中的可用资源由多个组织共享，这些组织根据其计算需求共同为集群提供资金。还有一个额外的好处是，一个组织可以访问任何未被其他人使用的过剩产能。这以一种经济有效的方式为组织提供了弹性。
跨组织共享集群需要对多用户的强大支持，因为每个组织必须保证容量和安全防护，以确保共享集群不受单一大型应用程序或用户或其他的影响。CapacityScheduler提供了一组严格的限制，以确保单个应用程序、用户或队列不能消耗集群中过多的资源。此外，capacityscheduler还对来自单个用户和队列的已初始化/挂起的应用程序提供限制，以确保集群的公平性和稳定性。
容量调度程序提供的主要抽象是队列的概念。这些队列通常由管理员设置，以反映共享集群的经济性。
为了在资源共享上提供进一步的控制和可预测性，CapacityScheduler支持分层队列，以确保在允许其他队列使用自由资源之前，在组织的子队列之间共享资源，通过提供在给定组织的应用程序之间共享自由资源的亲和力。
3.1分层队列—通过提供更多的控制和可预测性，支持队列的层次结构，以确保在允许其他队列使用自由资源之前，在组织的子队列之间共享资源。
3.2容量保证—在一定的资源容量将由他们支配的意义上，队列被分配为网格容量的一小部分。提交到队列的所有应用程序都可以访问分配给队列的容量。管理员可以对分配给每个队列的容量配置软限制和可选硬限制。
3.3安全性—每个队列都有严格的ACL，用于控制哪些用户可以将应用程序提交到各个队列。此外，还有安全保护，以确保用户无法查看和/或修改其他用户的应用程序。此外，还支持每个队列和系统管理员角色。
3.4弹性—可以将可用资源分配给超出其容量的任何队列。如果将来某个时间点的运行容量不足的队列需要这些资源，随着这些资源上计划的任务完成，这些资源将分配给运行容量不足的队列上的应用程序（也支持先发制人）。这样可以确保资源以可预测和弹性的方式提供给队列，从而防止集群中的资源闲置，从而有助于利用资源。
3.5多用户控制—提供了一组全面的限制，以防止单个应用程序、用户和队列独占队列或整个集群的资源，以确保集群不会被压垮。
3.6可操作性-运行时配置-在运行时，管理员可以安全地更改队列定义和属性（如容量、ACL），以尽量减少对用户的干扰。此外，还为用户和管理员提供了一个控制台，以查看当前分配给系统中各个队列的资源。管理员可以在运行时添加其他队列，但不能在运行时删除队列。
排出应用程序-管理员可以在运行时停止队列，以确保在现有应用程序运行到完成时，不能提交新的应用程序。如果队列处于已停止状态，则无法将新应用程序提交到其自身或其任何子队列。现有的应用程序继续完成，因此可以适当地排出队列。管理员还可以启动已停止的队列。
3.7基于资源的调度-支持资源密集型应用程序，在应用程序中，可以选择指定比默认值更高的资源需求，通过适应具有不同资源需求的应用程序。目前，内存是支持的资源需求。
3.8基于用户或组的队列映射-此功能允许用户将作业映射到基于用户或组的特定队列。
4.1yarn ResourceManager 设置使用 CapacityScheduler
在conf/yarn-site.xml配置如下
| Property | Value |
|---|---|
| yarn.resourcemanager.scheduler.class | org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler |
4.2配置队列
在etc/hadoop/capacity-scheduler.xml中配置队列
capacity scheduler调度器有一个名为root的预定义队列。系统中的所有队列都是根队列的子队列。
通过使用逗号分隔的子队列列表配置yarn.scheduler.capacity.root.queues，可以设置更多的队列。
capacity scheduler的配置使用一个名为queue path的概念来配置队列的层次结构。队列路径是队列层次结构的完整路径，从根目录开始。（点）作为分隔符。
可以使用配置项：yarn.scheduler.capacity.<queue path>.queues来定义给定队列的子队列。除非另有说明，否则子级不会直接从父级继承属性。
下面是三个顶级子队列A、B和C以及一些子队列A和B的示例：
<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>
4.3队列配置属性
4.3.1 资源配置
Property | Description |
yarn.scheduler.capacity.<queue-path>.capacity | 以百分比（%）表示的队列容量（如12.5）。各级所有队列的容量总和必须等于100。如果有空闲资源 ，队列中的应用程序可能会消耗比队列容量更多的资源，从而提供弹性。 |
yarn.scheduler.capacity.<queue-path>.maximum-capacity | 以百分比（%）表示的最大队列容量。这限制了队列中应用程序的弹性。默认为-1，禁用它。 |
yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent | 如果对资源有需求，每个队列都强制限制在任何给定时间分配给用户的资源百分比。用户限制可以在最小值和最大值之间变化 。前者（最小值）设置为该属性值，后者（最大值）取决于已提交应用程序的用户数。例如，假设该属性的值为25。 如果两个用户向一个队列提交了应用程序，则任何一个用户都不能使用超过50%的队列资源。如果第三个用户提交了一个应用程序， 那么任何一个用户都不能使用超过33%的队列资源。对于4个或更多用户，没有任何用户可以使用超过25%的队列资源。 值为100表示不施加用户限制。默认值为100。值被指定为整数。 |
yarn.scheduler.capacity.<queue-path>.user-limit-factor | 可以配置为允许单个用户获取更多资源的队列容量的倍数。默认情况下，该值设置为1，以确保无论集群的空闲程度如何 ，单个用户都不能占用超过队列配置的容量。值被指定为浮点。 |
yarn.scheduler.capacity.<queue-path>.maximum-allocation-mb | 在资源管理器上分配给每个容器请求的每个队列的最大内存限制。此设置将覆盖集群配置yarn.scheduler.maximum-allocation-mb 。此值必须小于或等于群集最大值。 |
yarn.scheduler.capacity.<queue-path>.maximum-allocation-vcores | 在资源管理器上分配给每个容器请求的虚拟核心的每个队列的最大限制 。此设置将覆盖集群配置yarn.scheduler.maximum-allocation-vcore。此值必须小于或等于群集最大值。 |
4.3.2 应用和挂起程序的限制
CapacityScheduler支持以下参数来控制正在运行和挂起的应用程序：
Property | Description |
yarn.scheduler.capacity.maximum-applications / yarn.scheduler.capacity.<queue-path>.maximum-applications | 系统中同时处于运行和挂起状态的最大应用程序数。每个队列的限制与其队列容量和用户限制成正比 。这是一个硬限制，达到此限制后提交的任何申请都将被拒绝。默认值为10000。 这可以为所有使用yarn.scheduler.capacity.maximum-applications的队列设置， 也可以通过设置yarn.scheduler.capacity.<queue path>maximum-applications在每个队列的基础上覆盖。需要整数值。 |
yarn.scheduler.capacity.maximum-am-resource-percent / yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent | 群集中可用于运行应用程序的最大资源百分比-控制并发活动应用程序的数量。每个队列的限制与其队列容量和用户限制成正比 。指定为浮点数-即0.5=50%。默认值为10%。 这可以为具有yarn.scheduler.capacity.maximum-am-resource-percent的所有队列设置， 也可以通过设置yarn.scheduler.capacity.<queue path>maximum am resource-percent 在每个队列的基础上覆盖。 |
4.3.3队列权限管理配置项
CapacityScheduler支持以下参数来管理队列：
Property | Description |
yarn.scheduler.capacity.<queue-path>.state | 队列的状态。可以是正在运行或已停止。如果队列处于已停止状态，则无法将新应用程序提交到其自身或其任何子队列 。因此，如果根队列被停止，就不能向整个集群提交任何应用程序。现有的应用程序继续完成， 因此可以适当地排出队列。值被指定为枚举。 |
yarn.scheduler.capacity.root.<queue-path>.acl_submit_applications | 控制谁可以向给定队列提交应用程序的ACL。如果给定的用户/组在给定队列或层次结构中的某个父队列上具有必要的ACL ，则可以提交应用程序。如果未指定，则此属性的ACL将从父队列继承。 |
yarn.scheduler.capacity.root.<queue-path>.acl_administer_queue | 控制谁可以管理给定队列上的应用程序的ACL。如果给定的用户/组在给定队列或层次结构中的某个父队列上具有必要的ACL ，则可以管理应用程序。如果未指定，则此属性的ACL将从父队列继承。 |
注意：acl的格式为user1、user2spacegroup1、group2。*的特殊价值意味着任何人。空间的特殊价值并不意味着任何人。如果未指定，则根队列的默认值为*。
4.3.4 基于用户或组的队列映射
CapacityScheduler支持以下参数以根据用户或组配置队列映射：
Property | Description |
yarn.scheduler.capacity.queue-mappings | 此配置指定用户或组到特定队列的映射。可以将单个用户或用户列表映射到队列。语法：[u或g]：[name]：[queue_name][，next_mapping]* 。这里，u或g表示映射是针对用户还是针对组。用户的值为U，组的值为G。名称表示用户名或组名。若要指定已提交应用程序的用户，可以使用%user。 队列名称表示应用程序必须映射到的队列名称。若要指定与用户名相同的队列名称，可以使用%user。若要指定与用户所属主组的名称相同的队列名称，可以使用%primary_group。 |
yarn.scheduler.capacity.queue-mappings-override.enable | 此函数用于指定是否可以覆盖用户指定的队列。这是一个布尔值，默认值为假。 |
案例
<property> <name>yarn.scheduler.capacity.queue-mappings</name> <value>u:user1:queue1,g:group1:queue2,u:%user:%user,u:user2:%primary_group</value> <description> Here, <user1> is mapped to <queue1>, <group1> is mapped to <queue2>, maps users to queues with the same name as user, <user2> is mapped to queue name same as <primary group> respectively. The mappings will be evaluated from left to right, and the first valid mapping will be used. </description> </property>
4.4 调度器资源容器抢占
CapacityScheduler支持从资源使用超过其保证容量的队列中抢占容器。为了支持应用程序容器的抢占，需要在yarn-site.xml中启用以下配置参数
。
Property | Description |
yarn.resourcemanager.scheduler.monitor.enable | 启用定期监视器（在yarn.resourcemanager.scheduler.monitor.policies中指定）。默认值为false。 |
yarn.resourcemanager.scheduler.monitor.policies | 与调度程序交互的schedulingEditPolicy类的列表。配置的策略需要与调度程序兼容。默认值为org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.proportionalcapacitypreemptionpolicy，与capacityscheduler兼容 |
当为yarn.resourcemanager.scheduler.monitor.policies配置了成比例的capacitypreemptionpolicy类时，可以在yarn-site.xml中配置以下配置参数，以控制容器的抢占。
| Property | Description |
|---|---|
| yarn.resourcemanager.monitor.capacity.preemption.observe_only | 如果为true，则运行策略，但不影响具有抢占和终止事件的群集。默认值为false |
| yarn.resourcemanager.monitor.capacity.preemption.monitoring_interval | 调用此比例容量抢占策略之间的时间（毫秒）。默认值为3000 |
| yarn.resourcemanager.monitor.capacity.preemption.max_wait_before_kill | 从应用程序请求抢占和终止容器之间的时间（毫秒）。默认值为15000 |
| yarn.resourcemanager.monitor.capacity.preemption.total_preemption_per_round | 单轮中抢占资源的最大百分比。通过控制这个值，可以控制容器从集群中回收的速度。在计算出所需的全部抢占权之后，策略将其扩展回这个限制范围内。默认值为0.1 |
| yarn.resourcemanager.monitor.capacity.preemption.max_ignored_over_capacity | 为抢占而忽略的超过目标容量的最大资源量。这定义了围绕目标容量的死区 ，有助于防止围绕计算的目标平衡的震荡和振荡。高值会减慢产能的实现时间，并且（不存在自然完工）可能会阻止收敛到保证产能。默认值为0.1 |
| yarn.resourcemanager.monitor.capacity.preemption.natural_termination_factor | 给定一个计算出的抢占目标，说明容器自然过期，只抢占增量的这个百分比 。这决定了几何收敛到死区的速率（max_ignored_over_capacity）。 例如，0.5的终止因子将在5*等待时间内回收几乎95%的资源，即使没有自然终止。默认值为0.2 |
capacity scheduler在capacity-scheduler.xml中支持以下配置，以控制提交到队列的应用程序容器的抢占。
Property | Description |
yarn.scheduler.capacity.<queue-path>.disable_preemption | 可以将此配置设置为true，以选择性地禁用提交到给定队列的应用程序容器的抢占。仅当通过将yarn.resourcemanager.scheduler.monitor.enable配置为true 并将yarn.resourcemanager.scheduler.monitor.policies配置为成比例的capacity preemption policy来启用系统范围的抢占 时，此属性才适用。如果没有为队列设置此属性，则属性值将从队列的父级继承。默认值为false |
4.5 其他配置项
4.5.1 资源计算器规则
Property | Description |
yarn.scheduler.capacity.resource-calculator | 用于比较计划程序中资源的ResourceCalculator实现。默认的，即org.apache.hadoop.yarn.util.resource.DefaultResourseCalculato资源计算只使用内存 ，而DominantResourceCalculator使用主资源来比较多维资源，如内存、CPU等。 |
4.5.2 数据局部性
| Property | Description |
|---|---|
| yarn.scheduler.capacity.node-locality-delay | CapacityScheduler尝试调度机本地容器之后错过的调度机会数。通常，应该将其设置为集群中的节点数。默认情况下 ，在一个架构中设置大约40个节点。应为正整数值。 |
4.6检查配置是否成功
配置完后，启动yarn集群，然后打开8088web界面，点击scheduler就可以查看当前配置好的队列了。
4.7 让修改后的队列配置生效
运行命令
yarn rmadmin -refreshQueues
或者运行stop-yarn.sh再start-yarn.sh重启集群
5.1yarn-site.xml配置
<property> <name>yarn.resourcemanager.scheduler.class</name> <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler</value> </property>
5.2capacity-scheduler.xml配置
需要实现的队列如下，实现测试环境和生产环境资源分离，并分各个等级，注意队列的名称不能重复的
--root
----pro(70%资源可以占用其他资源)
--------high(50%可扩展)
--------middle(30%可扩展)
--------low(20%可扩展)
----dev(30%资源不可以占用其他)
--------more(70%不可扩展)
--------less(30%不可扩展)
<!--root--> <property> <name>yarn.scheduler.capacity.root.queues</name> <value>pro,dev</value> </property> <!--pro--> <property> <name>yarn.scheduler.capacity.root.pro.capacity</name> <value>70</value> </property> <property> <name>yarn.scheduler.capacity.root.pro.maximum-capacity</name> <value>100</value> </property> <property> <name>yarn.scheduler.capacity.root.pro.user-limit-factor</name> <value>1</value> </property> <!--dev--> <property> <name>yarn.scheduler.capacity.root.dev.capacity</name> <value>30</value> </property> <property> <name>yarn.scheduler.capacity.root.dev.maximum-capacity</name> <value>30</value> </property> <property> <name>yarn.scheduler.capacity.root.dev.user-limit-factor</name> <value>1</value> </property> <!--root child--> <property> <name>yarn.scheduler.capacity.root.pro.queues</name> <value>high,middle,low</value> </property> <property> <name>yarn.scheduler.capacity.root.dev.queues</name> <value>more,less</value> </property> <!--pro child--> <property> <name>yarn.scheduler.capacity.root.pro.high.capacity</name> <value>50</value> </property> <property> <name>yarn.scheduler.capacity.root.pro.high.maximum-capacity</name> <value>100</value> </property> <property> <name>yarn.scheduler.capacity.root.pro.high.user-limit-factor</name> <value>1</value> </property> <property> <name>yarn.scheduler.capacity.root.pro.middle.capacity</name> <value>30</value> </property> <property> <name>yarn.scheduler.capacity.root.pro.middle.maximum-capacity</name> <value>100</value> </property> <property> <name>yarn.scheduler.capacity.root.pro.middle.user-limit-factor</name> <value>1</value> </property> <property> <name>yarn.scheduler.capacity.root.pro.low.capacity</name> <value>20</value> </property> <property> <name>yarn.scheduler.capacity.root.pro.low.maximum-capacity</name> <value>100</value> </property> <property> <name>yarn.scheduler.capacity.root.pro.low.user-limit-factor</name> <value>1</value> </property> <!--dev child--> <property> <name>yarn.scheduler.capacity.root.dev.more.capacity</name> <value>70</value> </property> <property> <name>yarn.scheduler.capacity.root.dev.more.maximum-capacity</name> <value>100</value> </property> <property> <name>yarn.scheduler.capacity.root.dev.more.user-limit-factor</name> <value>1</value> </property> <property> <name>yarn.scheduler.capacity.root.dev.less.capacity</name> <value>30</value> </property> <property> <name>yarn.scheduler.capacity.root.dev.less.maximum-capacity</name> <value>100</value> </property> <property> <name>yarn.scheduler.capacity.root.dev.less.user-limit-factor</name> <value>1</value> </property>
然后重启yarn集群
5.38088端口网页端查看效果
http://master:8088/cluster/scheduler
spark运行应用程序使用队列queue
$ ./bin/spark-submit --class org.apache.spark.examples.SparkPi \ --master yarn \ --deploy-mode cluster \ --driver-memory 4g \ --executor-memory 2g \ --executor-cores 1 \ --queue thequeue \ examples/jars/spark-examples*.jar \ 10
