• 软件:1160
  • 资讯:41590|
  • 收录网站:97880|

IT精英团

58同城Hadoop2.6升级3.2实践

58同城Hadoop2.6升级3.2实践

浏览次数:
评论次数:
编辑: 温瑜
信息来源: ITPUB
更新日期: 2021-06-04 16:30:25
摘要

导读Hadoop3已经发布了多个稳定版本,最新版本为3.3.0,Hadoop3.x中增加了很多特性和重大改进。在HDFS方面,最主要是EC能力成熟,显著降低HDFS数据存储成本。在Yarn层面,支持多集群Federation,可以有效利用多YARN集群空闲资源,达到降本增效的目标。此外,还有大量其他" />

-->
  • 资讯详情

导读

Hadoop3已经发布了几个稳定的版本,最新的版本是3.3.0,Hadoop3.x增加了很多特性和显著的改进。在HDFS,最重要的是EC成熟,显著降低了HDFS的数据存储成本。在纱层,支持多簇联盟可以有效利用多纱簇的闲置资源,达到降低成本、提高效率的目的。此外,还有很多其他新功能,可以有效提高集群的稳定性和效率,降低运营成本。

升级背景

以上是同城58个数据平台的架构。可以看出,Hadoop(包括HDFS和纱)作为58个数据平台最基础、最核心的组件,承载着58个离线数据存储和计算资源的调度。

本文将从HDFS/纱线/MR3三个层面来阐述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还有很多未知的风险,还有很多工作需要调查和梳理。我们重点关注以下五个方面:

NN元数据兼容性:保证升级过程中如果主服务升级失败,可以降级到旧版本,这里的元数据包括FSImage和EditLog。为了解决从2.6.0到3.2.1的元数据兼容性问题,我们回滚了HDFS-14831中描述的问题。

DN布局版本兼容性:DN新旧版本之间的布局版本不能变化太大,需要兼容,以保证DN在升级过程中遇到问题可以降级回旧版本。但从2.6.0到3.2.1,DN上块存储的目录结构从256x256变为32x32目录,解决了在Ext4文件系统中DN使用256x256目录存储块的性能问题。为了兼容,我们回滚了此提交。

客户端界面兼容性:因为HDFS被太多组件(Mr/spark/blink/kylin/flu/druid等)使用。),每个组件的HDFS客户端同步升级工作量太大,所以我们只选择升级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方向研发工程师。


部门简介:TEG-大数据部-数据平台部负责58数据中台的大数据基础平台能力的建设,拥有单集群5000+的Hadoop集群,日万亿级实时数据分发,PB级存储等,招聘大数据架构方向相关职位(HDFS/HBase/YARN/Spark/Presto/Flink/Kafak/Clickhouse/Druid/Kylin等)
一篇文章带你了解MySQL执行计划
« 上一篇
返回列表
下一篇 »
发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表
你会是第一个来这里评论的人吗?
最近发布资讯
更多