小米Hadoop YARN平滑升级3.1实践

 小米所有业务的离线和流式计算资源都是基于Hadoop YARN进行管理的。

随着业务快速发展，集群规模成倍增长，带来了单集群调度性能和跨机房部署等挑战。

为了更好地应对这些挑战，经过调研我们决定从2.6版本升级到3.1版本和社区保持同步，之后再基于社区在扩展性、性能等方面做的工作进行二次开发

往期文章回顾：小米Talos GC性能调优实践

背景

小米之前生产环境的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版本。由于版本跨度很大，这一步我们做了大量的重构工作，这期间主要通过单元测试来保障代码质量。

我们内部的工作主要集中在以下几个方面：