eBay万台规模Hadoop集群3.3 升级实践

伴随着eBay业务的快速发展，eBay Hadoop集群的规模也在不断地扩展来支撑业务的发展。截至目前，eBay Hadoop集群最大集群规模已经达到上万台节点，总数据存储量也已经突破EB级别。

面对如此大体量规模的Hadoop集群，eBay Hadoop team需要做非常多集群优化相关的工作来保证它的性能和稳定性。目前集群主要使用的是基于社区2.7.3的版本来运行的，这个版本发布于2016年，距离现在已经超过8年时间，而且社区早在2018年7月（EOL）就已经宣布不再对2.7系列版本进行维护了。因此我们在过去几年时间里花了非常大的effort去解决里面的各种bug, CVE安全漏洞问题，也做了非常多的定制化改动来提升版本性能。

鉴于社区早已经不再维护这个版本，后期在2.7.3版本里面暴漏出了越来越多的安全漏洞问题，导致我们已经没办法完全去解决这些漏洞问题。另外一方面，Hadoop 2.7.3作为Hadoop 2.x系列里比较老旧的版本，缺少了Hadoop3版本里诸多优秀的功能特性（比如HDFS EC， Consistent-Read功能 和YARN Federation）。因此我们决定将现有eBay Hadoop集群的版本从2.7.3升级到最新社区的3.3.3版本。

本文我们将会详细介绍eBay Hadoop集群升级到3.3版本的实践经验。此次Hadoop集群升级涵盖了非常多的服务组件（包括存储和计算），因此在这里我们会将升级实践分为以下3个小篇章来做阐述介绍：

• 升级准备篇

• 存储升级篇

• 计算升级篇

  
  

最后我们会介绍eBay Hadoop集群升级到3.3版本后的收获总结以及未来展望，如何最大化Hadoop 3.3升级带给我们的好处。

众所周知集群版本升级从来不是一项简单的事情，更何况是目前我们当前新旧Hadoop版本跨度如此之大的一个情况，中间必然会存在许多不兼容的问题。在前期需要尽可能地理清升级之前必须要完成的以及需要去考虑的事情，这里列出有以下相关的事项：

• 解决所有已知Hadoop2和Hadoop3之间的不兼容问题

  
  

• Release出稳定的eBay Hadoop 3.3版本用做正式的集群升级

  
  

• 零停服时间的升级方案

  
  

• 独立于集群升级的解耦式用户升级方案

下面来一一介绍我们对以上相关事项的逐一解决办法。

前期升级准备工作完成之后，后面就正式开始进行集群的升级了。我们此次升级的对象不仅包含存储集群（HDFS）的升级，还包含了计算集群（YARN）的升级，最终的目标是让所有的Hadoop集群以及我们的用户（客户端）都升级到Hadoop 3.3这个版本。

在这一节篇章里面，我们将会主要讨论存储方面的升级。对于数据存储升级而言，数据的完整性和安全性无疑是里面最重要的一块。我们需要确保集群数据在升级前后都能保持完整，并且始终对用户是可读写的状态。

在存储集群升级的过程中，我们重点要去关注和解决用户数据本身前后版本的兼容性问题。经过调研以及实际升级测试，这里有以下几类数据不兼容的问题：

以上就是主要列出的4个不兼容问题，需要在3.3版本里revert掉3个相关commit，另外backport一个社区commit到2.7.3版本。后续我们在实际进行集群升级的过程中，又陆续发现了更多其他类型的问题，包括HDFS Rolling Upgrade过程中的一些行为问题，API层面的不兼容问题以及Hadoop3里新带入的一些问题。

Rolling Upgrade过程中，HDFS为了兼顾rollback的情况，将升级期间deleted的数据临时存放到了DN下的trash目录里（如下图目录），未做到真正的数据删除。

这导致了集群物理使用空间会变得越来越大，需要人工定期去清理DN的trash目录，这在一定程度上复杂化了升级的操作。考虑到我们所采用的Rolling Upgrade方案不会使用到数据rollback的场景，因此我们在代码层面禁用了这个行为，使得升级期间数据删除行为和正常情况一致。

