【Yarn】The Capacity Scheduler

功能

CapacityScheduler支持以下功能。

• 分层队列 - 支持队列的分层，以确保在允许其他队列使用空闲资源之前，在一个组织的子队列中共享资源，从而提供更多的控制和可预测性。

• 容量保证–队列被分配了一部分网格的容量，即一定容量的资源将由他们支配。所有提交给队列的应用都可以使用分配给队列的容量。管理员可以对分配给每个队列的容量配置软限制和可选的硬限制。

• 安全性 - 每个队列都有严格的ACL，控制哪些用户可以向单个队列提交应用程序。此外，还有安全保护措施，确保用户不能查看和/或修改其他用户的应用程序。此外，还支持每个队列和系统管理员角色。

• 弹性 - 自由资源可以分配给任何队列，超过其容量。当在未来某个时间点，运行在容量以下的队列对这些资源有需求时，随着这些资源上安排的任务完成，它们将被分配给运行在容量以下的队列上的应用（也支持抢占）。这确保了资源以可预测和弹性的方式提供给队列，从而防止集群中的人为资源孤岛，这有助于提高利用率。

• 多租户 - 提供一套全面的限制，以防止单个应用程序、用户和队列垄断队列或整个集群的资源，确保集群不被淹没。

• 可操作性

1. 运行时配置 - 队列定义和属性，如容量、ACLs，可以在运行时由管理员以安全的方式改变，以尽量减少对用户的干扰。此外，还为用户和管理员提供了一个控制台，以查看当前分配给系统中各种队列的资源。管理员可以在运行时添加额外的队列，但在运行时不能删除队列，除非该队列是停止的，并且没有待定/运行的应用程序。

2. 排除应用程序 - 管理员可以在运行时停止队列，以确保在现有应用程序运行到完成时，不能提交新的应用程序。如果一个队列处于 STOPPED 状态，新的应用程序不能提交给它自己或它的任何子队列。现有的应用程序继续完成，因此队列可以被优雅地耗尽。管理员也可以启动停止的队列。

• 基于资源的调度 - 支持资源密集型的应用程序，其中一个应用程序可以选择指定比默认值更高的资源要求，从而适应具有不同资源要求的应用程序。目前，内存是支持的资源要求。

• 基于默认或用户定义的放置规则的队列映射界面–该功能允许用户根据一些默认的放置规则将作业映射到一个特定的队列。例如，基于用户和组，或应用程序名称。用户也可以定义他们自己的安置规则。

• 优先级调度 - 该功能允许以不同的优先级提交和调度应用程序。更高的整数值表示一个应用程序的更高优先级。目前，应用程序的优先级只支持先进先出的排序策略。

• 绝对资源配置 - 管理员可以为队列指定绝对资源，而不是提供基于百分比的值。这为管理员提供了更好的控制，为一个给定的队列配置所需的资源量。

• 动态自动创建和管理叶子队列 - 该功能支持自动创建叶子队列，结合队列映射，目前支持基于用户组的队列映射，将应用程序放置到队列中。调度器还支持根据在父队列上配置的策略对这些队列进行容量管理。

容量和分层设计

• 最小容量是指如果集群上所有东西都运行到最大，队列应该期望拥有的可用资源量。
• 最大容量是一种类似于弹性的容量，允许队列利用没有被用来填补其他队列的最小容量需求的资源。
  

如上图中的子队列继承其父队列的资源。例如，在Preference队列中，Low叶子队列得到Preference 最小容量20%的20%，而High 队列得到20%最小容量的80%。 最小容量对于一个父系下的所有叶子来说，加起来总是要达到100%

最低用户百分比和用户限制系数

最小用户百分比和用户限制系数是控制如何将资源分配给正在使用队列的用户的方法。最小用户百分比是一个软限制，即单个用户在请求资源时应该获得的最小的资源量。例如，最小用户百分比为10%，意味着假设10个用户都要求获得10%的资源，这个值是软限制，如果其中一个用户要求的资源较少，我们可以将更多的用户放在队列中。

用户限制系数是一种控制单个用户可消耗的最大资源量的方法。用户限制系数被设置为队列最小容量的倍数，用户限制系数为1意味着用户可以消耗整个队列的最小容量。如果用户限制系数大于1，用户就有可能增长到最大容量，如果该值被设置为小于1，如0.5，用户将只能获得队列最小容量的一半。如果你想让用户也能增长到队列的最大容量，设置大于1的值将允许最小容量被用户超过那么多倍。

一个最初可能不直观的常见设计点是按工作负载而不是按应用程序创建队列，然后使用用户限制因素，通过使用小于1.0的值来防止单个用户对队列的单独接管。这种模式支持更简单的操作，不允许通过在每个LoB上创建一个队列而使队列的创建失控，而是通过按工作负载创建队列来创造可预测的队列行为。一旦集群被充分使用，并有应用程序排队等待运行，较低的用户限制因素将是控制租户之间资源共享的关键。

