Hadoop实践 | 58同城Hadoop2.6升级3.2实践
本帖最后由 Mirinda 于 2021-5-31 16:29 编辑问题导读:
1.Hadoop2.6升级3.2的升级背景是什么?
2.HDFS升级包含哪些内容?
3.MR3升级包含哪些内容?
Hadoop3已经发布了多个稳定版本，最新版本为3.3.0，Hadoop3.x中增加了很多特性和重大改进。在HDFS方面，最主要是EC能力成熟，显著降低HDFS数据存储成本。在Yarn层面，支持多集群Federation，可以有效利用多YARN集群空闲资源，达到降本增效的目标。此外，还有大量其他新的特性，有效提高集群的稳定性及效率，降低运营成本。
一、升级背景
以上是58同城数据平台部架构，可以看出，Hadoop（包括HDFS和Yarn）作为58大数据平台最基础最核心的组件，承载了整个58的离线数据存储和计算资源的调度。
本文会从HDFS/Yarn/MR3等3个层面的来说明Hadoop3.2.1在58的升级实践。
二、HDFS升级从2020年初开始，我们就开始推进HDFS的版本升级，并在2020年第二季度，在完成调研、代码整合和兼容性测试后，我们将HDFS从2.6.0-cdh5.4.4升级到了3.2.1。由于我们没有用来升级过渡的小集群，最终直接将我们的离线大集群（5000+规模）HDFS升级到了3.2.1。
1、升级梳理由于我们的现网Hadoop版本为2.6.0，和3.2.1版本之间存在较大的差距，升级HDFS存在较多的未知风险，需要调研梳理的工作比较多，我们从以下5个方面进行了重点梳理：①、NN元数据兼容：保证升级过程中，如果主服务升级失败后可以降级到旧版本，这里的元数据包括FSImage和EditLog。为了解决2.6.0到3.2.1的元数据兼容性问题，我们回滚了HDFS-14831中描述的问题。②、DN布局版本兼容：新旧版本DN之间布局版本不能有太大变化，需要保持兼容，这样才能保证DN在升级时如果遇到问题还能降级回旧版本。但是从2.6.0到3.2.1，DN上的数据块存储目录结构发生变化，从256x256变成了32x32个目录，以解决DN在Ext4文件系统中用256x256个目录存储数据块的性能问题。为了兼容，我们回滚了这个提交。③、Client接口兼容：由于HDFS被太多的组件（MR/Spark/Flink/Kylin/Flume/Druid等）使用，要同步升级每个组件的HDFS Client有太多工作要做，我们最终只选择升级HDFS 后端服务，包括NN/JN/ZKFC/DN。所以需要保证2.6.0的客户端可以正常访问3.x的NN和DN服务。经过梳理测试，2.6.0版本的客户端访问3.2.1版本的服务端是完全兼容的。④、后端交互接口兼容：在升级过程中存在新旧NN/新旧JN/新旧ZKFC/新旧DN等中间状态，这就要保证新旧版本服务之间接口要兼容。经过测试，后端服务的交互接口都是兼容的。⑤、简单高效的升级流程：跨大版本升级也尽可能做到和小版本升级一样的简单，方便运维操作。梳理了HDFS自带的滚动升级流程，发现有一些不方便的地方，比如滚动升级期间会生成一个回滚的FSImage文件，DN端保存删除的数据块等，我们对HDFS自带的滚动升级流程进行了改造，使得HDFS从2.6.0到3.2.1的跨大版本升级流程可以和我们之前在2.6.0的小版本升级一样简单可控。
2、代码整合在Hadoop 2.6.0版本中，我们针对HDFS开发了很多的特性，包括安全体系、NN性能优化，DN IO优化及定制化issue等，我们将这些定制的特性全部整合到了3.2.1版本中。
3、测试由于HDFS跨大版本升级存在较大的难度和风险性，我们进行了尽可能全面的测试，包括：①、Client接口兼容性测试：包括现网全类型任务、全量SQL，以及部分业务核心任务测试；②、滚动升级测试：进行多次滚动升级测试，保证了滚动升/降级中新旧版本NN元数据的兼容性、新旧DN布局版本的兼容性、以及后端服务接口在不同状态的兼容性；③、3.2.1 NN性能测试：在测试环境保持现网配置和现网集群元数据压力情况下，3.2.1版本的NN读写元数据性能可以达到现网性能要求，保证了升级后NN性能不会成为瓶颈。
4、上线我们的HDFS升级分为成了两个阶段：①、主节点升级阶段：升级流程为：JN-->NN-->ZKFC，4组NS升级花了1周多时间，升级整体相对顺利。②、DN升级阶段：在主节点升级完成后，我们在一个月内完成了5000+ DN节点的升级。由于我们简化了滚动升级流程，不需要太多的运维介入操作，使得我们的升级更加简单顺利。在HDFS升级到3.2.1后，我们落地了新版本中的两个重大特性：RBF和EC，并都取得了很好的效果，接下来我们会重点介绍。
5、ViewFS切换到RBF在Hadoop2.6.0版本中，我们使用基于客户端的ViewFS路由来实现多NS的访问，但是随着业务增长，集群规模越来越大，NS越拆越多，基于客户端ViewFS的方式存在以下几个明显缺点：①、挂载表信息非集中式管理，变更维护时很难保证客户端的一致性②、挂载表信息变更时，部分依赖服务需重启才能生效，变更代价大③、ViewFs挂载点不支持挂载到多个集群，在线跨集群迁移数据困难ViewFS架构如下：
从Hadoop 2.9.0版本开始，社区提供了新的解决方案，即RBF，并在最新Hadoop 3.3.0发布版中变得稳定，RBF架构如下：
分析RBF的架构和原理，相对ViewFS存在的优势：①、挂载表信息集中式管理，不存在不一致的情况②、挂载表信息变更实时生效，对服务透明，不用重启服务③、挂载点支持挂载多个集群，数据跨集群在线迁移变得容易④、支持全局Quota，实现联邦模式下的全局Quota管理
想要切换到RBF，必须考虑我们的现网情况，社区并没有从ViewFS透明切换到RBF的解决方案，需要我们自己实现，我们从以下几个方面进行了优化：(1)、用户透明访问RBF为了实现用户访问透明的从ViewFS切换到RBF，我们自定义了两个类：ViewFsRedirectDistributedFileSystem.java类（继承DistributedFileSystem.java类）和ViewFsRedirectHdfs.java类（继承Hdfs.java类），保证了ViewFS请求透明切换到RBF，并通过配置让这两个类来生效：
(2)、自定义写集群策略RBF其中一个强大能力是支持一个挂载点挂载到多个集群，这样使得业务数据能够跨集群存储和数据在线迁移，原生提供了多种写集群选择策略：①、RANDOM：随机选择②、LOCAL：本地优先选择③、HASH_ALL：完全哈希方式选择④、HASH：局部哈希方式选择⑤、SPACE：基于可用空间选择但是以上策略都不能满足我们现网和未来数据迁移的需求，所以我们自定义了两个策略：①、FIRST：挂载点挂载多个集群时，新数据写到第一个集群，数据同时从两个集群访问②、LAST：挂载点挂载多个集群时，新数据写到最后一个集群，数据同时从两个集群访问(3)、重点业务访问隔离对重点业务我们需要做到访问隔离，在切换到RBF后，对所有联邦子集群的HDFS访问请求都会经过Router转发，如果某个子集群响应变慢，进而反压到Router端，会导致通过Router访问其他子集群的请求也受到影响，这增加了上线RBF的风险，我们针对这个风险点也做了一些工作，包括：①、分组管理Router：重点业务使用单独的一组Router，在客户端将重点业务的HDFS请求自动转换到单独的一组Router。客户端配置：
通过以上配置就可以将某个业务对子集群ns1/ns2/ns3，以及默认rbf-ns的请求切换到rbf-x-ns了，rbf-x-ns对应的Router为单独的一组Router。②、对Router服务进行改造，实现和FCQ类似的功能，参考：HDFS-14090(4)、其他优化除了以上三点优化外，我们还对3.2.1版本的RBF进行了若干的优化和BUG修复，包括：①、修复服务认证访问失败BUG②、修复Router不能递客户端IP到NN的BUG（HDFS-16254）③、修复通过Router访问NN，导致NN白名单机制失效BUG④、修复通过Router来创建目录，出现目录权限有误的BUG⑤、挂载表修改时即时更新所有Router（HDFS-13443）⑥、安全模式下拒绝读请求⑦、去掉getDataNodeReport请求：避免对NN造成较大压力⑧、修复UI错误的统计信息等
6、EC落地社区对EC的开发分为两个阶段，第一阶段支持条形布局，以更友好的支持小文件的EC转换，第二阶段支持连续布局。目前第一阶段的功能已经可用，第二阶段还处于规划阶段。我们基于条形布局来落地EC，基于条形布局的EC支持在线文件转换，比如对新写入文件直接转换为EC模式，也支持离线转换，但是考虑到读取EC数据时会有大量的跨节点带宽和EC数据损坏恢复时会消耗更多CPU，我们只使用了离线EC转换方式，也就是只对冷数据进行EC转换。为了落地EC，我们做了以下几项准备工作：(1)、客户端支持EC数据读/写在落地EC时，我们的Hadoop客户端和Yarn集群都是2.6.0版本，需要改造HDFS客户端以支持EC数据读/写。(2)、distcp支持EC数据转换EC一期的实现是基于条形布局的，普通数据块转换为EC模式，需要进行一次数据拷贝，为了快速高效进行数据EC模式转换，我们改造了distcp的实现。(3)、EC文件检验和支持Hadoop 2.6.0版本中没有实现普通文件和EC文件的校验和验证方式，但是数据作为公司最重要的资产，我们在对普通文件转EC时，必须要进行转换文件的校验，以免EC后的数据存在问题。我们使用了社区中HDFS-13056实现的COMPOSITE_CRC方式来对EC模式文件和原文件进行校验和验证，从而来保证EC数据的正确性。(4)、EC自动转换管理平台我们开发了冷数据自动转换EC的管理平台，实现冷数据自动识别和自动执行转换为EC模式文件。
EC落地效果：历史累计冷数据：50P，EC转换后为25P，节省存储空间25P；每季新增冷数据：5P，EC转换后为2.5P，每季度可节省存储空间2.5P。说明：我们冷数据定义为1年以上未访问的数据。
三、Yarn升级由于是跨大版本升级，技术挑战大，存在很多未知风险，我们希望严格遵循以下几个原则来进行相关Yarn升级准备工作：①、对业务完全透明：升级不影响用户现有任务，不影响用户提交新任务；②、兼容所有计算框架：升级保证现有计算框架都能准确执行；③、支持滚动升级/降级：升级有问题，相关服务可以从3.2.1版本降级到2.6.0版本。以下是Yarn个组件的简单架构图：
1、升级梳理
我们按以上5个方面对Yarn升级进行了梳理，保证Yarn升级工作的全面性和准确性。以降低升级风险。①、RM状态数据兼容Yarn本身有一些状态数据，比如app及其相关的attempt信息、token信息、标签和container等信息，状态信息RM端是存储到ZK中的，NM是存储到本地的LevelDB中的，我们升级时要求做到能升级还能降级，所以升级时旧版本状态能否被新版本RM/NM准确识别，降级时新版本RM/NM生成的状态能否被旧版本RM/NM准确识别就至关重要了。Yarn的状态数据兼容要考虑两个方面：数据结构，存储方式（组织方式）。梳理RM状态对应的协议发现，3.2.1新增了很多信息，但是在ProtocolBuffer层面都做了兼容。但是RM状态在ZK中的存储方式发生了变化，3.x版本中app和token状态信息在ZK中使用了更深节点层级关系来存储，社区对应issue为YARN-2962和YARN-7262，为了向前兼容，需要设置参数yarn.resourcemanager.zk-appid-node.split-index和yarn.resourcemanager.zk-delegation-token-node.split-index为0来关闭该功能，好在这两个参数默认值都为0，不需要特殊设置。②、NM状态数据兼容NM中的状态数据以ProtocolBuffer的形式存储到本地的LevelDB中的，3.2.1新增了很多信息，但是在ProtocolBuffer层面也做了兼容。不过由于3.2.1版本NM新增的状态信息，在回滚到2.6.0时会出现NM不识别的key，报错如下：
这部分需要从代码层面做一下兼容，我们修改代码将3.2.1 NM新增的状态信息不保存到LevelDB中，并通过开关控制，这样就避免了该问题，待NM都滚动升级到3.2.1版本并稳定后，再打开开关保存新增状态。③、Client接口兼容考虑到客户端的复杂性，升级Yarn时，我们也只会升级Yarn的服务端，客户端还是保留为2.6.0版本。所以需要保证2.6.0的客户端可以正常访问3.2.1的Yarn后端服务。经过梳理和测试，2.6.0版本的客户端访问3.2.1版本的Yarn服务端是完全兼容的。④、后端交互接口兼容在升级过程中存在新旧RM/新旧NM等中间状态，这就要保证新旧版本服务之间接口兼容。经过测试，后端服务的交互接口都是兼容的。不过2.8.0版本中NM新增了一个注销接口，在停止NM进程时，会导致NM本地的任务也被停掉，该功能是在YARN-41引入的，需要通过配置yarn.nodemanager.recovery.enabled=true和yarn.nodemanager.recovery.supervised=true来避免触发NM的停止注销。同时从2.8.0版本开始，CGroup在计算NM可用内核数时，默认计算的是物理核数，而非按超线程数计算，出现可用核数偏少，导致任务执行时不能充分利用CPU资源，任务执行会变慢，对应为YARN-160，需要将参数yarn.nodemanager.resource.count-logical-processors-as-cores设置为true，这样才能按逻辑内核计算，也就是按超线程来计算NM可用内核数。同时从YARN-668开始，Yarn相关Token的序列化反序列化开始支持ProtocolBuffer，NM从2.6.0滚动升级到3.2.1过程中，会出现兼容性问题，需要回滚该issue的修改，才能保持兼容。⑤、MR接口兼容梳理了MR相关的接口，大部分都是兼容的，但是TaskUmbilicalProtocol协议接口存在兼容性问题，该接口是Map/Reduce子任务和MRAppMaster进程的通信接口，该通信接口的协议基于Writable实现，在滚动升级NM期间，MR的任务在3.2.1版本和2.6.0版本之间通信时存在兼容性问题。如果从服务端做兼容需要进行一次集群升级，而且存在不可控风险，我们最终通过修改Hadoop 2.6.0客户端来保证MR任务classpath在集群中的一致性来解决该问题。对应fad9d7e85b1ba0934ab592daa9d3c9550b2bb501提交和YARN-41中，RM新增了两种NM状态：NS_DECOMMISSIONING/NS_SHUTDOWN，用于维护NM的下线和停止注销状态，这两个状态在RM和MR的MRAppMaster心跳交互时会下发到MRAppMaster端，之前为了解决NM滚动升级期间MR接口兼容问题，我们的MR任务在NM上用的都是2.6.0版本的jar包，导致NM新增的两种状态不能被识别，如果NM出现下线和停止注销的情况，MR任务的MRAppMaster会出现空指针异常并进行任务重试，导致任务重新调度，为了解决这个问题，我们修改了RM端代码，暂时不下发这两种新增的NM状态信息。
2、代码整合在Hadoop 2.6.0版本中，我们针对Yarn进行了很多的优化和改进，包括公平调度的性能优化、公平调度支持标签、调度吞吐CPS指标、任务失败诊断、坏盘检查、任务优先级等，我们将这些重要patch迁移到了3.2.1版本。
3、测试Yarn跨大版本升级存在较大的难度和风险性，虽然进行了全面的梳理，但是也需要进行尽可能全面的测试，测试内容包括：
①、计算框架测试：在客户端为2.6.0版本，Yarn服务端为3.2.1版本情况下，MR/Hive/Spark/Flink，经过测试都是可以正常执行的。②、自研框架测试：我们对公司其他团队自研计算框架也进行了兼容测试，发现存在一些问题，大都在Yarn侧修改兼容，部分需要业务侧调整的，也推进业务进行了调整。③、滚动升级测试：由于我们是从2.6.0版本滚动升级到3.2.1，NM节点会同时存在两个不同的版本，所以需要重点测试NM滚动升级过程中各个计算框架的兼容性。经过测试发现MR/Hive/Spark/Flink都可以正常执行。④、调度性能测试：RM的调度性能至关重要，我们将2.6.0版本中的多个调度性能优化点迁移到了3.2.1版本，保证了3.2.1版本RM的调度性能不会低于2.6.0版本的性能。并经过压测后发现调度性能相比2.6.0有比较大的提升。
4、上线我们的Yarn集群升级也分为成了两个阶段：①、主节点升级阶段：我们先将3个离线集群的RM升级到了3.2.1，到目前已经稳定运行了一段时间。②、NM升级阶段：目前已经将其中一个近千个节点Yarn集群的NM升级到了3.2.1，其他集群正在灰度中。
四、MR3升级MR在3.x版本有很多重大的改进，比如NativeTask，FileOutputCommitter优化等，可以有效提升MR的执行性能。但我们发现要直接使用MR3也存在一些问题。
1、NativeTask不支持Hive任务的序列号/反序列化由于历史原因，我们集群中很大一部分还是Hive任务，为了利用上MR3的NativeTask特性，NativeTask需要支持Hive的序列号/反序列化，为此我们自定义了HivePlatform类来支持，并且修改了相关的本地库代码。
2、MR3透明升级 为了可以及时利用上MR3的各种重大特性和改进，我们希望在Yarn服务端没有完全升级到3.2.1版本的情况下也能用上线MR3，基于这个想法，我们采用了和前面滚动升级NM期间MR解决兼容类似的解决方案，在Hadoop 2.6.0客户端实现将MR3相关的jar包作为classpath在NM中执行，同时将NativeTask中的本地库以分布式缓存方式传递到NM端来实现MR3启用NativeTask特性。通过我们测试对比，基于MR3（开启NativeTask）Hive SQL，平均性能比基于MR2提升了15%以上。
五、展望未来在完成HDFS架构升级到3.2.1后，我们已经成功落地了RBF和EC，并且取得了很好的效果，今年在逐步完成Yarn架构升级后，我们将基于HDFS的内核改造和Yarn的Federation特性来落地Hadoop单集群的跨机房部署，我们也将在未来一段时间逐步开启Hadoop 3.x版本HDFS和Yarn的更多重大特性，享受Hadoop架构升级带来的好处，为公司各业务部门提供更加高效的离线数据存储和资源调度平台，达到降本增效的目标。
六、作者简介良均，鹤铭，丹琦，家成，数据平台部Hadoop方向研发工程师
七、团队介绍 数据平台部负责58数据中台的大数据基础平台能力的建设，拥有单集群5000+的Hadoop集群，日万亿级实时数据分发，PB级存储等，长期招聘大数据架构方向相关职位（HDFS/HBase/YARN/Spark/Presto/Flink/Kafak/Clickhouse/Druid/Kylin等），联系邮箱yuyi03@58.com，注明“大数据架构”。
最新经典文章，欢迎关注公众号http://www.aboutyun.com/data/attachment/forum/201903/18/215536lzpn7n3u7m7u90vm.jpg
原文链接:https://blog.csdn.net/u011598442/article/details/117173931?spm=1001.2014.3001.5501
页:
[1]