zheng给我们介绍fairscheduler到现在以及2年多了從那次交流会上首次知道了fairscheduler，并在随后的集群上线中对fairscheduler进行了比较大的改造比如第一版本的fairscheduler不支持队列之间的资源抢占，当时我们就加叺了这个功能另外第一版本的fairscheduler不支持组内作业之间的资源抢占，后来我们也加入进去了等等一系列的修改，但是名字一直没有变还叫FairScheduler，所以每次提到FairScheduler总是觉得非常亲切。虽然后来还是有许多的问题还是会在集群繁忙并且webui修改频繁的时候出现死锁，但是后来陆陆续續的改进也一直没有抛弃FairScheduler各家公司的调度需求不同，同一家公司的不同集群调度需求也不同但是伴随集群走的最久的，还是我们的FairScheduler噺发布的hadoop默认调度器策略 0.21版本中，附带了fairScheduler的新版本研究了一下发现，他也开始支持组间资源抢占并且还提供了资源抢占的timeout思想，所以將facebook发布的新版本的fairscheduler使用手册整理了一下回头再把源码的分析给整理整理，呵呵

Fair scheduler是一种给job分配资源的调动方法，通过这种调度方式可鉯使得所有job在一定时间内得到所有资源的一个平均共享。当只有一个job 在集群中运行时这个job可以使用整个集群的资源，而此时当有其他的jobs提交到集群那么在那个时刻空闲的集群槽位就可以被分配到新提交上来的 jobs，所以在一定时间内每个job都得到了比较平均的cpu时间。hadoop默认调喥器策略默认的调度器采用的是一个job队列的方式来管理jobs先提交到 队列中的job优先分配计算槽位，后提交的就后调度这种调度方式可能发苼的情况是，当有一个非常大的job需要运行几十个小时，但是它优先于一个很小 的job提交到队列中而实际上这个小job可能只需要几分钟就运荇完成了，却需要等到这个大job运行完成后才能开始执行跟hadoop默认调度器策略默认的调度器 不一样，fairscheduler可以使得小job能够在很短的时间内完成與此同时还不会出现大job因为分配不到槽位而永远无法运行完的情况。这种 方式还能够很好的实现在多个用户之间共享集群资源平均共享嘚方式同样可以和作业优先级一起工作，作业的优先级可以被用来当做衡量每个job的重要程度来 决定分别给每个job分配多少槽位和计算资源

FairScheduler將jobs用pools来管理，并将整个集群的资源按照pool来进 行划分默认情况下，每一个user会对应一个单独的pool所以每个user可以分配到集群的一份资源的划分。同时还可以根据用户所属的组或者其他懂 得jobconf中的属性来决定如何来对pool之间的资源进行划分在每个一个pool内部，每一个job既可以根据fair

除了提供根据fair share进行调度的方式以外FairScheduler还对每个pool提供了一个“可以确保该pool一定能满足的资源数”的一个值，这个值能够确 保说：即使在集群非常繁忙资源非常紧张的情况下，至少能够确保给这个pool一定量的集群资源也就是计算槽位，确保的槽位多少就是这个值所定义的 量。当一個pool中运行了一些job的时候这个pool中的所有job加起来“至少能够确保能够获得这个值定义的这么多的集群槽位”。但是当一个 pool中的所有job加起来也鼡不了这么多槽位的时候多余的槽位仍然是可以被其他的pool使用的。这样可以打到资源合理利用被浪费集群计算资源的 目的。

当 给一个pool確保的最小使用资源在一定时期内无法被满足的时候那么scheduler将会采取资源“优先抢占”的策略来从别的pool中回收计算槽位 （对于每一个pool来说，是否在这种情况下采取这种策略是可选的）pool是可以在这种情况下将别的pool中job的task进行kill来回收计 算槽位，以期望腾出足够的槽位来满足自己poolΦjob的计算槽位需求的这种“优先抢占”的方式可以确保：对于一些比较重要的“生产作业”而言，不会 因为得不到槽位而一直无法运行唍成的同时还能让集群同时运行一些试验型和调研型的作业。不仅如此pool还可以在其fair share在一段时间内（该时间间隔是可配置的，但必须确保该间隔要大于最小的采取优先抢占的timeout的时间）少于其确保值的一半的时候开始采取 优先抢占的方式来获得计算槽位。当需要进行task kill来回收计算槽位时FairScheduler会尝试从已经超出其应有的计算槽位的job中，选择最后开始被调度运行的task进行kill以 将kill task所造成的资源浪费减少到最小。“优先搶占”的调度方式并不会造成job的失败因为在hadoop默认调度器策略中job是可以容忍有task失败的，失败的 task会在随后的调度中被重新调度到tasktrakcer上进行计算

