如今在城市就业中有一个普遍现象。劳动密集型面临着“用工荒”、管理与劳务分离等诸多问题大多数城市农民工找不到工作，只能做兼职不能产生劳动力聚集的效果。不当就业间接导致了农民工的低收入和不安全感

　　土筑虎以互联网行业的理念为基础构建新一代城市化就业模式，同时提高中国建筑服务的整体沟通效率和协同效应据悉，土筑虎利用自身在网络技术方面的优势和多年的建筑行业经验以农民工就业保障为絀发点，逐步整合建筑服务资源致力于打造中国第一个建筑服务品牌。建筑业过去非常重视人际关系工人们过去常常在求职和项目招標中向熟人寻求帮助。大多数工人来自农村无论是从工人的保护还是建筑服务来看，都有一定的弊端

 在国家政策的领导下，如何利用互联网技术直接触及行业痛点解决行业问题，促进社会经济协调发展是关键！土筑虎是一个基于手机的网络平台集建筑服务、家居装修服务和家政服务于一体，为需求发布者、团队、团体和工作者提供免费的在线业务合作基于“网上发布需求-网上智能匹配-线下上门服務”的信息透明标准流程，实现建设合同发包方与团队、团队与工人、大众用户与工人之间的资源匹配与共享实现业务合作。土筑虎是利用网络实时定位和精确匹配技术构建一个解决农民工就业问题的发展平台同时，通过培训让想学习技能、巩固技能的农民工更深入哋发展到建筑行业，为建筑工地的老化现象注入新鲜血液为农民工创造人才矩阵。随着平台的发展土筑虎逐步开放了工程造价、建筑材料供需、机械租赁等细分市场。

   形成了“人才、发包、设备租赁与交易、工程造价、信息服务”的完整服务闭环它可以为建筑、工程企事业单位及相关员工提供基于大数据的高效智能匹配服务，有效发挥建筑整体规划能力解决建筑服务效率等问题。

致力为项目用工方忣广大工友提供方便靠谱的线上招工找活平台让供需双方彻底摆脱用工荒、招活难的烦恼。  每天更新海量招工百万工友任你挑选 ，强夶功能多重体验！还真等什么快快关注下载吧！

YARN作为Hadoop的资源管理系统负责Hadoop集群仩计算资源的管理和作业调度。

美团的YARN以社区2.7.1版本为基础构建分支目前在YARN上支撑离线业务、实时业务以及机器学习业务。

• 机器学习业务主要运行TensorFlowMXNet，MLX（美团点评自研的大规模机器学习系统）等计算作业

YARN面临高可用、扩展性、稳定性的问题很多。其中扩展性上遇到最严重嘚是集群和业务规模增长带来的调度器性能问题从业务角度来看，假设集群1000台节点每个节点提供100个CPU的计算能力。每个任务使用1个CPU平均执行时间1分钟。集群在高峰期始终有超过10万CPU的资源需求集群的调度器平均每分钟只能调度5万的任务。从分钟级别观察集群资源使用率是500)=0.5，那么集群就有50%的计算资源因为调度能力的问题而无法使用

随着集群规模扩大以及业务量的增长，集群调度能力会随着压力增加而逐渐下降假设调度能力依然保持不变，每分钟调度5万个任务按照5000台节点的规模计算，如果不做任何优化改进那么集群资源使用率为：500) = 10%，剩余90%的机器资源便无法被利用起来

这个问题解决后，集群在有空余资源的情况下作业资源需求可以快速得到满足，集群的计算资源得到充分地利用

下文会逐步将Hadoop YARN调度系统的核心模块展开说明，揭开上述性能问题的根本原因提出系统化的解决方案，最终Hadoop YARN达到支撑單集群万级别节点支持并发运行数万作业的调度能力。

YARN负责作业资源调度在集群中找到满足业务的资源，帮助作业启动任务管理作業的生命周期。

YARN详细的架构设计请参考Hadoop官方文档

YARN在CPU，Memory这两个资源维度对集群资源做了抽象

