Hadoop YARN：调理性能优化实践15

  配景

YARN作为Hadoop的资源管理体系，负责Hadoop集群上计算资源的管理和作业调理。
美团的YARN以社区2.7.1版本为底子构建分支。目前在YARN上支撑离线业务、及时业务以及机器学习业务。

• 离线业务主要运行的是Hive on MapReduce， Spark SQL为主的数据仓库作业。
  
• 及时业务主要运行Spark Streaming，Flink为主的及时流计算作业。
  
• 机器学习业务主要运行TensorFlow，MXNet，MLX（美团点评自研的大规模机器学习体系）等计算作业。
  

YARN面对高可用、扩展性、稳固性的标题许多。其中扩展性上遇到的最严重的，是集群和业务规模增长带来的调理器性能标题。从业务角度来看，假设集群1000台节点，每个节点提供100个CPU的计算本事。每个任务使用1个CPU，匀称实验时间1分钟。集群在高峰期始终有超过10万CPU的资源需求。集群的调理器匀称每分钟只能调理5万的任务。从分钟级别观察，集群资源使用率是50000/(100*1000)=0.5，那么集群就有50%的计算资源因为调理本事的标题而无法使用。
随着集群规模扩大以及业务量的增长，集群调理本事会随着压力增长而逐渐下降。假设调理本事依然保持稳定，每分钟调理5万个任务，按照5000台节点的规模计算，如果不做任何优化改进，那么集群资源使用率为：50000/(100*5000) = 10%，剩余的90%的机器资源无法被使用起来。
这个标题解决后，集群在有空余资源的情况下，作业资源需求可以快速得到满意，集群的计算资源得到充实地使用。
下文会逐步将Hadoop YARN调理体系的核心模块展开说明，揭开上述性能标题的根本缘故原由，提出体系化的解决方案，最终Hadoop YARN达到支撑单集群万级别节点，支持并发运行数万作业的调理本事。
团体架构

YARN架构

YARN负责作业资源调理，在集群中找到满意业务的资源，帮助作业启动任务，管理作业的生命周期。
YARN详细的架构设计请参考Hadoop官方文档。
资源抽象

YARN在cpu，memory这两个资源维度对集群资源做了抽象。

1. class Resource{
2.   int cpu;   //cpu核心个数
3.   int memory-mb; //内存的MB数
4. }

复制代码

作业向YARN申请资源的哀求是：List[ResourceRequest]

1. class ResourceRequest{
2.   int numContainers; //需要的container个数
3.   Resource capability;//每个container的资源
4. }

复制代码

YARN对作业响应是：List[Container]

1. class Container{
2.   ContainerId containerId; //YARN全局唯一的container标示
3.   Resource capability;  //该container的资源信息
4.   String nodeHttpAddress; //该container可以启动的NodeManager的hostname
5. }

复制代码

YARN调理架构

YARN调理器
名词表明

• ResourceScheduler是YARN的调理器，负责Container的分配。
  
• AsyncDispatcher是单线程的事件分发器，负责向调理器发送调理事件。
  
• ResourceTrackerService是资源跟踪服务，主要负责接收处理NodeManager的心跳信息。
  
• ApplicationMasterService是作业的RPC服务，主要负责接收处理作业的心跳信息。
  
• AppMaster是作业的程序控制器，负责跟YARN交互获取/开释资源。
  

调理流程

• 作业资源申请过程：AppMaster通过心跳告知YARN资源需求(List[ResourceRequest])，并取回上次心跳之后，调理器已经分配好的资源(List[Container])。
  
• 调理器分配资源流程是：Nodemanager心跳触发调理器为该NodeManager分配Container。
  

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

作业的构造方式

在公平调理器中，作业(App)是挂载如下图的树形队列的叶子。

队列结构
核心调理流程

核心调理流程

• 调理器锁住FairScheduler对象，避免核心数据结构辩论。
  
• 调理器选取集群的一个节点(node)，从树形队列的根节点ROOT开始出发，每层队列都会按照公平策略选择一个子队列，最后在叶子队列按照公平策略选择一个App，为这个App在node上找一块适配的资源。
  

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

• 队列预先查抄：查抄队列的资源使用量是否已经超过了队列的Quota
  
