XORing Elephants: Novel Erasure Codes for Big Data
RS基礎上做了改進，通過增加儲存冗餘，優化效能
1. INTRODUCTION
介紹了多副本，糾刪碼。
糾刪碼的修復主要問題是，頻寬開銷，假如是（10，4），修復一塊需要10倍塊大小的頻寬
提出了LRC的概念
1.1. Importance of Repair
分析了Facebook的相關資料得出降低網路頻寬代價是重要的結論
efficiently repairable重要的原因
-
degraded reads
很多瞬時錯誤並不會丟失永久性資料，但是會造成資料不可用，這個時候讀編碼的條塊會讀降級。
這個時候可以通過修復過程重建資料塊，但是目的不是容錯，而是為了更高的資料可用性。重建的塊不必寫入磁碟
所以efficient and fast repair 可以提高資料可用性
-
efficient node decommissioning
Hadoop可以讓故障節點退役
Functional data必須在退役之前從節點中複製出來，這是一個複雜且耗時的過程
Fast repairs可以把節點退役視為定期修復，並且重新建立塊，不會產生非常大的網路流量
-
repair influences the performance of other concurrent MapReduce jobs
因為修復需要佔用一定的網路頻寬，與資料中心的網路頻寬相比，儲存空間的增長速度不成比例地快。所以這個問題會越來越嚴重，所以local repairs顯得越發重要
-
local repair would be a key in facilitating geographically distributed file systems across data centers
RS在跨地理的程度上是不可行的 因為high bandwidth requirements across wide area networks
local repair是可行的
複製可以很好的處理上面的問題，但是儲存開銷較大。MDS開銷小，但是會遇到上面的問題。
本文可以看作是犧牲了一些儲存效率，來達到其他指標
2. THEORETICAL CONTRIBUTIONS
MDS在通訊和儲存領域應用非常廣泛
MDS是最低恢復冗餘
兩個定義
-
Minimum Code Distance
-
Block Locality
locality和good distance是矛盾的
LRC(k, n−k, r)
2.1. LRC implemented in Xorbas
Ci的選擇有要求 線性無關，不能為0
設計了一個隨機演算法和確定演算法，可以生成係數
有個優化S3不用儲存，構造出來S1+S2+S3=0
係數的構造
3. SYSTEM DESCRIPTION
在HDFS-RAID上實現
RaidNode
負責建立和維護校驗塊
BlockFixer
用來修復塊
ErasureCode
實現編碼和解碼功能，上面兩個元件都依賴於他
HDFS-Xorbas 在HDFS-RAID基礎上增加了LRC
3.1. HDFS-Xorbas
3.1.1. 編碼
RaidNode 將一個檔案分成10塊，然後編碼出4塊。可能一個檔案可能不夠10塊，預設剩下的填充為0，依舊是10塊
LRC會額外計算兩個塊，如上圖所示
3.1.1.2 解碼和修復
RaidNode
light-decoder
針對於每個條帶單個塊的錯誤
heavy-decoder
light-decoder失敗的時候使用
BlockFixer
檢測到塊失敗，決定LRC恢復需要的5個塊
light-decoding嘗試恢復
如果出現multiple failures，可能沒有需要的5個塊， light-decoder失敗， heavy-decoder啟動
heavy-decoder跟RS恢復過程一樣，將結果傳送和儲存到資料節點
4.RELIABILITY ANALYSIS
mean-time to data loss (MTTDL) 可靠性分析的依據
可以容忍的故障數
修復的速度
彈性增加和修復時間減小，MTTDL也會增加
結果LRC，RS比複製高了很多，但是複製的資料可用性比LRC和RS強
5. EVALUATION
兩種環境效能
Amazon’s Elastic Compute Cloud
a test cluster in Facebook
5.1 評價指標
HDFS Bytes Read
對應於為修復而啟動的作業所讀取的總資料量
collected from the statistics-reports of the jobs spawned following a failure event
Network Traffic
the total amount of data communicated from nodes in the cluster
單位為GB
用下面這個工具來監測
Amazon’s A WS Cloudwatch monitoring tools
Repair Duration
the time interval between the starting time of the first repair job and the ending time of the last repair job.
5.2 EC2
two Hadoop clusters
HDFS-Xorbas
HDFS-RS
Each cluster
51 instances of type m1.small
1 master hosting Hadoop’s NameNode, JobTracker and RaidNode daemons
50 slave as DataNode and a TaskTracker daemon
file size 640 MB
block size 64MB
每個檔案兩個叢集中分別生成14和16塊
故障包括一個數據節點或者多個數據節點的終止
四個故障事件是單節點錯誤，兩個三節點錯誤，兩個兩節點錯誤
檔案數量（20，100，200）
5.2.1 HDFS Bytes Read
HDFS-Xorbas 比HDFS-RS好41%-52%
讀的平均塊數從11.5降到5.8
5.2.2 Network Traffic
網路流量和讀取的位元組數基本上一致，二倍的關係
5.2.3 Repair Time
Xorbas比HDFS-RS快25%到45%
實驗裡面頻寬沒滿，實際環境中頻寬可能跑滿，時間表現可能更好
5.2.4 Repair under Workload
為了演示修復效能對叢集負載的影響。
建立了兩個叢集
每個叢集15個從節點
塊故障時不可用，LRC相比RS延遲小
5.3 Facebook’s cluster
區別點在於利用的叢集中現有的資料集
塊大小為256MB
94%檔案3塊 剩下10塊 平均3.4塊
由於塊大小比較小，Xorbas比HDFS-RS儲存開銷大了27%（最好應為13%）
6. RELATED WORK
functional repair
雖然塊可以恢復，但是這個時候確實不可使用，需要其他k塊來恢復
exact repair
使用更小網路代價來修復是有可能的
low rate
high rate
這部分涉及到的工作還挺多的，有時間可以看一看具體內容
7. CONCLUSIONS
LRC降低頻寬開銷2倍，增加儲存開銷14%
提出了想法，應用在寬條帶上，RS在寬條帶上不可行，因為頻寬要求隨著塊大小增長