HDFS 糾刪碼

目的

HDFS 集羣中經常配置的3個副本是很佔用空間的 - HDFS中的默認3x 複製方案在存儲空間和其他資源(例如，網絡帶寬)上有 200%的開銷。但是，對於具有較低 I/O 活動的暖數據集和冷數據集，在正常操作期間很少訪問其他塊副本，但仍然消耗與第一個副本相同的資源。

因此，一種自然的改進是使用 Erasure Coding (EC) 來代替複製，它提供了相同級別的容錯能力，但存儲空間要小得多。在典型的 Erasure Coding (EC) 設置中，存儲開銷不超過50%。EC 文件的複製因子是無意義的。它總是1，不能通過 -setrep 命令更改。

背景

在存儲系統中，EC 最顯著的用法是廉價磁盤冗餘陣列(RAID)。RAID 通過條帶實現 EC，條帶將邏輯上順序的數據(如文件)劃分爲更小的單元(如位、字節或塊)，並在不同的磁盤上存儲連續的單元。在本指南的其餘部分中，條帶分佈的單位被稱爲條帶單元(或單元)。對於每條原始數據單元，計算並存儲一定數量的奇偶校驗單元，此過程稱爲編碼。任何條帶單元上的錯誤都可以通過基於存活數據和奇偶校驗單元的解碼計算來恢復。

將 EC 與 HDFS 集成可以提高存儲效率，同時仍然提供與傳統基於副本的 HDFS 部署類似的數據持久性。例如，一個具有6個塊的3x複製文件將消耗6*3 = 18塊磁盤空間。但是對於 EC (6 data, 3 parity)部署，它只會消耗9塊磁盤空間。

架構

在電子商務的背景下，條帶化具有幾個關鍵的優勢。首先，它啓用了在線 EC(立即以 EC 格式寫入數據)，避免了轉換階段，並立即節省了存儲空間。在線電子商務還提高了連續 I/O 性能，利用多個磁盤主軸並行；這在具有高端網絡的集羣中尤其可取。其次，它自然地將一個小文件分發到多個 datanode，並消除了將多個文件捆綁到單個編碼組的需要。這極大地簡化了文件操作，例如刪除、配額報告和在聯邦名稱空間之間遷移。

在典型的 HDFS 集羣中，小文件佔總存儲消耗的 3/4 以上。爲了更好地支持小文件，在第一階段的工作中，HDFS 支持帶條帶的 EC。將來，HDFS 還將支持連續的 EC 佈局。

• NameNode Extensions - 分段的 HDFS 文件在邏輯上由塊組組成，每個塊組包含一定數量的內部塊。爲了減少這些額外塊的 NameNode 內存消耗，引入了一種新的分層塊命名協議。塊組的 ID 可以從其內部塊的 ID 推斷出來。這允許在塊組級別而不是塊級別進行管理。

• Client Extensions - 客戶端讀和寫路徑得到了增強，可以並行地處理一個塊組中的多個內部塊。在輸出/寫入路徑上， DFSStripedOutputStream 管理一組數據流，每個 DataNode 都有一個數據流，用於存儲當前塊組中的一個內部塊。流媒體大多是異步工作的。協調器負責對整個塊組的操作，包括結束當前塊組、分配新塊組等等。在輸入/讀取路徑上， DFSStripedInputStream 將請求的邏輯字節範圍的數據轉換爲存儲在 datanode 上的內部塊。然後並行地發出讀請求。如果失敗，它會發出額外的讀請求進行解碼。

• DataNode Extensions - DataNode 運行一個額外的 ErasureCodingWorker (ECWorker)任務，用於後臺恢復失敗的擦除代碼塊。失敗的 EC 塊由 NameNode 檢測，然後由 NameNode 選擇一個 DataNode 來執行恢復工作。恢復任務作爲心跳響應傳遞。這個過程類似於在失敗時重新複製已複製的塊。重構有三個關鍵任務：

  • 1、從源節點讀取數據：使用專用線程池並行地從源節點讀取輸入數據。基於 EC 策略，它將讀請求調度到所有源目標，並且只讀取用於重構的最小輸入塊數。

  • 2、解碼數據並生成輸出數據：從輸入數據中解碼出新的數據和奇偶校驗塊。所有丟失的數據和奇偶校驗塊一起被解碼。

  • 3、將生成的數據塊傳輸到目標節點：解碼完成後，將恢復的數據塊傳輸到目標 datanode。

