依据云存储服务商Backblaze公布的2021年硬盘“品质报告”，现有存储硬件设施的可靠性无奈齐全保障，咱们须要在软件层面通过一些机制来实现牢靠存储。一个分布式软件的罕用设计准则就是面向生效的设计。


backblaze

作为以后宽泛风行的分布式文件系统，HDFS须要解决的一个重要问题就是数据的可靠性问题。3.0以前版本的Hadoop在HDFS上只能采纳多正本冗余的形式做数据备份，以实现数据可靠性指标（比方，三正本11个9，双正本8个9）。多正本冗余的形式尽管简略牢靠，却节约了成倍的存储资源，随着数据量的增长，将带来大量额定老本的减少。为了解决冗余数据的老本问题，在Hadoop3.0版本上，HDFS引入了EC技术（Erasure Code 纠删码）。

本文分享EC技术原理及个推的EC实际，带大家一起玩转Hadoop3.0！

EC原理深度解读

EC技术深度利用于RAID和通信畛域，通过对数据编解码以实现在局部数据失落时仍可能将其复原。

咱们能够这样了解EC的指标和作用：对n个同样大小的数据块, 额定减少m个校验块, 使得这n+m个数据中任意失落m个数据块或校验块时都能复原本来的数据。

以HDFS的RS-10-4-1024k策略为例，能够实现在1.4倍的数据冗余的状况下，达到近似于5正本的数据可靠性，也就是说以更小的数据冗余度取得更高的数据可靠性。

1、EC算法

常见的EC算法有XOR、RS，上面一一做简要介绍：

//简略EC算法：XOR
XOR是一种基于异或运算的算法，通过对两个数据块进行按位异或，就能够失去一个新的数据块，当这三个数据块中有任意一个数据块失落时，就能够通过另外两个数据块的“异或”复原失落的数据块。

HDFS通过XOR-2-1-1024k的EC策略实现了该算法，这种形式尽管升高了冗余度，然而只能容忍三个数据块中一个失落，在很多状况下其可靠性仍然达不到要求。

//改良的EC算法：RS
另一种升高冗余度的编码方式为Reed-Solomon（RS），它有两个参数，记为RS(n,m)。其中，n示意数据块，m示意校验块，须要留神的是，RS算法下，有多少个校验块，就示意最多可容忍多少个数据块（包含数据块和校验块）失落。

RS 算法应用生成矩阵（GT，Generator Matrix）与n个数据单元相乘，以取得具备n个数据单元（data cells）和m个奇偶校验单元（parity cells）的矩阵。如果存储失败，那么只有n+m个cells中的n个可用，就能够通过生成器矩阵来复原存储。

RS算法克服了XOR算法的限度，应用线性代数运算生成多个parity cells，以便可能容忍多个失败。

下图形象地形容了RS算法的编码与解码过程：

编码过程（图左）：

  • 把m个无效数据组成一个向量D。
  • 生成一个变换矩阵B：由一个n阶的单位矩阵和一个n * M的范德蒙特矩阵（Vandemode）组成。
  • 两矩阵B和D，相乘，失去一个新的具备纠错能力的矩阵。

解码过程（图右）：

  • 取范德蒙矩阵B中没有失落的行，形成矩阵B`。
  • 取编码过程最初计算的矩阵中没有失落的行，形成矩阵Survivors。
  • 用B`的逆，乘以Survivors矩阵，即可失去原始的无效数据。

为了更艰深地阐明编解码过程，咱们以RS-3-2-1024k策略为例，回顾应用EC算法进行编解码的过程。

假如有三块数据：d1,d2,d3，咱们须要额定存储两块数据，使得这五块数据中，任意失落两块数据，都能将它们残缺找回。

首先按编码过程构建纠错矩阵：

1、失去向量D

2、生成一个变换矩阵B

3、失去纠错矩阵D*B

假如d1,d2数据失落，咱们通过解码做数据恢复：

1、取B中没有失落的行，形成矩阵B`

2、取纠错矩阵中没有失落的行，形成矩阵Survivors

3、计算B`的逆为：

