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