YARN调度

最新推荐文章于 2024-01-23 13:20:10 发布

weixin_34387468

最新推荐文章于 2024-01-23 13:20:10 发布

阅读量225

点赞数

文章标签：操作系统 python 运维

原文链接：https://my.oschina.net/hblt147/blog/2878332

版权

2019独角兽企业重金招聘Python工程师标准>>>

理想情况下，应用对YARN发起的资源请求应该立刻得到满足，但现实情况资源往往是有限的，特别是在一个很繁忙的集群，一个应用对资源的请求经常需要等待一段时间才能获取到相应的资源。在YARN中，Scheduler的职责就是根据定义的策略给应用分配资源。其实调度本身就是一个难题，很难找到一个完美的策略可以解决所有的应用场景。为此，YARN提供了多种调度器和可配置的策略供我们选择。

一、调度器的选择

在YARN中有三种调度器可以选择：FIFO Scheduler，Capacity Scheduler，Fair Scheduler。
FIFO Scheduler把应用按提交的顺序排成一个队列，是一个先进先出队列，在进行资源分配的时候，先给队列中最头部的应用进行分配资源，待最头部的应用需求满足后再给下一个分配，以此类推。FIFO Scheduler是最简单也是最容易理解的调度器，它不需要任何配置，但不适用于共享集群中。大的应用可能会占用所有集群资源，从而导致其它应用被阻塞。在共享集群中，更适合采用Capacity Scheduler或Fair Scheduler，这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。

下面“YARN调度器对比图”展示了这几个调度器的区别，从图中可以看出，在FIFO调度器中，小任务会被大任务阻塞。而对于Capacity调度器，设置了一个专门的队列用来运行小任务，但是为小任务专门设置一个队列会预先占用一定的集群资源，这就导致大任务的执行时间会落后于使用FIFO调度器时的时间。在Fair调度器中，不需要预先保留一定的系统资源，Fair调度器会为所有运行的job动态的调整系统资源。如下图所示，当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。
需要注意的是，在下图Fair调度器中，从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的Container。小任务执行完成之后也会释放自己占用的资源，大任务又获得了全部的系统资源。最终的效果就是Fair调度器即得到了高的资源利用率又能保证小任务及时完成。

Yarn调度器对比图:

二、Capacity Scheduler（容量调度器）的配置

2.1 容量调度器介绍

Capacity 调度器允许多个组织共享整个集群，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外，队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了，在一个队列内部，资源的调度是采用的是先进先出(FIFO)策略。

通过上面的图我们可以看到，单独一个job使用的资源不会超出队列的容量。然而如果这个队列中运行多个job，如果还有空闲资源，则会把空闲资源分配给队列中的job使用，尽管这样会使得队列的容量超出限制(当yarn.scheduler.capacity.<queue-path>.user-limit-factor的值大于1时，单个job也允许使用超出队列容量的资源)。这就是队列弹性(queue elasticity)的概念。

在正常的操作中，Capacity调度器不会通过强制kill Container来抢占资源，当一个队列资源不够用时，这个队列只能等到其它队列完成释放资源后再使用该Container。当然，我们可以为队列设置一个最大资源使用量(maximum capacity)，以免这个队列过多的占用其它队列空闲资源。这会在一定程度上降低队列弹性，所以一个合理的折衷应该通过不断尝试找到。

2.2 容量调度器的配置

假设我们有如下层次的队列：

root
├── prod
└── dev
├── eng
└── science

下面是一个简单的Capacity调度器的配置文件，文件名为capacity-scheduler.xml。在这个配置中，在root队列下面定义了两个子队列prod和dev，分别占40%和60%的容量。需要注意，一个队列的配置是通过属性yarn.sheduler.capacity.<queue-path>.<sub-property>指定的，<queue-path>代表的是队列的继承树，如root.prod队列，<sub-property>一般指capacity和maximum-capacity。

我们可以看到，dev队列又被分成了eng和science两个相同容量的子队列。dev的maximum-capacity属性被设置成了75%，所以即使prod队列完全空闲dev也不会占用全部集群资源，也就是说，prod队列仍有25%的可用资源用来应急。我们注意到，eng和science两个队列没有设置maximum-capacity属性，也就是说eng或science队列中的job可能会用到整个dev队列的所有资源（最多为集群的75%）。而类似的，prod由于没有设置maximum-capacity属性，它有可能会占用集群全部资源。

Capacity容器除了可以配置队列及其容量外，我们还可以配置一个用户或应用可以分配的最大资源数量、可以同时运行多少应用、队列的ACL认证等。

2.3 队列的设置

关于队列的设置，这取决于我们具体的应用。比如，在MapReduce中，我们可以通过mapreduce.job.queuename属性指定要用的队列。如果队列不存在，我们在提交任务时就会收到错误。如果我们没有定义任何队列，所有的应用将会放在一个default队列中。

注意：对于Capacity调度器，我们的队列名必须是队列树中的最后一部分，如果我们使用队列树则不会被识别。比如，在上面配置中，我们使用prod和eng作为队列名是可以的，但是如果我们用root.dev.eng或者dev.eng是无效的。

三、Fair Scheduler（公平调度器）的配置

3.1 公平调度

Fair调度器的设计目标是为所有的应用分配公平的资源（对公平的定义可以通过参数来设置）。在上面的“Yarn调度器对比图”展示了一个队列中两个应用的公平调度；当然，公平调度在也可以在多个队列间工作。举个例子，假设有两个用户A和B，他们分别拥有一个队列。当A启动一个job而B没有任务时，A会获得全部集群资源；当B启动一个job后，A的job会继续运行，不过一会儿之后两个任务会各自获得一半的集群资源。如果此时B再启动第二个job并且其它job还在运行，则它将会和B的第一个job共享B这个队列的资源，也就是B的两个job会用于四分之一的集群资源，而A的job仍然用于集群一半的资源，结果就是资源最终在两个用户之间平等的共享。过程如下图所示：
这里写图片描述

3.2 启用Fair Scheduler

调度器的使用是通过yarn-site.xml配置文件中的yarn.resourcemanager.scheduler.class参数进行配置的，默认采用Capacity Scheduler调度器。如果我们要使用Fair调度器，需要在这个参数上配置FairScheduler类的全限定名： org.apache.Hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler。