在升级期间，DN里突然出现的坏盘会导致DN处理Rolling Upgrade信息操作出错，从而会中断block key的正常更新，最终DN将无法服务于任何Client的读写操作。

这是社区的一个known issue（HDFS-8893）但是没有最终解决，后续我们在内部版本中进行了异常捕获来避免了这个问题。

NameNode服务在升级到Hadoop3之后，我们发现部分API接口出现了不兼容的问题，主要发生在和Hadoop2 Client之间的不兼容。

Hadoop 3.3 版本相比之前3.2版本包含了很多的改动，其中的部分改动也带来了一些新的问题。

3.3版本中HDFS-13541的改动导致了DataNode SASL QOP存在被篡改的可能性, 这导致了DN在升级到Hadoop3之后出现了时不时数据无法读写的错误。

我们首先检查了本地conf的QOP配置，配置并没有任何问题。我们最终添加了debug的日志定位出出问题的地方在以下的代码逻辑段。

在新版本逻辑中DN会利用client里传来的QOP值做自身SASL QOP的覆盖，它在这里少了关键的QOP校验操作。当有别的老版本的client端发送了一个无效的QOP值后，就会导致DN SASL认证问题。社区有一个类似的issue JIRA（HDFS-16644）但没有最终解决，后来我们在内部版本里添加了开关直接禁用了此逻辑。

Hadoop3的ViewFileSystem里引入了内部cache（HADOOP-15565）来存放它所创建的FileSystem实例。这个功能改变了之前通过调用FileSystem.get(uri, conf)来实际创建FileSystem instance的逻辑，新的API会每次创建新的实例而老的API会复用已创建的实例。这会导致之前没有close FileSystem实例的应用在切换使用Hadoop3的API后会出现instance泄漏问题，最终导致OOM错误（如下图例子所示）。

3.3.3 Hadoop3版本

加载Openssl 3.x失败问题

3.4 NameNode性能问题

3.4.1 Group权限检查问题

3.4.2 Block异步删除问题

前面讲述完存储升级相关的内容后，下半部分我们来重点介绍计算层面的升级。在存储集群升级过程中，我们关注的核心点是数据本身。但是在计算升级里面，我们更关心的是计算引擎和计算逻辑（用户应用）。我们的升级目标是让这些不同类型的计算引擎，计算应用都能够平滑地升级到Hadoop3版本。

回到Hadoop计算升级的本身，它又可以分为Hadoop计算服务（YARN）升级和用户应用（Client）升级，下面来逐一介绍这两部分的升级内容。

YARN服务兼容性问题都和外部状态数据有关，分别是RM node label信息以及NM recovery相关的Container状态数据。

RM服务在升级到Hadoop3之后如果遇到需要downgrade到Hadoop2的场景，会遇到如下错误：

这里需要提前在Hadoop2版本中backport YARN-6143 and YARN-6585的改动来达到和Hadoop3版本的兼容性。

和RM downgrade失败问题类似，NM在升级完之后如果进行回退，也会遇到下面的兼容性错误：

上面错误的意思是说NM做recovery时其leveldb里存的container状态数据无法被老版本NM所识别，这里需要在Hadoop2版本中打入相关的社区改动YARN-5547来保持兼容性。

除了上面的兼容性问题，我们在YARN服务升级过程中还遇到了其他类型的问题。

用户运行环境升级又可细分为集群用户环境升级和平台公共客户端环境升级，这两个环境都属于我们Hadoop team所管理的环境。

1.集群环境升级 - Dynamic Hadoop Runtime

前面上文提过，我们eBay Hadoop集群是一个多租户的统一大集群模式，它是一套共享的Hadoop运行环境。如果直接对slave service做集群升级，实际上会变相将上面所有用户的应用升级到Hadoop3的运行模式，显然这是一个非常简单粗暴且风险极高的升级方法。在升级版本跨度如此之大的情况下，我们需要探索出一种更加平稳的升级方法。