最初，由于使用较小的用户限制来限制用户资源，这可能无法提供他们在Hadoop平台旅程开始时的集群利用率，有许多方法，但要考虑的是，最初允许一个租户接管一个很小的集群（例如10个节点）可能是合理的，但当扩大平台足迹时，降低用户限制因素，使每个租户保持与你添加新节点之前相同数量的可分配资源。这可以让用户保持他最初的体验，但随着集群的增长，他将被禁止接管整个集群，从而为新用户轻松获得分配的容量提供空间，同时不会降低原有用户的体验。

容器流失

队列中的流失最好描述为不断存在和启动新的容器。这种行为对于拥有一个表现良好的集群是非常重要的，因为队列可以快速地重新平衡到它们的最小容量，并在其用户之间公平地平衡队列的容量。反对流失的模式是长期存在的容器，它自己分配，从不释放，因为它可以阻止资源的适当再平衡，在某些情况下，它可以完全阻止其他应用程序的启动或队列的容量恢复。在不使用抢占的情况下，如果一个队列增长到弹性空间，但从未释放其容器，那么弹性空间将永远不会回馈给被保证的队列。如果在你的队列中运行的应用程序有长期的容器，请特别注意，并考虑如何通过用户限制因素、抢占、甚至没有弹性容量的专用队列等功能来减轻其对其他用户的影响。

容量调度器的特点和行为

CPU调度（主导资源的公平性）

CPU调度在默认情况下是不启用的，它允许超额占用核心，不考虑强制使用或优先分配。如果使用CPU调度，许多批处理驱动的工作负载可能会经历吞吐量的减少，但对于严格的SLA保证可能是必需的。一种叫做主导资源公平性（DRF）的方法被用来决定将利用率加权为哪种资源类型。 DRF采取使用最多的资源，并把你当作使用最高的百分比进行调度。

CPU调度有两个主要部分

• 分配和安置
• 强制执行

分配和安置的问题只需通过启用CPU调度来解决，这样主导资源公平算法和VCores节点管理器的报告就开始被调度器使用。这解决了一些新的问题，比如一个最终用户曾经用1或2个执行器但每个8个内核来调度他的Spark应用程序，然后由于可用内存过多，所有在这些节点上运行的其他任务都受到了影响。通过启用简单的CPU调度，其他任务将不再被分配到所有核心都被利用的服务器上，并在集群中找到其他任务放置的首选位置。

通过利用CG组来解决执行问题。 这使得YARN能够确保，如果一个任务要求一个单核，他们不能利用超过所要求的数量。在不使用vcores的情况下，可以启用共享vcores的功能，也可以严格执行只使用预定的内容。 节点管理器也可以配置服务器上CPU的最大使用量，他们将允许所有的任务加起来，这允许核心被保证用于操作系统功能。

上图给出了一个概念，如果限制在最小的资源（通常是CPU核心），那么可以改变多少并发的容器。 不太可能真正的1:1核心与容器的比例是需要的，但这方面的调整最好留给监测历史系统指标，然后增加或减少NodeManager VCores的数量，以允许在一个给定的服务器组上更多或更少的容器。

抢占

当应用程序在他们的队列中使用弹性容量时，另一个应用程序来要求取回他们的最小容量（这些容量正在另一个队列中作为弹性容量使用），传统上，应用程序将不得不等待任务完成以获得其资源分配。启用 "抢占 "后，其他队列中的资源可以被回收，以提供最小容量给需要它的队列。抢占将尽量不直接杀死一个应用程序，并将把还原器放在最后，因为它们必须重复更多的工作，而映射器则必须重新运行。从排序的角度来看，抢占会首先关注最年轻的应用程序和最超额的任务回收。

抢占有一些非常具体的行为，其中一些行为并不像用户所期望的那样。最常见的预期行为是，队列在自己内部抢占，以平衡所有用户的资源。这个假设是错误的，因为现在**抢占只在队列之间起作用，用户之间的队列内资源不平衡**，需要研究其他方法来控制，如用户限制因素、改进的队列搅动和队列先进先出/公平竞争政策。

另一个行为是，如果不能提供足够的资源来满足另一个资源分配请求，抢占将不会抢占资源。虽然这在大型集群中通常不是问题，但对于具有较大容器尺寸的小型集群来说，可能会遇到这样的情况，即抢占没有被配置为回收尽可能大的容器，因此根本不会做什么。 用来控制这种行为的主要属性是每轮总抢占和自然终止因子。每轮总抢占是指集群上一次可以被抢占的资源的百分比，自然终止因子是指在总集群（100%）中被要求抢占的资源的百分比，直到每轮总抢占。