3.3 队列的配置

Fair调度器的配置文件位于类路径下的fair-scheduler.xml文件中，这个路径可以通过yarn.scheduler.fair.allocation.file属性进行修改。若没有这个配置文件，Fair调度器采用的分配策略，这个策略和3.1节介绍的类似：调度器会在用户提交第一个应用时为其自动创建一个队列，队列的名字就是用户名，所有的应用都会被分配到相应的用户队列中。

我们可以在配置文件中配置每一个队列，并且可以像Capacity 调度器一样分层次配置队列。比如，参考capacity-scheduler.xml来配置fair-scheduler：
这里写图片描述

队列的层次是通过嵌套<queue>元素实现的。所有的队列都是root队列的孩子，即使我们没有配到<root>元素里。在这个配置中，我们把dev队列有分成了eng和science两个队列。

Fair调度器中的队列有一个权重属性（这个权重就是对公平的定义），并把这个属性作为公平调度的依据。在这个例子中，当调度器分配集群40:60资源给prod和dev时便视作公平，eng和science队列没有定义权重，则会被平均分配。这里的权重并不是百分比，我们把上面的40和60分别替换成2和3，效果也是一样的。注意，对于在没有配置文件时按用户自动创建的队列，它们仍有权重并且权重值为1。

每个队列内部仍可以有不同的调度策略。队列的默认调度策略可以通过顶级元素<defaultQueueSchedulingPolicy>进行配置，如果没有配置，默认采用公平调度。

尽管是Fair调度器，其仍支持在队列级别进行FIFO调度。每个队列的调度策略可以被其内部的<schedulingPolicy> 元素覆盖，在上面这个例子中，prod队列就被指定采用FIFO进行调度，所以，对于提交到prod队列的任务就可以按照FIFO规则顺序的执行了。需要注意，prod和dev之间的调度仍然是公平调度，同样eng和science也是公平调度。

尽管上面的配置中没有展示，每个队列仍可配置最大、最小资源占用数和最大可运行的应用的数量。

3.4 队列的设置

Fair调度器采用了一套基于规则的系统来确定应用应该放到哪个队列。在上面的例子中，<queuePlacementPolicy> 元素定义了一个规则列表，其中的每个规则会被逐个尝试直到匹配成功。例如，上例第一个规则specified，则会把应用放到它指定的队列中，若这个应用没有指定队列名或队列名不存在，则说明不匹配这个规则，然后尝试下一个规则。primaryGroup规则会尝试把应用放在以用户所在的Unix组名命名的队列中，如果没有这个队列，不创建队列转而尝试下一个规则。当前面所有规则不满足时，则触发default规则，把应用放在dev.eng队列中。

当然，我们可以不配置queuePlacementPolicy规则，调度器则默认采用如下规则：

<queuePlacementPolicy>
<rule name="specified" />
<rule name="user" />
</queuePlacementPolicy>

上面规则可以归结成一句话，除非显式指定了特定的队列，否则会把用户名做为队列名，如果部存在则创建队列。

还有一个简单的配置策略可以使得所有的应用放入同一个队列（default），这样就可以让所有应用之间平等共享集群而不是在用户之间。这个配置的定义如下：

<queuePlacementPolicy>
<rule name="default" />
</queuePlacementPolicy>

实现上面功能我们还可以不使用配置文件，直接设置yarn.scheduler.fair.user-as-default-queue=false，这样应用便会被放入default 队列，而不是各个用户名队列。另外，我们还可以设置yarn.scheduler.fair.allow-undeclared-pools=false，这样用户就无法创建队列了。

3.5 抢占（Preemption）

当一个job提交到一个繁忙集群中的空队列时，job并不会马上执行，而是阻塞直到正在运行的job释放系统资源。为了使提交job的执行时间更具预测性（可以设置等待的超时时间），Fair调度器支持抢占。

抢占就是允许调度器杀掉占用超过其应占份额资源队列的containers，这些containers资源便可被分配到应该享有这些份额资源的队列中。需要注意抢占会降低集群的执行效率，因为被终止的containers需要被重新执行。

可以通过设置一个全局的参数yarn.scheduler.fair.preemption=true来启用抢占功能。此外，还有两个参数用来控制抢占的过期时间（这两个参数默认没有配置，需要至少配置一个来允许抢占Container）：

- minimum share preemption timeout
- fair share preemption timeout

如果队列在minimum share preemption timeout指定的时间内未获得最小的资源保障，调度器就会抢占containers。我们可以通过配置文件中的顶级元素<defaultMinSharePreemptionTimeout>为所有队列配置这个超时时间；我们还可以在<queue>元素内配置<minSharePreemptionTimeout>元素来为某个队列指定超时时间。

与之类似，如果队列在fair share preemption timeout指定时间内未获得平等的资源的一半（这个比例可以配置），调度器则会进行抢占containers。这个超时时间可以通过顶级元素<defaultFairSharePreemptionTimeout>和元素级元素<fairSharePreemptionTimeout>分别配置所有队列和某个队列的超时时间。上面提到的比例可以通过<defaultFairSharePreemptionThreshold>(配置所有队列)和<fairSharePreemptionThreshold>(配置某个队列)进行配置，默认是0.5。

四、实际配置举例

4.1 Fair Scheduler根据用户名分配资源池

如图所示，假设整个Yarn集群的可用资源为100vCPU，100GB内存，现在为3个业务各自规划一个资源池，另外，规划一个default资源池，用于运行其他用户和业务提交的任务。如果没有在任务中指定资源池（通过参数mapreduce.job.queuename），那么可以配置使用用户名作为资源池名称来提交任务，即用户businessA提交的任务被分配到资源池businessA中，用户businessC提交的任务被分配到资源池businessC中。除了配置的固定用户，其他用户提交的任务将会被分配到资源池default中。
这里的用户名，就是提交Application所使用的Linux/Unix用户名。
另外，每个资源池可以配置允许提交任务的用户名，比如，在资源池businessA中配置了允许用户businessA和用户lxw1234提交任务，如果使用用户lxw1234提交任务，并且在任务中指定了资源池为businessA，那么也可以正常提交到资源池businessA中。

根据权重获得额外的空闲资源