• Erasure coding policies 爲了適應不同的工作負載，我們允許 HDFS 集羣中的文件和目錄具有不同的複製和 EC 策略。擦除編碼策略封裝瞭如何對文件進行編碼/解碼。每個策略由以下信息定義：

  • 1、EC 模式：這包括 EC 組(如6+3)中的數據和奇偶校驗塊的數量，以及編解碼器算法(如Reed-Solomon、XOR)。

  • 2、條帶化大小：這決定了條帶化讀寫的粒度，包括緩衝區大小和編碼工作。

策略被命名爲 codec-num 數據塊 -num奇偶校驗塊-單元大小。目前支持5種內置策略：RS-3-2-1024k、RS-6-3-1024k、RS-10-4-1024k、RS-LEGACY-6-3-1024k、XOR-2-1-1024k。

還支持默認的複製方案。它只能在目錄上設置，以強制目錄採用 3x 複製方案，而不是繼承其祖先的 EC 策略。該策略使 3x 複製方案目錄與 EC 目錄交叉成爲可能。

始終啓用複製。在所有 EC 策略中，RS(6,3)在默認情況下是啓用的。

與 HDFS 存儲策略類似，EC 策略是在目錄上設置的。創建文件時，它繼承最近的祖先目錄的 EC 策略。

目錄級的 EC 策略隻影響在目錄中創建的新文件。一旦創建了一個文件，就可以查詢它的 EC 策略，但不能更改它。如果將 EC 文件重命名爲具有不同 EC 策略的目錄，則該文件將保留其現有 EC 策略。將文件轉換爲不同的 EC 策略需要重寫其數據；通過複製文件(例如，通過 distcp)而不是重命名文件來實現這一點。

我們允許用戶通過一個 XML 文件定義他們自己的 EC 策略，該文件必須包含以下三個部分：

1. layoutversion: 這表示 EC policy XML 文件格式的版本。

2. schemas: 這包括所有用戶定義的EC模式。

3. policies: 這包括所有用戶定義的 EC 策略，每個策略由模式 id 和分段單元格(cellsize)的大小組成。

一個名爲 user_ec_policies.xml 的示例 EC 策略 XML 文件。模板位於 Hadoop conf 目錄中，用戶可以引用它。

• Intel ISA-L Intel ISA-L 代表 Intel 智能存儲加速庫。ISA-L 是一個爲存儲應用程序設計的優化的底層函數的開源集合。它包括爲英特爾 AVX 和 AVX2 指令集優化的快速塊 Reed-Solomon 類型擦除代碼。HDFS EC 可以利用 ISA-L 加速編碼和解碼計算。ISA-L 支持大多數主要的操作系統，包括 Linux 和 Windows。默認情況下沒有啓用 ISA-L。有關如何啓用 ISA-L，請參閱下面的說明。

部署

集羣和硬件配置

EC 在 CPU 和網絡方面對集羣提出了額外的要求。

編碼和解碼工作消耗 HDFS 客戶端和 DataNode 上的額外 CPU。

EC 要求集羣中的 DataNode 數量至少與配置的 EC 條帶寬度相同。對於 EC 策略RS(6,3)，這意味着至少有 9個 datanode。

EC 文件也分佈在機架上，以獲得機架的容錯能力。這意味着當讀取和寫入條帶文件時，大多數操作都是 off-rack。因此，網絡對分帶寬非常重要。

對於機架容錯，擁有足夠的機架數量也很重要，這樣，平均而言，每個機架擁有的塊的數量不超過 EC 奇偶校驗塊的數量。計算這個的公式是(數據塊+奇偶校驗塊)/奇偶校驗塊，向上舍入。對於 EC 策略 RS(6,3)，這意味着最少3個機架(通過(6 + 3)/ 3 = 3計算)，理想情況下是 9 個或更多機架來處理計劃內和計劃外停機。對於機架數量少於奇偶校驗單元數量的集羣，HDFS 不能維護機架的容錯能力，但仍然會嘗試跨多個節點傳播帶條文件，以保持節點級別的容錯能力。由於這個原因，建議使用相同數量的 datanode 來設置機架。

