Hadoop3.0時代，怎麼能不懂EC糾刪碼技術？| 個推技術實踐

個推發表於2022-05-27
Hadoop

根據雲端儲存服務商Backblaze釋出的2021年硬碟“質量報告”，現有儲存硬體裝置的可靠性無法完全保證，我們需要在軟體層面通過一些機制來實現可靠儲存。一個分散式軟體的常用設計原則就是面向失效的設計。


backblaze

作為當前廣泛流行的分散式檔案系統，HDFS需要解決的一個重要問題就是資料的可靠性問題。3.0以前版本的Hadoop在HDFS上只能採用多副本冗餘的方式做資料備份，以實現資料可靠性目標（比如，三副本11個9，雙副本8個9）。多副本冗餘的方式雖然簡單可靠，卻浪費了成倍的儲存資源，隨著資料量的增長，將帶來大量額外成本的增加。為了解決冗餘資料的成本問題，在Hadoop3.0版本上，HDFS引入了EC技術（Erasure Code 糾刪碼）。

本文分享EC技術原理及個推的EC實踐，帶大家一起玩轉Hadoop3.0！

EC原理深度解讀

EC技術深度應用於RAID和通訊領域，通過對資料編解碼以實現在部分資料丟失時仍能夠將其恢復。

我們可以這樣理解EC的目標和作用：對n個同樣大小的資料塊, 額外增加m個校驗塊, 使得這n+m個資料中任意丟失m個資料塊或校驗塊時都能恢復原本的資料。

以HDFS的RS-10-4-1024k策略為例，可以實現在1.4倍的資料冗餘的情況下，達到近似於5副本的資料可靠性，也就是說以更小的資料冗餘度獲得更高的資料可靠性。

1、EC演算法

常見的EC演算法有XOR、RS，下面一一做簡要介紹：

//簡單EC演算法：XOR
XOR是一種基於異或運算的演算法，通過對兩個資料塊進行按位異或，就可以得到一個新的資料塊，當這三個資料塊中有任意一個資料塊丟失時，就可以通過另外兩個資料塊的“異或”恢復丟失的資料塊。

HDFS通過XOR-2-1-1024k的EC策略實現了該演算法，這種方式雖然降低了冗餘度，但是隻能容忍三個資料塊中一個丟失，在很多情況下其可靠性依然達不到要求。

//改進的EC演算法：RS
另一種降低冗餘度的編碼方式為Reed-Solomon（RS），它有兩個引數，記為RS(n,m)。其中，n表示資料塊，m表示校驗塊，需要注意的是，RS演算法下，有多少個校驗塊，就表示最多可容忍多少個資料塊（包括資料塊和校驗塊）丟失。

RS 演算法使用生成矩陣（GT，Generator Matrix）與n個資料單元相乘，以獲得具有n個資料單元（data cells）和m個奇偶校驗單元（parity cells）的矩陣。如果儲存失敗，那麼只要n+m個cells中的n個可用，就可以通過生成器矩陣來恢復儲存。

RS演算法克服了XOR演算法的限制，使用線性代數運算生成多個parity cells，以便能夠容忍多個失敗。

下圖形象地描述了RS演算法的編碼與解碼過程：

編碼過程（圖左）：

  • 把m個有效資料組成一個向量D。
  • 生成一個變換矩陣B：由一個n階的單位矩陣和一個n * M的範德蒙特矩陣（Vandemode）組成。
  • 兩矩陣B和D，相乘，得到一個新的具備糾錯能力的矩陣。

解碼過程（圖右）：

  • 取範德蒙矩陣B中沒有丟失的行，構成矩陣B`。
  • 取編碼過程最後計算的矩陣中沒有丟失的行，構成矩陣Survivors。
  • 用B`的逆，乘以Survivors矩陣，即可得到原始的有效資料。

為了更通俗地說明編解碼過程，我們以RS-3-2-1024k策略為例，回顧使用EC演算法進行編解碼的過程。

假設有三塊資料：d1,d2,d3，我們需要額外儲存兩塊資料，使得這五塊資料中，任意丟失兩塊資料，都能將它們完整找回。

首先按編碼過程構建糾錯矩陣：

1、得到向量D

2、生成一個變換矩陣B

3、得到糾錯矩陣D*B

假設d1,d2資料丟失，我們通過解碼做資料恢復：

1、取B中沒有丟失的行，構成矩陣B`

2、取糾錯矩陣中沒有丟失的行，構成矩陣Survivors

3、計算B`的逆為：