在每个资源池的配置项中，有个weight属性（默认为1），标记了资源池的权重，当资源池中有任务等待，并且集群中有空闲资源时候，每个资源池可以根据权重获得不同比例的集群空闲资源。
比如，资源池businessA和businessB的权重分别为2和1，这两个资源池中的资源都已经跑满了，并且还有任务在排队，此时集群中有30个Container的空闲资源，那么，businessA将会额外获得20个Container的资源，businessB会额外获得10个Container的资源。

最小资源保证

在每个资源池中，允许配置该资源池的最小资源，这是为了防止把空闲资源共享出去还未回收的时候，该资源池有任务需要运行时候的资源保证。
比如，资源池businessA中配置了最小资源为（5vCPU，5GB），那么即使没有任务运行，Yarn也会为资源池businessA预留出最小资源，一旦有任务需要运行，而集群中已经没有其他空闲资源的时候，这个最小资源也可以保证资源池businessA中的任务可以先运行起来，随后再从集群中获取资源。

动态更新资源配额

Fair Scheduler除了需要在yarn-site.xml文件中启用和配置之外，还需要一个XML文件来配置资源池以及配额，而该XML中每个资源池的配额可以动态更新，之后使用命令：yarn rmadmin –refreshQueues 来使得其生效即可，不用重启Yarn集群。
需要注意的是：动态更新只支持修改资源池配额，如果是新增或减少资源池，则需要重启Yarn集群。

Fair Scheduler配置示例
以上面图中所示的业务场景为例。

yarn-site.xml中的配置：

<property>
<name>yarn.resourcemanager.scheduler.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>
<property>
<name>yarn.scheduler.fair.allocation.file</name>
<value>/etc/hadoop/conf/fair-scheduler.xml</value>
</property>
<property>
<name>yarn.scheduler.fair.preemption</name>
<value>true</value>
</property>
<property>
<name>yarn.scheduler.fair.user-as-default-queue</name>
<value>true</value>
<description>default is True</description>
</property>
<property>
<name>yarn.scheduler.fair.allow-undeclared-pools</name>
<value>false</value>
<description>default is True</description>
</property>

yarn.resourcemanager.scheduler.class
配置Yarn使用的调度器插件类名；
Fair Scheduler对应的是：org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler
yarn.scheduler.fair.allocation.file
配置资源池以及其属性配额的XML文件路径（本地路径）；
yarn.scheduler.fair.preemption
开启资源抢占。
yarn.scheduler.fair.user-as-default-queue
设置成true，当任务中未指定资源池的时候，将以用户名作为资源池名。这个配置就实现了根据用户名自动分配资源池。
yarn.scheduler.fair.allow-undeclared-pools
是否允许创建未定义的资源池。

如果设置成true，yarn将会自动创建任务中指定的未定义过的资源池。设置成false之后，任务中指定的未定义的资源池将无效，该任务会被分配到default资源池中。

fair-scheduler.xml中的配置:

<?xml version=”1.0″?>
<allocations>
<!– users max running apps –>
<userMaxAppsDefault>30</userMaxAppsDefault>
<!– queues –>
<queue name=”root”>
<minResources>51200mb,50vcores</minResources>
<maxResources>102400mb,100vcores</maxResources>
<maxRunningApps>100</maxRunningApps>
<weight>1.0</weight>
<schedulingMode>fair</schedulingMode>
<aclSubmitApps> </aclSubmitApps>
<aclAdministerApps> </aclAdministerApps>
<queue name=”default”>
<minResources>10240mb,10vcores</minResources>
<maxResources>30720mb,30vcores</maxResources>
<maxRunningApps>100</maxRunningApps>
<schedulingMode>fair</schedulingMode>
<weight>1.0</weight>
<aclSubmitApps>*</aclSubmitApps>
</queue>
<queue name=”businessA”>
<minResources>5120mb,5vcores</minResources>
<maxResources>20480mb,20vcores</maxResources>
<maxRunningApps>100</maxRunningApps>
<schedulingMode>fair</schedulingMode>
<weight>2.0</weight>
<aclSubmitApps>businessA,lxw1234 group_businessA,group_lxw1234</aclSubmitApps>
<aclAdministerApps>businessA,hadoop group_businessA,supergroup</aclAdministerApps>
</queue>
<queue name=”businessB”>
<minResources>5120mb,5vcores</minResources>
<maxResources>20480mb,20vcores</maxResources>
<maxRunningApps>100</maxRunningApps>
<schedulingMode>fair</schedulingMode>
<weight>1</weight>
<aclSubmitApps>businessB group_businessA</aclSubmitApps>
<aclAdministerApps>businessA,hadoop group_businessA,supergroup</aclAdministerApps>
</queue>
<queue name=”businessC”>
<minResources>5120mb,5vcores</minResources>
<maxResources>20480mb,20vcores</maxResources>
<maxRunningApps>100</maxRunningApps>
<schedulingMode>fair</schedulingMode>
<weight>1.5</weight>
<aclSubmitApps>businessC group_businessC</aclSubmitApps>
<aclAdministerApps>businessC,hadoop group_businessC,supergroup</aclAdministerApps>
</queue>
</queue>
</allocations>

minResources：最小资源
maxResources：最大资源
maxRunningApps：最大同时运行application数量
weight：资源池权重
aclSubmitApps：允许提交任务的用户名和组；
格式为：用户名用户组
当有多个用户时候，格式为：用户名1,用户名2 用户名1所属组,用户名2所属组
aclAdministerApps：允许管理任务的用户名和组，格式同上。
Fair Scheduer各资源池配置及使用情况，在ResourceManager的WEB监控页面上也可以看到。

4.2 Fair Scheduler根据用户组管理分配资源池的配置

假设在生产环境Yarn中，总共有四类用户需要使用集群，开发用户、测试用户、业务1用户、业务2用户。为了使其提交的任务不受影响，我们在Yarn上规划配置了五个资源池，分别为 dev_group（开发用户组资源池）、test_group（测试用户组资源池）、business1_group（业务1用户组资源池）、business2_group（业务2用户组资源池）、default（只分配了极少资源）。并根据实际业务情况，为每个资源池分配了相应的资源及优先级等。
ResourceManager上fair-scheduler.xml配置如下：