配置 Keys

默認情況下，所有內置的 EC 策略都是禁用的，除了在默認情況下啓用的 dfs.namenode.ec.system.default.policy 中定義的策略。集羣管理員可以根據集羣的大小和所需的容錯屬性，通過 hdfs ec [-enablePolicy -policy <policyName>] 命令啓用一組策略。例如，對於有 9 個機架的集羣，RS-10-4-1024k 這樣的策略將不能保持機架級容錯，而 RS-6-3-1024k 或 RS-3-2-1024k 可能更合適。如果管理員只關心節點級容錯，只要集羣中至少有14個 datanode, RS-10-4-1024k 仍然是合適的。

系統默認的 EC 策略可以通過' dfs.namenode.ec.system.default.policy '配置來配置。使用此配置，當“-setPolicy”命令中沒有將策略名稱作爲參數傳遞時，將使用默認的 EC 策略。

默認情況下，“dfs.namenode.ec.system.default.policy”爲“RS-6-3-1024k”。

Reed-Solomon 和 XOR 的編解碼器實現可以使用以下客戶機和 DataNode 配置鍵配置：io.erasurecode.codec.rs。默認 RS 編解碼器的 rawcoders, io.erasureco.codec . RS -legacy。爲遺留RS編解碼器的 rawcoders, io.erasureco.codec .xor。XOR 編解碼器的 rawcoders。用戶也可以配置自定義的編解碼器與配置鍵像：io.erasurecode.codec.self-defined-codec.rawcoders。這些鍵的值是帶有回退機制的編碼器名稱列表。這些編解碼器工廠將按照配置值指定的順序加載，直到成功加載編解碼器爲止。默認的 RS 和 XOR 編解碼器配置更喜歡本機實現，而不是純 Java 實現。沒有 rs 遺留的本地編解碼器實現，因此默認是純 Java 實現。所有這些編解碼器都用純 Java 實現。對於默認的 RS 編解碼器，還有一個原生實現，它利用 Intel ISA-L 庫來提高編解碼器的性能。對於 XOR 編解碼器，還支持利用 Intel ISA-L 庫來提高編解碼器性能的本地實現。請參閱“啓用Intel ISA-L”一節以獲得更多詳細信息。RS Legacy 的缺省實現是純 Java，缺省 RS 和 XOR 的缺省實現是使用 Intel ISA-L 庫的本機實現。

DataNode 上的 EC 後臺恢復工作也可以通過以下配置參數進行調整：

1. dfs.datanode.ec.reconstruction.stripedread.timeout.millis - 條帶讀取的超時。默認值是5000毫秒。
2. dfs.datanode.ec.reconstruction.stripedread.buffer.size - 閱讀器服務的緩衝區大小。默認值爲64KB。
3. dfs.datanode.ec.reconstruction.threads - Datanode 用於後臺重構工作的線程數。默認值是8個線程。
4. dfs.datanode.ec.reconstruction.xmits.weight - EC 後臺恢復任務中 xmits 的相對權重與複製塊恢復的比較。默認值是0.5。它設置爲 0 來禁用 EC 恢復任務的計算權重，即 EC 任務總是有 1 xmits。EC 恢復任務的 xmits 計算爲讀流數和寫流數之間的最大值。例如，一個 EC 恢復任務需要從 6 個節點讀取數據，向 2 個節點寫入數據，那麼它的 xmits max(6,2) * 0.5 = 3。複製文件的恢復任務總是計算爲1 xmit。NameNode 利用 dfs. NameNode . copy .max-streams 減去合併了來自複製文件的xmits 和 EC 文件的 DataNode 上的 xmitsInProgress 總數，將恢復任務調度到該 DataNode。

啓用 Intel ISA-L

默認 RS 編解碼器的 HDFS 本機實現利用 Intel ISA-L 庫來改進編碼和解碼計算。要啓用和使用 Intel ISA-L，需要三個步驟。