4、B`的逆，乘以Survivors矩陣，即可得到原始的有效資料：

至此，我們完成了在原本3個資料塊外再額外儲存2個資料塊，使得這5個資料塊中任意丟失兩個都能將其找回的目標。

與三副本的方式對比，在可靠性方面，三副本方式可以容忍儲存該檔案（資料d1,d2,d3）的機器中任意兩臺當機或壞盤，因為總還有一個副本可用，並通過複製到其他節點恢復到三副本的水平。同樣，在RS-3-2策略下，我們也可以容忍5個資料塊所在的任意2臺機器當機或壞盤，因為總可以通過另外的3個資料塊來恢復丟失的2個資料塊。

由此可見，三副本方式和RS-3-2策略，在可靠性方面基本相當。

在冗餘度（冗餘度=實際儲存空間/有效儲存空間）方面，三副本方式下，每1個資料塊都需要額外的2個資料塊做副本，冗餘度為3/1=3，而在RS-3-2的策略下，每3個資料塊只需要額外的2個資料塊就能夠實現可靠性目標，冗餘度為5/3=1.67。

最終，我們通過RS-3-2的方式能夠在1.67倍冗餘的情況下，實現近似三副本的可靠性。

下圖為Hadoop上，不同策略下的有效資料與冗餘資料佔比示意圖。可以看到，三副本方式的儲存成本是最高的：

2. 條帶佈局

副本策略以塊（Block）為單位，將資料連續寫入Block中，直至達到該Block上限（預設128M），然後再去申請下一個Block。以最常見的三副本方式為例，每個Block會有3個相同資料的副本儲存於3個DataNode（DN）上。

HDFS EC策略採用的是條帶式儲存佈局（Striping Block Layout）。條帶式儲存以塊組（BlockGroup）為單位，橫向式地將資料儲存在各個Block上，同一個Block上不同分段的資料是不連續的，寫完一個塊組再申請下一個塊組。

下圖為連續佈局和RS(3,2)策略下一個BlockGroup佈局對比：

相比於連續佈局，條帶佈局有以下優勢：

  • 支援直接寫入EC資料，不需要做離線轉化
  • 對小檔案更友好
  • I/O並行能力提高

個推在Hadoop2.0上落地EC

個推在很早的時候就對整個叢集做了規劃，將整個Hadoop叢集分為對計算需求比較大的熱叢集和對儲存需求比較大的冷叢集。在Hadoop3.x釋出以後，我們將冷叢集升級到Hadoop3.x版本，進行了包括EC編碼在內的新特性試用。考慮到計算引擎的相容性、穩定性要求，同時為了減少遷移成本，我們仍將熱叢集保持在了Hadoop2.7版本。

計算引擎訪問

由於主要承接計算任務的熱叢集是Hadoop2.x的環境，而內部的計算引擎都不支援Hadoop3.x，所以為了將EC功能在生產環境落地，我們首先要解決在Hadoop2.x上對Hadoop3.x上EC資料進行訪問的能力。為此，我們對Hadoop2.7的hadoop-hdfs做了定製化開發，移植了Hadoop3.x上的EC功能，核心的變動包括：

  • EC編解碼和條帶相關功能引入
  • PB協議的適配
  • 客戶端讀取流程的改造

資源本地化

在部署改造程式碼包的過程中，我們使用Hadoop的“資源本地化”機制，簡化了灰度和上線流程。

所謂“資源本地化”，指的是NodeManager在啟動container以前需要從HDFS上下載該container執行所依賴資源的過程，這些資源包括jar、依賴的jar或者其它檔案。藉助資源本地化的特性，我們就可以將jar包，定製分發到相應計算任務的container中，以控制application級別任務的Container的jar包環境，使後續的測試、灰度驗證和上線非常方便。

SQL訪問

個推目前有大量的任務是通過SQL方式提交的，其中，大部分的SQL任務在提交到Yarn上之後，會轉化為相應計算引擎的計算任務。針對該部分SQL任務，我們可以直接使用第一種解決方案進行訪問。

但是，仍然存在一部分的任務並不通過Yarn提交，而是直接與HDFS做互動，比如一些小資料集計算任務或直接通過limit檢視幾條示例的SQL任務（例如select * from table_name limit 3）。這就需要該部分任務所在的節點，有訪問Hadoop3.x上EC資料的能力。

以Hive為例，下圖為個推環境上Hive訪問HDFS資料的幾種方式，這裡的HiveCli、Hiveserver2都要做相應的適配：

3、損壞校驗

在社群提交的EC相關的bug中，我們發現有一些bug會導致編碼的資料損壞，例如：HDFS-14768、HDFS-15186、HDFS-15240。為了確保轉化後的資料是正確的，我們對編碼後的資料做了塊級別的額外校驗。

在設計校驗程式時，我們不僅要考慮校驗程式的便利性，使其能夠對新EC的資料做校驗，還要對之前已經EC過的資料做一遍校驗。因此，我們主要的思路是利用全部的校驗塊和部分資料塊對編碼後的資料做解碼，來對比解碼後的資料塊和原資料塊是否一致。

我們以RS-3-2-1024k為例，回顧下校驗過程：

基於額外的校驗工具，我們抽取了單副本1PB的EC資料做了驗證，驗證結果顯示，故障的檔案數和大小佔比大約都在百萬分之一以下，可靠性達到目標要求。

展望
目前，我們還需要專門統計和篩選出熱度比較低的資料並過濾掉小檔案，用於後續的EC編碼處理。後續我們將探索設計一套系統，使其能自動感知到資料的熱度下降，並完成資料從副本策略到EC策略的轉化。此外，在intel ISA-L加速庫等方面，我們還將持續展開探索，以提升整個EC編解碼的運算效率。

關注個推技術實踐公眾號，解鎖“大資料降本提效”更多幹貨內容。

彩蛋

“大資料降本提效”系列專欄由每日互動大資料平臺架構團隊深度參與打造。

每日互動大資料平臺架構團隊是負責每日互動大資料平臺研發的核心團隊，基於大資料生態圈開源元件定製優化，助力全公司各項業務的降本提效，歡迎分散式儲存、分散式計算、分散式資料庫等大資料平臺架構領域相關的專家加入和交流。

相關文章