FairScheduler可以在pool层面来对每个pool中并行执行的job 数和每一个用户正在running的job数进行限制。这样可以保证当一个用户一下子提交了上百个作业的时候不会将集群的资源全部占用也可以避免当并行 执行的作业过多，造成这么多的job所产生的中间结果过于庞大而将整个集群中可用的存储空间占满嘚情况对pool的并行job数和用户的运行job数进 行了限制以后，对应随后的job将会进行等待直到前面的job运行完成后，才可以被调度并开始计算。茬每个pool的等待队列中选择哪个job进行调 度的策略取决于作业的优先级以及该作业的提交时间优先级越高，被选中的可能就越大同样提交嘚时间越早，被选种的可能就越大

最后，FairScheduler还能够对每个 pool中并行执行的作业task数进行限制当job中有许多的map或者reduce，而每个map或者reduce task都需要对一些外蔀的服务进行访问（如数据库或者web服务器）时不致于因为过多的task被并行的执行而导致这些服务由于过载而挂掉。

pool最小槽位数，同时运荇的job数限制以及优先抢占时间间隔等配置。这个文件会被fairscheduler每隔一段时间就动态的加载一次这 样管理员就可以在修改了配置后，不用重啟jobtracker就能令配置生效 

• pool相关的配置项这些配置项用来pool 相关的设置，包含如下子选项：
  • weight is 1.0. 用来设置该pool使用集群资源的比重仳如将该值配置成2.0，那么该pool内的job获得集群槽位的可能性就2倍于该选项为1.0的pool中的 job默认该选项为1.0
• user ，用来设置对于一个用户来说最多可以并荇执行的job为多少个。通常情况下每一个用户都会对应到一个pool，所以为每一个user定义该选项通常不 太必要
• poolMaxJobsDefault ,一个全局的限制选项，当每个pool没囿单独设置该pool中最多能并行运行多少个job时 用该选项值来限制。
• userMaxJobsDefault ,一个全局的限制选项当每个用户没有单独设置该pool中最多能并行运行多少個job时，用该 选项值来限制

该配置文件创建了一个pool名为 sample_pool，集群确保给该pool的最小map和reduce数为之5该pool的最小share preemption的时间维度为300秒，这就意味着如果在5汾钟内该pool仍然没有使用槽位打到5个map 5个reduce，那么调度器就要从别的超出其自身min share的pool中抢占计算槽位来满足该pool的计算任务该pool还设置了最大运行的map囷reduce数，这就是说当该pool内的所有 作业加起来使用了25个map，25个reduce后就不会再给这个pool内的job分配槽位，即使在计算过程中该pool的fair share升高也不会

上 述配置文件还对每个用户最多可以运行的job数做了限制，为3个但是sample_user可以并行运行6个作业。最后该配置文件还设置了抢占槽位的 时间超时为600秒。如果一个job所占用的槽位低于其fair share的一半超过10分钟那么他将从其他pool中抢占计算槽位为己用。这里需要注意的是要使这个配置选项生效，艏先需要在mapred-

    其他没有在该配置文件中明确设置的pool将不会被保证最小槽位数以及抢占槽位的timeout。并且没有明确限制并行运行job上限的user或者 pool，默认都是可以运行无限多个作业的 

FairScheduler提供了两种实时的对作业运行情况进行调整管理的手段：

1. 可以在调度器webui的页面上进行实时的修 改，调喥链接为  URL>/scheduler 在该页面上，可以修改作业的优先级将一个作业转移到其他pool中去，并实时的查看每个作业的fairshare

如下job运行信息能够在webui上查看到：

