Hadoop系列之HDFS 纠删码(18)

谁践踏了优雅 2023-01-12 10:06 157阅读 0赞

# HDFS 纠删码 #

Hadoop HDFS 纠删码已经克服了之前使用的数据块多副本策略的限制，它具有和多副本策略相同的容错效果，但需要的存储空间却少很多。使用纠删码技术可以减少 50% 的存储空间。

## HDFS 副本策略的问题 ##

HDFS 为了数据容错，在存储的时候回，每个数据块会被复制3次。为了防止由于 Datanode 发生故障带来数据丢失，这是一种简单且健壮的方式。利用本地存储多个数据块副本的方式，还可以减轻 MapReduce 任务或者其他计算任务的负担。但数据块复制技术的开销比较大，3个副本就需要 200% 的存储空间开销和其他资源开销。

因此，一个新的 HDFS 特性 —— 纠删码，就是来代替数据块复制技术的。在比较两种存储模式的时候，重点考虑的是：

*  数据持久性
 *  存储利用率

## 纠删码（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 个块（包括数据块和校验块）丢失。

![hdfs纠删码和Reed Solomon码][hdfs_Reed Solomon]

## 块组（BlockGroup） ##

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

![HDFS 块组（blcokgroup）][HDFS _blcokgroup]

## 连续布局（Contiguous Layout） VS 条形布局（Striping Layout） ##

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

![HDFS 连续布局和条形布局][HDFS]

## Erasure Coding技术的优劣势 ##

优势  
纠删码技术作为一门数据保护技术，自然有许多的优势，首先可以解决的就是目前分布式系统，云计算中采用副本来防止数据的丢失。副本机制确实可以解决数据丢失的问题，但是翻倍的数据存储空间也必然要被消耗，这一点却是非常致命的。EC 技术的运用就可以直接解决这个问题。

## 劣势 ##

EC技术的优势确实明显，但是他的使用也是需要一些代价的，一旦数据需要恢复，他会造成2大资源的消耗：

*  网络带宽的消耗，因为数据恢复需要去读其他的数据块和校验块。
 *  进行编码，解码计算需要消耗CPU资源。

概况来讲一句话，就是既耗网络又耗CPU，看来代价也不小。所以这么来看，将此计数用于线上服务可能会觉得不够稳定，所以最好的选择是用于冷数据集群，有下面2点原因可以支持这种选择：

*  冷数据集群往往有大量的长期没有被访问的数据，体量确实很大，采用 EC 技术，可以大大减少副本数。
 *  冷数据集群基本稳定，耗资源量少，所以一旦进行数据恢复，将不会对集群造成大的影响。

出于上述2种原因，冷数据集群无非是一个很好的选择。

[hdfs_Reed Solomon]: /images/20221119/ad91dc18b84a4b1fbe094eb9eb9636a9.png
[HDFS _blcokgroup]: /images/20221119/1976985765a94c54967b3d5fa3c1b9e3.png
[HDFS]: /images/20221119/6d5f7a652ee8466ab373c8b7a26fb0df.png