加入收藏 | 设为首页 | 会员中心 | 我要投稿 惠州站长网 (https://www.0752zz.com.cn/)- 办公协同、云通信、物联设备、操作系统、高性能计算!
当前位置: 首页 > 教程 > 正文

Hadoop YARN:调度性能优化实践

发布时间:2019-08-03 14:07:36 所属栏目:教程 来源:世龙、廷稳
导读:副标题#e# 背景 YARN作为Hadoop的资源管理系统,负责Hadoop集群上计算资源的管理和作业调度。 美团的YARN以社区2.7.1版本为基础构建分支。目前在YARN上支撑离线业务、实时业务以及机器学习业务。 离线业务主要运行的是Hive on MapReduce, Spark SQL为主的

这时,从上图中可以明显看到有一条线呈现上升趋势,并且这个指标占了整个调度时间的最大比例。这条线对应的指标含义是确定要调度的作业后,调度器为这个作业分配出一个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. 排序之前,通过深度克隆队列/作业中用于排序部分的信息,保证排序过程中队列/作业的数据结构不变。 

Hadoop YARN:调度性能优化实践

并行排序优化

优化效果如下:

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

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

Hadoop YARN:调度性能优化实践

并发作业数

Hadoop YARN:调度性能优化实践

作业资源需求量

Hadoop YARN:调度性能优化实践

集群资源使用率

上图中,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。

(编辑:惠州站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

推荐文章
    热点阅读