<?xml version="1.0"?>
<allocations>

<userMaxAppsDefault>30</userMaxAppsDefault>
<queue name="root">
<aclSubmitApps> </aclSubmitApps>
<aclAdministerApps> </aclAdministerApps>
<queue name="default">
<minResources>2000mb,1vcores</minResources>
<maxResources>10000mb,1vcores</maxResources>
<maxRunningApps>1</maxRunningApps>
<schedulingMode>fair</schedulingMode>
<weight>0.5</weight>
<aclSubmitApps>*</aclSubmitApps>
</queue>
<queue name="dev_group">
<minResources>200000mb,33vcores</minResources>
<maxResources>300000mb,90vcores</maxResources>
<maxRunningApps>150</maxRunningApps>
<schedulingMode>fair</schedulingMode>
<weight>2.5</weight>
<aclSubmitApps> dev_group</aclSubmitApps>
<aclAdministerApps> hadoop,dev_group</aclAdministerApps>
</queue>
<queue name="test_group">
<minResources>70000mb,20vcores</minResources>
<maxResources>95000mb,25vcores</maxResources>
<maxRunningApps>60</maxRunningApps>
<schedulingMode>fair</schedulingMode>
<weight>1</weight>
<aclSubmitApps> test_group</aclSubmitApps>
<aclAdministerApps> hadoop,test_group</aclAdministerApps>
</queue>
<queue name="business1_group">
<minResources>75000mb,15vcores</minResources>
<maxResources>100000mb,20vcores</maxResources>
<maxRunningApps>80</maxRunningApps>
<schedulingMode>fair</schedulingMode>
<weight>1</weight>
<aclSubmitApps> business1_group</aclSubmitApps>
<aclAdministerApps> hadoop,business1_group</aclAdministerApps>
</queue>
<queue name="business2_group">
<minResources>75000mb,15vcores</minResources>
<maxResources>102400mb,20vcores</maxResources>
<maxRunningApps>80</maxRunningApps>
<schedulingMode>fair</schedulingMode>
<weight>1</weight>
<aclSubmitApps> business2_group</aclSubmitApps>
<aclAdministerApps> hadoop,business2_group</aclAdministerApps>
</queue>
</queue>
<queuePlacementPolicy>
<rule name="primaryGroup" create="false" />
<rule name="secondaryGroupExistingQueue" create="false" />
<rule name="default" />
</queuePlacementPolicy>
</allocations>

这样，每个用户组下的用户提交任务时候，会到相应的资源池中，而不影响其他业务。

需要注意的是，所有客户端提交任务的用户和用户组的对应关系，需要维护在ResourceManager上，ResourceManager在分配资源池时候，是从ResourceManager上读取用户和用户组的对应关系的，否则就会被分配到default资源池。在日志中出现”UserGroupInformation: No groups available for user”类似的警告。而客户端机器上的用户对应的用户组无关紧要。
每次在ResourceManager上新增用户或者调整资源池配额后，需要执行下面的命令刷新使其生效：
yarn rmadmin -refreshQueues
yarn rmadmin -refreshUserToGroupsMappings

参考

《hadoop权威指南》第四版英文版(Scheduling in YARN章节)

http://blog.csdn.net/suifeng3051/article/details/49508261

http://lxw1234.com/archives/2015/10/536.htm

YARN总共提供了三种调度策略：CapacityScheduler，FIFO Scheduler,

FairScheduler

一 FIFOScheduler-先进先出调度策略

即所有的应用程序将按照提交顺序来执行，这些应用程序都放在一个队列里，只有在执行完了一个之后，在执行顺序执行下一个

缺点：

耗时长的任务会导致后提交的一直处于等待状态，资源利用率不高；如果集群多人共享，显然不太合理

二 CapacityScheduler

2.1由于FIFOScheduler的局限性，后来衍生出来了多个用户可以共享集群资源，然后集群资源按照队列为单位进行划分的调度器

2.2还可以控制每一个队列资源最低保障和最高使用限制，最高使用限制是防止过多占用空闲资源，而导致其他队列资源紧张

2.3还可以针对用户设置每个用户最高资源使用限制，以防止该用户滥用或者频繁使用资源

2.4每一个队列内部也是按照先进先出的原则调度资源

2.5如果某个队列资源使用紧张，某个队列比较资源有剩余，那么可以暂时把剩余的资源共享给资源比较紧张的队列，一旦共享资源的队列有应用程序提交，那么被共享资源的队列释放的资源会归还给该共享资源的队列(弹性队列)

2.6每一个队列有严格的访问控制，只有那些被允许的用户才可以查看该队列应用程序的状态

假设我们有如下层次的队列：

root

|-uat

|-dev

|-ecomerce

|-scicne

CapacityScheduler有自己的配置文件，即conf目录下的capacity-scheduler.xml

配置选项：

capacity:队列的资源容量比,所有对列的资源容量比之后不能超过100

maximum-capacity:该队列最多使用到集群资源的上限比

minimum-user-limit-percent:每一个用户最低资源百分比

user-limit-factor:每一个用户最多可用的资源百分比

maximum-applications:集群或者队列资源同时处于等待的和运行状态的应用程序数目上限，一旦超过此配置，后需提交的应用程序将会被拒绝。默认10000.

yarn.scheduler.capacity.maximum-applications：集群最大允许的应用程序总数

yarn.scheduler.capacity.<queue-path>.maximum-applications：队列允许最大的应用程序总数

maximum-am-resource-percent:集群中用于运行应用程序Application

Master的资源比例上限。用浮点数表示，0.1表示10%。所有队列的ApplicationMaster资源比例上限可通过参数yarn.scheduler.capacity.ma

ximum-am-resource-percent.设置

下面是一个简单的capacity-scheduler配置文件：

<name>yarn.scheduler.capacity.maximum-applications</name>

</property>

<name>yarn.scheduler.capacity.maximum-am-resource-percent</name>

</property>

<name>yarn.scheduler.capacity.resource-calculator</name>

<value>org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator</value>

</property>

<name>yarn.scheduler.capacity.root.queues</name>

</property>

<name>yarn.scheduler.capacity.root.dev.queues</name>

<value>ecomerce,scicne</value>

</property>

<name>yarn.scheduler.capacity.root.uat.capacity</name>

