HDFSEC在滴滴的实践

桔妹导读&＃xff1a;HDFS中默认的3副本方案在存储空间和其他资源&＃xff08;例如网络带宽&＃xff09;上有200&＃xff05;的开销。对于冷数据&＃xff0c;使用纠删码&＃xff08;ErasureCoding&＃xff0c;EC&＃xff09;存储代替副本存储是一种非常不错的替代方案。EC存储在保证容错能力不低于副本存储的同时&＃xff0c;有着更低的存储空间消耗。HDFS EC在滴滴内部稳定落地已超过半年&＃xff0c;为公司节约了大量的存储成本。本文将介绍EC在滴滴内部的实践情况。

1. 

EC原理 

▍1. EC算法

EC是一种编码容错技术&＃xff0c;最早用于通信行业数据传输中的数据恢复。Hadoop3.0版本将EC加入到HDFS中。这里简要介绍EC中使用广泛的两个算法&＃xff1a;XOR Codes与Reed-Solomon Codes。

• XOR Codes

XOR编码即“异或”编码&＃xff0c;其原理是&＃xff1a;数据编码时按照位进行异或运算&＃xff0c;数据解码&＃xff08;数据恢复&＃xff09;时则通过结果与其他数据位进行异或操作。这里&＃xff0c;我们不妨抽象成数学运算用于解释&＃xff0c;例如&＃xff1a;1 ⊕ 1 &＃61; 0 中&＃xff0c;运算位中的任何一位丢失&＃xff0c;则能通过另外两位计算得出&＃xff0c;但是如果丢失两位则无法恢复。对应到HDFS中&＃xff0c;实现该算法的EC策略是XOR-2-1-1024k&＃xff0c;如果使用XOR编码3个数据块&＃xff0c;则最多能容忍一个数据块丢失。该编码常用于HDFS测试。

• Reed-Solomon Codes

Reed-Solomon Codes缩写为RS码&＃xff0c;使用复杂的线性代数运算来生成多个奇偶校验块&＃xff0c;因此可以容忍多个数据块故障。RS码在使用的时候需指定2个参数RS(n, m)&＃xff0c;n代表的是数据块的数量&＃xff0c;m代表的是校验块的数量&＃xff0c;校验块由数据块编码产生。RS编码的编码与解码原理如图1所示&＃xff08;网络图&＃xff09;。编码时&＃xff0c;利用生成矩阵B&＃xff08;这里选用范德蒙单位矩阵&＃xff09;与数据列向量D的乘积得到信息列向量D&＃43;C&＃xff1b;重构时&＃xff0c;利用现存的信息列向量Survivors与对应的逆矩阵B&＃39;-1 乘积得到原数据列向量D&＃xff0c;从而达到恢复原数据的目的。

图1 RS编码的编码与重构原理

▍2.HDFS EC块布局

先回顾一下3副本存储的连续存储方式&＃xff08;Contiguous Block Layout&＃xff09;&＃xff0c;3副本存储以块&＃xff08;Block&＃xff09;为单位&＃xff0c;会将数据连续写入Block中&＃xff0c;直至达到该Block大小&＃xff08;如128M&＃xff09;再去申请下一个Block&＃xff0c;每个Block会有3个相同数据的副本存于3个DataNode&＃xff08;DN&＃xff09;上。连续存储示意图如图2(a)所示。HDFS EC采用条带条带式存储布局&＃xff08;Striping Block Layout&＃xff09;。条带式存储是以块组&＃xff08;BlockGroup&＃xff09;为单位&＃xff0c;横向式地将数据保存在各个Block上&＃xff0c;同一个Block上的不同分段的数据是不连续的。写完一个块组再申请下一个块组。条带式的存储结构图2(b)所示&＃xff08;图示为RS(6,3)策略下1个BlockGroup布局示意图&＃xff09;。

图2(a) 3副本存储示意图

 图2(b) EC存储示意图

2. 

EC在滴滴的实践

▍1. EC落地工作

为了将EC存储引入生产环境&＃xff0c;我们做了如下的定制和优化。

• 升级NameNode与DataNode到3.2版本

EC是Hadoop3才有的新特性&＃xff0c;因此服务端需要升级。在EC投入生产环境之前&＃xff0c;滴滴内部已经完成了HDFS 2.7版本到3.2版本的滚动升级&＃xff08;不停服务&＃xff0c;对用户无感知&＃xff09;。版本升级的相关总结见「 HDFS3.2升级在滴滴的实践」。

