小米所有业务的离线和流式计算资源都是基于Hadoop YARN进行管理的。随着业务快速发展，集群规模成倍增长，带来了单集群调度性能和跨机房部署等挑战。为了更好地应对这些挑战，经过调研我们决定从2.6版本升级到3.1版本和社区保持同步，之后再基于社区在扩展性、性能等方面做的工作进行二次开发。
背景
小米之前生产环境的Hadoop YARN是基于社区2.6版本修改的内部版本，我们最大规模集群已经数千台，而且还在不断增长。在目前2.6版本，我们主要面临两个问题：
· 滞后社区多个大版本， 很多新特性以及bug修复没法使用或者需要重新开发；
· 集群规模增长很快，经历了多次机房迁移，当前版本不能很好地支持跨机房部署方案来实现作业透明迁移；
我们调研3.1过程中发现，基于YARN Federation(YARN-2915)的跨机房部署方案已经很成熟。同时，为了和社区保持同步，减少代码的维护成本。我们决定升级到Hadoop 3.1（注：在我们开始调研的时候3.2还没release）。
在升级到Hadoop 3.1之后，我们会基于YARN Federation这个特性来落地跨机房部署方案。同时，在3.1版本我们会和社区一起推进落地基于公有云的Auto Scaling方案。
目标与挑战
小米Hadoop YARN在生产环境有数十个集群（包括国内和海外），服务于小米所有业务线，包含大量的批处理和流式计算作业（>10w/天）。本次升级到Hadoop 3.1希望能做到对业务透明，尽量减少对业务的影响：
· 升级期间，不需要停服；
· 升级期间历史作业不失败；
· 升级期间可以持续提交新作业；
· 升级期间，作业日志能够正常查看；
Hadoop YARN的架构组成包括ResourceManager(简写RM)、NodeManager(简写NM)、HistoryServer、ProxyServer等多个组件，这些组件之间需要进行RPC通信，如下图所示：
图1-Hadoop YARN各个组件通信
由于Hadoop YARN组件很多，集群规模也很大，为了控制风险，不能一次性把所有组件都升级到3.1版本。我们面临的挑战是在多个模块不同版本共存的时候，如何保障上层各类计算框架（Spark、Flink、MapReduce等）调度的作业不受影响。
升级过程
>>>> patch合并/重构
之前我们内部一直维护的是基于社区2.6修改的内部版本，我们实现了很多patch来满足业务场景。为了升级到3.1版本，我们首先要做的就是把内部patch合并到社区的3.1版本。由于版本跨度很大，这一步我们做了大量的重构工作，这期间主要通过单元测试来保障代码质量。
我们内部的工作主要集中在以下几个方面：
· 稳定性优化，如基于ZK的client配置管理，实现了RM等服务的平滑迁移(YARN-9605)，NM隔离优化(YARN-9977)，HistoryServer稳定性优化(YARN-9973)等；
· 调度优化，如延时调度，缓存resource usage提升排序效率，事件处理优化(YARN-9979)等；
· 易用性优化，如支持MR作业查看实时jstack信息(YARN-10069)，支持ui kill app，支持MySQL的StateStore等；
· 多集群管理和多租户管理，我们主要进行了资源管理服务产品化，提供统一的infra-client和web化的资源管理（支持计量计费等）；
目前，这些工作已经陆续往社区提交，为我们后续升级版本减轻工作量，同时也希望我们的解决方案能给社区其他成员提供帮助。
>>>> 兼容性/回归测试
前面提到，我们patch合并重构期间主要是通过单元测试来保证代码质量。但是大量patch合并之后，我们必须对整体功能进行完整的回归测试。
同时，在图1中我们看到Hadoop YARN涉及的RPC通信模块很多，版本升级过程中，需要保证各个模块之间通信协议的兼容性。这里，重点讲一下我们如何进行兼容性测试的。
兼容性测试第一块是Hadoop本身各个服务模块之间的通信兼容，主要设计的case如图2所示：
图2-Hadoop YARN组件兼容性测试
当然，兼容性相关还有一个比较重要的测试就是针对计算框架的测试。这里我们主要针对内部使用的如下框架进行了测试：
· Hive 1.2；
· Hadoop MapReduce 2.6/3.1；
· Spark 1.6/2.1/2.3；
· Flink 1.8；
在测试过程，也需要考虑不同版本和不同部署模式的HDFS，比如我们内部有2.6的Federation集群和非Federation集群。另外，考虑到我们目前访问HBase的作业大部分是通过Spark实现，我们主要测试了Spark作业访问HBase的场景。
>>>> 调度器测试
小米之前使用的调度器是基于社区2.6版本修改的FairScheduler。在和社区交流过程发现，社区后续的发展方向主要在CapacityScheduler (YARN-5864)，并且在Hadoop 3.x中CapacityScheduler对调度性能、资源利用率等方面进行了很多优化。所以在升级3.1之后我们有一个比较大的改动是从FairScheduler切换到CapacityScheduler。这里主要面临两个问题：
· 线上生产集群的FairScheduler相关队列配置已经使用了很长一段时间，需要平滑切换到CapacityScheduler；
· 我们的资源管理服务之前是针对FairScheduler设计的，需要对CapacityScheduler进行适配；
其中比较重要的是问题1，这个问题在社区会议的时候提出来了，之后社区也有相关issue跟进(YARN-9698)。我们内部的解决办法是把重要配置进行了梳理，实现一个工具基于FairScheduler的配置自动化地生成对应的CapacityScheduler配置。这里几个比较重要的配置提一下：
maximum-am-resource-percent user-limit-factor intra-queue-preemption.disable_preemption disable_preemption maximum-capacity |
其中user-limit-factor和maximum-am-resource-percent在FairScheduler语义不太一样或者是没有实现。我们针对调度器的测试主要是通过线上FairScheduler配置生成CapacityScheduler配置来启动测试RM，然后进行验证。目前，针对调度器的性能测试我们也探索了SLS工具。
针对CapacityScheduler我们提交了一些patch给社区：YARN-7621，YARN-9748，YARN-9709等。
>>>> 升级/回滚方案
经过上面的单元测试、兼容性测试、调度器测试之后，我们设计和演练了升级方案。最后确定的主要步骤如下：
1、准备好回归测试作业（包括Hive/MR/Spark等），作业类型包含基本的TeraSort、WordCount以及一些用户的作业
2、升级资源管理服务
支持同时更新FairScheduler和CapacityScheduler的配置，当CapacityScheduler出现问题的时候可以直接回滚到FairScheduler
3、升级控制节点（RM/HistoryServer/ProxyServer）
RM主节点使用3.1版本的CapacityScheduler，备节点使用2.6版本的FairScheduler，当调度出现问题的时候，可以做主备切换进行恢复
基于回归测试作业进行验证，同时确认日志查看、主备跳转是否正常
4、升级Hadoop客户端配置和包
升级测试机器，验证回归测试作业是否正常运行
升级监控机器，验证监控作业是否正常运行
分批逐步升级作业调度机器，观察用户作业是否正常运行
5、升级Hive到兼容3.1的版本
部署一个兼容3.1版本的Hive实例，然后验证回归作业和线上部分历史作业
分批逐步升级其他Hive实例，观察用户查询是否正常运行
6、分批升级NM（注：我们修改了2.6版本NM的recovery模块，支持直接从3.1回滚到2.6）
我们会按照5%->25%->50%->75%->100%的灰度策略对NM进行操作
每步更新都会对回归测试作业进行验证
在升级过程中，我们主要通过作业级别、队列级别、集群级别的监控报警来帮助我们及时发现问题。
问题&解决
在升级测试、演练和执行落地过程中，我们遇到一些问题：
>>>> NM回滚2.6版本异常
测试回滚NM的时候，发现如下异常，主要是3.1版本的recovery相关状态多了很多字段
2019-xx-xx,17:06:12,797 FATAL org.apache.hadoop.yarn.server.nodemanager.NodeManager: Error starting NodeManager org.apache.hadoop.service.ServiceStateException: java.io.IOException: Unexpected container state key: ContainerManager/containers/container_e36_1558337587778_0027_01_000002/starttime |
修复办法就是在2.6版本实现类似逻辑或者是直接兼容一下。
>>>> MR RPC协议修改导致作业执行异常
Hadoop Mapreduce在3.1版本针对TaskUmbilicalProtocol做了一些改动，如果是2.6和3.1进行通信，会出现下面问题。这里解决办法是通过在client指定classpath保证单个作业依赖的版本是一致的。
2019-xx-xx 16:49:49,306 WARN [main] org.apache.hadoop.mapred.YarnChild: Exception running child : org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.ipc.RPC$VersionMismatch): Protocol org.apache.hadoop.mapred.TaskUmbilicalProtocol version mismatch. (client = 19, server = 21) |
>>>> FileOutputCommitter版本改变导致数据丢失
FileOutputCommitter在3.1版本增加了新的commit算法，并且默认是不写临时目录了。而在2.6版本，默认的commit算法是先写临时目录最后原子的move到最终输出目录。当NM版本是2.6和3.1共存的时候，我们遇到了Spark作业结果数据比预期少很多的问题。
解决办法很简单，先调整代码的默认算法：
mapred-default.xml:
<name>mapreduce.fileoutputcommitter.algorithm.version</name> <value>1</value> |
FileOutputCommitter:
public static final String FILEOUTPUTCOMMITTER_ALGORITHM_VERSION = "mapreduce.fileoutputcommitter.algorithm.version"; public static final int FILEOUTPUTCOMMITTER_ALGORITHM_VERSION_DEFAULT = 1; |
>>>> 日志配置文件不存在
3.1和2.6在生成launch container脚本的时候对于log目录的设置存在差异。
log4j:ERROR setFile(null,true) call failed. java.io.FileNotFoundException: /home/work/hdd3/yarn/c4prc-preview/nodemanager/application_1559618566050_0070/container_e18_1559618566050_0070_01_000001 (Is a directory) |
>>>> 容量调度器配置不对
容量调度器对于<0,0>的配置是不识别的，并且会直接抛异常导致RM启动失败。
2019-06-25,16:07:19,266 FATAL org.apache.hadoop.yarn.server.resourcemanager.ResourceManager: Error starting ResourceManager java.lang.IllegalArgumentException: Parent queue 'root.production' and child queue 'root.production.xiaoqiang_group' should use either percentage based capacityconfiguration or absolute resource together for label |
当然，还有很多其他问题这里没有展示。部分修复我们已经提交社区比如：(YARN-9693)、(YARN-9689)，后续其他修复我们也会提交社区。
后续计划
2019年我们已经完成了国内外数十个集群的升级，2020年Q1我们会完成最后一个公共集群的升级。从成本和扩展性考虑，我们下一步会在如下几个方向继续探索：
落地Yarn Federation支持超大规模联邦集群，支持同城跨机房部署(>1w台)；
在海外落地基于公有云的Auto Scaling方案(YARN-9548)，系统化地优化公有云集群成本；
探索落地离在线混部的方案，打通在线/离线计算资源；
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