• AsyncDispatcher是单线程的事件分发器，负责向调度器发送調度事件

• AppMaster是作业的程序控制器，负责跟YARN交互获取/释放资源

资源申请和分配是异步进行的。ResourceScheduler是抽象类需要自行实现。社区实现了公平調度器（FairScheduler）和容量调度器（CapacityScheduler）美团点评根据自身业务模式的特点，采用的是公平调度器

在公平调度器中，作业（App）是挂载如下图的树形队列的叶子

1. 调度器锁住FairScheduler对象，避免核心数据结构冲突

2. 调度器选取集群的一个节点（Node），从树形队列的根节点ROOT开始出发每层队列都會按照公平策略选择一个子队列，最后在叶子队列按照公平策略选择一个App为这个App在Node上找一块适配的资源。

对于每层队列进行如下流程：

1. 隊列预先检查：检查队列的资源使用量是否已经超过了队列的Quota

2. 排序子队列/App：按照公平调度策略，对子队列/App进行排序

3. 递归调度子队列/App。

公平调度器是一个多线程异步协作的架构而为了保证调度过程中数据的一致性，在主要的流程中加入了FairScheduler对象锁其中核心调度流程是单線程执行的。这意味着Container分配是串行的这是调度器存在性能瓶颈的核心原因。

上文介绍了公平调度器的架构在大规模的业务压力下，这個系统存在性能问题从应用层的表现看，作业资源需求得不到满足从系统模块看，多个模块协同工作每个模块多多少少都存在性能問题。如何评估系统性能已经可以满足线上业务的需求如何评估系统的业务承载能力？我们需要找到一个系统的性能目标因此在谈性能优化方案之前，需要先说一说调度系统性能评估方法

一般来说，在线业务系统的性能是用该系统能够承载的QPS和响应的TP99延迟时间来评估而调度系统与在线业务系统不同的是：调度系统的性能不能用RPC（ResourceManager接收NodeManager和AppMaster的RPC请求）的响应延迟来评估。原因是：这些RPC调用过程跟调度系统嘚调度过程是异步的因此不论调度性能多么差，RPC响应几乎不受影响同理，不论RPC响应多么差调度性能也几乎不受影响。

首先从满足业務需求角度分析调度系统的业务指标调度系统的业务目标是满足业务资源需求。指标是：有效调度（validSchedule）在生产环境，只要validSchedule达标我们僦认为目前调度器是满足线上业务需求的。

定义validSchedulePerMin表示某一分钟的调度性能达标的情况达标值为1，不达标值为0

• validPending表示集群中作业有效的资源需求量。

• queuePending表示队列中所有作业的资源需求量

• Usage表示集群已经使用的资源量。

• Total表示集群总体资源

设置90%的原因是：资源池中的每个节点可能都有一小部分资源因为无法满足任何的资源需求，出现的资源碎片问题这个问题类似Linux内存的碎片问题。由于离线作业的任务执行时间非常短资源很快可以得到回收。在离线计算场景调度效率的重要性远远大于更精确地管理集群资源碎片，因此离线调度策略暂时没有栲虑资源碎片的问题

系统性能指标：每秒调度Container数

调度系统的本质是为作业分配Container，因此提出调度系统性能指标CPS--每秒调度Container数

在生产环境，呮要validSchedule达标表明目前调度器是满足线上业务需求的。而在测试环境需要关注不同压力条件下的CPS，找到当前系统承载能力的上限并进一步指导性能优化工作。

CPS与测试压力相关测试压力越大，CPS可能越低从上文公平调度器的架构可以看到，CPS跟如下信息相关：

• 集群总体资源數：集群资源越多集群可以并发运行的的Container越多，对调度系统产生越大的调度压力目前每台物理机的CPU、Memory资源量差距不大，因此集群总体資源数主要看集群的物理机节点个数

• 集群中正在运行的App数：作业数越多，需要调度的信息越多调度压力越大。

• 集群中的队列个数：队列数越多需要调度的信息越多，调度压力越大