• 定制Hadoop2兼容EC读写客户端

客户端&＃xff08;Client&＃xff09;受到Spark&＃xff0c;Hive&＃xff0c;Flink等很多组件依赖&＃xff0c;目前这些组件还不支持Hadoop3&＃xff0c;因此客户端暂时保持2.7版本不变&＃xff0c;这就要求内部的Hadoop2.7版本客户端要做EC读写兼容。我们将Hadoop3.2中的hadoop-common、hadoop-hdfs、hadoop-hdfs-client 中关于EC读写相关部分移植到Hadoop2.7版本。同时&＃xff0c;RBF部分也需要做相应的兼容工作。这里&＃xff0c;我们展示一些代码举例&＃xff0c;例如&＃xff0c;在hdfs.proto协议和ClientNamenodeProtocol.proto协议中&＃xff0c;我们增加了EC相关字段&＃xff1a;

• 自研转EC系统

目前&＃xff0c;将文件转为EC存储的途径是将文件写入启用EC特性的目录中&＃xff08;社区正在开发更优雅的方式见&＃xff1a;HDFS-14978&＃xff09;。将文件/目录mv到已启用EC的目录不会自动转换存储方式&＃xff0c;只有写操作才会。因此&＃xff0c;通常执行以下步骤来将副本存储方式的文件转EC存储方式&＃xff1a;

为了能够可靠地、高效地将副本文件转EC&＃xff0c;滴滴内部做了如下工作&＃xff1a;

1. 定制distcp工具。在将副本文件转EC文件后&＃xff0c;必须要保证数据一致性。这就要求复制的源和目标文件checksum必须相同。由于存储方式不同&＃xff0c;使用传统的CRC校验方式不能适用于副本文件和EC文件的校准。因此&＃xff0c;定制版本将Hadoop3中的COMPOSITE_CRC校验方式&＃xff08;HDFS-13056&＃xff09;引入到Hadoop2的distcp中供内部使用。

2. 自研转EC系统&＃xff08;Anty系统&＃xff09;用于周期性&＃xff08;或手动&＃xff09;执行转EC作业&＃xff0c;以及统计集群EC文件存储量、占比等信息。具体介绍见后文的实践场景部分。

• 定制离线计算物理空间工具

内部资产平台需要周期性地离线分析整个集群的存储空间用于评估成本。若对每个文件使用du命令将对NameNode产生不小的压力。解析fsimage镜像文件可以得到每个文件的逻辑大小&＃xff0c;副本文件的物理空间计算非常简单&＃xff0c;即逻辑大小 * 副本因子&＃xff1b;EC文件的物理空间由于其条带式存储而复杂许多&＃xff0c;这里简要介绍下计算方法。

考虑到最后一个块组的最后一个strip有两种情况&＃xff08;如图3所示&＃xff09;&＃xff1a;

1. 第一个块的cell写满了&＃xff0c;则校验块cell大小也写满

