HDFS 纠删码

在HDFS中，可靠性通过多副本的方式来实现，从而较低的存储利用率成为时下基于HDFS应用的主要问题之一。本文将详细介绍HDFS一个新的特性——Erasure Coding（EC）， 它在保证同等（或者更高）可靠性的情况下将存储利用率提高了近一倍。

背景

近些年，随着大数据技术的发展，HDFS作为Hadoop的核心模块之一得到了广泛的应用。然而，随着需要存储的数据被越来越快的产生，越来越高的HDFS存储利用率要求被提出。而对于一个分布式文件系统来说，可靠性必不可少。因此，在HDFS中每一份数据都有两个副本，这也使得存储利用率仅为1/3，每TB数据都需要占用3TB的存储空间。因此，在保证可靠性的前提下如何提高存储利用率已成为当前HDFS应用的主要问题之一。

纠删码技术起源于通信传输领域，后被逐渐运用到存储系统中。它对数据进行分块，然后计算出一些冗余的校验块。当一部分数据块丢失时，可以通过剩余的数据块和校验块计算出丢失的数据块。Facebook 的开源项目HDFS-RAID在HDFS之上使用了纠删码技术。HDFS-RAID对属于同一文件的块分组并依次生成校验块，将这些校验块构成独立的文件，并与原始的数据文件一一对应。RaidNode作为一个新的角色被引入进来，它负责从DataNode中读取文件的数据块，计算出校验块， 并写入校验文件中；同时，它还周期性地检查被编码了的文件是否存在块丢失，如有丢失则重新进行计算以恢复丢失的块。HDFS-RAID的优点是其构建于HDFS之上，不需要修改HDFS本已经复杂的内部逻辑，但缺点也显而易见：校验文件对用户是可见的，存在被误删除的可能；依赖于MySQL和MapReduce来存储元数据和生成校验文件；RaidNode需要周期性地查找丢失的块，加重了NameNode的负担；使用的编解码器性能较差，在实际应用中往往不能满足要求。另外，由于缺乏维护，HDFS已将HDFS-RAID的代码从contrib包中移除，这给使用HDFS-RAID带来不少困难。

2014下半年，英特尔和Cloudera共同提出了将纠删码融入到HDFS内部的想法和设计（HDFS EC），随后吸引了包括Hortonworks、华为、Yahoo!等众多公司的参与，使之成为Hadoop开源社区较为活跃的一个项目。将纠删码融入到HDFS内部带来了诸多好处：它不再需要任何的外部依赖，用户使用起来更为方便；其代码成为HDFS的一部分，便于维护；可以充分利用HDFS的内部机制使性能得到最大程度的优化。纠删码的编解码性能对其在HDFS中的应用起着至关重要的作用，如果不利用硬件方面的优化就很难得到理想的性能。英特尔的智能存储加速库（ISA-L）提供了对纠删码编解码的优化，极大的提升了其性能，这一点将在实验部分做详细的阐述。HDFS EC项目主要要实现以下的功能：

1. 用户可以读和写一个条形布局（Striping Layout，定义见下文）的文件；如果该文件的一个块丢失，后台能够检查出并恢复；如果在读的过程中发现数据丢失，能够立即解码出丢失的数据从而不影响读操作。
2. 支持将一个多备份模式（HDFS原有模式）的文件转换成连续布局（Contiguous Layout，定义见下文），以及从连续布局转换成多备份模式。
3. 编解码器将作为插件，用户可指定文件所使用的编解码器。
   由于HDFS的内部逻辑已经相当复杂，HDFS EC项目将分阶段进行：第一阶段（HDFS-7285）已经实现第1个功能，第二阶段（HDFS-8030）正在进行中，将实现第2和第3个功能。本文将主要阐述第一阶段（HDFS-7285）的设计与实现。

相关概念

纠删码（Erasure Code）与 Reed Solomon码

在存储系统中，纠删码技术主要是通过利用纠删码算法将原始的数据进行编码得到校验，并将数据和校验一并存储起来，以达到容错的目的。其基本思想是将ｋ块原始的数据元素通过一定的编码计算，得到ｍ块校验元素。对于这ｋ+ｍ块元素，当其中任意的ｍ块元素出错（包括数据和校验出错），均可以通过对应的重构算法恢复出原来的ｋ块数据。生成校验的过程被成为编码（encoding），恢复丢失数据块的过程被称为解码（decoding）。