</property>

<name>yarn.scheduler.capacity.root.dev.capacity</name>

</property>

<name>yarn.scheduler.capacity.root.default.user-limit-factor</name>

</property>

<!--指定某个队列所占用Container资源上限百分比,因为我们知道如果uat队列空闲

而如果dev所需要资源比较紧张，那么就可以把暂时剩余的资源比如uat队列的

空闲资源使用，为了防止dev全部使用了剩余的空闲资源，然后uat队列无资源

可用的情况，我们需要设一个最大限度值给dev队列；反之，我们没给uat设置

这个最大限度之，那么dev资源空闲，uat需要Container资源紧缺，那么uat可

以全部使用剩余的dev的剩余资源，比如下面配置，dev最多只能站到整个资源

的70%，还可以剩余30%给uat队列应急-->

<name>yarn.scheduler.capacity.root.dev.maximum-capacity</name>

</property>

<!--我们并没有指定ecomerce和scicne队列的maximum-capacity所占用百分比

那么他们ecommerce和scicne中的job有可能会用到整个dev的资源，占总资源的

75%-->

<name>yarn.scheduler.capacity.root.dev.ecomerce.capacity</name>

</property>

<name>yarn.scheduler.capacity.root.dev.scicne.capacity</name>

</property>

<!—队列状态：如果一个队列状态时STOPPED,则不能向其提交应用程序或者其子对列提交应用程序-->

<name>yarn.scheduler.capacity.root.prod.state</name>

<value>RUNNING</value>

</property>

<name>yarn.scheduler.capacity.root.dev.state</name>

<value>RUNNING</value>

</property>

<!—限定哪些用户或者用户组可以向给定对列中提交应用程序-->

<name>yarn.scheduler.capacity.root.prod.acl_submit_applications</name>

</property>

<name>yarn.scheduler.capacity.root.prod.acl_administer_queue</name>

</property>

<name>yarn.scheduler.capacity.node-locality-delay</name>

</property>

<name>yarn.scheduler.capacity.queue-mappings</name>

</property>

</configuration>

三 FairScheduler

试图为每一个任务均匀分配资源，比如当前集群只有一个任务A，那么A拥有整个集群资源，这时候又提交了一个任务B，这时候任务A和B平分资源。

主要特点：

3.1也是将集群资源以队列为单位进行划分

3.2我们也可以设定队列的所使用container资源的最低保障百分比和最高上限

3.3我们也可以针对每一个用户设置资源使用的最低保障和使用上限

3.4当一个队列资源紧缺，可以共享其他队列的资源

3.5我们可以根据的不同策略为应用程序分配资源，比如FIFO,Fair或者DRF,默认是Fair.这就说明2个应用程序可以个占用1/2的资源，三个应用程序可以个占用1/3的资源

3.6当某个队列有剩余资源时，调度器会将这些资源共享给其他队列；如果当该队列有新的应用程序提交时，调度器为他回收资源，采用的是先等待在抢占，等待一段时间后，尚有为归还的资源，则会进行资源抢占，怎么抢占呢？从那些超额的资源的队列杀死一部分任务，进而释放资源

3.7负载均衡：提供一个基于任务数目负载均衡机制，该机制尽可能将系统的任务均匀分配到各个节点上

yarn-site.xml关于公平调度的配置：

yarn.scheduler.fair.allocation.file:自定义XML配置文件所在位置，该文件主要用于描述各个队列属性，比如资源量，权重

yarn.scheduler.fair.user-as-default-name:当应用程序未指定队列名的时候，是否指定用户名作为应用程序所在队列名；如果未设置，那么所有的应用程序提交大default队列中，默认为true

yarn.scheduler.fair.preemption:是否启用抢占机制，默认为false

yarn.scheduler.fair.sizebaseweight:在一个队列分配资源时默认情况采用公平轮询的方式将资源分配给各个应用程序，而该参数提供了另外一种分配方式，按照应用程序资源需求数目进行资源分配，默认为fasle

yarn.scheduler.fair.assignmultiple:是否启动批量分配

yarn.scheduler.fair.max.assign:如果开启批量分配，可指定一次分配的Container数量

yarn.scheduler.increment-allocation-mb:内存资源规整化单位，默认1024，这意味着一个Container请求资源是1.5GB,则将被调整为ceiling

(1.5/1)*1GB=2GB

自定义配置文件，默认是fair-scheduler.xml

minResources:最少资源保证量，格式为 X mb,Y vcores,当一个队列最小资源保证量为满足，他将优先于其他队列获取资源。

maxResources:最多可以使用的资源量

maxRunningApps:最多同时运行的应用程序数目

schedulingMode/schedulingPolicy:队列采用的调度模式

aclSubmitApps:可向队列中提交应用程序的用户列表

minSharePreemptionTimeout：最小公向量抢占时间：即一个资源池在该时间内使用的资源量一直低于最小资源量，则开始抢占资源

<minResources>100 mb,100 vcores</minResources>

<maxResources>150 mb,200vcores</maxResources>

</queue>

<minResources>30 mb,30 vcores</minResources>

<maxResources>50 mb,50vcores</maxResources>

</queue>

<queuename="eng" />

<queuename="science" />

</queueplacementpolicy>

</user>

</allocations>

自定义2队列uat和dev,权重比40:60,也就是说不采用均分的策略。

每一个队列可以有不同的调度策略，默认是fair,此外还有fifo和DRF

四 CapacityScheduler和 FairScheduler的比较

4.1相同点=>

>都允许多用户共享集群资源

>都是以队列对资源进行划分

>都支持层级队列

>都可以进行队列所需资源最低保证和使用资源的最高上限

>资源紧缺的队列可以共享其他队列的空闲资源(或者集群的空闲资源)

>都可以针对用户设置最低资源保障和资源使用最高上限

>都可以对用户设置

4.2不同点=>

>是否支持负载均衡：

CapacityScheduler: 不支持负载均衡

FairScheduler: 支持负载均衡

>Container请求资源粒度不一样

CapacityScheduler: 请求资源的最小整数倍

FairScheduler: 可以根据内存规整化参数控制，粒度更小

>队列之间的资源分配方式：

CapacityScheduler优先选择资源使用率低的队列，然后队列中通过FIFO或者DRF策略进行调度