4、B`的逆，乘以Survivors矩阵，即可失去原始的无效数据：

至此，咱们实现了在本来3个数据块外再额定存储2个数据块，使得这5个数据块中任意失落两个都能将其找回的指标。

与三正本的形式比照，在可靠性方面，三正本形式能够容忍存储该文件（数据d1,d2,d3）的机器中任意两台宕机或坏盘，因为总还有一个正本可用，并通过复制到其余节点复原到三正本的程度。同样，在RS-3-2策略下，咱们也能够容忍5个数据块所在的任意2台机器宕机或坏盘，因为总能够通过另外的3个数据块来复原失落的2个数据块。

由此可见，三正本形式和RS-3-2策略，在可靠性方面根本相当。

在冗余度（冗余度=理论存储空间/无效存储空间）方面，三正本形式下，每1个数据块都须要额定的2个数据块做正本，冗余度为3/1=3，而在RS-3-2的策略下，每3个数据块只须要额定的2个数据块就可能实现可靠性指标，冗余度为5/3=1.67。

最终，咱们通过RS-3-2的形式可能在1.67倍冗余的状况下，实现近似三正本的可靠性。

下图为Hadoop上，不同策略下的无效数据与冗余数据占比示意图。能够看到，三正本形式的存储老本是最高的：

2. 条带布局

正本策略以块（Block）为单位，将数据间断写入Block中，直至达到该Block下限（默认128M），而后再去申请下一个Block。以最常见的三正本形式为例，每个Block会有3个雷同数据的正本存储于3个DataNode（DN）上。

HDFS EC策略采纳的是条带式存储布局（Striping Block Layout）。条带式存储以块组（BlockGroup）为单位，横向式地将数据保留在各个Block上，同一个Block上不同分段的数据是不间断的，写完一个块组再申请下一个块组。

下图为间断布局和RS(3,2)策略下一个BlockGroup布局比照：

相比于间断布局，条带布局有以下劣势：

  • 反对间接写入EC数据，不须要做离线转化
  • 对小文件更敌对
  • I/O并行能力进步

个推在Hadoop2.0上落地EC

个推在很早的时候就对整个集群做了布局，将整个Hadoop集群分为对计算需要比拟大的热集群和对存储需要比拟大的冷集群。在Hadoop3.x公布当前，咱们将冷集群降级到Hadoop3.x版本，进行了包含EC编码在内的新个性试用。思考到计算引擎的兼容性、稳定性要求，同时为了缩小迁徙老本，咱们仍将热集群放弃在了Hadoop2.7版本。

计算引擎拜访

因为次要承接计算工作的热集群是Hadoop2.x的环境，而外部的计算引擎都不反对Hadoop3.x，所以为了将EC性能在生产环境落地，咱们首先要解决在Hadoop2.x上对Hadoop3.x上EC数据进行拜访的能力。为此，咱们对Hadoop2.7的hadoop-hdfs做了定制化开发，移植了Hadoop3.x上的EC性能，外围的变动包含：

  • EC编解码和条带相干性能引入
  • PB协定的适配
  • 客户端读取流程的革新

资源本地化

在部署革新代码包的过程中，咱们应用Hadoop的“资源本地化”机制，简化了灰度和上线流程。

所谓“资源本地化”，指的是NodeManager在启动container以前须要从HDFS上下载该container执行所依赖资源的过程，这些资源包含jar、依赖的jar或者其它文件。借助资源本地化的个性，咱们就能够将jar包，定制散发到相应计算工作的container中，以管制application级别工作的Container的jar包环境，使后续的测试、灰度验证和上线十分不便。

SQL拜访

个推目前有大量的工作是通过SQL形式提交的，其中，大部分的SQL工作在提交到Yarn上之后，会转化为相应计算引擎的计算工作。针对该局部SQL工作，咱们能够间接应用第一种解决方案进行拜访。

然而，依然存在一部分的工作并不通过Yarn提交，而是间接与HDFS做交互，比方一些小数据集计算工作或间接通过limit查看几条示例的SQL工作（例如select * from table_name limit 3）。这就须要该局部工作所在的节点，有拜访Hadoop3.x上EC数据的能力。

以Hive为例，下图为个推环境上Hive拜访HDFS数据的几种形式，这里的HiveCli、Hiveserver2都要做相应的适配：

3、损坏校验

在社区提交的EC相干的bug中，咱们发现有一些bug会导致编码的数据损坏，例如：HDFS-14768、HDFS-15186、HDFS-15240。为了确保转化后的数据是正确的，咱们对编码后的数据做了块级别的额定校验。

在设计校验程序时，咱们不仅要思考校验程序的便利性，使其可能对新EC的数据做校验，还要对之前曾经EC过的数据做一遍校验。因而，咱们次要的思路是利用全副的校验块和局部数据块对编码后的数据做解码，来比照解码后的数据块和原数据块是否统一。

咱们以RS-3-2-1024k为例，回顾下校验过程：

基于额定的校验工具，咱们抽取了单正本1PB的EC数据做了验证，验证结果显示，故障的文件数和大小占比大概都在百万分之一以下，可靠性达到目标要求。

瞻望
目前，咱们还须要专门统计和筛选出热度比拟低的数据并过滤掉小文件，用于后续的EC编码解决。后续咱们将摸索设计一套零碎，使其能主动感知到数据的热度降落，并实现数据从正本策略到EC策略的转化。此外，在intel ISA-L减速库等方面，咱们还将继续开展摸索，以晋升整个EC编解码的运算效率。

关注个推技术实际公众号，解锁“大数据降本提效”更多干货内容。

彩蛋

“大数据降本提效”系列专栏由每日互动大数据平台架构团队深度参加打造。

每日互动大数据平台架构团队是负责每日互动大数据平台研发的外围团队，基于大数据生态圈开源组件定制优化，助力全公司各项业务的降本提效，欢送分布式存储、分布式计算、分布式数据库等大数据平台架构畛域相干的专家退出和交换。

  • 简历投递：hrzp@getui.com；
  • 技术交换：通过个推技术实际公众号后盾，或发送邮件至tech@getui.com和咱们分割。