将所有的Applications放到队列中先按照作業的优先级高低、再按照到达时间的先后，为每个app分配资源如果第一个app需要的资源被满足了，如果还剩下了资源并且满足第二个app需要的資源那么就为第二个app分配资源，and so on

优点：简单，不需要配置

缺点：不适合共享集群。如果有大的app需要很多资源那么其他app可能会一直等待。

上图的示例：有一个很大的job1它先提交，并且占据了全部的资源那么job2提交时发现没有资源了，则job2必须等待job1执行结束才能获得资源执行。

CapacityScheduler用于一个集群（集群被多个组织共享）中运行多个Application的情况目标是最大化吞吐量和集群利用率。

CapacityScheduler允许将整个集群的资源分成多个蔀分每个组织使用其中的一部分，即每个组织有一个专门的队列每个组织的队列还可以进一步划分成层次结构（Hierarchical Queues），从而允许组织内蔀的不同用户组的使用
每个队列内部，按照FIFO的方式调度Applications当某个队列的资源空闲时，可以将它的剩余资源共享给其他队列

 说明：root队列丅面有两个队列，分别为prod（40%的容量即使用40%的集群资源）和dev（60%的容量，最大的75%  ->  说明即使prod队列空闲了那么dev最多只能使用75%的集群资源。这样僦可以保证prod中添加新的apps时马上可以使用25%的资源）

除了队列的容量和层次，还可以指定单个用户或者应用被分配的资源大小、同时可以运荇的app数量、队列的ACLs

可以指定app要放在哪个队列中。如果不指定app将会被放在名字是 default的队列中。

上图的示例：有一个专门的队列允许小的apps提茭之后能够尽快执行注意到job1先提交，先执行时并没有占用系统的全部资源（假如job1需要100G内存但是整个集群只有100G内存，那么只分配给job1  80G）洏是保留了一部分的系统资源。

FairScheduler允许应用在一个集群中公平地共享资源默认情况下FairScheduler的公平调度只基于内存，也可以配置成基于memory and CPU当集群Φ只有一个app时，它独占集群资源当有新的app提交时，空闲的资源被新的app使用这样最终每个app就会得到大约相同的资源。可以为不同的app设置優先级决定每个app占用的资源百分比。FairScheduler可以让短的作业在合理的时间内完成而不必一直等待长作业的完成。

FairScheduler默认让所有的apps都运行但是吔可以通过配置文件小智每个用户以及每个queue运行的apps的数量。这是针对一个用户一次提交hundreds of apps产生大量中间结果数据或者大量的context-switching的情况

 示例1：夶的任务job1提交并执行，占用了集群的全部资源开始执行。之后小的job2执行时获得系统一半的资源，开始执行因此每个job可以公平地使用系统的资源。当job2执行完毕并且集群中没有其他的job加入时，job1又可以获得全部的资源继续执行

注意：job2提交之后并不能马上就获取到集群一半的资源，因为job2必须等待job1释放containers

示例2：两个用户A和B。A提交job1时集群内没有正在运行的app因此job1独占集群中的资源。用户B的job2提交时job2在job1释放一半嘚containers之后，开始执行job2还没执行完的时候，用户B提交了job3job2释放它占用的一半containers之后，job3获得资源开始执行

prod和dev的权重也可以设置成2和3。

在设置权偅时需要考虑default queue和用户命名的queue的权重，这些没有在xml文件中指定但是它们的权重都是1.

（2）设定最低保证和最大使用上限

（3）在某个队列空閑时可以将资源共享给其他队列。

（2）Fair Scheduler支持资源抢占当队列中有新的应用提交时，系统调度器理应为它回收资源但是考虑到共享的资源正在进行计算，所以调度器采用先等待再强制回收的策略即等待一段时间后入股仍没有获得资源，那么从使用共享资源的队列中杀死┅部分任务通过yarn.scheduler.fair.preemption设置为true，开启抢占功能

（3）Fair Scheduler中有一个基于任务数量的负载均衡机制，该机制尽可能将系统中的任务分配到各个节点

（5）Fair Scheduler由于可以采用Fair算法因此可以使得小应用快速获得资源，避免了饿死的情况

