公平调度是一种将资源分配给应用程序的方法，这样，随着时间的流逝，所有应用程序平均可获得相等的资源份额。Hadoop NextGen能够调度多种资源类型。默认情况下，公平调度程序仅基于内存来调度公平决策。可以使用Ghodsi等人开发的“主导资源公平性”概念将其配置为与内存和CPU一起调度。当有一个应用程序运行时，该应用程序将使用整个群集。提交其他应用程序时，会将释放的资源分配给新应用程序，这样每个应用程序最终都将获得大致相同数量的资源。与构成应用程序队列的默认Hadoop调度程序不同，这可让短时间的应用程序在合理的时间内完成，而不会饿死长寿命的应用程序。这也是在多个用户之间共享集群的一种合理方法。最后，公平共享也可以与应用程序优先级一起使用-优先级用作权重，以确定每个应用程序应获得的总资源的比例。
调度程序将应用程序进一步组织到“队列”中，并在这些队列之间公平地共享资源。默认情况下，所有用户共享一个名为“默认”的队列。如果应用明确在容器资源请求中列出了队列，则该请求将提交到该队列。也可以通过配置根据请求中包含的用户名分配队列。在每个队列中，使用调度策略在运行的应用程序之间共享资源。默认设置是基于内存的公平共享，但是也可以配置具有优势资源公平性的FIFO和多资源。队列可以按层次结构排列以划分资源，并可以配置权重以按特定比例共享集群。
除提供公平共享外，公平调度程序还允许将保证的最小份额分配给队列，这对于确保某些用户，组或生产应用程序始终获得足够的资源很有用。当队列包含应用程序时，它至少获得其最小份额，但是当队列不需要其完全保证的份额时，多余的份额将在其他正在运行的应用程序之间分配。这样，当这些队列不包含应用程序时，调度程序就可以保证队列的容量，同时可以有效地利用资源。
Fair Scheduler默认情况下允许所有应用程序运行，但是也可以通过配置文件限制每个用户和每个队列中正在运行的应用程序的数量。当用户必须一次提交数百个应用程序时，这很有用；或者，如果一次运行太多应用程序会导致创建过多的中间数据或进行过多的上下文切换，则通常可以提高性能。限制应用程序不会导致任何后续提交的应用程序失败，而只会在调度程序的队列中等待，直到某些用户的早期应用程序完成为止。
公平调度程序支持分层队列。所有队列均来自名为“ root”的队列。可用资源以典型的公平调度方式在根队列的子级之间分配。然后，孩子们以相同的方式将分配给他们的资源分配给他们的孩子。只能在叶队列上安排应用程序。通过将队列作为其父级的子元素放置在公平调度程序分配文件中，可以将队列指定为其他队列的子级。
队列的名称以其父代的名称开头，以句点作为分隔符。因此，根队列下名为“ queue1”的队列将被称为“ root.queue1”，而在名为“ parent1”的队列下的名为“ queue2”的队列将被称为“ root.parent1.queue2”。在引用队列时，名称的根部分是可选的，因此queue1可以仅称为“ queue1”，而queue2可以仅称为“ parent1.queue2”。
此外，公平调度程序允许为每个队列设置不同的自定义策略，以允许以用户希望的任何方式共享队列的资源。可以通过扩展org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy来构建自定义策略。FifoPolicy，FairSharePolicy（默认值）和DominantResourceFairnessPolicy是内置的，可以方便地使用。
原始的（MR1）Fair Scheduler中尚不支持某些附加组件。其中包括使用自定义策略来管理对某些应用程序的优先级“增强”。
Fair Scheduler使管理员可以配置策略，以自动将提交的应用程序放入适当的队列中。放置位置取决于提交者的用户和组以及应用程序传递的请求队列。策略由一组规则组成，这些规则被顺序应用以对传入的应用程序进行分类。每个规则要么将应用程序放入队列，拒绝它，要么继续执行下一个规则。请参阅下面的分配文件格式，以了解如何配置这些策略。
要使用公平调度程序，请首先在yarn-site.xml中分配适当的调度程序类：
<属性> <name> yarn.resourcemanager.scheduler.class </ name> <value> org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler </ value> </ property>
自定义Fair Scheduler通常涉及更改两个文件。首先，可以通过在现有配置目录中的yarn-site.xml文件中添加配置属性来设置调度程序范围的选项。其次，在大多数情况下，用户将希望创建一个分配文件，列出存在的队列及其各自的权重和容量。分配文件每10秒钟重新加载一次，可以随时进行更改。
| 属性 | 描述 |
|---|---|
| yarn.scheduler.fair.allocation.file | 分配文件的路径。分配文件是一个XML清单，除了某些默认策略默认值以外，还描述了队列及其属性。该文件必须采用下一部分中描述的XML格式。如果给出了相对路径，则在类路径（通常包括Hadoop conf目录）中搜索文件。默认为fair-scheduler.xml。 |
| yarn.scheduler.fair.user-as-default-queue | 如果未指定队列名，是否将与分配关联的用户名用作默认队列名。如果将其设置为“ false”或未设置，则所有作业都具有一个共享的默认队列，称为“ default”。默认为true。如果在分配文件中给出了队列放置策略，则将忽略此属性。 |
| 纱线调度程序公平抢占 | 是否使用抢占。默认为false。 |
| yarn.scheduler.fair.preemption.cluster-utilization-threshold | 抢占开始后的利用率阈值。利用率计算为所有资源中利用率与容量的最大比率。默认为0.8f。 |
| 基于纱线计划的公平大小的重量 | 是否根据大小将份额分配给单个应用程序，而不是为所有应用程序分配均等的份额，而不管大小如何。设置为true时，应用程序将按自然对数1加应用程序请求的总内存除以自然对数2进行加权。默认为false。 |
| yarn.scheduler.fair.assignmultiple | 是否在一个心跳中允许多个容器分配。默认为false。 |
| 纱线调度器公平动态最大分配 | 如果assignmultiple为true，则是否动态确定一个心跳中可以分配的资源量。启用后，节点上大约一半的未分配资源会在单个心跳中分配给容器。默认为true。 |
| yarn.scheduler.fair.max.assign | 如果assignmultiple为true，dynamic.max.assign为false，则表示一个心跳中可以分配的最大容器数。默认值为-1，不设置限制。 |
| yarn.scheduler.fair.locality.threshold.node | 对于在特定节点上请求容器的应用程序，自上一次容器分配以来在接受另一个节点上的放置之前要等待的调度机会数。表示为介于0到1之间的浮点数，占集群大小的一部分，是经过的调度机会的数量。默认值-1.0表示不放弃任何调度机会。 |
| yarn.scheduler.fair.locality.threshold.rack | 对于要求在特定机架上放置容器的应用程序，自上一次分配容器以来在接受另一个机架上的放置之前要等待的调度机会的数量。表示为介于0到1之间的浮点数，占集群大小的一部分，是经过的调度机会的数量。默认值-1.0表示不放弃任何调度机会。 |
| yarn.scheduler.fair.allow-未声明的池 | 如果是这样，则可以在提交应用程序时创建新队列，无论是因为提交者将它们指定为应用程序队列，还是因为它们被user-as-default-queue属性放置在该队列中。如果为false，则将应用程序放置在分配文件中未指定的队列中时，都会将其放置在“默认”队列中。默认为true。如果在分配文件中给出了队列放置策略，则将忽略此属性。 |
| yarn.scheduler.fair.update-interval-ms | 锁定调度程序并重新计算公平份额，重新计算需求并检查是否有任何要抢占的时间间隔。默认为500毫秒。 |
| yarn.resource-types.memory-mb。增量分配 | 公平调度程序以该值的增量授予内存。如果您提交的任务的资源请求不是memory-mb.increment-allocation的倍数，则请求将四舍五入到最接近的增量。默认为1024 MB。 |
| yarn.resource-types.vcores.increment-allocation | Fairscheduler以该值的增量授予vcores。如果您提交的任务的资源请求不是vcores.increment-allocation的倍数，则该请求将被四舍五入到最接近的增量。默认为1。 |
| yarn.resource-types。<resource> .increment-allocation | Fairscheduler 以该值的增量授予<resource>。如果您提交的任务的资源请求不是<resource> .increment-allocation的倍数，则该请求将四舍五入到最接近的增量。如果未为资源指定此属性，则不会应用增量舍入。如果未指定单位，则假定资源的默认单位。 |
| 纱线计划程序增量分配mb | 内存的分配增量。不再是首选。请改用yarn.resource-types.memory-mb.increment-allocation。默认为1024 MB。 |
| yarn.scheduler.increment-allocation-vcores | CPU vcore的分配增量。不再是首选。请改用yarn.resource-types.vcores.increment-allocation。默认为1。 |
分配文件必须为XML格式。该格式包含五种类型的元素：
队列元素：代表队列。队列元素可以采用可选属性'type'，将其设置为'parent'使其成为父队列。当我们要创建父队列而不配置任何叶队列时，这很有用。每个队列元素可能包含以下属性：
minResources：队列有权使用的最少资源。对于单资源公平性策略，仅使用内存，而忽略其他资源。如果不满足队列的最小份额，将在同一父项下的任何其他队列之前为它提供可用资源。根据单资源公平性策略，如果队列的内存使用率低于其最小内存份额，则认为该队列不满意。在主导资源公平的情况下，如果队列相对于集群容量而言对主导资源的使用低于该资源的最小份额，则认为该队列不满意。如果在这种情况下无法满足多个队列，则资源以相关资源使用率与其最小值之间的最小比率进入队列。
maxResources：可以分配队列的最大资源。不会为队列分配一个容器，该容器的总使用量将超过此限制。此限制是递归实施的，如果该分配会使队列或其父级超过最大资源，则不会为该队列分配容器。
maxContainerAllocation：队列可以为单个容器分配的最大资源。如果未设置该属性，则其值将从父队列继承。默认值为yarn.scheduler.maximum-allocation-mb和yarn.scheduler.maximum-allocation-vcores。不能高于maxResources。该属性对于根队列无效。
maxChildResources：可以分配临时子队列的最大资源。子队列限制是递归实施的，因此，如果该分配会使子队列或其父队列超出最大资源，则不会分配容器。
旧格式：“ X mb，Y vcores”，“ X％cpu，Y％memory”，“ X％”。如果未提供单个百分比，则必须同时配置内存和cpu，而忽略其他资源类型并将其设置为零。
新格式（推荐）：“ vcores = X，memory-mb = Y”或“ vcores = X％，memory-mb = Y％”。可以看出，以这种格式，可以给出百分比或整数的无单位资源值。在后一种情况下，将根据为该资源配置的默认单位来推断单位。当指定了内存和CPU以外的资源时，需要这种格式。如果使用minResources，则任何未指定的资源都将设置为0；如果使用maxResources，maxContainerAllocation和maxChildResources，则该资源的最大值将设置为0。
maxRunningApps：限制队列中一次运行的应用程序数量
maxAMShare：限制可用于运行应用程序主服务器的队列公平份额的比例。此属性只能用于叶队列。例如，如果设置为1.0f，则叶队列中的AM最多可以占用100％的内存和CPU公平份额。-1.0f的值将禁用此功能，并且不会检查amShare。默认值为0.5f。
weight：与其他队列不成比例地共享集群。权重默认为1，权重为2的队列所接收的资源大约是权重为默认队列的两倍。
schedulePolicy：设置任何队列的调度策略。允许的值为“ fifo” /“ fair” /“ drf”或任何扩展org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy的类。默认为“公平”。如果为“ fifo”，则优先考虑具有较早提交时间的应用程序的容器，但是如果满足较早应用程序的请求后群集上仍有剩余空间，则较晚提交的应用程序可以并发运行。
aclSubmitApps：可以将应用程序提交到队列的用户和/或组的列表。有关此列表的格式以及队列ACL如何工作的更多信息，请参考下面的ACL部分。
aclAdministerApps：可以管理队列的用户和/或组的列表。当前，唯一的管理操作是杀死应用程序。有关此列表的格式以及队列ACL如何工作的更多信息，请参考下面的ACL部分。
minSharePreemptionTimeout：队列在尝试抢占容器以从其他队列中获取资源之前，处于其最小份额之下的秒数。如果未设置，则队列将从其父队列继承值。默认值为Long.MAX_VALUE，这意味着它将在设置有意义的值之前抢占容器。
fairSharePreemptionTimeout：队列在尝试抢占容器以从其他队列中获取资源之前，处于其公平份额阈值以下的秒数。如果未设置，则队列将从其父队列继承值。默认值为Long.MAX_VALUE，这意味着它将在设置有意义的值之前抢占容器。
fairSharePreemptionThreshold：队列的公平份额抢占阈值。如果队列在等待fairSharePreemptionTimeout而不接收fairSharePreemptionThreshold * fairShare资源，则允许抢占容器以从其他队列中获取资源。如果未设置，则队列将从其父队列继承值。默认值为0.5f。
allowPreemptionFrom：确定是否允许调度程序从队列中抢占资源。默认值为true。如果队列的此属性设置为false，则此属性将递归应用于所有子队列。
预约：表示该ReservationSystem队列的资源可供用户储备。这仅适用于叶子队列。如果未配置此属性，则无法保留叶队列。
用户元素：代表用于控制单个用户行为的设置。它们可以包含一个属性：maxRunningApps，对特定用户正在运行的应用程序数量的限制。
userMaxAppsDefault元素：可以为未指定限制的所有用户设置默认的运行应用程序限制。
defaultFairSharePreemptionTimeout元素：设置根队列的公平抢占超时。被根队列中的fairSharePreemptionTimeout元素覆盖。默认设置为Long.MAX_VALUE。
defaultMinSharePreemptionTimeout元素：设置根队列的最小共享抢占超时；由根队列中的minSharePreemptionTimeout元素覆盖。默认设置为Long.MAX_VALUE。
defaultFairSharePreemptionThreshold元素：设置根队列的公平份额抢占阈值；被根队列中的fairSharePreemptionThreshold元素覆盖。默认设置为0.5f。
queueMaxAppsDefault元素：设置队列的默认运行应用程序限制；在每个队列中被maxRunningApps元素覆盖。
queueMaxResourcesDefault元素：设置队列的默认最大资源限制；在每个队列中被maxResources元素覆盖。
queueMaxAMShareDefault元素：设置队列的默认AM资源限制。在每个队列中被maxAMShare元素覆盖。
defaultQueueSchedulingPolicy元素：设置队列的默认调度策略。如果指定，则由每个队列中的schedulePolicy元素覆盖。默认为“公平”。
Reservation -agent元素：设置ReservationAgent的实现的类名，该类试图将用户的预订请求放入Plan中。默认值为org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.AlignedPlannerWithGreedy。
Reservation-policy元素：设置SharingPolicy实现的类名，该元素验证新的保留是否不违反任何不变式。默认值为org.apache.hadoop.yarn.server.resourcemanager.reservation.CapacityOverTimePolicy。
Reservation-planner元素：设置Planner的实现的类名，如果Plan容量低于（由于计划的维护或节点故障）用户保留的资源，则调用该元素。默认值为org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.SimpleCapacityReplanner，它扫描计划并按相反的接受顺序（LIFO）贪婪地删除保留，直到保留的资源在计划容量之内。
queuePlacementPolicy元素：包含一个规则元素列表，这些规则元素告诉调度程序如何将传入的应用程序放入队列中。规则以列出顺序应用。规则可能会引起争论。所有规则都接受“创建”参数，该参数指示规则是否可以创建新队列。“创建”默认为true；如果设置为false并且规则会将应用程序放置在分配文件中未配置的队列中，则我们继续执行下一条规则。最后一条规则必须是永远不能发出继续的规则。有效规则是：
指定：将应用放入请求的队列中。如果应用程序没有请求队列，即指定了“默认”，则我们继续。如果应用程序请求队列名称以句号开头或结尾，即“ .q1”或“ q1”之类的名称。将被拒绝。
user：应用程序以提交用户的名称放置在队列中。用户名中的句点将被替换为“ _dot_”，即用户“ first.last”的队列名称为“ first_dot_last”。
primaryGroup：将应用程序放入队列中，队列中包含提交该应用程序的用户的主要组的名称。组名中的句点将被替换为“ _dot_”，即组“ one.two”的队列名称为“ one_dot_two”。
secondaryGroupExistingQueue：将应用程序放入一个队列中，该队列的名称与提交该应用程序的用户的次要组相匹配。将选择与已配置队列匹配的第一个辅助组。组名中的句点将被替换为“ _dot_”，即，如果存在这样的队列，则以“ one.two”作为其次要组之一的用户将被放入“ one_dot_two”队列中。
nestedUserQueue：将应用程序放入用户队列中，并将用户名放在嵌套规则建议的队列下。这类似于“用户”规则，区别在于“ nestedUserQueue”规则，可以在任何父队列下创建用户队列，而“用户”规则仅在根队列下创建用户队列。请注意，仅当嵌套规则返回父队列时，才会应用nestedUserQueue规则。可以通过将队列的“类型”属性设置为“父”或在该队列下配置至少一个叶子作为父节点来配置父队列。有关示例用例，请参见分配示例。
default：将应用程序放入默认规则的'queue'属性中指定的队列中。如果未指定'queue'属性，则将应用程序放置在'root.default'队列中。
拒绝：该应用程序被拒绝。
分配文件示例如下：
<？xml version =“ 1.0”？>
<分配>
<queue name =“ sample_queue”>
<minResources> 10000 mb，0vcores </ minResources>
<maxResources> 90000 mb，0vcores </ maxResources>
<maxRunningApps> 50 </ maxRunningApps>
<maxAMShare> 0.1 </ maxAMShare>
<weight> 2.0 </ weight>
<schedulingPolicy>公平</ schedulingPolicy>
<queue name =“ sample_sub_queue”>
<aclSubmitApps>查理</ aclSubmitApps>
<minResources> 5000 mb，0vcores </ minResources>
</ queue>
<queue name =“ sample_reservable_queue”>
<reservation> </ reservation>
</ queue>
</ queue>
<queueMaxAMShareDefault> 0.5 </ queueMaxAMShareDefault>
<queueMaxResourcesDefault> 40000 mb，0vcores </ queueMaxResourcesDefault>
<！-队列“ secondary_group_queue”是父队列，可能有
用户在它下面排队->
<queue name =“ secondary_group_queue” type =“ parent”>
<weight> 3.0 </ weight>
<maxChildResources> 4096 mb，4vcores </ maxChildResources>
</ queue>
<user name =“ sample_user”>
<maxRunningApps> 30 </ maxRunningApps>
</ user>
<userMaxAppsDefault> 5 </ userMaxAppsDefault>
<queuePlacementPolicy>
<rule name =“ specified” />
<rule name =“ primaryGroup” create =“ false” />
<rule name =“ nestedUserQueue”>
<rule name =“ secondaryGroupExistingQueue” create =“ false” />
</ rule>
<rule name =“ default” queue =“ sample_queue” />
</ queuePlacementPolicy>
</ allocations>
请注意，为了与原始FairScheduler向后兼容，可以将“ queue”元素命名为“ pool”元素。
队列访问控制列表（ACL）允许管理员控制谁可以对特定队列执行操作。它们使用aclSubmitApps和aclAdministerApps属性进行配置，可以针对每个队列进行设置。当前，唯一受支持的管理操作是终止应用程序。管理员也可以向其提交申请。这些属性采用“ user1，user2 group1，group2”或“ group1，group2”格式的值。如果用户/组是队列ACL的成员或该队列的任何祖先的队列ACL的成员，则允许对队列执行操作。因此，如果queue2在queue1内，并且user1在queue1的ACL中，而user2在queue2的ACL中，则两个用户都可以提交到queue2。
注意：定界符是空格字符。要仅指定ACL组，请以空格字符开头的值。
默认情况下，根队列的ACL为“ *”，这是因为ACL是向下传递的，这意味着每个人都可以提交到每个队列并杀死每个队列中的应用程序。要开始限制访问，请将根队列的ACL更改为“ *”以外的其他内容。
预留访问控制列表（ACL）允许管理员控制谁可以对特定队列执行预留操作。它们使用aclAdministerReservations，aclListReservations和aclSubmitReservations属性进行配置，可以针对每个队列进行设置。当前支持的管理操作是更新和删除保留。管理员还可以提交并列出队列中的所有保留。这些属性采用“ user1，user2 group1，group2”或“ group1，group2”格式的值。如果用户/组是保留ACL的成员，则允许对队列执行操作。请注意，任何用户都可以更新，删除或列出自己的保留。如果启用了保留ACL但未定义，则每个人都可以访问。
Fair Scheduler支持保留系统，该系统允许用户提前保留资源。该应用程序可以通过指定在运行时请求的保留资源预留ID提交期间。可以在yarn-site.xml中为ReservationSystem配置以下配置参数。
| 属性 | 描述 |
|---|---|
| 纱线资源管理器保留系统启用 | 必填参数：在ResourceManager中启用ReservationSystem。预期为布尔值。默认值为false，即默认情况下未启用ReservationSystem。 |
| yarn.resourcemanager.reservation-system.class | 可选参数：ReservationSystem的类名。根据配置的Scheduler选择默认值，即，如果配置了FairScheduler，则为FairReservationSystem。 |
| 纱线资源管理器预订系统计划追随者 | 可选参数：在计时器上运行的PlanFollower的类名称，并将FairScheduler与Plan同步，反之亦然。根据配置的Scheduler选择默认值，即，如果配置了FairScheduler，则为FairSchedulerPlanFollower。 |
| 纱线资源管理器预订系统计划员时间步长 | 可选参数：PlanFollower计时器的频率（以毫秒为单位）。预期长值。默认值为1000。 |
所述ReservationSystem集成了公平调度队列层级，并且可以配置为只为叶队列。详细说明在“ 分配文件格式”部分中。
公平调度程序通过以下几种机制在运行时为管理提供支持：
可以通过ResourceManager的Web界面（http：// * ResourceManager URL * / cluster / scheduler）检查当前的应用程序，队列和公平份额。
在Web界面上可以看到每个队列的以下字段：
已用资源-分配给队列内容器的资源总和。
活动应用程序数-队列中至少接收到一个容器的应用程序数。
待处理的应用程序数-队列中尚未收到任何容器的应用程序数。
最小资源-配置为队列保证的最小资源。
最大资源-允许队列配置的最大资源。
瞬时公平份额-队列的瞬时公平资源份额。这些共享仅考虑活动队列（那些正在运行应用程序的队列），并用于调度决策。当其他队列不使用队列时，可能会为其分配超出其共享范围的资源。资源消耗等于或低于其瞬时公平份额的队列将永远不会抢占其容器。
稳定的公平份额-队列中的资源的稳定公平份额。这些共享将考虑所有队列，无论它们是否处于活动状态（已运行应用程序）。它们的计算频率较低，并且仅在配置或容量更改时更改。它们旨在提供对用户期望资源的可见性，并因此显示在Web UI中。