• 排序子队列/App：按照公平调理策略，对子队列/App举行排序
  
• 递归调理子队列/App
  

例如，某次调理的路径是ROOT -> ParentQueueA -> LeafQueueA1 -> App11，这次调理会从node上给App11分配Container。
伪代码

1. class FairScheduler{
2.   /* input：NodeId
3.    *  output：Resource 表示分配出来的某个app的一个container的资源量
4.    *  root 是树形队列Queue的根
5.    */
6.   synchronized Resource attemptScheduling(NodeId node){
7.     root.assignContainer(NodeId);
8.   }
9. }
11. class Queue{
12.   Resource assignContainer(NodeId node){
13.     if(! preCheck(node) ) return;  //预先检查
14.       sort(this.children);  //排序
15.     if(this.isParent){
16.       for(Queue q: this.children)
17.         q.assignContainer(node);  //递归调用
18.     }else{
19.       for(App app: this.runnableApps)
20.         app.assignContainer(node);
21.     }
22.   }
23. }
25. class App{
26.   Resource assignContainer(NodeId node){
27.     ......
28.   }
29. }

复制代码

公平调理器架构

公平调理器是一个多线程异步协作的架构，而为了包管调理过程中数据的一致性，在主要的流程中参加了FairScheduler对象锁。其中核心调理流程是单线程实验的。这意味着Container分配是串行的，这是调理器存在性能瓶颈的核心缘故原由。

公平调理器架构

• scheduler Lock：FairScheduler对象锁
  
• AllocationFileLoaderService：负责公平策略设置文件的热加载，更新队列数据结构
  
• Continuous Scheduling Thread：核心调理线程，不绝地实验上节的核心调理流程
  
• Update Thread：更新队列资源需求，实验Container抢占流程等
  
• Scheduler Event Dispatcher Thread: 调理器事件的处理器，处理App新增，App竣事，node新增，node移除等事件
  

性能评估

上文先容了公平调理器的架构，在大规模的业务压力下，这个体系存在性能标题。从应用层的体现看，作业资源需求得不到满意。从体系模块看，多个模块协同工作，每个模块多多少少都存在性能标题。如何评估体系性能已经可以满意线上业务的需求？如何评估体系的业务承载本事？我们需要找到一个体系的性能目标。因此在谈性能优化方案之前，需要先说一说调理体系性能评估方法。
一般来说，在线业务体系的性能是用该体系能够承载的QPS和响应的TP99的延迟时间来评估，而调理体系与在线业务体系不同的是：调理体系的性能不能用RPC（ResourceManager接收NodeManager和AppMaster的RPC哀求）的响应延迟来评估。缘故原由是：这些RPC调用过程跟调理体系的调理过程是异步的，因此不论调理性能多么差，RPC响应险些不受影响。同理，不论RPC响应多么差，调理性能也险些不受影响。
业务指标-有效调理

首先从满意业务需求角度分析调理体系的业务指标。调理体系的业务目标是满意业务资源需求。指标是：有效调理(validSchedule)。在生产情况，只要validSchedule达标，我们就认为目前调理器是满意线上业务需求的。
界说validSchedulePerMin表示某一分钟的调理性能达标的情况。达标值为1，不达标值为0。

1. validPending = min(queuePending, QueueMaxQuota)
2. if  (usage / total  > 90% || validPending == 0):   validSchedulePerMin = 1 //集群资源使用率高于90%，或者集群有效资源需求为0，这时调度器性能达标。
3. if (validPending > 0 &&  usage / total < 90%) : validSchedulePerMin = 0;//集群资源使用率低于90%，并且集群存在有效资源需求，这时调度器性能不达标。

复制代码

• validPending表示集群中作业有效的资源需求量
  
• queuePending表示队列中所有作业的资源需求量
  
• QueueMaxQuota表示该队列资源最大限额
  
• usage表示集群已经使用的资源量
  
• total表示集群总体资源
  

