Erasure Code為Hadoop節省資料恢復頻寬

來自南加州大學和Facebook的7名作者共同完成了論文《 XORing Elephants: Novel Erasure Code for Big Data》。 論文作者開發了Erasure Code家族的新成員——Locally Repairable Codes（即本機複本存儲，以下簡稱LRC，它基於XOR。 ），明顯減少修復資料時的I/O和網路流量。 他們將這些編碼應用在新的Hadoop元件中，並稱之為 HDFS–Xorbas，並在Amazon AWS上和Facebook內部做了測試。

從Reed Solomon code到LRC

大約十年前，業界開始採用 Reed Solomon code對資料分發兩份或三份，替代傳統的RAID5或RAID6。 由於採用了廉價的磁片替代昂貴的存儲陣列，所以這種方法非常經濟。 Reed Solomon code和XOR都是Erasure Code的分支。 其中，XOR只允許丟失一塊資料，而Reed Solomon code可以容忍丟失多塊資料。

但標準的Reed Solomon code並不能很好的解決超大規模Hadoop負載。 因為資料修復的時間和花費（主要為I/O和網路流量）成本較高。 同時，在一段時間內，指數級增長的資料超出了互聯網公司的基礎設施能力。 三副本有時候也不能滿足更高的可靠性需求。

現在，這些互聯網巨頭設計的存儲系統標準為：即便四個存儲物件同時失效（這些物件包括磁片、伺服器、節點，甚至整個資料中心），也不能失去任何資料（目前Reed Solomon code是採用（10,4）策略， 即10個數據塊生成4個校驗檔，可以容忍丟失4塊資料。 ）。 從這篇論文來看，Facebook採用Erasure Code方式後，相對於Reed Solomon code只需要60%的I/O和網路流量。

論文作者分析了Facebook的Hadoop集群中的3000個節點，涉及45PB資料。 這些資料平均每天有22個節點失效，有些時候一天的失效節點超過100個，見圖1。

圖1：日節點失效圖

Hadoop集群的網路經常被被動佔用，幾個活躍的磁片就可以占滿1Gb頻寬，修復失效資料產生的擁堵是不可能忽略不計的。 一個理想的存儲方案不僅要保證存儲效率，還要減少修復資料所需的流量。

LRC測試結果的主要指標：

表1：LRC與Reed Solomon code、傳統Hadoop三副本策略對比。 LRC比Reed Solomon code的無故障執行時間提升兩個數量級，修復流量減少一半。

圖2：LRC與Reed Solomon code在多節點、多資料塊失效的情況下，HDFS讀取資料量、網路流量和修復時間的對比，LRC基本上比Reed Solomon code節省一半資源。

包括 HDFS-3544在內，業界正在不斷追求高可靠下對網路頻寬的節省方法，這對於互聯網巨頭和雲計算基礎架構服務商而言的意義不言而喻。 由南加州大學、韋恩州立大學和微軟共同參與的《 Simple Regenerating Codes》也在朝這個方向努力。 值得注意的是，前文所說的LRC、HDFS-3544和《Simple Regenerating Codes》都是通過增加本地資料，來減少修復資料需要的網路流量。

在 ATC2012上，微軟Azure工程師Cheng Huang和他的同事分享了《 Erasure Coding in Windows Azure Storage》。 Cheng Huang表示，微軟在Azure上也使用了LRC技術。 這裡可以看到Cheng Huang此次分享視頻。 另外，Cheng Huang也參與了《Simple Regenerating Codes》。

在國內，Azure在世紀互聯北京、上海的兩個資料中心部署了服務。 在接受CSDN採訪時，微軟雲計算與伺服器事業部總經理嚴治慶 透露：

Windwos Azure上的資料要存放6份，即使是虛機的本機存放區也不例外。 在中國，沒有一家公有雲計算的公司願意去承諾三個9這樣的 SLA，但微軟會承諾3個9或更高。

關於HDFS–Xorbas、LRC和GFS2

目前，HDFS–Xorbas基於Facebook的HDFS-RAID版Hadoop（ GitHub入口、 Apache入口）修改而來，並在 GitHub上託管代碼。

HDFS–Xorbas專案由 Maheswaran Sathiamoorthy維護，他是一名南加州大學謝明電子工程部的候選教授。 諮詢公司TechnoQWAN創始人Robin Harris在 文章中表示：論文中的幾名作者已經創立了公司。

論文作者之一的 Dhruba Borthakur是Facebook的Hadoop工程師，他在2009年的一篇 博客中對Erasure Code進行了介紹：

我知道使用Erasure Code的想法來自 DiskReduce，這是一幫來自卡內基梅隆大學的傢伙搞出來的。 於是我借用了這個想法，並在Apache Hadoop上增加了這一功能 HDFS-503。

Dhruba強調，HDFS Erasure Code只是在HDFS之上的代碼，並沒有對HDFS內部代碼進行修改。 這樣做的原因是HDFS代碼已經十分複雜，不想自找麻煩把它弄的更複雜。

Dhruba還在Hadoop Summit 2012中的一個關於HDFS的 研討會上談到了HDFS-RAID在Facebook內部運行的情況。 資料工程師 梁堰波在 博客中分享了Dhruba的觀點：

存放在HDFS上的資料分為熱資料和冷資料兩種。 熱資料一般是存放三備份，因為這些資料經常會被用到，所以多備份除了高效冗余外還能起到負載均衡的作用。 對於冷資料，並非一定要在HDFS裡面保存3個副本。 Dhruba介紹了兩種不同的RAID方案，對於不太冷的資料塊A/B/C,通過XOR方式產生校驗資料塊，原來的資料塊A/B/C各保留2個副本，校驗資料塊也有兩個副本。 這樣，副本係數就從3減小到了2.6（理論值）。

對於很冷的資料，方案更加激進，由10個數據塊通過Reed Solomon code生成4個校驗檔，對於原來的資料塊，只保留一個副本，校驗資料塊有2份副本。 這樣，副本係數就降到了1.2。

梁堰波在 博客分享了Dhruba介紹的分散式RAID檔案系統實現原理，在2009年Dhruba的博客中也對此進行了介紹，可以分別查閱。

當然，Hadoop不過是GFS的開源實現，那麼Google是如何解決資料修復帶來的高成本呢？ 在Google GFS2（Colossus）中使用了Reed Solomon code來複製。 在Google去年發表的《 Spanner: Google's Globally-Distributed Database》（ CSDN摘譯稿）中透露：

Reed Solomon code可以將原先的3副本減小到1.5副本，提高寫入性能，降低延遲。

但是關於GFS2的資訊，Google透露非常有限。 Google首席工程師Andrew Fikes在Faculty Summit 2010會議上分享了《 Google的存儲架構挑戰》，他談到了Google為什麼使用Reed Solomon  code，並列舉了以下理由：