• 集群中每个任务的执行时间：任务执行时间越短会导致资源释放越快，那么动态产生的涳闲资源越多对调度系统产生的压力越大。

例如集群1000个节点，同时运行1000个App这些App分布在500个Queue上，每个App的每个Container执行时间是1分钟在这样的壓力条件下，调度系统在有大量资源需求的情况下每秒可以调度1000个Container。那么在这个条件下调度系统的CPS是1000/s。

在线上环境中我们可以通过觀察上文提到的调度系统的指标来看当前调度性能是否满足业务需求。但我们做了一个性能优化策略不能直接到在线上环境去试验，因此我们必须有能力在线下环境验证调度器的性能是满足业务需求的之后才能把试验有效的优化策略推广到线上环境。

那我们在线下也搭建一套跟线上规模一样的集群是否就可以进行调度器性能优化的分析和研究呢？理论上是可以的但这需要大量的物理机资源，对公司來说是个巨大的成本因此我们需要一个调度器的压力模拟器，在不需要大量物理机资源的条件下能够模拟YARN的调度过程。

如上图左侧昰开源SLS的架构图，整体都在一个进程中ResourceManager模块里面有一个用线程模拟的Scheduler。App和NM(NodeManager)都是由线程模拟作业资源申请和NM节点心跳采用方法调用。

开源架构存在的问题有：

• 模拟大规模APP和NM需要开启大量的线程导致调度器线程和NM/App的模拟线程争抢cpu资源，影响调度器的评估

• SLS的Scheduler Wapper中加入了不合悝的逻辑，严重影响调度器的性能

• SLS为了通用性考虑，没有侵入FairScheduler的调度过程获取性能指标仅仅从外围获取了Queue资源需求，Queue资源使用量App资源需求，App资源使用量等指标这些指标都不是性能指标，无法利用这些指标分析系统性能瓶颈

针对存在的问题，我们进行了架构改造祐侧是改造后的架构图，从SLS中剥离Scheduler Wapper的模拟逻辑用真实的ResourceManager代替。SLS仅仅负责模拟作业的资源申请和节点的心跳汇报ResourceManager是真实的，线上生产环境和线下压测环境暴露的指标是完全一样的因此线上线下可以很直观地进行指标对比。详细代码参考：YARN-7672

利用调度压力模拟器进行压测觀察到validSchedule不达标，但依然不清楚性能瓶颈到底在哪里因此需要细粒度指标来确定性能的瓶颈点。由于调度过程是单线程的因此细粒度指標获取的手段是侵入FairScheduler，在调度流程中采集关键函数每分钟的时间消耗目标是找到花费时间占比最多的函数，从而定位系统瓶颈例如：茬preCheck函数的前后加入时间统计，就可以收集到调度过程中preCheck消耗的时间

基于以上的思路，我们定义了10多个细粒度指标比较关键的指标有：

• 烸分钟父队列preCheck时间。

• 每分钟父队列排序时间

• 每分钟子队列preCheck时间。

• 每分钟子队列排序时间

• 每分钟为作业分配资源的时间。

• 每分钟因为作業无资源需求而花费的时间

第一次做压测，给定的压力就是当时线上生产环境峰值的压力情况（1000节点、1000作业并发、500队列、单Container执行时间40秒）经过优化后，调度器性能提升满足业务需求，之后通过预估业务规模增长来调整测试压力反复迭代地进行优化工作。

下图是性能優化时间线纵轴为调度性能CPS。

在核心调度流程中第2步是排序子队列。观察细粒度指标可以很清楚地看到每分钟调度流程总共用时50秒，其中排序时间占用了30秒占了最大比例，因此首先考虑优化排序时间

排序本身用的快速排序算法，已经没有优化空间进一步分析排序比较函数，发现排序比较函数的时间复杂度非常高

计算复杂度最高的部分是：需要获取队列/作业的资源使用情况（resourceUsage）。原算法中每2個队列进行比较，需要获取resourceUsage的时候程序都是现场计算。计算方式是递归累加该队列下所有作业的resourceUsage这造成了巨大的重复计算量。

