大规模HDFS离线计算集群的架构演进与存储治理实践-赵永祥

1 .vivo离线HDFS集群的架构演进及存储治理实践 主讲人 – vivo互联网 大数据专家 赵永祥 

2 .vivo HDFS集群的发展之路 2021.04 2022.02 2022.11 2023.10 启动3.x大版本升级 完成3.x大版本升级 联邦&EC稳定上线 存储治理取得阶段性成果 版本落后于社区较多 离线主集群规模近万台 引入联邦机制建设冷热共享DN 大规模推广EC/ZSTD等技术， 较多新特性/优化没有 涉及12个region EC特性基本稳定，试用业务的 节约160PB+存储空间 数据0丢失/损坏 数据性能/安全性满足要求 业务全程无感知 

3 .01 HDFS 3.x 大版本升级 

4 .升级背景 现状 HDFS 3.0带来了什么？ 目前平台的Hadoop集群 存储空间 性能 运维成本 的版本已经落后于社区 较多版本，且有很多的 EC码可节约50%的存储空间， 大量的Bug修复和代码优化 Router Based Federation 新特性，新优化均没有 用于冷备数据 Standby NameNode一致性读 More than 2 NameNodes 

5 .挑战 1 严格的上线标准 2 集群规模庞大 数据一致性校验 升级的离线数仓集群涉及12个Region(近万台机器) 性能测试 逐台滚动升级，并且要求业务全程无感知 兼容性测试 完备的升级/降级/回滚方案 

6 .NameNodeLayoutVersion 滚动升级/降级/回滚的完整演练 start JN SNN/ZKFC SNN/ZKFC DN DONE NameNode主备倒换 1. 2.0已有的优化打入 2. 高版本的Critical/Major级别patch打入 3. 关键代码流程深入分析 (NameNodeLayoutVersion兼容范围 可以按需调整) 4. 5轮 升级/降级/回滚演练 

7 .数据一致性校验 & RPC性能测试 数据一致性校验 fsck工具检查升级后的文件系统是否有丢块 Spark程序批量比对大目录的MD5值 RPC性能测试 官方工具Dynamometer NNBench Hive动态分区 通过回放审计日志来做性能压测 测试简单 RPC种类比较丰富 架构复杂，测试成本高 RPC种类过于单一 可以达到线上峰值的量(110万/min) 测试成本低 

8 .兼容性测试 组件 Client MR / Hive / Spark / Flink 最复杂的集群场景 Distcp / Druid / Kylin / Presto • 2.x • 升级中3.x / • 升级完成的3.x 场景 ViewFS 大量小文件 少量大文件 文件&压缩格式 /user /data /tmp Orc + snappy / Orc + lzo Parquet + snappy / Orc + zlib 2.x集群 升级中的3.x 升级完成的 集群 3.x集群 

9 .升级结果 升级结果 近万台机器/12个region的集群在11个月内完成全部升级 全程数据0丢失/损坏，业务无感知 RPC性能指标不差于2.0版本 总结文章：<< vivo万台规模HDFS集群升级HDFS3.x实践>> // https://mp.weixin.qq.com/s/MReYEmPB8LKo8L4WESIcFA 兼容性情况 组件 版本 兼容性情况 Spark 2.x 3.x 正常 Yarn/MR 2.x 正常 HDFS Client 2.x 正常 Flink 1.13.x 正常 Hive 1.x 正常 

10 .02 HDFS架构优化 & DN 读写性能优化 

11 .原HDFS集群架构 Hive/Spark HMS 1. 冷备集群/离线主集群版本不统一 冷备3.0 YARN 2.0 YARN 2. 需维护两套YARN集群，冷备集群计算资源闲置 viewFS 3. 业务使用冷备不方便 4. 各region之间DN的存储资源使用不均衡 3.0 HDFS 3.0 HDFS 3.0 HDFS 冷备3.0 HDFS region 1 region 2 region N 5. 冷备集群EC版本不稳定 Distcp 冷备集群 离线计算主集群 

12 .优化后HDFS集群架构 Hive/Spark HMS 2.0 YARN 1. 合并冷/热两套集群为一套集群 2. 引入联邦机制, 提高DN的存储资源利用率 viewFS 3. 原地冷备,不需要迁移数据 4. 冷热分层, 降低存储成本 region 1 region 2 region 3 region N 5. EC版本更稳定 NN NN NN NN 离线计算主集群 DNs DNs DNs DNs 热共享DN (DISK) Federation 冷共享DN (ARCHIVE) 

13 .DN读写性能优化 随着HDFS集群规模越来越大，业务越来越多，经常会有业务反馈DN读写性能存在瓶颈 一. 慢节点剔除 二. 优化DN锁 三. 减少IO访问 通过DN统计写入慢的节点,并上报至 排他锁改为读写锁 delete block时在代码上剔除非必 NN汇总处理 更细粒度(BlockPool/Volume级别) 要的toURI接口调用，在I/O负载 锁在跟进中 比较高的DN节点效果很明显 实际效果未达预期 四. DirectoryScanner 五. 使用外部Shuffle服务 六. 存算I/O隔离 参数优化 降低计算任务对磁盘I/O的占用 共享DN(存算混部)对NM/DN的盘做 扫描限速 & 降低扫描频率 隔离 

14 .03 HDFS 存储治理 

15 .存储治理 存储面临的问题 目前线上 HDFS 集群机器数已经超过万台，数据总存储成本高，每年新增数据大，亟需进行治理 解决的方法 • Erasure Coding • 更高压缩比的算法（例如：ZSTD/ZLIB） • 生命周期管理 • 数据冷热分层 • 成本更低的硬件/架构 

