EC---->LRC---->Sparse Erasure Code

     副本存储(3副本技术)方案是将一个文件切分成多个Block进行存储，通常一个Block 64MB或者128MB，每个Block有多个(工业界默认3个)副本(replica)，每个副本作为一个整体存储在一个Data Node上，这种方法在增加可用性的同时也增加了存储成本。

    Erasure Code通过将M个数据block进行编码(Reed-Solomon算法 / LRC)，生成K个校验(parity)block，这M+K个block组成一个block group，可以同时容忍K个block丢失，任何K个block都可以由其他M个block计算出来。 overhead是K/M。

    以M=8,K=4(sheepdog 8:4)为例，使用EC之前，假设block副本数为3，那么8个block一共24个副本，overhead是200；使用EC后，12个block，每个block只需一个副本，一共12个副本，其中8个数据副本，4个校验副本，overhead是4/8=50%

   传统的Erasure Code(RS码)需要读取至少8份数据block进行计算和数据恢复。

EC过程：

   设定12X8的矩阵B(矩阵可以自己选定，范德蒙德矩阵的转置)和原始的8个数据块(8X1矩阵)相乘，得到12X1的矩阵(其中前8行是原始的数据，后4行就是erasure code)；通过数据块group的相互关系可以知道哪几部分的数据丢失了，假设存在删去对应行的矩阵(B‘)去和原始的数据块相乘就得到现在的结果。等号两边分别乘以(B’)^-1，就可以得到原始的数据块(数学关系其实是矩阵乘法：具体来说是用编码矩阵和分块数据矩阵做乘法从而得到校验块)

纠删码的演化: RS->LRC

    纠删码通过技术含量较高的算法，提供和副本近似的可靠性，同时减小了额外所需冗余设备的数量，从而提高了存储设备的利用率。但纠删码所带来的额外负担主要是计算量和数倍的网络负载，优缺点都相当明显。尤其是在出现硬盘故障后，重建数据非常耗CPU，而且计算一个数据块需要通过网络读出N倍的数据并传输，所以网络负载也有数倍甚至10数倍的增加。 整体来看，若采用纠删码技术，你能够得到了希望的容错能力和存储资源利用率，但是需要接受一定的数据重建代价，两者间做一个平衡。

    因此，优化的思路自然聚集到更容易出现的单个磁盘故障上来，如何更有效的处理这种概率较大的事件呢，直接出现的对策就是分组，把单个磁盘故障影响范围缩小到各个组内部，出坏盘故障时，该组内部解决，在恢复过程中读组内更少的盘，跑更少的网络流量，从而减小对全局的影响。

    LRC(locally repairable codes本地副本存储)是基于RS编码改进，可以有效减少数据修复时的网络I/O、数据量和运算量、以及数据恢复时间。当然，在相同数据可靠性的情况下，LRC占用的物理空间略大，比三副本方式还是小很多

例如：

    计算10:6:2的LRC码，首先按照10:6的比例计算出RS码，得到chunk分片X1、X2、......X10、Y1、Y2、......Y6(全局校验快)
    然后(局部校验块)取Z1=X1+X2+......+X5,Z2=X6+......+X10
        X1、X2、......X10、Y1、Y2、......Y6、Z1、Z2就构成了(10:6:2)的LRC码

    如果X1、X2、......X10中有一个分片出现数据丢失，那么只需要读取(前5个分片中的4个+Z1)或者(后5个分片中的4个+Z2)，就可计算出丢失的分片

     而传统的RS码则需要读取10个chunk分片
    此时，LRC码可以节省二分之一的磁盘I/O和网络I/O。 LRC的数据可靠性低于RS高于副本，数据修复的性能低于副本高于RS，是一种折中的算法