Reed-Solomon（RS）码是存储系统较为常用的一种纠删码，它有两个参数k和m，记为RS(k,m)。如图1所示，k个数据块组成一个向量被乘上一个生成矩阵（Generator Matrix）GT从而得到一个码字（codeword）向量，该向量由k个数据块和m个校验块构成。如果一个数据块丢失，可以用(GT)-1乘以码字向量来恢复出丢失的数据块。RS(k,m)最多可容忍m个块（包括数据块和校验块）丢失。

 

图1 RS(4,2)编码过程示意图

 

块组（BlockGroup）

对HDFS的一个普通文件来说，构成它的基本单位是块。对于EC模式下的文件，构成它的基本单位为块组。块组由一定数目的数据块加上生成的校验块放一起构成。以RS(6,3)为例，每一个块组包含1-6个数据块，以及3个校验块。进行EC编码的前提是每个块的长度一致。如果不一致，则应填充0。图2给出三种不同类型的块组及其编码。

图2 三种类型块组及其编码

 

连续布局（Contiguous Layout） VS 条形布局（Striping Layout）
数据被依次写入一个块中，一个块写满之后再写入下一个块，数据的这种分布方式被称为连续布局。在一些分布式文件系统如QFS和Ceph中，广泛使用另外一种布局：条形布局。条（stripe）是由若干个相同大小单元（cell）构成的序列。在条形布局下，数据被依次写入条的各个单元中，当条被写满之后就写入下一个条，一个条的不同单元位于不同的数据块中。

图3 连续布局与条形布局示意图

 

总体设计

布局的选择

对HDFS EC来说，首要的问题是选择什么样的布局方式。连续布局实现起来较为容易，但它只适合较大的文件。另外，如果让client端直接写一个连续布局文件需要缓存下足够的数据块，然后生成校验块并写入，以RS（6,3），blockSize=128M为例，client端需要缓存1.12G的数据，这点决定了连续布局的文件更适合由普通文件转化而来，而条形布局就不存在上述缺点。由于一个条的单元往往较小（通常为64K或1M），因此无论文件大小，条形布局都可以为文件节省出空间。client端在写完一个条的数据单元后就可以计算出校验单元并写出，因此client端需要缓存的数据很少。 条形布局的一个缺点是会影响一些位置敏感任务的性能，因为原先在一个节点上的一个块被分散到了多个不同的节点上。
HDFS最初就是为较大文件设计的分布式文件系统，但随着越来越多的应用将数据存储于HDFS上，HDFS的小（即小于1个块组）文件数目越来越多，而且它们所占空间的比率也越来越高。以Cloudera一些较大客户的集群为例，小文件占整个空间的比例在36-97%之间。

基于以上分析，HDFS EC优先考虑对条形布局的支持。下面的设计与实现也主要围绕已经实现了的条形布局展开。

NameNode端扩展

在EC模式下，构成文件的基本单位为块组，因此首先需要考虑的是如何在NameNode里保存每个文件的块组信息。一种比较直接的方法是给每个块组分配一个块ID，同时用一个Map来记录这个ID与块组信息的映射，每个块组信息包含了每个内部块的信息。对小文件来说，这种做法将增加其在NameNode中的内存消耗。以RS（6,3）为例，如果一个文件比6个块略小些，那么NameNode必须为它维护10个ID（1个块组ID、6个数据块ID和3个校验块ID）。在小文件数目占优的情况下，NameNode的内存使用将面临考验。

一个块ID有64位，这里将第1个位作为flag来区分块的类型：如果为1，则为EC块（条形布局的EC块，连续布局将在第二阶段考虑）；如果为0，则为普通块。对EC块来说，会将剩下的63位分成两部分：最后的4位用来标识内部块在块组中的位置，前面的59位用来区分不同的块组。块组ID等同于第0个内部块ID，其他的内部块ID可由块组ID加上其在块组中的位置索引得到，比如第0个内部块ID为0xB23400（也即块组ID），那么第3个内部块的ID为0xB23403。由于只是用最后4位来区分一个块组中的内部块，因此对一个块组来说，系统目前支持最多16个内部块。

这样一来就可以尽可能地利用HDFS当前的机制来实现对块组的支持。块组依旧用类Block来表示，其中的三个成员：blockId代表块组ID；numBytes代表块组大小，即所有数据块大小之和，不包括校验块的大小；generationStamp代表块组的生成时间戳，所有内部块共享块组的时间戳。这里可以根据块组的Block对象得到内部块的Block对象：blockId由块组ID加上该内部块在块组中的位置索引；numBytes可由块组大小和该内部块位置索引计算出来；生成时间戳等同于块组的时间戳。每个内部块所在的DataNode