FairScheduler: 使用公平算法选择队列，然后在在队列中通过Fair、

FIFO或者DRF调度

YARN总共提供了三种调度策略：CapacityScheduler，FIFO Scheduler,

FairScheduler

一 FIFOScheduler-先进先出调度策略

即所有的应用程序将按照提交顺序来执行，这些应用程序都放在一个队列里，只有在执行完了一个之后，在执行顺序执行下一个

缺点：

耗时长的任务会导致后提交的一直处于等待状态，资源利用率不高；如果集群多人共享，显然不太合理

二 CapacityScheduler

2.1由于FIFOScheduler的局限性，后来衍生出来了多个用户可以共享集群资源，然后集群资源按照队列为单位进行划分的调度器

2.2还可以控制每一个队列资源最低保障和最高使用限制，最高使用限制是防止过多占用空闲资源，而导致其他队列资源紧张

2.3还可以针对用户设置每个用户最高资源使用限制，以防止该用户滥用或者频繁使用资源

2.4每一个队列内部也是按照先进先出的原则调度资源

2.6每一个队列有严格的访问控制，只有那些被允许的用户才可以查看该队列应用程序的状态

假设我们有如下层次的队列：

root

|-uat

|-dev

|-ecomerce

|-scicne

CapacityScheduler有自己的配置文件，即conf目录下的capacity-scheduler.xml

配置选项：

capacity:队列的资源容量比,所有对列的资源容量比之后不能超过100

maximum-capacity:该队列最多使用到集群资源的上限比

minimum-user-limit-percent:每一个用户最低资源百分比

user-limit-factor:每一个用户最多可用的资源百分比

maximum-applications:集群或者队列资源同时处于等待的和运行状态的应用程序数目上限，一旦超过此配置，后需提交的应用程序将会被拒绝。默认10000.

yarn.scheduler.capacity.maximum-applications：集群最大允许的应用程序总数

yarn.scheduler.capacity.<queue-path>.maximum-applications：队列允许最大的应用程序总数

maximum-am-resource-percent:集群中用于运行应用程序Application

Master的资源比例上限。用浮点数表示，0.1表示10%。所有队列的ApplicationMaster资源比例上限可通过参数yarn.scheduler.capacity.ma

ximum-am-resource-percent.设置

下面是一个简单的capacity-scheduler配置文件：

<name>yarn.scheduler.capacity.maximum-applications</name>

</property>

<name>yarn.scheduler.capacity.maximum-am-resource-percent</name>

</property>

<name>yarn.scheduler.capacity.resource-calculator</name>

<value>org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator</value>

</property>

<name>yarn.scheduler.capacity.root.queues</name>

</property>

<name>yarn.scheduler.capacity.root.dev.queues</name>

<value>ecomerce,scicne</value>

</property>

<name>yarn.scheduler.capacity.root.uat.capacity</name>

</property>

<name>yarn.scheduler.capacity.root.dev.capacity</name>

</property>

<name>yarn.scheduler.capacity.root.default.user-limit-factor</name>

</property>

<!--指定某个队列所占用Container资源上限百分比,因为我们知道如果uat队列空闲

而如果dev所需要资源比较紧张，那么就可以把暂时剩余的资源比如uat队列的

空闲资源使用，为了防止dev全部使用了剩余的空闲资源，然后uat队列无资源

可用的情况，我们需要设一个最大限度值给dev队列；反之，我们没给uat设置

这个最大限度之，那么dev资源空闲，uat需要Container资源紧缺，那么uat可

以全部使用剩余的dev的剩余资源，比如下面配置，dev最多只能站到整个资源

的70%，还可以剩余30%给uat队列应急-->

<name>yarn.scheduler.capacity.root.dev.maximum-capacity</name>

</property>

<!--我们并没有指定ecomerce和scicne队列的maximum-capacity所占用百分比

那么他们ecommerce和scicne中的job有可能会用到整个dev的资源，占总资源的

75%-->

<name>yarn.scheduler.capacity.root.dev.ecomerce.capacity</name>

</property>

<name>yarn.scheduler.capacity.root.dev.scicne.capacity</name>

</property>

<!—队列状态：如果一个队列状态时STOPPED,则不能向其提交应用程序或者其子对列提交应用程序-->

<name>yarn.scheduler.capacity.root.prod.state</name>

<value>RUNNING</value>

</property>

<name>yarn.scheduler.capacity.root.dev.state</name>

<value>RUNNING</value>

</property>

<!—限定哪些用户或者用户组可以向给定对列中提交应用程序-->

<name>yarn.scheduler.capacity.root.prod.acl_submit_applications</name>

</property>

<name>yarn.scheduler.capacity.root.prod.acl_administer_queue</name>

</property>

<name>yarn.scheduler.capacity.node-locality-delay</name>

</property>

<name>yarn.scheduler.capacity.queue-mappings</name>

</property>

</configuration>

三 FairScheduler

试图为每一个任务均匀分配资源，比如当前集群只有一个任务A，那么A拥有整个集群资源，这时候又提交了一个任务B，这时候任务A和B平分资源。

主要特点：

3.1也是将集群资源以队列为单位进行划分

3.2我们也可以设定队列的所使用container资源的最低保障百分比和最高上限

3.3我们也可以针对每一个用户设置资源使用的最低保障和使用上限

3.4当一个队列资源紧缺，可以共享其他队列的资源

3.7负载均衡：提供一个基于任务数目负载均衡机制，该机制尽可能将系统的任务均匀分配到各个节点上

yarn-site.xml关于公平调度的配置：

yarn.scheduler.fair.allocation.file:自定义XML配置文件所在位置，该文件主要用于描述各个队列属性，比如资源量，权重

yarn.scheduler.fair.preemption:是否启用抢占机制，默认为false

yarn.scheduler.fair.assignmultiple:是否启动批量分配

yarn.scheduler.fair.max.assign:如果开启批量分配，可指定一次分配的Container数量

yarn.scheduler.increment-allocation-mb:内存资源规整化单位，默认1024，这意味着一个Container请求资源是1.5GB,则将被调整为ceiling

(1.5/1)*1GB=2GB

自定义配置文件，默认是fair-scheduler.xml