最后一个误解是，抢占将重新平衡最大（弹性）容量的使用，用于希望增长到它的队列之间。最大容量是以先来后到为基础的。如果一个队列占用了所有的集群容量，而另一个应用程序开始在一个队列中需要它的最小容量，只有最小容量将被抢占，所有被其他队列使用的最大容量将保持，直到容器自然流失。

队列排序策略

目前Capacity Scheduler支持两种类型的排序策略。FIFO和FAIR。队列开始时的默认值是先进先出，根据我的经验，这不是客户期望从他们的队列中得到的行为。通过在队列叶子级别配置先进先出和公平处理，你可以创建行为，导致吞吐量驱动的处理或运行的应用程序之间共享公平处理。要知道关于排序策略的一件重要事情是，它们在队列中的应用层面上运行，并不关心哪个用户拥有这些应用。

在先进先出的政策下，应用程序按照从大到小的顺序进行资源分配评估。如果一个应用程序有未完成的资源请求，它们会立即得到满足，先到先得。这样做的结果是，如果一个应用程序有足够多的未完成的请求，以至于他们在完成之前会多次消耗整个队列，他们将阻止其他应用程序的启动，而他们作为最老的应用程序首先被分配资源。正是这种行为对用户来说是最出乎意料的，也是最令人不满的，因为用户甚至可以用他们自己的应用程序来阻止他们自己的应用程序。

现在，这种行为很容易通过使用FAIR排序策略得到解决。当在叶子队列上使用FAIR排序策略时，应用程序被评估为资源分配请求，首先是使用最少资源的应用程序，最后是最多的。这样一来，进入队列的新应用如果没有资源可供处理，将首先被要求提供他们所需的分配，以便开始处理。一旦队列中的所有应用都有资源，它们就会在所有要求资源的用户之间得到公平的平衡。

值得注意的是，这种行为只有在你的队列中有良好的容器流动时才会发生。因为队列中不存在优先权，资源不能在队列中被强行重新分配，而且FAIR排序策略只关注资源的新分配，而不是当前的分配；这意味着什么？如果队列目前被使用的任务从未完成或运行了很长时间，而不允许队列中的容器发生变化，那么队列将持有资源，仍然阻止应用程序的执行。

用户名和应用程序驱动的计算

当试图提供分配时，容量调度器中的计算要看两个主要属性。用户名和应用程序ID。当涉及到在队列中的用户之间共享资源时，像最小用户百分比和用户限制因素都是看用户名本身；如果你为多个用户使用一个服务账户来运行作业，这显然会导致一些冲突的问题，因为只有一个用户会出现在容量调度器中。在一个队列中，哪个应用程序获得资源分配是由叶队列的排序策略驱动的。FIFO或FAIR只关心应用程序，而不关心哪个用户正在运行它。 在FIFO中，资源首先被分配给队列中最老的应用程序，只有当它不再需要任何资源时，下一个应用程序才会得到分配。在FAIR中，首先询问使用资源最少的应用程序是否有待分配的资源，如果有，则满足，如果没有，则检查下一个资源最少的应用程序；这有助于与通常会消耗资源的应用程序均匀地分享队列。

优先权

当资源被分配到多个队列时，相对容量最小的队列首先获得资源。如果你想拥有一个高优先级的队列，在其他队列之前获得资源，那么改变为高优先级是一个简单的方法。今天，使用LLAP和Tez的队列优先级可以实现更多的交互式工作负载，因为这些队列可以以更高的优先级分配资源，以减少终端用户可能遇到的终端延迟。

队列名称

队列的叶子名称在容量调度器中必须是唯一的。例如，如果你在容量调度器中创建了一个队列为root.adhoc.dev，作为所有队列名称的叶子必须是唯一的，你不能有一个root.workflow.dev队列，因为它不再是唯一的。这与只使用叶子名称而不是整个复合队列名称来指定提交队列的方式是一致的。叶子的父辈从不直接提交，不需要是唯一的，所以你可以有 root.adhoc.dev 和 root.adhoc.qa，没有问题，因为 dev 和 qa 都是唯一的叶子名称。

容器的大小

很多使用容量调度器的人不知道的是，容器的大小是最小分配的倍数。例如，如果你的每个容器的最小调度器mb内存是1gb，而你要求一个4.5gb大小的容器，调度器会把这个请求四舍五入为5gb。对于非常高的最小值，这可能会造成巨大的资源浪费问题，例如，如果我们要求5GB的最小值，我们将得到8GB的服务，提供我们甚至从未计划使用的3GB的额外资源 当配置最小和最大的容器大小时，最大的容器应该被最小的容器平均分割。