上一篇讲到Yarn是什么？讲到这，我们知道其有哪些调度方式吗？

YARN之三种调度方式：

下面主要讲CapacityScheduler实现逻辑：

一、应用程序初始化

      应用程序被提交到ResourceManager之后，ResourceManager会向Capacity Scheduler发送一个SchedulerEventType.APP_ADDED事件，Capacity Scheduler收到该事件后，将为应用程序创建一个FiCaSchedulerApp对象跟踪和维护该应用程序的运行时信息，同时将应用程序提交到对应的叶子队列中，叶子队列会对应用程序进行一系列检查，包括以下几个方面：

1. 应用程序所属用户拥有该叶子队列的应用程序提交权限

2. 队列及其父队列当前处于RUNNING状态（递归检查）

3. 队列当前已提交的应用程序数目未达到管理员设定的上限

4. 应用程序所属用户提交的应用程序数目未超过管理员设定的上限

二、资源调度

       当ResourceManager收到来自NodeManager发送的心跳信息后，将向Capacity Scheduler发送一个SchedulerEventType.NODE_UPDATE事件，Capacity Scheduler收到该事件后，会依次进行以下操作：

      

1. 处理心跳信息：NodeManager发送的心跳信息中有两类信息需资源调度器处理，一类是最新启动的Container，另一类是运行完成的Container，具体如下：

         对于最新启动的Container，资源调度器需向ResourceManager发送一个RMContainerEventType.LAUNCHED，进而将该Container从超时监控队列中删除。当资源调度器为ApplicationMaster分配一个Container后，为了防止ApplicationMaster长时间不使用该Container造成资源浪费，它会将该Container加入一个超时监控队列中。如果一段时间内，该队列中的Container仍未被使用，则资源调度器会回收该Container。

         对于运行完成的Container，资源管理器将回收它使用的资源，以便接下来对这些资源进行再分配。

         

         处理完以上两类信息后，Capacity Scheduler将节点上的空闲资源分配给应用程序。

2. 资源分配：

(1). Container主要包含5类信息：

优先级(底层根本：FIFO原则、其他优先级配置)

期望资源所在节点(节点标签管理)

资源量(依据预留、个人、队列等容量设置)

Container数目是否松弛本地性（即是否在没有满足节点本地性资源时，选择机架本地性资源）延迟度

(2). 资源调度器收到资源申请后，会暂时将这些数据请求存放到一个数据结构中，以等待空闲资源出现后为其分配合适的资源。

(3). 当一个节点上有空闲资源时，它会依次选择队列、应用程序和container（请求）使用该资源：

Step1：选择队列

从根队列开始，使用深度优先遍历算法，从根队列开始，依次遍历子队列找出资源使用率最小的子队列。若子队列为叶子队列，则选择该队列，从而进行step2、step3；若子队列为非叶子队列，则以该子队列为根队列重复前面的过程直到找到一个资源使用率最小的叶子队列为止。

注意：上述“队列资源使用率”计算方法为已经使用的资源量除以最小队列资源容量（由管理员配置）。对于非叶子队列，它的已使 用资源量是各个子队列已使用资源量之和。

Step2：选择应用程序

在Step1中选好了叶子队列后，取该队列中最早提交的应用程序（实际排序时用的 Application ID，提交时间越早的应用程序，Application ID 越小）。

Step3：选择 Container

在 Step2中选好应用程序之后，对于同一个应用程序，它请求的Container可能是多样化的，涉及不同的优先级、节点、资源量和数量。当选中一个应用程序后，Capacity Scheduler将尝试优先满足优先级高的Container。对于同一类优先级，优先选择满足本地性的Container，它会依次选择node local、rack local和no local的Container。

(4). 在 Capacity Scheduler 中，在比较资源使用率时，不同的资源比较器对资源定义是不一样的。默认的是 DefaultResourceCalculator，它只考虑Memory资源。另外一种是 DominantResourceCalculator，采用了 DRF 比较算法，同时考虑Memory和 cpu 两种资源。通过参数 yarn.scheduler.capacity.resource-calculator 来设置。

(5). 其他事件处理

APP_REMOVED：在多种情况下Capacity Scheduler将收到该事件，包括应用程序正常结束、应用程序被杀死等。Capacity Scheduler收到该事件后，首先会向所有未运行完成的Container发送一个RMContainerEventType.KILL事件，以释放正在使用的Container；然后才会将应用程序相关数据结构从内存中移除。

