共计 3994 个字符，预计需要花费 10 分钟才能阅读完成。
依据云存储服务商 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 和咱们分割。