minResources:最少资源保证量，格式为 X mb,Y vcores,当一个队列最小资源保证量为满足，他将优先于其他队列获取资源。

maxResources:最多可以使用的资源量

maxRunningApps:最多同时运行的应用程序数目

schedulingMode/schedulingPolicy:队列采用的调度模式

aclSubmitApps:可向队列中提交应用程序的用户列表

minSharePreemptionTimeout：最小公向量抢占时间：即一个资源池在该时间内使用的资源量一直低于最小资源量，则开始抢占资源

<minResources>100 mb,100 vcores</minResources>

<maxResources>150 mb,200vcores</maxResources>

</queue>

<minResources>30 mb,30 vcores</minResources>

<maxResources>50 mb,50vcores</maxResources>

</queue>

<queuename="eng" />

<queuename="science" />

</queueplacementpolicy>

</user>

</allocations>

自定义2队列uat和dev,权重比40:60,也就是说不采用均分的策略。

每一个队列可以有不同的调度策略，默认是fair,此外还有fifo和DRF

四 CapacityScheduler和 FairScheduler的比较

4.1相同点=>

>都允许多用户共享集群资源

>都是以队列对资源进行划分

>都支持层级队列

>都可以进行队列所需资源最低保证和使用资源的最高上限

>资源紧缺的队列可以共享其他队列的空闲资源(或者集群的空闲资源)

>都可以针对用户设置最低资源保障和资源使用最高上限

>都可以对用户设置

4.2不同点=>

>是否支持负载均衡：

CapacityScheduler: 不支持负载均衡

FairScheduler: 支持负载均衡

>Container请求资源粒度不一样

CapacityScheduler: 请求资源的最小整数倍

FairScheduler: 可以根据内存规整化参数控制，粒度更小

>队列之间的资源分配方式：

CapacityScheduler优先选择资源使用率低的队列，然后队列中通过FIFO或者DRF策略进行调度

FairScheduler: 使用公平算法选择队列，然后在在队列中通过Fair、

FIFO或者DRF调度

http://www.cnblogs.com/xing901022/p/6174178.html

Hadoop YARN同时支持内存和CPU两种资源的调度（默认只支持内存，如果想进一步调度CPU，需要自己进行一些配置），本文将介绍YARN是如何对这些资源进行调度和隔离的。yarn对于自己运行时作业的资源分配模式有Capacity Scheduler和Fair Scheduler两种。

在YARN中，资源管理由ResourceManager和NodeManager共同完成，其中，ResourceManager中的调度器负责资源的分配，而NodeManager则负责资源的供给和隔离。ResourceManager将某个NodeManager上资源分配给任务（这就是所谓的“资源调度”）后，NodeManager需按照要求为任务提供相应的资源，甚至保证这些资源应具有独占性，为任务运行提供基础的保证，这就是所谓的资源隔离。

基于以上考虑，YARN允许用户配置每个节点上可用的物理内存资源，注意，这里是“可用的”，因为一个节点上的内存会被若干个服务共享，比如一部分给YARN，一部分给HDFS，一部分给HBase等，YARN配置的只是自己可以使用的，配置参数如下：

（1）yarn.nodemanager.resource.memory-mb

表示该节点上YARN可使用的物理内存总量，默认是8192（MB），注意，如果你的节点内存资源不够8GB，则需要调减小这个值，而YARN不会智能的探测节点的物理内存总量。

（2）yarn.nodemanager.vmem-pmem-ratio

任务每使用1MB物理内存，最多可使用虚拟内存量，默认是2.1。

（3） yarn.nodemanager.pmem-check-enabled

是否启动一个线程检查每个任务正使用的物理内存量，如果任务超出分配值，则直接将其杀掉，默认是true。

（4） yarn.nodemanager.vmem-check-enabled

是否启动一个线程检查每个任务正使用的虚拟内存量，如果任务超出分配值，则直接将其杀掉，默认是true。

（5）yarn.scheduler.minimum-allocation-mb

单个任务可申请的最少物理内存量，默认是1024（MB），如果一个任务申请的物理内存量少于该值，则该对应的值改为这个数。

（6）yarn.scheduler.maximum-allocation-mb

单个任务可申请的最多物理内存量，默认是8192（MB）。

默认情况下，YARN采用了线程监控的方法判断任务是否超量使用内存，一旦发现超量，则直接将其杀死。由于Cgroups对内存的控制缺乏灵活性（即任务任何时刻不能超过内存上限，如果超过，则直接将其杀死或者报OOM），而Java进程在创建瞬间内存将翻倍，之后骤降到正常值，这种情况下，采用线程监控的方式更加灵活（当发现进程树内存瞬间翻倍超过设定值时，可认为是正常现象，不会将任务杀死），因此YARN未提供Cgroups内存隔离机制。

Capacity Scheduler

Capacity Scheduler支持以下特性：

(1) 计算能力保证。支持多个队列，某个作业可被提交到某一个队列中。每个队列会配置一定比例的计算资源，且所有提交到队列中的作业共享该队列中的资源。

(2) 灵活性。空闲资源会被分配给那些未达到资源使用上限的队列，当某个未达到资源的队列需要资源时，一旦出现空闲资源资源，便会分配给他们。

(3) 支持优先级。队列支持作业优先级调度（默认是FIFO）

(4) 多重租赁。综合考虑多种约束防止单个作业、用户或者队列独占队列或者集群中的资源。

(5) 基于资源的调度。支持资源密集型作业，允许作业使用的资源量高于默认值，进而可容纳不同资源需求的作业。不过，当前仅支持内存资源的调度。

想要配置能力调度模式首先我们需要将yarn-site.xml文件中设置yarn.resourcemanager.scheduler.class属性为org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.CapacityScheduler

1. 资源分配相关参数

（1） capacity：队列的资源容量（百分比）。当系统非常繁忙时，应保证每个队列的容量得到满足，而如果每个队列应用程序较少，可将剩余资源共享给其他队列。注意，所有队列的容量之和应小于100。

（2） maximum-capacity：队列的资源使用上限（百分比）。由于存在资源共享，因此一个队列使用的资源量可能超过其容量，而最多使用资源量可通过该参数限制。