NODE_ADDED：当集群中动态加入一个节点时（比如管理员动态扩充集群规模或者节点断开后又复活等），Capacity Scheduler将收到该事件。Capacity Scheduler收到该事件后，只需在相应数据结构中记录NodeManager信息并增加系统总资源量即可。

NODE_REMOVED：当集群中动态移除一个节点时（比如管理员动态移除节点或者节点在一定事件内未汇报心跳而被ResourceManager移除集群），Capacity Scheduler将收到该事件。Capacity Scheduler收到该事件后，除了移除NodeManager信息并减少系统总资源外，还需向所有正运行的Container发送一个RMContainerEventType.KILL事件，以清空相关信息。

CONTAINER_EXPIRED：当Capacity Scheduler将一个Container分配给ApplicationMaster后，ApplicationMaster在一定时间内必须使用该Container，否则ResourceManager将进行强制回收，此时会触发一个CONTAINER_EXPIRED事件。

CS资源分配流程：

Step1：选择队列

从根队列开始，使用深度优先遍历算法，从根队列开始，依次遍历子队列找出资源占用率最小的子队列。若子队列为叶子队列，则选择该队列；若子队列为非叶子队列，则以该子队列为根队列重复前面的过程直到找到一个资源使用率最小的叶子队列为止。

Step2：选择应用

在Step1中选好了叶子队列后，取该队列中最早提交的应用程序（实际排序时用的 Application ID，提交时间越早的应用程序，Application ID 越小）。

Step3：选择 Container

在 Step2中选好应用程序之后，选择该应用程序中优先级最高的 Container。对于优先级相同的 Containers，优选选择满足本地性的 Container，会依次选择 node local、rack local、off switch，在 Capacity Scheduler 中，在比较资源占用率时，不同的资源比较器对资源定义是不一样的。默认的是 DefaultResourceCalculator，它只考虑内存资源。另外一种是 DominantResourceCalculator，采用了 DRF 比较算法，同时考虑内存和 cpu 两种资源。通过参数 yarn.scheduler.capacity.resource-calculator 来设置。为应用申请资源的时候，如果是NODE_LOCAL，顺便也会创建这个节点对应的RACK的RACK_LOCAL的请求和OFF_SWITCH的请求。

YARN请求资源时的locality和relaxility限定:

Resource Name:资源名称(某个节点的ip、某个机架的ip或者是*代表任意)，这里叫做名称有些让人难以理解，其实是限制这个ResourceRequest对象资源运行的地点，这里有必要非常具体的讲解YARN的locality。ApplicationMaster客户端在提交应用的时候，有时候会对container运行的位置提出限制，比如，由于某些数据在服务器node1上，因此ApplicationMaster客户端希望用来处理这些数据的container就运行在这个服务器上，这个要求运行在某个特定节点的本地化叫做NODE_LOCAL，也可以，要求运行在某个固定的机架rack1上，这种机架的本地化叫做RACK_LOCAL，或者，也许没有要求(OFF_SWITCH)。因此，Resource Name可以是某个节点的ip(NODE_LOCAL)，或者某个机架的ip(RACK_LOCAL)，或者是通配符*(OFF_SWITCH)。

上面的一种是没有任何本地化限制的请求，一种是限制为本地机架的请求，一种是限制为本节点内的请求。relaxLocality:是否允许某种本地化限制松弛到更低的要求，比如，当某个ResourceRequest要求其container运行在node1，但是node1的资源剩余量始终无法满足要求，那么需要进行本地化松弛，可以放弃必须运行在服务器node1的要求，改为只要求运行在这个服务器node1所在的机架rack1上就行。返回允许的进行container调度的本地化水平，参数nodeLocalityDelayMs、rackLocalityDelayMs分别代表对NODE_LOCAL和RACK_LOCAL的进行降级前需要延迟的时间阈值。

CS分配资源过程：

CS中配置：

yarn.scheduler.capacity.maximum-am-resource-percent #设置有多少资源可以用来运行app master，即控制当前激活状态的应用：100%

yarn.scheduler.capacity.maximum-applications #设置系统中可以同时运行和等待的应用数量：10000

yarn.scheduler.capacity.root.queues #子对列：default, vc1

yarn.scheduler.capacity.root.default.capacity #它是队列的资源容量占比(百分比)。系统繁忙时，每个队列都应该得到设置的量的资源；当系统空闲时，该队列的资源则可以被其他的队列使用。同一层的所有队列加起来必须是100%。

