HDFS纠删码技术介绍

Posted 2021-04-14 Qiang的杂谈

HDFS三备份存储

众所周知，HDFS为了实现数据的高可用性，将Block复制为三份，按照策略将三份副本存于不同的DataNode和Rack，即使服务器宕机或者磁盘出现问题，NameNode也会从不同的DataNode上获取Client需要的Block，为了trade off性能和风险，第一个副本存放于随机的DN-1上，第二个副本则存放在与DN-1不同机架的DN-2，而第三个副本存放在与DN-2同机架的不同DN-3上。

图1 HDFS三备份存储

优点 & 劣势

当有宕机、磁盘损坏或机架故障时Client端总能得到要读取的数据，这样HDFS就满足了CAP理论中的Availability。

三副本机制带来的不仅是高可用性，同样带来了巨大的数据冗余和一致性问题，存储一份数据就会占用三份存储空间，而更新一份数据也同样要对三份数据进行同步。

随着天量数据的持续增加，集群存储所承载的压力也不断增加，同时带来还有高昂的存储成本，通过不断扩容以存储更多的数据成了互联网公司永恒的话题。

什么是纠删码

Erasure Coding，简称EC，是一种容错编码技术，通过对原始数据生成检验位来达到数据恢复的用途。在保证数据可靠性的前提下，通过只生成校验数据的方法能节省更多的存储空间，从而带来巨大的经济效益。以Reed Solomon（RS被广泛的应用于光盘数据校验和二维码识别）为例，采用RS-6-3的纠删码技术，即：6个单位数据+3个单位校验数据（当任意小于、等于3个单位数据被破坏后，都可以通过剩余6个数据单位进行恢复）。采用三副本时则要占用3 x 6 = 18个单位数据，可见采用了RS-6-3的策略后可节省原来一半的存储开销。在这样的巨大利益背景下，Facebook、Yahoo、Google、Alibaba、EMC、Azure都基于自身的存储系统开发了纠删码功能（Facebook是基于Raid做的，Raid是一种特殊的RS，https://code.fb.com/core-data/saving-capacity-with-hdfs-raid/）。

Reed-Solomon的原理

RS-m-n的编解码定义：RS根据n个数据块（D1、D2、...Dn）生成m个编码块（C1、C2、...Cm），RS算法最多容忍m个数据或编码块丢失并从剩余的n个块中恢复。

数据块恢复流程：

（1）D1、D4、C2数据丢失

（2）等式两边同乘以B'的逆矩阵：B’^-1

（3）由：B’^-1 x B’ = I 推出：

（4）因此，恢复数据：D1、D2、...D5可由如下公式恢复：

注：RS编码一般采用6+3、5+4等策略

纠删码在Hadoop 3.0中的实现

在Facebook等大厂实现了EC功能后，Apache终于开始将EC特性的支持提上了日程，社区将EC特性实现分为两个阶段，在Hadoop 3.0中已经开始支持EC（https://issues.apache.org/jira/browse/HDFS-7285）：

在Hadoop3.0 release文档中也加入了对EC部分的描述。

HDFS EC架构及源码分析

与传统三副本相比（下图7所示），EC的支持对Block的Layout进行了重新设计，一个文件被划为Block Group，原本的128M默认Block Size设计成了更细的Cell，新的Cell的默认大小为1MB，每一行增加了重新计算的检验位（Parity）的Cell同源数据的Cell一并构成了Stripe（条带，下图8所示）。

图7 HDFS默认Block Layout

图8 支持EC的条带式的Block Layout 

• 一个Block Group就是HDFS逻辑上的一个文件；

• 将每个Block分为Cell，Cell默认的大小是1MB，最大值可配置到4MB（DFSConfigKeys.java）：

• EC的I/O的传输Buffer，默认为64KB（dfs.datanode.ec.reconstruction.stripedread.buffer.size）

• 更小的Cell会提高并发性，但也会带来过重的负载，而IO Buffer则关系到系统吞吐率

  图9 默认cell size

• 所有这些包含了原始数据（Raw Data）和校验数据（Parity Data）的条带块称为“Internal Block”（参看图10）

• 每个Internal Block都有自己的索引

以下是社区代码中一张关于Block Group、Block、Cell和Stripe的完整的注释：

图10 Block Group、Block、Cell和Index

下面我们来看一下EC的整体设计架构，蓝色部分为EC新增组件。ECClient为扩展后的支持EC的客户端，用于从DataNode读取和转换EC数据（条带化），如支持：

"hdfs ec -convertToEC -path ... -policy ..."

ECManager用于管理Block Group及相关策略：块分配、选取、健康度监测以及坏块重建协同等工作。ECWorker工作于DataNode一侧，用于接收来自ECManager发起的数据恢复或EC转换等命令，从不同的DataNode上拉取数据并应用ECManager发起的Codec模式（RS-6-3或RS-10-4等模式存于InodeFile）进行编解码。

图11 EC系统架构

Client会根据读取文件的存储策略决定是否调用ECClient（Inode设置了ECPolicy），一旦某个文件夹配置了EC Policy，则该文件夹下的所有文件均按照该策略（EC Schema，即：RS-10-4等）对所有文件进行转换。ECClient从NameNode读取到该文件的Block Group。

EC Writer，Client的写入是并行的（对DFSOutputStream进行了重构），以RS-6-3为例，前6个cell以并行方式写入，后3个则要经过计算后得出校验cell再写入DataNode，Client端会持续写入，直到DataNode返回给Client最后一个包的ack。

图12 ECClient的实现

图13 NameNode的扩展实现

EC块恢复NameNode侧扩展

• 块组ID和块信息的映射

• ReplicationMonitor周期性对数据块进行删除和备份

• 增加了对原始块和校验块丢失的优先级，包括在Block Group上的所有校验块丢失

• 增加了EC转副本和副本转EC的优先级的支持

• 增加了CPU、内存、IO带宽限制

• 实现了针对EC场景下的DataNode选取策略

未来工作

Reed-Solomon的校验位计算占用了过多的CPU计算资源，因此CPU负载问题将会成为集群弹性计算的瓶颈，接下来我也会投入部分精力到ISA-L的benchmark中，实践检验下这个库对性能提升有多大。

纠删码实现工作的具体实现，本文并未详细讨论数据重建的具体实现，这也是我的下一步工作重点。

参考文献

https://blog.csdn.net/runningtortoises/article/details/51589918

http://itfish.net/article/55176.html#

https://issues.apache.org/jira/browse/HDFS-7337