2. 第一个块的cell只写了k (k

 图3 最后一个strip cell写满情况示意图

为了简化计算&＃xff0c;可以不用考虑有多少个块组&＃xff0c;只关心一共写了多少strip。EC物理存储计算示意图4所示。

图4 EC物理存储计算示意图

部分代码如下所示&＃xff1a;

• FastCopy支持EC文件的改进

由于在Federation集群中会有集群间数据迁移的情况&＃xff0c;在3副本文件场景下FastCopy&＃xff08;HDFS-2139&＃xff09;是一个高效的迁移方案&＃xff0c;其通过将块进行硬链接的方式来达到快速迁移的目的。由于FastCopy不支持EC文件操作&＃xff0c;滴滴内部版本做了FastCopy兼容EC文件的改进&＃xff0c;极大地方便了Federation集群间的数据迁移。

▍2. EC的实践场景 

首先要考虑的是EC策略的选择。通过hdfs ec -listPolicies命令可以列出已经实现的EC策略。各个策略的一些特性如表1所示。

表1 EC策略特性对比

综合考虑&＃xff0c;滴滴内部只开启了RS-6-3-1024k策略。考虑到EC策略目录的规范性&＃xff0c;目前只支持管理员设置EC策略。

实践1&＃xff1a;冷数据转EC存储

国内离线集群已有上百P的逻辑数据&＃xff0c;数据量的增长对集群的存储也带来了一定压力。为了节约存储成本&＃xff0c;滴滴内部对冷数据进行了转EC存储。考虑到并不是所有3副本文件在转EC后都有更少的空间存储&＃xff0c;这里需要对转EC的文件做大小限制。在RS(6,3)策略下&＃xff0c;我们限制待转EC的目录下的非空平均文件大小>&＃61;6M。数据源选择如图5所示。

 图5 转EC文件数据源

转EC存储流程如下&＃xff08;自研Anty系统将自动化完成所有过程&＃xff09;&＃xff1a;

1. 周期性地&＃xff08;每天&＃xff09;从fsimage表中计算出需要转EC的叶子目录

2. 每个目录的转EC、替换原文件操作记为一次pipeline。多个pipeline并行操作进行转EC

3. 每个目录的转EC状态记为该目录的生命周期lifecycle&＃xff0c;生命周期有变化时更新到mysql&＃xff0c;用于前端页面对转EC情况的展示

整个转EC流程如图6所示。

图6 转EC流程图

经过半年多的实践&＃xff0c;生产环境已有大量符合条件的冷数据进行了转EC存储&＃xff0c;整个集群的EC文件存储效率&＃xff08;EC物理存储/EC逻辑存储&＃xff09;在1.500 ~ 1.505之间&＃xff0c;节省了可观的物理空间。

实践2:核心数据跨机房EC备份

为数据容灾考虑&＃xff0c;01机房的核心数据将每天增量地备份到02机房。这种场景非常适合将02机房数据使用EC存储。其备份流程如下&＃xff1a;

1. 通过数据资产平台每天的定时分析&＃xff0c;获得01机房核心增量数据

2. 自研的Anty系统将增量核心数据通过定制的distcp写到02机房存储为EC文件

系统内部细节不再赘述&＃xff0c;整体流程如图7所示。

图7 核心数据跨机房备份流程示意图

▍3.遇到的问题及解决办法

在EC存储落地的过程中&＃xff0c;我们遇到过一些问题&＃xff0c;有些问题社区高版本已经解决&＃xff0c;有些问题我们已提给社区。这里&＃xff0c;我们列举一些典型的问题做简要说明。

• 写EC文件客户端hang住问题

在转EC的过程中&＃xff0c;偶现客户端线程hang住问题。详情见&＃xff08;HDFS-15398&＃xff09;。

• DN下线失败问题

下线过程中&＃xff0c;在某些场景下触发DN下线失败问题。详情见&＃xff08;HDFS-14920、HDFS-14847&＃xff09;。

• DN重构EC块有脏数据问题

DN由于读超时出现NPE&＃xff0c;使用脏数据重构EC块问题。引入&＃xff08;HDFS-15240&＃xff09;解决。

• Standby内存泄露问题

线上出现StandbyNN内存偏高问题。经MAT及监控指标&＃xff08;dfs.FSNamesystem.PendingDataNodeMessageCount&＃xff09;发现PendingDataNodeMessages类存在内存泄露&＃xff0c;如图8。引入&＃xff08;HDFS-14687&＃xff09;解决。

图8 standby PendingDataNodeMessages内存泄露示意图

3. 

总结与展望

相比3副本存储&＃xff0c;EC存储也有一些不足的地方&＃xff0c;如读写性能有损失&＃xff08;滴滴暂未开启intel isa-l加速库&＃xff09;、小文件不适合转EC等。HDFS EC还处于发展的第一阶段&＃xff0c;社区也在持续优化&＃xff0c;滴滴内部也紧跟社区步伐。相信随着HDFS社区的不断发展&＃xff0c;越来越多的公司将受益于EC技术。

参考文献&＃xff1a;

[1] https://issues.apache.org/jira/browse/HDFS-7285

本文作者

▬

团队招聘

▬

滴滴大数据架构部主要负责滴滴大数据存储与计算等引擎的开发与运维工作&＃xff0c;通过持续应用和研发新一代大数据技术&＃xff0c;构建稳定可靠、高性能、低成本的大数据基础设施&＃xff0c;更多赋能业务&＃xff0c;创造更多价值。团队近期招聘:

Flink/ClickHouse/ElasticSearch/HDFS/Presto/融合计算等领域专家&＃xff0c;参与滴滴大数据建设工作&＃xff0c;欢迎加入。可投递简历至

diditech&＃64;didiglobal.com。

扫码了解更多岗位

延伸阅读

▬

内容编辑 | Sherry

联系我们 | DiDiTech&＃64;didiglobal.com