f4: Facebook’s Warm BLOB Storage System——Erasure Code

Facebook在OSDI 2014上发表论文f4: Facebook’s Warm BLOB Storage System,这个系统主要目的就是降低存储成本,在容忍磁盘,主机,机架,数据中心的同时提供2.1倍的存储因子(用户存储的1bit数据实际上占用磁盘2.1bit空间)。本文只讨论f4系统的核心Erasure Code部分,如何降低存储因子。

Facebook热的blob数据依然存在Haystack中,访问不那么频繁的数据(Warm)放入存储系统f4中。Haystack存储blob的思路就是将多个这样的blob数据聚合在一个文件中,每个blob在文件中的位置信息存储在内存中,为了容错,这些位置信息同时会持久化在硬盘上,叫做index file. 和大部分文件系统一样,为了容错,每个数据文件都是3备份,同时单机上做了RAID6(1.2X),这样实际上,存储因子是3 * 1.2 = 3.6倍。也就是说,逻辑上1个bit的数据实际上在磁盘上存了3.6个bit。对于facebook这样数据量级的公司成本还是太高了。实际上,根据facebook的统计,很多数据比如photo和video随着时间的推移,访问的频度越来越小。对于这样的数据,读性能不需要那么高。facebook的做法就是将这些个访问不那么频繁的数据做EC编码,在单数据中心内,facebook选择经典的Reed-solomon编码,n=10,k=4,f4将数据文件切成一个个的1GB大小的block,对连续的10个data block生成4个parity block,一共14个block,可以同时容忍最多4个block,如果读请求涉及的data block没有丢失,直接访问这个block即可,不需要recover。如果data block丢失,需要访问其他block中任意10个进行恢复。为了容忍机架故障,facebook将这14个block放在不同的机架上。这样,单数据中心内,磁盘,主机,机架故障都可以容忍,这时的存储因子是14/10=1.4。为了容忍数据中心故障,所有的block包括parity block在另外一个数据中心也复制一份,这样下来,整个的存储因子是2.8. 由于数据中心故障比较少见,为了进一步降低成本,f4在数据中心之间使用XOR编码,即3个数据中心A,B,C,数据中心A和B分别各自存储各自的data block和parity block,数据中心A的block和B的block进行XOR编码结果block存在数据中心C中。这样,任意一个数据中心挂掉,数据都可以从另外两个数据中心恢复,存储因子(1.4 * 2 + 1.4)/2=2.1。

参考资料

f4: Facebook’s Warm BLOB Storage System

Haystack

你可能感兴趣的:(Facebook)