本文主要是介绍Microsoft、Google、Facebook的erasure code技术进展及系统分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
http://blog.sina.com.cn/s/blog_999d1f4c0101e160.html
数据规模庞大（目前google、淘宝等存储的大数据规模以PB为单位）、大数据增长速度远超过摩尔定律，如何利用有限存储资源满足迅速膨胀的存储需求成为大数据时代存储技术面临的一项重大挑战。多副本策略在满足存储可靠、优化数据读性能同时也不可避免地造成存储资源利用率低的缺陷。erasure code编码存储策略在满足和多副本同样可靠性前提下，可以达到更高的存储资源利用率。
当前，Microsoft、Google、Facebook、Amazon、淘宝等互联网巨头早已开始研究erasure code编码存储技术，并将其实用各自主流存储系统中，本文将分析比较 Microsoft、Google、Facebook的erasure code编码技术及系统如下：
• Google ： RS(6,3) in GFS II ( Colossus)
Google GFS II中采用了最基本的RS（6,3）编码，将一个待编码数据单元(Data Unit)分为6个data block, 再添加3个parity block，最多可容包括parity blocks在内的任意3个数据块错误。存储的space overhead 为（6+3)/6 = 1.5x.数据恢复的网络I/O开销为：恢复任何一个数据块需要6次I/O，通过网络传输6个数据block.
•Microsoft：erasure code in WAS( Windows Azure Storage)
为减少数据恢复时的网络I/O，微软采用了如上LRC编码策略，其核心思想为：将校验块（parity block）分为全局校验块(global parity)、局部校验块(local reconstruction parity).微软LRC（12,2,2）编码将一个待编码数据块分为12个data blocks，并进一步将这12个data blocks平均分为2个groups,每个group包括6个data blocks.为每个data group分别计算出一个local parity，以及所有12个data blocks计算出2个global parities.当发生任何一个数据块错误时，恢复代价由传统RS（12,4）编码的12（通过网络传输的数据块数量），变为6，恢复过程的网络I/O开销减半。Microsoft 以上LRC编码的space overhead为（12+2+2）/12 = 1.33x
•Facebook：从RS(10,4)到LRC（10,6,5）
RS(10,4)编码是Facebook HDFS RAID的早期编码方式，如上图所示。将每个待编码Data Unit均分为10个data block, 后面添加4个校验的parities.以上编码方式的space overhead为（10+4）/10 = 1.4x,发生任何一个数据块错误的恢复代价为10,即发生任意一个块错误需要10次I/O操作，从网络传输的数据量为10个数据块。
同样为减少数据恢复的网络I/O,Facebook于VLDB 2013发表名为“XORing Elephants”的LRC编码方法如下：
除了在原先的10个data blocks之后添加4个parities外，还将10个data blocks均分为2组，每组单独计算出一个局部校验块（Parity），将数据恢复代价由原来的10降低为5.即恢复任何一个数据块错误只需要进行5次网络I/O，从网络传输5个数据块。此种编码方式的space overhead 为（10+4+2）/10 = 1.6x.
以上erasure code编码技术无疑对存储空间利用率带来很大提升，但由于引入额外的编码、解码运算，对分布式计算本身会造成一定程度的性能损失。由于当前的编码技术还未从根本上解决降低性能损失，目前erasure code还仅适用于对冷数据的离线处理阶段。LRC编码由于减少了网络I/O传输的数据量，参与数据恢复运算的数据量也随之减半，恢复过程的时间开销减半，却是以牺牲可靠性和空间利用率为代价。如何从根本上降低erasure code带来的performance overhead，使得编码存储技术得以真正大量适用，将为大数据存储带来不容质疑的重大意义。
这篇关于Microsoft、Google、Facebook的erasure code技术进展及系统分析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