目前行业内大规模Hadoop计算集群直接升级到Hadoop3的实践案例比较少，一种比较容易想到的低风险的升级方法是新搭建出一个Hadoop3集群，然后让用户做workload的迁移来做间接升级。这种升级方法虽然风险低，但是它有两个主要问题：

• 用户升级成本增加，需要自己迁移管理需要升级的应用，不可避免会加长升级的周期

  
  

• 需耗费更多机器资源用于集群升级

  
  

鉴于上述两点无法避免的缺点，我们设计出了dynamic runtime的功能很好地解决了这个问题。这里所说的dynamic runtime指的是动态hadoop执行环境的意思，它的核心作用是将集群服务环境和用户运行环境进行了解耦，以此达到集群服务升级和用户应用升级分离的效果。在这种模式下，用户可以根据自己时间安排来升级他们的应用从Hadoop2到Hadoop3。我们的集群服务也可以不用等全部用户升级完毕，直接先做服务的升级。

下面简单介绍下里面的具体实现细节。首先这里涉及到了多环境（集群环境和用户环境）的概念，因此在集群升级前我们会同时部署Hadoop2的环境和Hadoop3的环境，但是默认用户环境还是指向Hadoop2的环境（如下图所示）。但是我们在这里做了一个开关配置让用户来决定是否使用Hadoop3的环境来做他们应用的升级。如果他们打开了这个开关，他们应用的application classpath路径就会指向hadoop3的路径。

然后第二阶段，我们开始进入集群slave service的升级阶段，集群内会同时拥有Hadoop2的NM和Hadoop3的NM。但是这些不同版本的NM节点都会部署有两套Hadoop运行环境，默认依然是Hadoop2的环境。

最后到第三阶段，我们的集群服务都已经升级到Hadoop3的版本并且此时用户也基本差不多全部升级使用到Hadoop3版本了。这个时候我们就可以将集群运行环境默认指向Hadoop3的环境（即此时的集群服务环境），并且移除掉上面老的Hadoop2环境，最终完成集群和用户环境的Hadoop3升级。

我们在第三阶段切换集群默认环境到Hadoop3的时候，发现依然存在极少数个别用户还未完成升级。为了避免这种因少数未升级用户拖慢集群默认环境切换的情况，我们后来新开发了白名单功能可以让这部分用户能够使用Hadoop2环境，其他用户的默认环境全部指向默认Hadoop3的版本。

另外关于用户hadoop运行环境动态切换的原理，我们实际上是利用了用户应用提交时候传入的yarn.application.classpath路径，在NM启动Container的脚本文件launch_container.sh内对其classpath路径进行解析并做了动态的路径替换。以典型的Spark任务和MR任务为例，他们都可以通过yarn.application.classpath的配置传入他们想要运行的hadoop环境路径(默认情况，此配置和集群是一致的，用户不会主动改)。在我们升级的时候，我们会建议用户在这个配置尾部传入一个升级的tag标签。然后我们在NM这边就能够收到这个带了标签值的classpath值，随后NM会为其替换生成一个新的hadoop classpath路径，NM服务版本不同会导致不同的替换结果。

比如用户传入：

yarn.application.classpath=/apache/hadoop:USE_HADOOP3_CLASSPATH

实际NM Container运行classpath：

CLASSPATH=/apache/hadoop-3.3:USE_HADOOP3_CLASSPATH

2.公共客户端环境升级 - 

双Hadoop Client Runtime模式

另外一种环境是公共客户端的用户环境升级，升级的原则和上面dynamic runtime方案一样，在不改变默认Hadoop版本环境的情况下，通过多部署一套Hadoop版本的方式做环境的升级。最终等用户主动升级完毕，才切换最终默认环境。两套新老版本的环境都会有自己独立的配置，在一定程度上也能有效避免Hadoop2和Hadoop3配置混用的问题。升级过程如下图所示，用户可以通过export HADOOP_HOME环境变量的方式来做Client环境的升级或者回退。