yarn.scheduler.capacity.root.default.maximum-capacity #队列资源的使用上限。由于系统空闲时，队列可以使用其他的空闲资源，因此最多使用的资源量则是该参数控制。默认是-1，即禁用。

yarn.scheduler.capacity.root.default.user-limit-factor #可以配置为允许单个用户获取更多资源的队列容量的倍数。默认是1，这可以确保无论集群有多空闲，单个用户都不能占用超过队列配置的容量。值被指定为浮点。

每个用户最多使用的队列资源占比

yarn.scheduler.capacity.root.default.minimum-user-limit-percent #如果对资源有需求，每个队列都强制限制在任何给定时间分配给用户的资源百分比。用户限制可以在最小值和最大值之间变化。前者（最小值）设置为该属性值，后者（最大值）取决于已提交应用程序的用户数。例如，假设该属性的值为25。如果两个用户向一个队列提交了应用程序，则任何一个用户都不能使用超过50%的队列资源。如果第三个用户提交了一个应用程序，那么任何一个用户都不能使用超过33%的队列资源。对于4个或更多用户，没有任何用户可以使用超过25%的队列资源。值为100表示不施加用户限制。默认值为100。值被指定为整数。

yarn.scheduler.maximum-allocation-vcores #每个队列对Resource Manager申请的每一个容器分配虚拟计算核的最大限制。

yarn.scheduler.maximum-allocation-gpus #每个队列对Resource Manager申请的每一个容器分配gpu的最大限制。

yarn.resourcemanager.connect.retry-interval.ms #rm失联后重新链接的时间: 1000ms 。

yarn.scheduler.capacity.<queue-path>.user-settings.<user-name>.weight #此浮点值用于计算队列中用户的用户限制资源值。该值将使每个用户的权重大于或小于队列中的其他用户。例如，如果用户A在队列中收到的资源比用户B和C多50%，则用户A的此属性将设置为1.5。用户B和C将默认为1.0。

yarn.scheduler.capacity.<queue-path>.maximum-application-lifetime #提交到队列的应用程序的最长生存时间（秒）。任何小于或等于零的值都将被视为禁用。对于此队列中的所有应用程序，这将是一个困难的时间限制。如果配置了正值，则提交到此队列的任何应用程序都将在超过配置的生存期后终止。用户还可以在应用程序提交上下文中为每个应用程序指定生存期。但是，如果用户生存期超过了队列的最大生存期，那么它将被覆盖。它是时间点配置。注意：配置太低的值将导致更快地终止应用程序。此功能仅适用于叶队列。

yarn.scheduler.capacity.root.<queue-path>.default-application-lifetime #提交到队列的应用程序的默认生存期（秒）。任何小于或等于零的值都将被视为禁用。如果用户未提交生存期值为的应用程序，则将采用此值。它是时间点配置。注意：默认生存期不能超过最大生存期。此功能仅适用于叶队列。

yarn.scheduler.capacity.node-locality-delay:40 #表示调度器在放松节点限制、改为匹配同一机架上的其他节点前尝试错过的调度机会数。通常，应该将其设置为集群中的节点数。默认情况下，在一个机架中设置大约40个节点。应为正整数值。

yarn.scheduler.capacity.resource-calculator #有两种比较器用以比较两个资源的大小（比如比较用户当前使用的资源量是否超过了设置的上限资源量），默认是DefaultResourceCalculator，它只考虑Memory资源。另外一种是DominantResourceCalculator，它采用了DRF比较算法，同时考虑Memory和CPU两种资源。

yarn.scheduler.capacity.<queue-path>.state #队列的状态。可以是正在运行或已停止。如果队列处于已停止状态，则无法将新应用程序提交到其自身或其任何子队列。因此，如果根队列被停止，就不能向整个集群提交任何应用程序。现有的应用程序继续完成，因此可以适当地排出队列。值被指定为枚举。

yarn.scheduler.capacity.root.<queue-path>.acl_submit_applications:限定哪些用户/用户组可向给定队列中提交应用程序。该属性具有继承性，即如果一个用户可以向某个队列提交应用程序，则它可以向它所有子队列中提交应用程序。

