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