纠删码的演化: RS->SEC

    在传统Erasure Code的基础上，提出了Sparse Erasure Code(部分纠删码)(8:3:3)

    将分出来的8个数据block构成1个group，并生成3个全局校验快R1、R2和R3（利用编码矩阵和分块数据矩阵乘法得到）；再将group分成2组，分别生成2个局部校验快（异或运算，容易实现且占用CPU资源少）；全局校验快也被分成1组，生成对应的局部校验快，至此构成3组。任何一部分的数据丢失，都只需要4次网络IO,实现网络IO负载减半，计算量减半，恢复速度增加１倍，但是需要更多的存储空间并且相比于传统的EC恢复可靠性下降了(恢复不出来的概率上升了)(牺牲空间利用率和可靠性为代价)

    以上erasure code编码技术无疑对存储空间利用率带来很大提升，但由于引入额外的编码、解码运算，对分布式计算本身会造成一定程度的性能损失。由于当前的编码技术还未从根本上解决降低性能损失，目前erasure code还仅适用于对冷数据的离线处理阶段。LRC编码由于减少了网络I/O传输的数据量，参与数据恢复运算的数据量和运算量也随之减半，恢复过程的时间开销减半，却是以牺牲可靠性和空间利用率为代价。

HDFS-RAID

    HDFS-RAID这个方案是facebook在Hadoop 0.20-append分支上做的，为了不引入复杂度，基于HDFS，没有修改HDFS。只支持离线(异步)EC。

    当前HDFS block的副本作为一个整体连续(contiguous)的存储在一个DataNode上，在locality上具有一定的优势，特别是对于MapReduce这样的应用，但是这种方法不好做在线EC。当前社区方案不以block为单位进行EC，而是以strip为单位进行EC(HDFS依旧管理Block)设计思路参考了QFS。对于配置了EC的文件，客户端写入时将文件的数据切成一个个的64KB的strip，相邻的strip发往不同的DataNode,比如当前使用(6,3)-Reed-solomon编码，当前正在写的文件有6个strip: strip1, strip2, strip3, strip4, strip5, strip6, 那么这6个strip和相应的编码出来的3个校验strip共9个strip会并行的发往9个不同的DataNode。这种方式写入性能更好，但是也会对网卡出口带来一些压力，同时牺牲了locality。如果文件大小不是64KB * 6的整数倍，那么最后一个strip group显然不是满的，这时客户端还会将最后一个strip group的长度记在校验块中，后续读的时候，可以根据这个长度和数据块长度还有文件长度来校验。

Swift+Erasure Code

    作为OpenStack的对象存储项目Swift，自然要对存储成本进行有效的控制。不过要在成本、数据持久性（durability）和性能之间找到平衡，并非那么容易。在官方发行版中的Swift是不具备Erasure Code功能的，但SwiftStack已经实现了Swift+Erasure Code。相信支持Erasure Code功能的Swift不久将会出现在官方发行版中。

    不过，Swift+Erasure Code并非完美，这种算法会大量增加网络负载。Joe Arnold透露，Swift会提供Erasure Code和传统3副本两种策略，供用户选择。而 LRC通过增加本地存储来降低数据恢复时对网络资源的消耗，也许这是Swift未来更需要的策略。

Erasure Code相比于RAID的优势：

    Erasure code是设计用来将数据分割成不可识别的数据块，使用额外的信息追加到每个数据块中，允许从一些数据块的子集就可以复原完整的数据集，数据块可以分布在一个数据中心、城市、地区或全球任何地方的不同存储位置。

    Erasure code有内置的数据安全性，因为每个独立的数据块不包含足以泄露原始数据集的信息，要完全挽回完整的数据集，需要用到不同存储节点上的大量数据块子集，究竟需要多少数据块取决于当初加入到每个数据块的额外信息决定的，额外信息越多意味着恢复整个数据集需要的数据块越少。

    Erasure code在面对自然灾难或技术故障时具有很好的恢复能力，因为只需要数据块的一个子集就可以恢复原始数据，实际上，使用Erasure code时，允许同时发生多种故障，包括托管设备，服务器，存储元件，HDD或网络，数据始终保持是可访问的。

    Erasure code存储与RAID完全不同，它消除了所有RAID问题，它是一种全新的技术。

    Erasure code更适合用于大数据集，特别适合云计算和分布式存储，因为它不用复制数据集就可以跨多个地理位置分布数据。