1. Build ISA-L library. 詳細信息請參考官方網站“https://github.com/01org/isa-l/”。
2. Build Hadoop with ISA-L support. 請參閱源代碼(build .txt)中“Hadoop構建說明”中的“Intel iso - l構建選項”一節。
3. Use -Dbundle. 複製 isal 的內容。將 lib 目錄轉換爲最終的 tar 文件。使用 tar 文件部署 Hadoop。確保 iso - l 在 HDFS 客戶機和 DataNode 上可用。

要驗證 Hadoop 正確地檢測到 ISA-L，請運行 Hadoop checknative 命令。

管理命令

HDFS 提供了一個 ec 子命令來執行與 EC 相關的管理命令。

  hdfs ec [generic options]
     [-setPolicy -path <path> [-policy <policyName>] [-replicate]]
     [-getPolicy -path <path>]
     [-unsetPolicy -path <path>]
     [-listPolicies]
     [-addPolicies -policyFile <file>]
     [-listCodecs]
     [-enablePolicy -policy <policyName>]
     [-disablePolicy -policy <policyName>]
     [-help [cmd ...]]

下面是關於每個命令的詳細信息。

• [-setPolicy -path <path> [-policy <policyName>] [-replicate]]

  在指定路徑上的目錄上設置 EC 策略。

  path: HDFS 中的一個目錄。這是一個強制參數。設置策略隻影響新創建的文件，而不影響現有的文件。

  policyName: 用於此目錄下文件的 EC 策略。如果設置了“dfs.namenode.ec.system.default.policy”配置，則可以省略此參數。該路徑的 EC 策略將在配置中使用默認值設置。

  -replicate 對目錄應用默認複製方案，強制該目錄採用3x複製方案。

  -replicate 和 -policy <policyName> 是可選的參數。不能同時指定它們。

• [-getPolicy -path <path>]

  獲取指定路徑上文件或目錄的 EC 策略的詳細信息。

• [-unsetPolicy -path <path>]

  取消先前對目錄上的 setPolicy 調用所設置的 EC 策略。如果該目錄從一個祖先目錄繼承 EC 策略，則 unsetPolicy 爲無操作。在沒有顯式策略集的目錄上取消策略設置不會返回錯誤。

• [-listPolicies]

  列出在 HDFS 中註冊的所有(啓用、禁用和刪除)EC 策略。只有啓用的策略適合與 setPolicy 命令一起使用。

• [-addPolicies -policyFile <file>]

  添加用戶定義的 EC 策略列表。請參考等/ hadoop / user_ec_policies.xml。示例策略文件的模板。最大單元格大小在屬性' dfs.namenode.ec.policies.max.cellsize '中定義，默認值爲 4MB。目前 HDFS 允許用戶總共添加 64 個策略，添加的策略 ID在 64 到 127 之間。如果已經添加了 64 個策略，則添加策略將失敗。

• [-listCodecs]

  獲取系統中支持的 EC 編解碼器和編碼器的列表。編碼器是編解碼器的一種實現。一個編解碼器可以有不同的實現，因此不同的編碼器。編解碼器的編碼器是列出在一個後退順序。

• [-removePolicy -policy <policyName>]

  刪除用戶定義的 EC 策略。

• [-enablePolicy -policy <policyName>]

  啓用 EC 策略。

• [-disablePolicy -policy <policyName>]

  禁用 EC 策略。

侷限

某些 HDFS 操作，例如。刪除編碼文件不支持 hflush、hsync、concat、setReplication、truncate和append，因爲存在重大的技術挑戰。

• append() and truncate() on an erasure coded file will throw IOException.
• concat() will throw IOException if files are mixed with different erasure coding policies or with replicated files.
• setReplication() is no-op on erasure coded files.
• hflush() and hsync() on DFSStripedOutputStream are no-op. Thus calling hflush() or hsync() on an erasure coded file can not guarantee data being persistent.

客戶端可以使用 StreamCapabilities API 來查詢 OutputStream 是否支持 hflush()和 hsync()。如果客戶端希望通過 hflush()和 hsync()實現數據持久性，當前的補救方法是在一個非 EC 的目錄中創建常規 3x 複製文件，或者使用 FSDataOutputStreamBuilder# replication () API 在一個 EC 的目錄中創建 3x 複製文件。