🦄 个人主页——🎐开着拖拉机回家_Linux,Java基础学习,大数据运维-CSDN博客 🎐✨🍁
🪁🍁🪁🍁🪁🍁🪁🍁 🪁🍁🪁🍁🪁🍁🪁 🪁🍁🪁🍁🪁🍁🪁🍁🪁🍁🪁🍁
目录
一、CapacityScheduler简介
二、CapacityScheduler特性
三、CapacityScheduler配置
四、YARN WEB UI 参数详解
一、CapacityScheduler简介
Hadoop YARN的核心组件是ResourceManager，负责集群资源管理与调度，而ResourceManager组件的核心是调度器，负责统筹集群资源，满足应用的资源需求。调度器不仅需要优化整个集群的资源布局，避免热点等问题对应用的影响，最大程度利用集群资源；还要能协调好大量应用在集群的运行，基于多租户（队列）公平性、应用优先级等策略解决好资源竞争等问题；也要能满足个别应用在节点依赖、放置策略等方面的特殊需求。
YARN调度器是可拔插的插件，主要有FIFOScheduler、FairScheduler和CapacityScheduler三类。
- FIFOScheduler：是最简单的调度器，不支持多租户（所有应用都提交到Default队列），不考虑集群的资源分布（节点上堆叠调度），只支持以FIFO（First In，First Out）策略依次调度应用，无其他控制与调度特性。只适用于及其简单的场景，因此很少应用于正式生产。
- FairScheduler：是CDH（Cloudera Distributed Hadoop）的默认调度器，与HDP（Hortonworks Data Platform）合并后的CDP（Cloudera Data Platform）不再使用（迁移到CapacityScheduler），Apache Hadoop社区也建议迁移到CapacityScheduler。FairScheduler支持较为完善的多租户管理与资源调度能力，包括多级队列、配额管理、ACL控制、弹性资源共享、租户间公平性调度策略、租户内应用调度策略、资源预留、抢占、异步调度等，然而在Apache Hadoop社区的发展相比CapacityScheduler仍稍显落后，核心调度未考虑整个集群的资源布局，也不支持Node Labels（分区调度）、Node Attributes（节点打标调度）、Placement Constraints（放置约束）等调度特性。
- CapacityScheduler：是Apache Hadoop社区、HDP（Hortonworks Data Platform）及合并后CDP（Cloudera Data Platform）的默认调度器，具有最完善的多租户管理与资源调度能力，不仅包含了FairScheduler的全部能力，还能协调好整个集群的资源布局（基于Global Scheduling），减少热点概率，最大程度利用集群资源，还支持Node Labels（分区调度）Node Attributes（节点打标调度）、Placement Constraints（放置约束）等调度特性。
下面重点对CapacityScheduler进行介绍，其他调度器的使用说明请参考社区文档。
二、CapacityScheduler特性
- 分层队列——支持分层队列，以确保在允许其他队列使用空闲资源之前，在组织的子队列之间共享资源，从而提供更多的控制和可预测性。
- 容量保证——队列被分配了网格容量的一小部分，在某种意义上，一定容量的资源将供它们使用。提交到队列的所有应用程序都可以访问分配给队列的容量。管理员可以对分配给每个队列的容量配置软限制和可选的硬限制，就是可以使用其他队列的剩余资源，也可以严格限制不能超出限制。
- 安全性——每个队列都有严格的acl，它控制哪些用户可以向各个队列提交应用程序。此外，还有安全防护措施，以确保用户不能查看和/或修改来自其他用户的应用程序。此外，还支持每个队列和系统管理员角色。
- 弹性资源共享——可以将空闲资源分配给超出其容量的任何队列。当队列配置资源有空闲时，可以分配给其他有资源需求的队列。当再次需要这些资源时可以抢夺回这些资源。这确保了资源以可预测和弹性的方式对队列可用，从而防止集群中人为的资源孤岛，从而有助于利用率。
- 多租户——提供了一组全面的限制，以防止单个应用程序、用户和队列独占队列或整个集群的资源，以确保集群不会不堪重负。
- 可操作性
-
- 运行时配置——管理员可以在运行时以安全的方式更改队列定义和属性(如容量、acl)，以尽量减少对用户的干扰。此外，还为用户和管理员提供了一个控制台，以查看系统中各种队列的当前资源分配情况。管理员可以在运行时添加额外的队列，但不能在运行时删除队列，除非队列已停止并且没有挂起/正在运行的应用程序。
- 取消应用程序——管理员可以在运行时停止队列，以确保在现有应用程序运行到完成时，没有新的应用程序可以提交。如果队列处于STOPPED状态，则不能将新的应用程序提交给它自己或它的任何子队列。现有的应用程序将继续完成，因此可以正常地耗尽队列。管理员还可以启动已停止的队列。
- 基于资源的调度——支持资源密集型应用程序，其中应用程序可以选择指定比默认值更高的资源需求，从而容纳具有不同资源需求的应用程序。目前，内存是支持的资源需求。
- 优先级调度——该功能允许应用程序以不同的优先级提交和调度。整数值越大，优先级越高。目前，应用程序优先级仅支持FIFO排序策略。
- 绝对资源配置——管理员可以为队列指定绝对资源，而不是提供基于百分比的值。这为管理员提供了更好的控制，以便为给定队列配置所需的资源量。
三、CapacityScheduler配置
Ambari 2.7.4配置页面
配置队列层级如下：
root
├── acc
└── ipva
├── bzv2
└── defaultAmbari-queue-manager配置如下：
capacity-scheduler.xml 配置文件
<configuration xmlns:xi="http://www.w3.org/2001/XInclude">
<!-- 设置所有提交的job中ApplicationMaster的资源比例上限，该参数通常用于限制处于活动状态的job数量。-->
<property>
<name>yarn.scheduler.capacity.maximum-am-resource-percent</name>
<value>0.2</value>
</property>
<!-- 最多可运行的应用数，默认10000 -->
<property>
<name>yarn.scheduler.capacity.maximum-applications</name>
<value>10000</value>
</property>
<!-- 队列本地延迟设置，根据机架感知，对于有nodemanager的客户端，会优先考虑向本地的nodemanager派发task，该值用于配置，默认尝试次数为40次 -->
<property>
<name>yarn.scheduler.capacity.node-locality-delay</name>
<value>40</value>
</property>
<!-- 该配置指定调度器使用的资源计算器，资源计算器用于在调度器中比较资源。默认值是 org.apache.hadoop.yarn.util.resource.DefaultResourseCalculator，只使用内存进行比较
DominantResourceCalculator 用 Dominant-resource比较多维度资源，如内存，CPU等-->
<property>
<name>yarn.scheduler.capacity.resource-calculator</name>
<value>org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator</value>
</property>
<!-- 访问控制,控制谁可以管理(包括提交和取消)该队列的任务,表示任何人 -->
<property>
<name>yarn.scheduler.capacity.root.acc.acl_administer_queue</name>
<value>*</value>
</property>
<!-- 限定哪些用户/用户组可向给定队列中提交应用程序 -->
<property>
<name>yarn.scheduler.capacity.root.acc.acl_submit_applications</name>
<value>*</value>
</property>
<!-- acc 队列资源比例 -->
<property>
<name>yarn.scheduler.capacity.root.acc.capacity</name>
<value>60</value>
</property>
<!-- acc 队列最大资源比例 -->
<property>
<name>yarn.scheduler.capacity.root.acc.maximum-capacity</name>
<value>70</value>
</property>
<!-- 指定队列内单个用户的最小资源比例（相对于队列保障资源），队列内单个用户的资源限制=max（队列保障资源/用户数, 队列保障资源 * minimumUserLimitPercent / 100）， 默认值：100。 -->
<property>
<name>yarn.scheduler.capacity.root.acc.minimum-user-limit-percent</name>
<value>100</value>
</property>
<!-- 指定队列内应用调度策略，包括Fifo与Fair两种，Fifo即先入先出调度，对所有应用按优先级从高到低、提交时间从前往后的顺序排序，
Fair是公平调度，对所有应用按资源使用比例从小到大、提交时间从前往后的顺序排序。默认值：Fifo， 一般应用场景配置成Fair更合适。 -->
<property>
<name>yarn.scheduler.capacity.root.acc.ordering-policy</name>
<value>fifo</value>
</property>
<!-- acc 队列优先级 ，默认值0 -->
<property>
<name>yarn.scheduler.capacity.root.acc.priority</name>
<value>0</value>
</property>
<!-- 指定队列状态，默认值：RUNNING。通常不需要配置，只有在需要删除队列的时候，修改指定队列的状态为STOPPED，待队列下应用全部结束后队列将会被自动删除。 -->
<property>
<name>yarn.scheduler.capacity.root.acc.state</name>
<value>RUNNING</value>
</property>
<!-- acc 队列内单个用户的资源上限因子，队列内单个用户最大可用资源=min（队列最大资源, yarn.scheduler.capacity.xx.capacity * userLimitFactor），默认值：1.0。 -->
<property>
<name>yarn.scheduler.capacity.root.acc.user-limit-factor</name>
<value>1.5</value>
</property>
<!-- root 队列可以访问的label列表，默认不配置，访问所有无标签的 -->
<property>
<name>yarn.scheduler.capacity.root.accessible-node-labels</name>
<value>*</value>
</property>
<!-- 为队列指定一个管理员，该管理员可控制该队列的所有应用程序，比如杀死任意一个应用程序等。 -->
<property>
<name>yarn.scheduler.capacity.root.acl_administer_queue</name>
<value>yarn,spark,hive</value>
</property>
<!-- 限定用户/用户组可向给定队列中提交应用程序。需要注意的是，该属性具有继承性，即如果一个用户可以向某个队列中提交应用程序，则它可以向它的所有子队列中提交应用程序 -->
<property>
<name>yarn.scheduler.capacity.root.acl_submit_applications</name>
<value>yarn,ambari-qa</value>
</property>
<!-- bz2 队列 与acc 类似 -->
<!-- ipva 队列 与acc 类似 -->
<!-- 省略部分 -->
<!-- root根下的 子队列 -->
<property>
<name>yarn.scheduler.capacity.root.queues</name>
<value>acc,bz2,default,ipva</value>
</property>
</configuration>关键参数说明：
yarn.scheduler.capacity.root.acc.capacity：队列资源容量的百分比，用浮点数表示(如12.5)或者是作为绝对资源队列的最小容量。在各层级上所有队列的百分比之和必须等于100。
yarn.scheduler.capacity.root.acc.maximum-capacity：最大队列容量，以百分比(%)表示为浮点数，或以绝对资源队列最大容量表示。这限制了队列中应用程序的弹性。1)取值范围为0 ~ 100。2)管理员需要确保绝对最大容量>=每个队列的绝对容量。此外，将此值设置为-1将最大容量设置为100%。
yarn.scheduler.capacity.root.acc.user-limit-factor： 这个参数配置为允许单个用户最多能获取的队列资源（即yarn.scheduler.capacity..capacity的值）的倍数，值是一个浮点值。也就是说如果把这个参数设置为大于1时，用户使用的资源可以超过队列资源。如果该值为2.0，则单个用户使用的最多资源量可以是该队列容量的2倍，但无论配置为多大都不能超过队列的最大资源（即yarn.scheduler.capacity..maximum-capacity的值）。默认值为1，确保单个用户无论集群有多空闲，永远不会占用超过队列配置的资源量。
四、YARN WEB UI 参数详解
如下图 点击 Scheduler可以看到在 Ambari 页面上配置的层级队列
如下是acc 队列的使用情况，不用 队列使用不用的颜色显示
资源说明
- 总内存资源： 101.25*1024 = 103680M
- acc队列容量：103680*60% = 62208M
- acc队列容量最大：103680*70% = 72575M
| 显示 | 解释 |
| Queue State: RUNNING | 队列状态 RUNNING |
| Used Capacity : 78.2% | 已使用资源占队列配置值的百分比48640/62208=78.2% |
| Effective Capacity: memory:62208, vCores:36> (60.0%) | 有效容量，表示队列实际可用的内存和虚拟核心资源 分别为 62208 MB 和 36 个。 |
| Effective Max Capacity: 72575, vCores:41> (70.0%) | 有效最大容量，表示队列实际可用的内存和虚拟核心资源分别为 72575 MB 和 41 个。 |
| Absolute Used Capacity: 46.9% | 已使用绝对容量 48640/103680=46.9% |
| Absolute Configured Capacity: 60.0% | 表示队列在整个集群中占据配置容量60%。 |
| Absolute Configured Max Capacity: 70.0% | 表示队列在整个集群中占据最大配置容量70%。 |
| Used Resources: <48640, vCores:15> | acc 队列使用 资源 |
| Configured Max Application Master Limit: 20.0 | AppMaster 限制使用资源 20% |
| Max Application Master Resources: <memory:14848, vCores:1> | 表示每个 Application Master 最多可以使用 2560 MB 内存和 1 个虚拟核心资源 |
| Used Application Master Resources: <memory:1024, vCores:1> | AppMaster 资源使用 1核1G |
| Max Application Master Resources Per User: <memory:14848, vCores:1> | 表示每个用户的 Application Master 最多可以使用 14848MB 内存和 1 个虚拟核心资源。 |
| Num Schedulable Applications: 1 | 调度的App调用个数为 1 |
| Num Non-Schedulable Applications: 0 | 没有被调度的app应用个数 |
| Num Containers: 3 | 容器运行 个数3 |
| Max Applications: 6000 | 最大应用数量 6000 |
| Max Applications Per User: 6000 | 每个user最多可以运行的应用数量 6000 |
| Configured Minimum User Limit Percent: 100% | 每个user最多可以使用队列资源的百分比 |
| Configured User Limit Factor: 1.5 | 最多能获取的队列资源的1.5倍 |
| Accessible Node Labels: * | 标签策略 为匹配所有 |
| Ordering Policy: FifoOrderingPolicy | 队列内部任务采用策略Fifo |
参考文章：
什么是YARN调度器_开源大数据平台E-MapReduce-阿里云帮助中心
【深入浅出 Yarn 架构与实现】 Yarn 三种调度器_yarn调度器-CSDN博客
yarn web ui 参数详解 - gentleman_hai - 博客园
![[C/C++]数据结构 链表OJ题 : 链表中倒数第k个结点](https://img-blog.csdnimg.cn/aa67e8afba5c4036891a0dc39cbd2090.png)