yarn.scheduler.capacity.root.<queue-path>.acl_administer_queue #为队列指定一个管理员，该管理员可控制该队列的所有应用程序，比如杀死任意一个应用程序等。同样，该属性具有继承性，如果一个用户可以向某个队列中提交应用程序，则它可以向它的所有子队列中提交应用程序。

yarn.scheduler.capacity.root.<queue>.acl_administer_reservations #ACL控制谁可以管理指定的队列的保留资源。如果不指定，则对于这个属性的ACL不会从父队列继承。

yarn.scheduler.capacity.root.<queue>.acl_list_reservations #ACL控制谁可以列出指定队列的保留资源。如果不指定，则对于这个属性的ACL不会从父队列继承。

yarn.scheduler.capacity.root.<queue>.acl_submit_reservations #ACL控制谁可以提交保留资源到指定的队列。如果不指定，则对于这个属性的ACL不会从父队列继承。

yarn.scheduler.capacity.schedule-asynchronously.enable：是否开启异步调度 默认false

yarn.scheduler.capacity.schedule-asynchronously.scheduling-interval-ms：异步调度间隔  --- 5

yarn.scheduler.capacity.schedule-asynchronously.maximum-threads：开启异步调度最大线程数

yarn.scheduler.capacity.per-node-heartbeat.multiple-assignments-enabled：是否允许在一个节点管理器心跳中分配多个容器 true

yarn.scheduler.capacity.lazy-preemption-enabled：false 是否开启懒抢占 CapacitySchedulerConfiguration类

yarn.scheduler.capacity.per-node-heartbeat.maximum-container-assignments：如果启用了多个分配，则一个节点可以分配的最大容器数。默认为-1，不设置限制。

yarn.scheduler.capacity.maximum-am-resource-percent：群集中可用于运行应用程序主控形状的最大资源百分比-控制并发活动应用程序的数量。每个队列的限制与其队列容量和用户限制成正比。默认值为0.1。

yarn.scheduler.capacity.per-node-heartbeat.maximum-offswitch-assignments：如果启用了多个分配，控制节点心跳期间允许的OFF_SWITCH分配的数量

yarn.scheduler.capacity.queue-mappings-override.enable：此函数用于指定是否可以覆盖用户指定的队列。默认值为false   mapreduce.job.queuename

yarn.scheduler.capacity.rack-locality-additional-delay：在节点本地延迟时间之外的另外的错过的调度机会的次数,在此之后,CapacityScheduler尝试调度非切换容器而不是机架本地容器.例如：在node-locality-delay = 40和rack-locality-delay = 20的情况下,调度器将在40次错过机会之后尝试机架本地分配,在40 + 20 = 60之后错过机会.使用-1作为默认值,禁用此功能. 在这种情况下,根据资源请求中指定的容器和唯一位置的数量以及集群的大小,计算分配关闭交换容器的错失机会的数量

yarn.scheduler.capacity.root.<leaf-queue-path>.default-application-priority：定义叶队列中的默认应用程序优先级。默认0，最高，逻辑控制

yarn.cluster.max-application-priority：定义集群中最大应用的优先级

yarn.scheduler.capacity.root.<queue_name>.<priority>.acl=user1,user2 #队列的acl用户

具体参考：http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html

队列容量=yarn.scheduler.capacity.<queue-path>.capacity/100  --90

队列绝对容量=父队列的 队列绝对容量*队列容量   ---1 * 90%

队列最大容量=yarn.scheduler.capacity.<queue-path>.maximum-capacity/100  ---90%

队列绝对最大容量=父队列的 队列绝对最大容量*队列最大容量    ---90%

绝对资源使用比=使用的资源/全局资源

资源使用比=使用的资源/(全局资源 * 队列绝对容量)

最小分配量=yarn.scheduler.minimum-allocation-mb  ---逻辑控制

用户上限=MAX(yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent,1/队列用户数量)

用户调整因子=yarn.scheduler.capacity.<queue-path>.user-limit-factor，允许单个用户获取更多资源的队列容量的倍数

最大提交应用=yarn.scheduler.capacity.<queue-path>.maximum-applications，如果小于0 设置为(yarn.scheduler.capacity.maximum-applications*队列绝对容量)

单用户最大提交应用=最大提交应用*(用户上限/100)*用户调整因子

AM资源占比（AM可占用队列资源最大的百分比) =yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent，如果为空，设置为yarn.scheduler.capacity.maximum-am-resource-percent