设置90%的缘故原由是：资源池中的每个节点可能都有一小部分资源因为无法满意任何的资源需求，出现的资源碎片标题。这个标题类似linux内存的碎片标题。由于离线作业的任务实验时间非常短，资源很快可以得到回收。在离线计算场景，调理效率的紧张性远远大于更精确地管理集群资源碎片，因此离线调理策略临时没有考虑资源碎片的标题。
validSchedulePerDay表示调理性能每天的达标率。 validSchedulePerDay = ΣvalidSchedulePerMin /1440
目火线上业务规模下，业务指标如下： validSchedulePerMin > 0.9; validSchedulePerDay > 0.99
体系性能指标-每秒调理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的调理过程。
社区提供了开源调理器的压力模拟工具–Scheduler Load Simulater(SLS)。

调理压力模拟器
如上图，左侧是开源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。这造成了巨大的重复计算量。
优化策略：将现场计算优化为提前计算。
提前计算算法：当为某个App分配了一个Container（资源量界说为containerResource），那么递归调整父队列的resourceUsage，让父队列的resourceUsage += containerResource。当开释某个App的一个Container，同样的原理，让父队列resourceUsage -= containerResource。 使用提前计算算法，队列resourceUsage的统计时间复杂度降低到O(1)。
优化效果：排序相干的细粒度指标耗时明显下降。

优化排序比力函数效果
红框中的指标表示每分钟调理器用来做队列/作业排序的时间。从图中可以看出，颠末优化，排序时间从每分钟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时都举行排序。
综上分析，优化策略是排序过程与调理过程并行化。要点如下：

• 调理过程不再举行排序的步骤。
  
• 独立的线程池处理所有队列的排序，其中每个线程处理一个队列的排序。
  
• 排序之前，通过深度克隆队列/作业中用于排序部分的信息，包管排序过程中队列/作业的数据结构稳定。
  

并行排序优化
优化效果如下：
队列排序效率：使用线程池对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计算错误，那么就会导致调理策略一直错误实验下去。从而影响队列的资源分配。会对业务产生巨大的影响。例如，业务拿不到本来的资源量，导致业务延迟。
通过原先现场计算的方式得到的所有队列的resourceUsage肯定是正确的，界说为oldResourceUsage。 算法优化后，通过提前计算的方式得到所有队列的resourceUsage，界说为newResourceUsage。
在体系中，定期对oldResourceUsage和newResourceUsage举行比力，如果发现数据不一致，说明优化的算法有bug，newResourceUsage计算错误。这时体系会向RD发送报警通知，同时自动地将所有计算错误的数据用正确的数据替换，使得错误得到及时自动修正。
总结与将来展望

本文主要先容了美团点评Hadoop YARN集群公平调理器的性能优化实践。

• 做性能优化，首先要界说宏观的性能指标，从而能够评估体系的性能。
  
• 界说压测需要观察的细粒度指标，才气清晰看到体系的瓶颈。
  
• 工欲善其事，必先利其器。高效的压力测试工具是性能优化必备的利器。
  
• 优化算法的思路主要有：降低算法时间复杂度；减少重复计算和不须要的计算；并行化。
  
• 性能优化是永无止境的，要根据真实业务来公道预估业务压力，逐步开展性能优化的工作。
  
• 代码上线需审慎，做好防御方案。
  

单个YARN集群调理器的性能优化总是有限的，目前我们可以支持1万节点的集群规模，那么将来10万，100万的节点我们如何应对？
我们的解决思路是：基于社区的思路，设计适合美团点评的业务场景的技能方案。社区Hadoop 3.0研发了Global Scheduling，完全颠覆了目前YARN调理器的架构，可以极大提高单集群调理性能。我们正在跟进这个Feature。社区的YARN Federation已经逐步美满。该架构可以支撑多个YARN集群对外提供同一的集群计算服务，由于每个YARN集群都有自己的调理器，这相当于横向扩展了调理器的个数，从而提高集群团体的调理本事。我们基于社区的架构，联合美团点评的业务场景，正在不断地美满美团点评的YARN Federation。

from:
Hadoop YARN：调理性能优化实践 - 美团技能团队
日常开辟Guava提效工具库核心实用指南梳理_guava string转list-CSDN博客
异步处理优化：多线程线程池与消息队列的选择与应用_模版模式使用-CSDN博客
接口性能优化宝典：解决性能瓶颈的策略与实践_前端网站页面的搭建-CSDN博客
日常开辟Guava提效工具库核心实用指南梳理_guava string转list-CSDN博客

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。