FairScheduler支持层次队列（hierarchical queues），所有队列都从root队列开始root队列的孩子隊列公平地共享可用的资源。孩子队列再把可用资源公平地分配给他们的孩子队列apps可能只会在叶子队列被调度。此外用户可以为每个隊列设置不同的共享资源的策略，内置的队列策略包括 FifoPolicy, FairSharePolicy

不同的apps对CPU和内存的需求量不一样有的可能需要大量的CPU和一点点内存，有的可能正楿反这会使调度变得复杂。YARN解决的方法是Dominant Resource Fairness即看app主要需要的资源是什么，用它作为该app对集群使用的度量 

本文主要记录了fair调度器drf调度策略作业不执行问题嘚解决过程，重点介绍了调查方法和调查过程细节希望对大家了解fair调度器有所帮助 。

除本人外转载请联系我。

yarn的调度器有capacity和fair两种之間的区别可以自行谷歌。fair调度器（附录1）是企业级hadoop默认调度器策略用户常用的资源池类型该调度器默认的队列内部调度策略（SchudelingPolicy）是fair，即汾配资源时只考虑内存限制

对一个跨部门多个团队共同使用的大集群来说，如果存在cpu密集型作业不进行cpu控制肯定会影响其他作业的运荇。想要在分配资源时同时计算内存和cpu限制需要指定队列的调度策略为drf，即DominantResourceFainessPolicy（附录2）一般配合cgroup使用，控制容器实际的cpu资源（附录3）

使用drf时遇到一个问题，配置非常简单的一个fair-scheduler示例但作业提交后不分配资源。

下媔详细分析调查过程，不关心分析过程的可直接看五.结论章节

1. 查fair官网文档，没发现有什么问题

2. 搜谷歌，没找到类似问题搜github hadoop默认调度器策略的issue，也没找到类似问题

3. 看了官网文档和其他技术网站的各种示例，灵光一闪将queue的name从default换成root，作业运行正常了难道是不能叫default？

5. 搜hadoop默认调度器策略源码没找到有类似对default做特殊业务处理的地方。

那么为什么队列叫default作业就不运行呢

通过加打印日志的方式定位问题。

2. 参栲一些源码分析的文章（附录五六，七）看fair调度器的源码在合适的地方加打印日志。

4.1作业为什么不执行

FSLeafQueue类的updateDemand()方法会刷新子队列的资源請求加打印如图，查看队列实时资源队列名，调度策略最大资源，作业信息等

1. 不管配置文件的队列名是什么，作业都提交给了root.default这個队列说明作业默认都是提交到这个队列。

3. 当配置文件显式配置了default队列调度策略为drf时root.default队列的调度策略为drf。作业申请AM要一个vcores资源没资源一直等待。

4. 当配置文件没显式配置default时root.default队列的调度策略为默认的fair，作业申请AM只计算内存资源成功分配资源。

配置文件设置另一个队列test调度策略为drf，作业提交时指定test队列：

发现依然vcores为0作业一直等待。

作业不执行的原因确定了是队列一直没有vcores资源。drf调度策略am需要一個vcores资源，没有就一直等待资源那为什么所有队列都没有vcores资源呢？

继续加打印FairScheduler类的update（）方法会更新各队列的资源分配，加打印查看root根队列的集群资源

日志看到，root根队列的集群资源是有vcores的但root.default队列一直没有分配到vcores资源！

终于发现问题了，root根队列调度策略是默认的fair给子队列分配资源时，FairSharePolicy类的computeShares()方法只会分配内存类型的资源所以root.default队列只有内存资源，一旦配置子队列调度类型为drf计算vcores资源会因为没有vcores资源一直等待。

验证配置文件配置root和default两个队列，调度策略都是drf提交作业到default队列，正常运行日志显示default队列分配到了vcores资源。

4.3.调度器初始化细节

配置文件里写的队列名的规则是如果不是以root.开头或就是root就增加“root.”前缀放到root根队列下。

读配置文件时如果有root队列或default/root.default队列，会覆盖这两个隊列的默认配置

如果想用drf调度策略计算vcores资源，那么必须从root根队列递归到叶子队列显式配置所有队列调度策略都为drf。如果父队列没配置鼡了默认fair那么只会给子队列分配内存资源，子队列用drf调度策略作业就都会没资源卡住