最大活跃应用数量=全局总资源/最小分配量*AM资源占比*队列绝对最大容量

单用户最大活跃应用数量=(全局总资源/最小分配量*AM资源占比*队列绝对容量)*用户上限*用户调整因子

本地延迟分配次数=yarn.scheduler.capacity.node-locality-delay

枚举：

USED_CAP(0), 

ABS_USED_CAP(1), 绝对容量

MAX_CAP(2), 

ABS_MAX_CAP(3),绝对最大容量

CAP(4), 

ABS_CAP(5),

MAX_AM_PERC(6),

RESERVED_CAP(7),预留容量

ABS_RESERVED_CAP(8);绝对预留容量

CS中标签的概念：

什么是Node-label

实际的环境部署中，经常会出现不同的机器类型，比如有些机器是计算型的，有些则是内存型；另一种场景是在大集群中，有时候需要指定有些机器预留给特定的用户用，从而避免其它用户的任务对其造成影响；node label节点标签就是解决这类问题的一种好的方式。运维人员可以根据节点的特性将其分为不同的分区来满足业务多维度的使用需求。Yarn的Node-label功能将很好的试用于异构集群中，可以更好地管理和调度混合类型的应用程序。

Node-label特性

1. 只适用于Capacity Scheduler，不支持Fair Scheduler

2. 一个Node Manager节点只能属于一个label，如果一个资源节点没有配置label，则其属于一个不存在的DEFAULT分区【即没有被设置label的节点】，没有指定队列的作业将会被放置到这些节点上运行，如果所有节点被设置label，没有指定队列的将会停止在accepted节点，后续将因为得不到资源而failed

3. 用户可以为每个队列配置可以访问的分区【label】，默认是只可以访问DEFAULT分区

4. 如果队列配置为对所有label可访问，该队列上的作业可以使用所有label节点上的资源

5. 可以设置每个队列访问特定分区的资源比率

6. node label以及队列和node label的相关配置支持动态更新----即可使用yarn rmadmin –replaceLabelsOnNode 修改节点标签

Reservation概念：

为了解决Queue被一个需要很多资源的Application霸占。我们可以通过Reservation先保留一部分资源，分配给其他的高优先级的容器。这就是它的作用。但是需要注意的是，每台NodeManager只能对应一个Reservation.

yarn.resourcemanager.reservation-system.enable:必须指定的参数。默认值为false。

yarn.resourcemanager.reservation-system.class:可选参数。默认值取决于调度器，如果是容量调度器，则为CapacityReservationSystem。

yarn.resourcemanager.reservation-system.plan.follower:可选参数。基于调度器，CapacitySchedulerPlanFollower，通过动态的创建/调整/销毁队列，将计划状态发布到调度程序。

yarn.resourcemanager.reservation-system.planfollower.time-step:可选参数。默认值为1000ms。PlanFollower计时器的频率ReservationSystem可以被配置到任何队列，包括叶子队列。

yarn.scheduler.capacity.<queue-path>.reservable:必须指定的参数。表明队列的资源对于用户保留来说是可获得的。默认否false

yarn.scheduler.capacity.<queue-path>.reservation-agent:可选参数。将尝试将用户的预订请求放入计划中，默认值为org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.AlignedPlannerwithGreedy。

yarn.scheduler.capacity.<queue-path>.reservation-policy:可选参数。将用于确定sharingpolicy(共享策略)实现的类名，它将验证新保留是否不违反任何不变量。

org.apache.hadoop.yarn.server.resourcemanager.reservation.CapacityOverTimePolicy.

yarn.scheduler.capacity.<queue-path>.reservation-window:可选参数，表示如果满足计划中的约束，sharingpolicy将验证的时间（毫秒）。Long类型值，默认是一天。

yarn.scheduler.capacity.<queue-path>.instantaneous-max-capacity:可选参数，任何时候的最大容量，默认为1，即100%。

yarn.scheduler.capacity.<queue-path>.average-capacity:可选参数。将在ReservationWindow上聚合的平均允许容量，以百分比（%）表示，作为sharingPolicy允许单个用户保留的浮点值。默认100%。

yarn.scheduler.capacity.<queue-path>.reservation-planner:可选参数。计划预留器实现的类，默认：org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.SimpleCapacityReplanner。

yarn.scheduler.capacity.<queue-path>.reservation-enforcement-window:可选参数。表示计划预留者验证预留中约束是否满足的时间（毫秒）默认为1小时。

