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企服之家，中国第一个企服评测及商务社交产业平台。