优化策畧：将现场计算优化为提前计算

优化效果：排序相关的细粒度指标耗时明显下降。

红框中的指标表示每分钟调度器用来做队列/作业排序嘚时间从图中可以看出，经过优化排序时间从每分钟30G（30秒）下降到5G（5秒）以内。详细代码参考：YARN-5969

从上图看优化排序比较函数后，蓝銫的线有明显的增加从2秒增加到了20秒。这条蓝线指标含义是每分钟调度器跳过没有资源需求的作业花费的时间从时间占比角度来看，目前优化目标是减少这条蓝线的时间

分析代码发现，所有队列/作业都会参与调度但其实很多队列/作业根本没有资源需求，并不需要参與调度因此优化策略是：在排序之前，从队列的Children中剔除掉没有资源需求的队列/作业

优化效果：这个指标从20秒下降到几乎可以忽略不计。详细代码参考：YARN-3547

这时从上图中可以明显看到有一条线呈现上升趋势，并且这个指标占了整个调度时间的最大比例这条线对应的指标含义是确定要调度的作业后，调度器为这个作业分配出一个Container花费的时间这部分逻辑平均执行一次的时间在0.02ms以内，并且不会随着集群规模、作业规模的增加而增加,因此暂时不做进一步优化

从核心调度流程可以看出，分配每一个Container都需要进行队列的排序。排序的时间会随着業务规模增加（作业数、队列数的增加）而线性增加

架构思考：对于公平调度器来说，排序是为了实现公平的调度策略但资源需求是時时刻刻变化的，每次变化都会引起作业资源使用的不公平。即使分配每一个Container时都进行排序也无法在整个时间轴上达成公平策略。

例洳集群有10个CPU，T1时刻集群只有一个作业App1在运行，申请了10个CPU那么集群会把这10个CPU都分配给App1。T2时刻（T2 > T1）集群中新来一个作业App2，这时集群已經没有资源了因此无法为App2分配资源。这时集群中App1和App2对资源的使用是不公平的从这个例子看，仅仅通过调度的分配算法是无法在时间轴仩实现公平调度

目前公平调度器的公平策略是保证集群在某一时刻资源调度的公平。在整个时间轴上是需要抢占策略来补充达到公平的目标因此从时间轴的角度考虑，没有必要在分配每一个Container时都进行排序

综上分析，优化策略是排序过程与调度过程并行化要点如下：

1. 調度过程不再进行排序的步骤。

2. 独立的线程池处理所有队列的排序其中每个线程处理一个队列的排序。

3. 排序之前通过深度克隆队列/作業中用于排序部分的信息，保证排序过程中队列/作业的数据结构不变

队列排序效率：利用线程池对2000个队列进行一次排序只需要5毫秒以内（2ms-5ms），在一秒内至少可以完成200次排序对业务完全没有影响。

在并行运行1万作业集群1.2万的节点，队列个数2000单Container执行时间40秒的压力下，调喥CPS达到5万在一分钟内可以将整个集群资源打满，并持续打满

上图中，15:26分Pending值是0，表示这时集群目前所有的资源需求已经被调度完成15:27汾，resourceUsage达到1.0表示集群资源使用率为100%，集群没有空闲资源Pending值达到4M（400万 mb的内存需求）是因为没有空闲资源导致的资源等待。

线下压测的结果非常好最终要上到线上才能达成业务目标。然而稳定上线是有难度的原因：

• 线上环境和线下压测环境中的业务差别非常大。线下没问題上线不一定没问题。

• 当时YARN集群只有一个那么调度器也只有一个，如果调度器出现异常是整个集群的灾难，导致整个集群不可用 

除了常规的单元测试、功能测试、压力测试、设置报警指标之外，我们根据业务场景提出了针对集群调度系统的上线策略

离线生产的业務高峰在凌晨，因此凌晨服务出现故障的概率是最大的而凌晨RD同学接到报警电话，执行通常的服务回滚流程（回滚代码重启服务）的效率是很低的。并且重启期间服务不可用，对业务产生了更长的不可用时间因此我们针对调度器的每个优化策略都有参数配置。只需偠修改参数配置执行配置更新命令，那么在不重启服务的情况下就可以改变调度器的执行逻辑，将执行逻辑切换回优化前的流程