yarn.scheduler.capacity.resource-calculator:资源计算方法，默认是org.apache.hadoop.yarn.util.resource.DefaultResourseCalculator,它只会计算内存。DominantResourceCalculator则会计算内存和CPU。

CS调度流程：

Capacity调度器说的通俗点，可以理解成一个个的资源队列。这个资源队列是用户自己去分配的。比如我大体上把整个集群分成了AB两个队列，A队列给A项目组的人来使用。B队列给B项目组来使用。但是A项目组下面又有两个方向，那么还可以继续分，比如专门做A1、A2的。

在正常的操作中，Capacity调度器不会强制释放Container，当一个队列资源不够用时，这个队列只能获得其它队列释放后的Container资源。当然，我们可以为队列设置一个最大资源使用量，以免这个队列过多的占用空闲资源，导致其它队列无法使用这些空闲资源，这就是”弹性队列”需要权衡的地方。

Root

    --default 60%

       --a 40%

       --b  60%

    --vc1 40%

       --c

       --d

Queue Elasticity:虽然有了这样的资源分配，但是并不是说default提交了任务，它就只能使用60%的资源，那40%就空闲着。只要资源处于空闲状态，那么default就可以使用100%的资源。但是一旦vc1提交了任务，default就需要在释放资源后，把资源还给vc1队列，直到两者平衡在3:2的比例。

粗粒度上资源是按照上面的方式进行，在每个队列的内部，还是按照FIFO的原则来分配资源的。

Capacity Scheduler资源调度器也采用层级队列组织方式，其ROOT队列可以有多个子队列，而每个子队列又可以有自己的子队列，在队列层级最下面是叶子队列，所有Application皆提交至叶子队列。Capacity Scheduler以队列为单位划分资源，每个队列可设定一定比例的资源最低保证和使用上限。资源调度器总是优先满足最低资源保证，也就是说最低资源保证是每个队列分配资源的依据。

考虑下述极端情况：集群中部分队列提交应用较多，负载较重，设定的最低保证资源不能满足所有Application的请求，导致大部分应用处于pending状态；而与此同时，有部分队列则负责较轻，使用的资源量低于最低资源保证，导致整个集群资源利用率较低。

为了提高资源使用率，合理分配集群资源，YARN引入了资源抢占功能，即资源调度器会将负载较轻的队列的资源暂时分配给负载重的队列（即最低资源保证并不是硬资源保证，当队列不需要太多资源时，并不会满足它的最低资源保证，而是暂时将空闲资源分配给其他需要资源的队列），仅当负载较轻队列突然收到新提交的应用程序时，调度器才进一步将本属于该队列的资源还给它。由于此时资源可能正在被别的队列使用，因此调度器必须等待其他队列释放资源后，才能将这些资源“物归原主”，这通常需要等待一段不确定时间。为了防止等待时间过长，调度器发现等待一段时间后若发现资源并未得到释放，则会强制进行资源回收。

CS特性：

Capacity调度器具有以下的几个特性：

1. 层次化的队列设计，这种层次化的队列设计保证了子队列可以使用父队列设置的全部资源。这样通过层次化的管理，更容易合理分配和限制资源的使用。

2. 容量保证，队列上都会设置一个资源的占比，这样可以保证每个队列都不会占用整个集群的资源。

3. 安全，每个队列有严格的访问控制。只能向自己的队列里面提交任务，而且不能修改或者访问其他队列的任务。

4. 弹性分配，空闲的资源可以被分配给任何队列。当多个队列出现争用的时候，则会按照比例进行平衡。

5. 多租户租用，通过队列的容量限制，多个用户就可以共享同一个集群，同事保证每个队列分配到自己的容量，提高利用率。

6. 操作性，yarn支持动态修改调整容量、权限等的分配，可以在运行时直接修改。还提供给管理员界面，来显示当前的队列状况。管理员可以在运行时，添加一个队列；但是不能删除一个队列。管理员还可以在运行时暂停某个队列，这样可以保证当前的队列在执行过程中，集群不会接收其他的任务。如果一个队列被设置成了stopped，那么就不能向他或者子队列上提交任务了。

7. 基于资源的调度，协调不同资源需求的应用程序，比如内存、CPU、资源（Hdfs数据分区）。

以上是对YARN调度的整理。OVER

 

个人网站：

 

热文推荐

如有收获，点个在看，谢谢