m minimum-user-limit-percent：每个用户最低资源保障（百分比）。任何时刻，一个队列中每个用户可使用的资源量均有一定的限制。当一个队列中同时运行多个用户的应用程序时中，每个用户的使用资源量在一个最小值和最大值之间浮动，其中，最小值取决于正在运行的应用程序数目，而最大值则由minimum-user-limit-percent决定。比如，假设minimum-user-limit-percent为25。当两个用户向该队列提交应用程序时，每个用户可使用资源量不能超过50%，如果三个用户提交应用程序，则每个用户可使用资源量不能超多33%，如果四个或者更多用户提交应用程序，则每个用户可用资源量不能超过25%。

（3） user-limit-factor：每个用户最多可使用的资源量（百分比）。比如，假设该值为30，则任何时刻，每个用户使用的资源量不能超过该队列容量的30%。

2. 限制应用程序数目相关参数

（1） maximum-applications ：集群或者队列中同时处于等待和运行状态的应用程序数目上限，这是一个强限制，一旦集群中应用程序数目超过该上限，后续提交的应用程序将被拒绝，默认值为 10000。所有队列的数目上限可通过参数yarn.scheduler.capacity.maximum-applications设置（可看做默认值），而单个队列可通过参数yarn.scheduler.capacity.<queue-path>.maximum- applications设置适合自己的值。

（2） maximum-am-resource-percent：集群中用于运行应用程序 ApplicationMaster的资源比例上限，该参数通常用于限制处于活动状态的应用程序数目。该参数类型为浮点型，默认是0.1，表示10%。所有队列的ApplicationMaster资源比例上限可通过参数yarn.scheduler.capacity. maximum-am-resource-percent设置（可看做默认值），而单个队列可通过参数 yarn.scheduler.capacity.<queue-path>. maximum-am-resource-percent设置适合自己的值。

3. 队列访问和权限控制参数

（1） state ：队列状态可以为STOPPED或者 RUNNING，如果一个队列处于STOPPED状态，用户不可以将应用程序提交到该队列或者它的子队列中，类似的，如果ROOT队列处于STOPPED 状态，用户不可以向集群中提交应用程序，但正在运行的应用程序仍可以正常运行结束，以便队列可以优雅地退出。

（2） acl_submit_applications：限定哪些Linux用户/用户组可向给定队列中提交应用程序。需要注意的是，该属性具有继承性，即如果一个用户可以向某个队列中提交应用程序，则它可以向它的所有子队列中提交应用程序。配置该属性时，用户之间或用户组之间用“，”分割，用户和用户组之间用空格分割，比如“user1, user2 group1,group2”。

（3） acl_administer_queue：为队列指定一个管理员，该管理员可控制该队列的所有应用程序，比如杀死任意一个应用程序等。同样，该属性具有继承性，如果一个用户可以向某个队列中提交应用程序，则它可以向它的所有子队列中提交应用程序。

Fair Scheduler

公平调度器按资源池（pool）来组织作业，并把资源公平的分到这些资源池里。默认情况下，每一个用户拥有一个独立的资源池，以使每个用户都能获得一份等同的集群资源而不管他们提交了多少作业。按用户的 Unix 群组或作业配置（jobconf）属性来设置作业的资源池也是可以的。在每一个资源池内，会使用公平共享（fair sharing）的方法在运行作业之间共享容量（capacity）。用户也可以给予资源池相应的权重，以不按比例的方式共享集群。

除了提供公平共享方法外，公平调度器允许赋给资源池保证（guaranteed）最小共享资源，这个用在确保特定用户、群组或生产应用程序总能获取到足够的资源时是很有用的。当一个资源池包含作业时，它至少能获取到它的最小共享资源，但是当资源池不完全需要它所拥有的保证共享资源时，额外的部分会在其它资源池间进行切分。

要想配置公平调度模式首先我们需要将yarn-site.xml文件中设置yarn.resourcemanager.scheduler.class属性为org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler

Fair Scheduler允许用户将队列信息专门放到一个配置文件（默认是fair-scheduler.xml），对于每个队列，管理员可配置以下几个选项：

（1） minResources ：最少资源保证量，设置格式为“X mb, Y vcores”，当一个队列的最少资源保证量未满足时，它将优先于其他同级队列获得资源，对于不同的调度策略（后面会详细介绍），最少资源保证量的含义不同，对于fair策略，则只考虑内存资源，即如果一个队列使用的内存资源超过了它的最少资源量，则认为它已得到了满足；对于drf策略，则考虑主资源使用的资源量，即如果一个队列的主资源量超过它的最少资源量，则认为它已得到了满足。

（2） maxResources：最多可以使用的资源量，fair scheduler会保证每个队列使用的资源量不会超过该队列的最多可使用资源量。

（3） maxRunningApps：最多同时运行的应用程序数目。通过限制该数目，可防止超量Map Task同时运行时产生的中间输出结果撑爆磁盘。

（4） minSharePreemptionTimeout：最小共享量抢占时间。如果一个资源池在该时间内使用的资源量一直低于最小资源量，则开始抢占资源。

（5） schedulingMode/schedulingPolicy：队列采用的调度模式，可以是fifo、fair或者drf。

（6） aclSubmitApps：可向队列中提交应用程序的Linux用户或用户组列表，默认情况下为“*”，表示任何用户均可以向该队列提交应用程序。需要注意的是，该属性具有继承性，即子队列的列表会继承父队列的列表。配置该属性时，用户之间或用户组之间用“，”分割，用户和用户组之间用空格分割，比如“user1, user2 group1,group2”。

（7） aclAdministerApps：该队列的管理员列表。一个队列的管理员可管理该队列中的资源和应用程序，比如可杀死任意应用程序。

管理员也可为单个用户添加maxRunningJobs属性限制其最多同时运行的应用程序数目。此外，管理员也可通过以下参数设置以上属性的默认值：

（1） userMaxJobsDefault：用户的maxRunningJobs属性的默认值。

（2） defaultMinSharePreemptionTimeout ：队列的minSharePreemptionTimeout属性的默认值。

（3） defaultPoolSchedulingMode：队列的schedulingMode属性的默认值。

（4） fairSharePreemptionTimeout：公平共享量抢占时间。如果一个资源池在该时间内使用资源量一直低于公平共享量的一半，则开始抢占资源。