友情提醒：如果有对文件系统编码不太了解的朋友，可以先去了解下存储编码，其实很简单的就跟我们小学学的列方程、解方程相似。当然了特别复杂的编码就涉及到很深的数学知识了，我们此处不聊数学~~
HDFS-Raid作为Facebook在Hadoop内部实现的一个子模块，提供了DRFS(Distributed Raid File System)，即分布式Raid文件系统作为DFS的具体实现，为文件在Raid中具体使用的文件系统。
DRFS中原文件被分成由几个Blocks组成的Stripes组成，Stripe中Block数量称为stripeLength，stripeLength可通过配置文件经JSON(JavaScript Object Notation)对象具体配置，每个Stripe可编码成由几个Blocks组成的校验文件(parity file)，存储在具体的校验文件里，一个Stripe编码后对应校验文件Block数量称为parityLength。这样，当原文件Block损坏或丢失时，可通过一定数量的未损坏原文件Blocks和校验文件Blocks进行修复，保证了数据的可靠性。所以对原文件编码后，可将原文件的备份数减少(如将默认的3份备份数减少到2份备份数)，这样，总的存储量得到减少。
目前Raid中已实现的编码方式有XOR和RS两种。其中XOR编码stripeLength可通过配置文件具体配置，parityLength只能为1。RS编码stripeLength和parityLength都可通过配置文件具体配置。RS编码的操作基于有限域，需满足stripeLength和parityLength的和小于所选有限域大小。
对DRFS中存储的原文件进行编码操作(Raid操作)，主要有两种方式。一种是通过Shell工具RaidShell手动对特定文件或目录进行Raid操作，这种方式相对来说不是很系统化，但可以用于测试。另一种是启动RaidNode节点后，由RaidNode节点启动的相关线程如TriggerMonitor自动对相应文件进行Raid操作。TriggerMonitor定期刷新配置信息，对配置策略下需要Raid的文件进行Raid。当检测到Block损坏或丢失时，同样通过相关线程如BlockFixer进行Block修复。这种方式是比较系统的Raid方式，不管是对文件的Raid操作还是修复都是通过相关线程自动进行，无需人工干预，操作者可通过Web界面或日志文件查看状态。
RaidShell作为一个Shell工具，允许管理员查看并维护DRFS的基本状态。通过RaidShell，管理员可以查看某一文件的Block状态(通过执行fsck命令)，或者对某一文件或目录进行Raid操作(通过执行raidFile命令)，可指定Parity文件存放目录，或者对某一文件的损坏Block进行修复(通过执行recoverBlocks命令)等等，实现对DRFS中文件的手工管理。
RaidNode作为Hadoop中除NameNode和DataNode外的第三个master node，主要是接收Client端的RPC请求和调度各守护线程完成数据的Raid化和数据修复，parity文件删除等操作。在Facebook-Raid中有两种实现：LocalRaidNode和DistRaidNode，即本地RaidNode实现和分布式RaidNode实现。其中LocalRaidNode在RaidNode本地进行parity计算，parity文件的生成是一个计算密集型任务，而本地计算能力有限，因此该方式的扩展性有限。而DistRaidNode通过提交mapreduce job来进行parity计算，充分利用了Hadoop的并行计算能力，最大化计算效率。RaidNode中有main函数，根据配置文件生成local或者dist对象，函数中开启以下的线程：
1.TriggerMonitor，周期性检查配置信息，根据配置文件配置的需Raid的文件路径，对所在路径的文件进行Raid操作。Raid化的调度周期主要收两个配置的影响，raid.config.reload.interval(加载raid-policy的周期，默认10s)和raid.policy.rescan.interval（扫描需要Raid化的原文件的间隔，默认1小时）。这样，当新增了一个配置policy时，默认10s内该policy会被加载执行。而在一个已经Raid化的目录中新增了一个文件时，该文件将在1个小时内被Raid话。(配置policy传入需Raid文件的基本参数，如需Raid文件的路径，Raid后的备份数等)
2.BlockIntegrityMonitor，对已Raid化的文件进行周期性检查，检查内容包括corrupt(损坏)和decomssion(丢失)，当检测到有Block损坏或丢失时，通过其维护的CorruptMonitor和DecommsionMonitor两个线程进行修复。BlockIntegrityMonitor对应有两个实现：LocalBlockIntegrityMonitor和DistBlockIntegrityMonitor，即本地实现和分布式实现。
3.BlockFixer，为BlockIntegrityMonitor构建的用于修复损坏(corrupt)文件的线程。
4.BlockCopier，为BlockIntegrityMonitor构建的用于修复丢失(decommsion)文件的线程。
5.PurgeThread，封装了PurgeMonitor，定期扫描已经Raid文件的校验文件(parity file)，判断是否有孤儿Parity文件，所谓的孤儿Parity文件是指原文件已经不存在的Parity文件，若有，则删除孤儿Parity文件。
6.HarThread，封装了HarMonitor，定期对超期的Parity文件进行归档处理，将超期的Parity文件归档成大容量的Har文件，超期时间由raid.parity.har.threshold.days指定，默认是3天。
7.statsCollectorThread，封装了StatisticsCollector，当DRFS中文件状态变化时(Raid，丢失等)更新DRFS的统计数据。
说了这么多，是时候让大家见识一下raid是怎么做的编解码了
TriggerMonitor就是我前文提及的RaidNode进程中一个周期扫描raid policy的线程，进行raid操作。Raidshell则是使用shell命令，本质是相同的。raid操作最后是通过Encode对块信息进行编码，Encoder中包含ErasureCode类型的对象，最后使用ErasureCode子类的encodeBulk进行编码，所以最后还是落实到最HDFS的基本单元”文件块“的编码。可能有读者会问编码的方案有很多种，采用那种呢？这是个好问题！raid里面有一个函数叫Codec.createErasureCode(conf)生成ErasureCode的子类对象，这样我们是不是就拿到了编码方案的描述信息了。
下面我们看下，raid是如何做到解码的。
解码流程是编码的逆向，raid解码方式主要是3种分别是shell的方式，启动本地修复线程，启动分布式修复线程。相比于编码，解码还要稍微复杂一些。因为解码的任务是要恢复损坏的块，所以在修复之前就要先判断下是原始文件坏了，还是校验文件坏了，还是归档文件坏了？接着分别执行不同的流程，流程的最后还是跟编码一样，是对文件块的解码操作。流程图的中的Decoder就相当于编码中的Encoder。
上述都是从架构的层面解析HDFS-RAID，偏向于设计理念。正所谓程序就是算法加数据，我们解释清楚raid最后是要操作的HDFS文件块，那么具体是怎么操作的呢？
在此之前我们先弄清楚编解码的一个基本模型—"Stripe"
一个文件有很多块，我们则是根据编解码的规则，觉得将多少块视为一组，也就是我们所说的"Stripe"。好，搞清楚这个我们就开始解释Encoder和Decoder是怎么做的。
Encoder是一个负责生成parity文件的类，流程详解如下：
1.由于编码过程会比较长，所以先生成tmp文件。tmp文件的目录可以通过tmp_parity_dir配置，默认是tmp/$parity_dir
2.构建tmp文件path，tmp文件的path为tmp目录下parity文件path加上一个随机long值构成，$tmp_parity_dir/$parity_file+randomlong。
3.通过Erasued Code来进行编码到tmp文件
4.删除原有的parity文件
5.将tmp文件重命名为parity文件。
6.删除tmp文件。
Decoder这个修复数据的类则和Encoder有异曲同工之妙了。
具体流程如下：
1.根据文件中出错的位置，计算出错的block，该block所在的stripe，以及在stripe中的位置，计算parity文件相应block的位置。
2.通过ParallelStreamReader读取源block数据和parity数据，读取方式与编码时类似
3.通过Erasured Code将源block和parity数据的进行解码，生成丢失的block数据。
到此，HDFS-RAID的模块流程基本已经解释清楚了。facebook已经实现了RS和XOR编码并且投入了生产当中，并且于Hadoop3.0正式加入了这项编解码功能，其定义ErasureCode类也是考虑到这个模块的扩展性，可以加入其他编码。当然也不是所有的编码都能符合这种Stripe，也就是水平编码的模型，所以实现某种编码的时候最好先理解Hadoop提供的这种编码模型。而且MapRedude只是一种任务的负载均衡，无法用来解决各个节点解码任务不同的再生码。
至于为什么写这篇文章，主要因为国内讲解HDFS-RAID的文章不多，我和我的室友只能通过去看源码的方式去理解其中的流程，这其实是很费时费力的，所以在这个闲暇的时间总结了下之前的工作，希望能对搞存储编码的朋友有帮助。