为了能够快速跟踪分析用户应用的升级进度，我们制作了升级进度的dashboard。在这个dashboard里面会展示集群维度的升级总进展以及包括多少比例用户还未开始升级，多少用户已经100%升级完等信息（如下图所示）。

另外我们对用户粒度也做了精细化分析，能够知道每个用户目前还有哪些应用还未升级到Hadoop3的版本（如下图所示）。

这里用户升级的比例信息来源于HDFS audit log里面的记录，我们在audit log里面新加入了Client的本地版本信息，如下所示：

我们通过用户应用对于HDFS集群数据的不同版本访问情况来间接推算出用户升级的进度情况。但是光光有audit log记录信息还不够，假如我们还想知道每个用户job级别的升级情况，我们还需要对job信息表做关联分析。最终我们设计构建了如下图所示的pipeline流程，并且schedule成daily job的形式，每天产生最新的升级进度报表数据展示在我们的dashboard上。

最后是用户升级问题的分析，对于用户应用升级本身而言，它在升级过程中最常遇到的问题总结下来有下面两类问题：

• Client端API的适配问题，比如API语义变了，或者API方法名，参数变了

  
  

• 依赖冲突问题，Hadoop3相比较Hadoop2版本引入了大量的依赖更新

  
  

第一种问题解决起来相对简单一些，用户花比较多时间解决的是第二类问题。依赖冲突问题在日常开发过程中我们经常也会碰到，解决的思路大同小异。首先根据错误信息判断出是哪个dependency jar出现了冲突问题，通过打dependency tree的方式找到是否有其他间接引入的依赖导致了冲突问题，找到依赖冲突源后，进行exclude即可。但是在实际依赖问题的解决过程中，很多时候不是随便随便就能exclude掉一些比较重的dependency依赖的。一方面用户需要去改很多地方来适配dependency的改动，另外一方面新的依赖也不确定会不会有其他潜在的问题。那这个时候有什么好的办法呢？

Hadoop job升级如果遇到这种情况，我们一般推荐用户开启user classpath first的相关属性配置，让应用优先使用自己的依赖jar而不是集群环境提供的依赖jar。下面以Spark和MR job为例：

通过添加以上配置，用户指定的依赖jar将会优先被加载使用。这两个配置的原理比较类似，都是将应用传入的jar classpath路径前置于集群环境的classpath，从而达到优先被加载的效果。

为了能够更快响应用户升级所遇到的问题，我们创建了相应的support channel来进行迅速地沟通解决。另外我们整理了FAQ文档记录了一些常见的升级问题，这样用户可以优先自己通过查询文档来解决他们遇到的问题。

以上就是我们eBay Hadoop集群3.3升级相关的主要内容，当然我们难免会在升级过程中遇到很多Job升级到Hadoop3相关的其它问题，比如Hive shim老版本无法识别Hadoop3版本，部分MR job存在行为不兼容等等。由于本文篇幅有限，没有办法阐述完所有和升级相关的大大小小的问题和细节。

经过一年多左右时间的努力，我们最终将eBay现有Hadoop集群从2.7.3版本全部升级到了3.3版本，在预期时间之内完成了升级的目标。对于集群升级的顺序，我们采取了一种比较渐进式的升级策略。首先从流量不多的小集群开始进行升级，然后到流量大但是workload单一的集群，最终到大流量，多workload的大集群。

在整个升级周期内，我们总共升级了10+集群数，解决了50+与升级相关的各种问题，对130k+的batch job进行了升级，且集群服务无任何停服时间。从集群性能指标上，我们观察到HDFS的RPC处理时间也比升级前提速了大约20%(如下图所示)。另外，Hadoop 3.3版本解决了许多老旧的安全漏洞问题，加强了我们集群的安全运行环境。

Hadoop 3.3升级对于我们团队来说是一项具有挑战性的工程，它要求我们对Hadoop源码层面需要有更深入的理解并且需要有创新性的思维去构建一套完整的升级方案，并且要迎难而上去解决一些从来没有遇到过的问题。