16 .Erasure Coding原理 对 k 份原始数据进行纠错编码得到 m 份冗余数据，当数据丢失不多于 m 份时，通过剩余数据可恢复原始数 据。EC有多种实现，目前HDFS使用的是Reed-Solomon编码。 cell1 cell2 cell3 cell4 cell5 cell6 parity1 parity2 parity3 stripe 跟三副本对比 三副本 EC k=6 m=3 存储冗余 200% 50% 容忍DN宕机 2台 3台 前向纠错编码 

17 .遇到的问题 一. 文件损坏问题 二. 损坏文件修复 三. EC补块逻辑 代码存在Bug，导致补块时内存 利用Hive的orcfiledump命令， EC补块这部分代码逻辑Bug有点 被覆盖 再结合定制的HDFS Client修复 多，不过社区基本已经都修复， HDFS-15240 目前版本稳定 HDFS-14946 HDFS-14768 HDFS-14920 HDFS-14186 HDFS-15798 HDFS-14353 四. NN内存上涨 五. DN下线慢 HDFS-16182 HDFS-16839: 补块时没有考虑 需要打入补丁：HDFS-14854 EC补块任务的负载,导致补不出 并行下线 去 

18 .Erasure Coding 读性能测试 Spark任务测试 Caas任务测试 Spark任务 三副本任务耗时 EC任务耗时 差异 Caas任务 三副本任务耗时 EC任务耗时 差异 任务1 5小时5分14秒 5小时14分15秒 +8 min 第一次测试 7小时60分 6小时57分 -63 min 任务2 2小时38分31秒 2小时34分4秒 -4 min 第二次测试 7小时32分 6小时38分 -54 min 任务3 4小时29分56秒 4小时36分45秒 +7 min 第三次测试 6小时56分 7小时5分 +9 min 任务4 6小时7分6秒 6小时12分5秒 +5 min 第四次测试 7小时7分 6小时24分 -43 min 任务5 2小时24分10秒 2小时40分28秒 +16 min 测试结论: Caas任务EC性能稍优 测试结论: Spark任务三副本/EC差距不大 TensorFlow任务读性能测试 单机大量读性能测试 单机128线程 单机128线程 数据量: 920GB 数据量: 920GB EC目录相比三副本目录有30%的性能降低 EC目录相比三副本目录有15%的性能降低 

19 .Erasure Coding 写性能测试 写性能测试 文件大小 EC写入时间 三副本写入时间 测试集群配置： DN数量：9 128M 938ms 258ms 机器型号：2018H1-B1 256M 1774ms 503ms 384M 2681ms 770ms 测试方法： 512M 3413ms 979ms 每种文件大小的写入测试， 640M 4424ms 1254ms 重复30次，取平均值 768M 5096ms 1515ms 1536M 9949ms 3086ms 2304M 15021ms 4552ms 3072M 21052ms 6286ms 3840M 25110ms 7842ms 4608M 31097ms 9392ms 5376M 36360ms 11079ms 

20 .Erasure Coding落地场景 平台在后台转EC 1. 2023年新增EC总量100PB+ Hive库表 Hive库表（EC） 2. EC占总存储比例约22% APP目录 APP目录（EC） 开发目录全量EC 临时数据EC 

21 .ZSTD ZSTD是Facebook在2016年开源的新无损压缩算法，有着突出的压缩率和 压缩/解压缩性能表现 官方参考测试数据 平台实际测试数据 业务实际测试数据 

22 .压缩测试结论 & 值班的版本 测试结论 1. ZSTD在压缩比/压缩解压缩性能方面表现最优 2. ZSTD/ZLIB压缩比差距不大 3. ZSTD/ZLIB相较SNAPPY在压缩比方面有20～30%的收益 4. 具体比例还会依赖业务数据属性(训练平台的数据ZSTD收益较高 (相较GZIP)) 支持的组件 & 版本 组件 版本 备注 Spark 3.x 可以使用Hadoop或Spark自带Codec Spark 2.x ORC文件可以用Spark自带Codec Flink 1.13.x 移植至Hadoop 2.x (HADOOP-13578)，用Hadoop Codec MapReduce 2.x 移植至Hadoop 2.x (HADOOP-13578)，用Hadoop Codec Hive 1.x 不支持 

23 .数据现状 & 解决方案 离线服务的现状 离线任务ZLIB压缩测试 1. 80% 的离线任务是Spark任务 任务 任务类型 SNAPPY压缩 ZLIB压缩 2. >50% 的数据量产出方仍然是Hive任务 任务1 Hive(产出) 10分17秒 10分22秒 3. 大量的表使用的还是SNAPPY压缩 任务2 Spark(产出) 39分25秒 42分40秒 任务3 Hive(产出) 1小时6分59秒 1小时10分39秒 解决方案 任务4 Hive(产出) 49分24秒 47分53秒 场景 方案 任务5 Spark(产出) 1小时48分58秒 1小时42分49秒 增量数据 & 版本支持 SNAPPY -> ZSTD 测试结论: Spark/Hive任务数据从SNAPPY切换为ZLIB后, 任务运行时长差距不大 增量数据 & 版本不支持 SNAPPY -> ZLIB 存量数据 后台SNAPPY->ZSTD/ZLIB EC + ZSTD/ZLIB 节约存储160PB+ 

24 .HDFS未来的探索 一. 数据迁移的优化 & 更方便的横向元数据扩展 二. Erasure Coding的进一步覆盖 & 尝试更低冗余的EC编码 三. 数据冷热自动分层 四. 更低成本的机器引入 五. 统一存储的建设(POSIX API/S3 API) 

25 .