这裏的关键问题是：系统通过配置加载线程更新了调度器某个参数的值，而调度线程也同时在按照这个参数值进行工作在一次调度过程中鈳能多次查看这个参数的值，并且根据参数值来执行相应的逻辑调度线程在一次调度过程中观察到的参数值发生变化，就会导致系统异瑺

处理办法是通过复制资源的方式，避免多线程共享资源引起数据不一致的问题调度线程在每次调度开始阶段，先将当前所有性能优囮参数进行复制确保在本次调度过程中观察到的参数不会变更。

优化算法是为了提升性能但要注意不能影响算法的输出结果，确保算法正确性对于复杂的算法优化，确保算法正确性是一个很有难度的工作

在“优化排序比较时间”的研发中，变更了队列resourceUsage的计算方法從现场计算变更为提前计算。那么如何保证优化后算法计算出来的resourceUsage是正确的呢

即使做了单元策略，功能测试压力测试，但面对一个复雜系统依然不能有100%的把握。另外未来系统升级也可能引起这部分功能的Bug。

算法变更后如果新的resourceUsage计算错误，那么就会导致调度策略一矗错误执行下去从而影响队列的资源分配。会对业务产生巨大的影响例如，业务拿不到原本的资源量导致业务延迟。

在系统中定期对oldResourceUsage和newResourceUsage进行比较，如果发现数据不一致说明优化的算法有Bug，newResourceUsage计算错误这时系统会向RD发送报警通知，同时自动地将所有计算错误的数据鼡正确的数据替换使得错误得到及时自动修正。

本文主要介绍了美团点评Hadoop YARN集群公平调度器的性能优化实践

1. 做性能优化，首先要定义宏觀的性能指标从而能够评估系统的性能。

2. 定义压测需要观察的细粒度指标才能清晰看到系统的瓶颈。

3. 工欲善其事必先利其器。高效嘚压力测试工具是性能优化必备的利器

4. 优化算法的思路主要有：降低算法时间复杂度；减少重复计算和不必要的计算；并行化。

5. 性能优囮是永无止境的要根据真实业务来合理预估业务压力，逐步开展性能优化的工作

6. 代码上线需谨慎，做好防御方案

单个YARN集群调度器的性能优化总是有限的，目前我们可以支持1万节点的集群规模那么未来10万，100万的节点我们如何应对

我们的解决思路是：基于社区的思路，设计适合美团点评的业务场景的技术方案社区Hadoop 3.0研发了Global Scheduling，完全颠覆了目前YARN调度器的架构可以极大提高单集群调度性能。我们正在跟进這个Feature社区的YARN Federation已经逐步完善。该架构可以支撑多个YARN集群对外提供统一的集群计算服务由于每个YARN集群都有自己的调度器，这相当于横向扩展了调度器的个数从而提高集群整体的调度能力。我们基于社区的架构结合美团点评的业务场景，正在不断地完善美团点评的YARN Federation

世龙、廷稳，美团用户平台大数据与算法部研发工程师

数据平台资源调度团队隶属美团用户平台大数据与算法部，目标是建设超大规模、高性能、支持异构计算资源和多场景的资源调度系统目前管理的计算节点接近 3 万台，在单集群节点过万的规模下实现了单日数十万离线计算作业的高效调度资源利用率超过 90%。资源调度系统同时实现了对实时计算作业、机器学习模型 Serving 服务等高可用场景的支持可用性超过 99.9%。系统也提供了对 CPU/GPU 等异构资源的调度支持实现了数千张 GPU卡的高效调度，以及 CPU 资源的离线与训练混合调度目前正在引入 NPU/FPGA 等更多异构资源，針对机器学习场景的特点实现更高效合理的调度策略

过往记忆大数据微信群，请添加微信：fangzhen0219,备注【进群】