HDFS EC在滴滴的實踐

桔妹導讀：HDFS中默認的3副本方案在存儲空間和其他資源（例如網絡帶寬）上有200％的開銷。對於冷數據，使用糾刪碼（ErasureCoding，EC）存儲代替副本存儲是一種非常不錯的替代方案。EC存儲在保證容錯能力不低於副本存儲的同時，有着更低的存儲空間消耗。HDFS EC在滴滴內部穩定落地已超過半年，爲公司節約了大量的存儲成本。本文將介紹EC在滴滴內部的實踐情況。

EC原理

▍1. EC算法

EC是一種編碼容錯技術，最早用於通信行業數據傳輸中的數據恢復。Hadoop3.0版本將EC加入到HDFS中。這裏簡要介紹EC中使用廣泛的兩個算法：XOR Codes與Reed-Solomon Codes。

XOR Codes

XOR編碼即“異或”編碼，其原理是：數據編碼時按照位進行異或運算，數據解碼（數據恢復）時則通過結果與其他數據位進行異或操作。這裏，我們不妨抽象成數學運算用於解釋，例如：1 ⊕ 1 = 0 中，運算位中的任何一位丟失，則能通過另外兩位計算得出，但是如果丟失兩位則無法恢復。對應到HDFS中，實現該算法的EC策略是XOR-2-1-1024k，如果使用XOR編碼3個數據塊，則最多能容忍一個數據塊丟失。該編碼常用於HDFS測試。

Reed-Solomon Codes

Reed-Solomon Codes縮寫爲RS碼，使用複雜的線性代數運算來生成多個奇偶校驗塊，因此可以容忍多個數據塊故障。RS碼在使用的時候需指定2個參數RS(n, m)，n代表的是數據塊的數量，m代表的是校驗塊的數量，校驗塊由數據塊編碼產生。RS編碼的編碼與解碼原理如圖1所示（網絡圖）。編碼時，利用生成矩陣B（這裏選用範德蒙單位矩陣）與數據列向量D的乘積得到信息列向量D+C；重構時，利用現存的信息列向量Survivors與對應的逆矩陣B'-1 乘積得到原數據列向量D，從而達到恢復原數據的目的。

圖1 RS編碼的編碼與重構原理

▍2.HDFS EC塊佈局

先回顧一下3副本存儲的連續存儲方式（Contiguous Block Layout），3副本存儲以塊（Block）爲單位，會將數據連續寫入Block中，直至達到該Block大小（如128M）再去申請下一個Block，每個Block會有3個相同數據的副本存於3個DataNode（DN）上。連續存儲示意圖如圖2(a)所示。HDFS EC採用條帶條帶式存儲佈局（Striping Block Layout）。條帶式存儲是以塊組（BlockGroup）爲單位，橫向式地將數據保存在各個Block上，同一個Block上的不同分段的數據是不連續的。寫完一個塊組再申請下一個塊組。條帶式的存儲結構圖2(b)所示（圖示爲RS(6,3)策略下1個BlockGroup佈局示意圖）。

圖2(a) 3副本存儲示意圖

圖2(b) EC存儲示意圖

EC在滴滴的實踐

▍1. EC落地工作

爲了將EC存儲引入生產環境，我們做了如下的定製和優化。

升級NameNode與DataNode到3.2版本

EC是Hadoop3纔有的新特性，因此服務端需要升級。在EC投入生產環境之前，滴滴內部已經完成了HDFS 2.7版本到3.2版本的滾動升級（不停服務，對用戶無感知）。版本升級的相關總結見「 HDFS3.2升級在滴滴的實踐」。

定製Hadoop2兼容EC讀寫客戶端

客戶端（Client）受到Spark，Hive，Flink等很多組件依賴，目前這些組件還不支持Hadoop3，因此客戶端暫時保持2.7版本不變，這就要求內部的Hadoop2.7版本客戶端要做EC讀寫兼容。我們將Hadoop3.2中的hadoop-common、hadoop-hdfs、hadoop-hdfs-client 中關於EC讀寫相關部分移植到Hadoop2.7版本。同時，RBF部分也需要做相應的兼容工作。這裏，我們展示一些代碼舉例，例如，在hdfs.proto協議和ClientNamenodeProtocol.proto協議中，我們增加了EC相關字段：

自研轉EC系統

目前，將文件轉爲EC存儲的途徑是將文件寫入啓用EC特性的目錄中（社區正在開發更優雅的方式見： HDFS-14978）。將文件/目錄mv到已啓用EC的目錄不會自動轉換存儲方式，只有寫操作纔會。因此，通常執行以下步驟來將副本存儲方式的文件轉EC存儲方式：

爲了能夠可靠地、高效地將副本文件轉EC，滴滴內部做了如下工作：

定製distcp工具。在將副本文件轉EC文件後，必須要保證數據一致性。這就要求複製的源和目標文件checksum必須相同。由於存儲方式不同，使用傳統的CRC校驗方式不能適用於副本文件和EC文件的校準。因此，定製版本將Hadoop3中的COMPOSITE_CRC校驗方式（HDFS-13056）引入到Hadoop2的distcp中供內部使用。
自研轉EC系統（Anty系統）用於週期性（或手動）執行轉EC作業，以及統計集羣EC文件存儲量、佔比等信息。具體介紹見後文的實踐場景部分。

定製離線計算物理空間工具

內部資產平臺需要週期性地離線分析整個集羣的存儲空間用於評估成本。若對每個文件使用du命令將對NameNode產生不小的壓力。解析fsimage鏡像文件可以得到每個文件的邏輯大小，副本文件的物理空間計算非常簡單，即邏輯大小 * 副本因子；EC文件的物理空間由於其條帶式存儲而複雜許多，這裏簡要介紹下計算方法。

考慮到最後一個塊組的最後一個strip有兩種情況（如圖3所示）：

第一個塊的cell寫滿了，則校驗塊cell大小也寫滿
第一個塊的cell只寫了k (k<cellSize) 字節，則每個校驗塊也是k字節

圖3 最後一個strip cell寫滿情況示意圖

爲了簡化計算，可以不用考慮有多少個塊組，只關心一共寫了多少strip。EC物理存儲計算示意圖4所示。

圖4 EC物理存儲計算示意圖

部分代碼如下所示：

FastCopy支持EC文件的改進

由於在Federation集羣中會有集羣間數據遷移的情況，在3副本文件場景下FastCopy（HDFS-2139）是一個高效的遷移方案，其通過將塊進行硬鏈接的方式來達到快速遷移的目的。由於FastCopy不支持EC文件操作，滴滴內部版本做了FastCopy兼容EC文件的改進，極大地方便了Federation集羣間的數據遷移。

▍2. EC的實踐場景

首先要考慮的是EC策略的選擇。通過hdfs ec -listPolicies命令可以列出已經實現的EC策略。各個策略的一些特性如表1所示。

表1 EC策略特性對比

綜合考慮，滴滴內部只開啓了RS-6-3-1024k策略。考慮到EC策略目錄的規範性，目前只支持管理員設置EC策略。

實踐1：冷數據轉EC存儲

國內離線集羣已有上百P的邏輯數據，數據量的增長對集羣的存儲也帶來了一定壓力。爲了節約存儲成本，滴滴內部對冷數據進行了轉EC存儲。考慮到並不是所有3副本文件在轉EC後都有更少的空間存儲，這裏需要對轉EC的文件做大小限制。在RS(6,3)策略下，我們限制待轉EC的目錄下的非空平均文件大小>=6M。數據源選擇如圖5所示。