分享嘉宾：涂瑜 小米 高级软件开发工程师
编辑整理：杨旗 陕西理工大学
出品平台：DataFunTalk
导读：大数据技术的应用已经在各行各业都比较成熟了，基于Hadoop Yarn的调度和资源管理在离线以及在线方面有着举足轻重的地位。本文将分享Hadoop Yarn在小米内部的实践。
今天的分享会围绕以下几点展开：
- 调度优化实践
- 资源优化实践
- Yarn扩展性与其他优化
- Yarn元仓建设
- 未来规划
01调度优化实践
目前小米国内及海外已拥有20+个集群，其中最大的集群节点数已达6000+，最大单集群队列数量也已经达到了1000+。接下来基于目前Hadoop Yarn在小米内部的实践经验，分享一下各个方面所做出的优化。
首先来看一下使用过程中存在的一些问题。
1. 问题修复
（1）节点资源更新导致调度卡顿问题
在平时使用过程中，有时会遇到调度卡顿的现象。定位发现在ResouceManager收到 Nodemanager资源上报时会触发队列资源更新，队列资源更新过程中会获取锁，并且这个锁同时也会在调度线程线程中被使用。此时，如果 ResourceManager 内部队列数量过多，会出现队列资源更新耗时过长导致长时间占有该锁，进一步导致调度性能下降。
目前小米内部针对该情况，采用的优化方式是当节点上报资源时，不直接触发队列资源更新，而是基于异步批量更新的策略，该策略可以缓解短时间大量节点心跳上报或节点频繁上下线导致的调度性能下降问题。
（2）Global Scheduler多线程调度崩溃
小米内部Hadoop Yarn版本是 3.1.0，调度器使用Capacity Scheduler并且开启多线程，在社区该模式也称为 Global Scheduler。Global Scheduler调度模型会存在多个调度线程和一个仲裁线程。在使用Global Scheduler 过程中发现有时候会出现因为调度线程崩溃导致 ResourceManger 调度持续hang住的问题，并且不会进行自我恢复，导致ResourceManger长时间不做任何资源分配，严重影响业务。
通过异常排查定位，发现在队列的排序过程中会因为不满足 JDK TimeSort 算法对于数据的约束从而抛出异常导致线程崩溃。具体的流程是：调度线程在进行队列排序时不会对整颗队列树加锁并且会将分配成功的结果写入backlogs，仲裁线程通过backlogs获取调度线程分配的结果，尝试对分配结果进行apply，当app和queue apply 成功之后会加写锁，更新对应队列资源。但是这个资源更新发生在调度线程对队列排序过程中有概率会打破TimeSort算法对于数据的要求（自反性、传递性和对称性），导致调度线程的崩溃，进一步导致ResourceManger无法响应调度需求。
目前两种解决方法：
第一种会使用legacyMergeSort去替换TimeSort，这种方式比较简单，直接在 JVM 启动时注入一个配置项-Djava.util.Arrays.userLegacyMergeSort=true解决；
第二种是在调度线程进行调度时不使用原始的队列结构，而是使用深拷贝的形式将队列中的数据拷贝一份，通过拷贝后的数据进行排序，这种情况下，仲裁线程对队列的 apply就不会影响到整个队列的排序。关于这个问题可以看看内部推给社区的YARN-10178这个issue，其中也描述了定位的过程以及讨论的解决方案。
（3）ResourceLimit计算逻辑导致调度性能问题
在调度线程进行队列调度时，会获取其可使用资源配额ResourceLimit，通过Resource.min基于当前集群层面和队列层面max capacity资源配额，计算得到当前队列能使用的最大资源量。Resource.min基于DRF算法再考虑多纬资源类型情况下返回主导资源中权重较大的值。当前小米内部考虑内存和CPU多维资源。通过 Resource.min基于主导资源计算返回的 ResourceLimit 会出现调度线程能通过资源判断校验，但是仲裁线程中提交失败的情况。
用一个实际的例子来解释这种情况：存在一个队列A，资源为<60G, 100core>，其子队列A1的资源为<5G, 100core>，A2的资源为<40G, 70core>。此时对A2队列分配了一个<30G, 1core>的一个资源，此时队列的资源就变成了A<30G, 99core>，A1<5G, 100core>，A2<10G, 69core>。这种情况下如果尝试给A1分配一个<10G, 1core>的资源请求，正常情况下，因为A1的max capcity是<5GB, 100core>，从理解上来讲应该在调度线程尝试调度时因资源检测失败直接拒绝该队列的资源分配。但是由于Resource.min基于DRF算法选择 CPU 为主导资源进行计算，最终会返回<30G, 99core>的ResourceLimit，导致调度线程在尝试分配<10G, 1core>的资源时因小于 ResourceLimit 通过校验写入backlogs。仲裁线程会获取backlogs中的 commit进行apply，由于仲裁线程会严格比较各纬度资源，所以在apply过程中就会因为申请的资源<10G, 1core>大于A1队列的 max 资源<5G, 100core> 失败，产生大量的Failed to accept this proposal 错误严重影响调度性能。
目前在小米内部针对这种情况，再获取ResourceLimit时通过Resources.componentwiseMin函数获取各项资源的最小值，这样可以在调度线程中针对资源配比拒绝掉不合理的请求。关于这个问题可以参考YARN-11083这个issue，其中也描述了定位的过程以及讨论的解决方案。
介绍完使用过程中遇到的问题及对应解决方案后，接下来介绍小米内部针对Hadoop Yarn所做的性能优化。
2. 性能优化
（1）跳过userlimit计算逻辑
因为在小米内部场景中针对单个队列内多用户之间的资源隔离的需求并不是很多，而userlimit的计算逻辑是嵌入在整个调度流程当中，会产生大量的无效计算导致调度效率不高。目前小米内部采取的优化手段是在涉及配置加载重构整个队列树的时候，基于minimum-user-limit-percent以及userlimit-factor这两个参数和队列的资源量计算出一个值，通过该值判断队列内部是否需要用户级别的隔离，如果不需要，会直接在涉及对应队列的调度流程中将userlimit计算跳过避免大量的无效计算逻辑去计算userlimit的操作。
（2）单次分配多个container
Hadoop Yarn的调度原理是先基于队列的排序，在进行各层级的排序后会最后会选择最优的一个container进行调度，如果队列数过多就会产生大量的排序操作，同时也因为在小米内部集群规模比较大，所以可以接受放弃一定的公平性来提升集群的调度性能。另外虽然Capacity Scheduler调度策略内部使用公平算法去进行分配，但并不是绝对的公平。所以目前在小米内部使用的优化策略是调度策略选择出子队列后，尝试分配多个container，去提升单位时间分配的container数量。
（3）效果
小结：平时遇到的问题主要分为性能&功能两大类，首先会定位具体原因，明确具体问题，后根据社区进度以及基于小米内部业务场景进行优化或者修复，来满足小米内部大规模集群下调度的需求。
