Hadoop HDFS 數據平衡原理
- 2019 年 12 月 23 日
- 筆記
來源：IBM 本文章介紹HDFS數據平衡以及測試結果，我覺得寫得非常不錯，建議食用
Hadoop 分散式文件系統（Hadoop Distributed FilSystem），簡稱 HDFS，被設計成適合運行在通用硬體上的分散式文件系統。它和現有的分散式文件系統有很多的共同點。HDFS 是一個高容錯性的文件系統，提供高吞吐量的數據訪問，非常適合大規模數據集上的應用。HDFS 是 Apache Hadoop Core 項目一部分。
數據平衡期望滿足的需求
當集群內新增、刪除節點，或者某個節點機器內硬碟存儲達到飽和值時，我們需要對 Hadoop 底層負責存儲數據的 HDFS 進行數據的負載均衡調整，也可以說是各節點機器上數據的存儲分布調整。當數據不平衡時，由於 Map 任務可能會被分配給沒有存儲數據的機器，這會最終導致網路頻寬的消耗。另一方面，當一些數據節點數據完全滿載時，新的數據塊只會被存放在有空餘數據的節點機器上，造成了並行讀取的可能性。
我們所希望的方式必須滿足先決條件：
- 數據平衡不會導致數據塊減少，數據塊備份丟失；
- 管理員可以中止數據平衡進程；
- 每次數據塊移動的大小應該是可控的，這樣可以放置阻塞網路；
- namenode 不會因為數據平衡服務而導致過於繁忙。
Hadoop 提供的自帶工具可以來完成這個任務，並且該工具可以做到熱插拔，即無須重啟電腦和 Hadoop 服務。$Hadoop_Home/bin 目錄下的 start-balancer.sh 腳本就是該任務的啟動腳本。
Hadoop HDFS 數據自動平衡原理
數據平衡過程由於平衡演算法的原因造成它是一個迭代的、周而復始的過程。每一次迭代的最終目的是讓高負載的機器能夠降低數據負載，所以數據平衡會最大程度上地使用網路頻寬。下圖 1 數據平衡流程交互圖顯示了數據平衡服務內部的交互情況，包括 NameNode 和 DataNode。
圖 1. 數據平衡流程交互圖
圖 1 所示步驟分析如下：
- 數據平衡服務首先要求 NameNode 生成 DataNode 數據分布分析報告。
- 選擇所有的 DataNode 機器後，要求 NameNode 匯總數據分布的具體情況。
- 確定具體數據塊遷移路線圖，保證網路內最短路徑，並且確保原始數據塊被刪除。
- 實際開始數據塊遷移任務。
- 數據遷移任務完成後，通過 NameNode 可以刪除原始數據塊。
- NameNode 在確保滿足數據塊最低副本條件下選擇一塊數據塊刪除。
- NameNode 通知數據平衡服務任務全部完成。
HDFS 數據在各個數據節點間可能保存的格式不一致。當存放新的數據塊 (一個文件包含多個數據塊) 時,NameNode 在選擇數據節點作為其存儲地點前需要考慮以下幾點因素：
- 當數據節點正在寫入一個數據塊時，會自動在本節點內保存一個副本。
- 跨節點備份數據塊。
- 相同節點內的備份數據塊可以節約網路消耗。
- HDFS 數據均勻分布在整個集群的數據節點上。
Hadoop HDFS 數據自動平衡腳本使用方法
運行 start-balancer.sh 腳本
格式：$Hadoop_home/bin/start-balancer.sh –threshold<threshold>
清單 1. 運行腳本
$Hadoop_home/bin/start-balancer.sh 啟動數據平衡，默認閾值為 10% bin/start-balancer.sh –threshold 5 啟動數據平衡，閾值 5% 如何停止數據平衡： $Hadoop_home/bin/stop-balancer.sh
hdfs-site.xml 文件里可以設置每秒鐘數據節點間移動數據塊的最大速度。
清單 2. 設置數據塊移動速度
<property> <name>dfs.balance.bandwidthPerSec</name> <value>1048576</value> <description> Specifies the maximum bandwidth that each datanode can utilize for the balancing purpose in term of the number of bytes per second. </description> </property>
上面默認是 1MB/s，速度越快完成任務時間也越短，但是這也對機器進程速度有要求。
注意事項：
- 閾值越小表示集群內各節點的 DFS 使用率越相近，每次需要的數據均衡時間也越久。
- 當應用程式正在使用集群，即對集群進行讀寫文件操作時，無法達到過於小的閾值。
- 每次數據節點的數據遷移交互不會超過 10GB 或者指定的閾值大小數據塊。每一個交互過程不會大於 20 分鐘。
- 上文說明的修改最大移動數據塊速度值需要重新啟動 HDFS 服務才能生效。
- 數據平衡是一個逐漸迭代的過程，可以通過查看輸出日誌知道這個過程，
清單 3. 日誌輸出
imeStamp Iteration# Bytes Already Moved Bytes LeftTo Move Bytes Being Moved June 13, 2014 8:48:13 PM 0 0 KB 40.88 TB 2.03 TB June 13, 2014 8:10:24PM 1 2 TB 38.29 TB 2.01 TB June 13, 2014 8:31:06PM 2 3.98 TB 36.38 TB 1.98 TB June 13, 2014 8:54:58PM 3 5.94 TB 34.42 TB 1.96 TB
該腳本不允許多進程運行。
失敗原因包括下述因素：
- 腳本自動退出條件
- 集群內數據已經達到平衡條件了。
- 沒有數據塊可以被移動。
- 連續三次迭代中都沒有數據塊移動。
- NameNode 交互失敗；
- 另外已經有數據平衡進程啟動。
清單 4. 失敗資訊輸出
The cluster is balanced. Exiting… No block can be moved. Exiting... No block has been moved for 3 iterations. Exiting... Received an IO exception: failure reason. Exiting... Another balancer is running. Exiting...
測試過程及結果
測試集群內有 2 個節點，集群內機器配置完全一致。分別對新增、刪除 1 個節點做數據平衡調整。所有的數據平衡測試都是基於閾值 10%，非此默認值會予以特別說明。
集群機器配置說明如表 1 硬體配置表所示：
表 1. 硬體配置表
根據不同測試場景，舉例出 18 種測試用例，如表 2 測試用例表所示：
表 2. 測試用例表
測試用例運行前，運行 hadoop dfsadmin –report 命令可以查看當前集群內各 DataNode 的數據存儲情況。圖 2 節點機器數據負載情況圖所示，2 個存活的數據節點，分別使用了 21.71%和 21.48%，整個集群的使用是 22.83%，各節點上的百分比與總集群的百分比差距在 1%左右，小於默認的 10%，表明目前負載均衡。
圖 2. 節點機器數據負載情況圖
手動讓集群內數據分布不均勻後開始測試用例測試，測試結果如表 3 測試結果表所示。
表 3. 測試結果表
其他性能改善方法
來自中國吉林大學的三位學者針對跨機架機器的數據平衡演算法進行了深入研究。首先，他們將跨機架的數據節點根據其被使用情況劃分為 4 個類型，
- 大於平均使用；
- 過度使用；
- 小於平均使用；
- 幾乎沒有被使用。
跨機架數據平衡步驟如下所示：
- 首先，數據從類型 2 機器移動到類型 4 機器；
- 其次，數據從類型 2 機器移動到類型 3 機器；
- 最後，數據從類型 1 機器移動到類型 3 機器。
以上步驟在負載沒有達到指定閾值前會迭代式執行。
從實際測試過程來看，如果一個機架內某些機器負載均衡 (屬於類型 1 和類型 3)，剩餘的機器一部分高負載 (屬於類型 2)，一部分幾乎沒有數據 (屬於類型 4)，但從整體來看該機架可能屬於平均負載 (類型 1 和類型 3)，所以在迭代過程中，機架內部資訊沒有被完整地收集清楚並且數據平衡前，該集群不會被加入到本輪迭代的平衡任務中。但是問題是如果錯過本輪數據平衡，也許到下一輪迭代時部分機器已經數據超負荷，甚至導致更嚴重的宕機。
經過一番數學論證後，學者們給出了解決方案，
- 過度使用的機器和大於平均使用的機器以升序形式排序；
- 小於平均使用的機器和幾乎沒有使用的機器以降序形式排序。
結合上述演算法上的改動後做了一些實驗，實驗集群包括 A、B、C 三個機架，其中 A 機架包括三台機器 A1、A2、A3，B 機架包括三台機器 B1、B2、B3，C 機架包括兩台機器 C1、C2。集群架構圖如下圖 3 集群拓撲圖所示：
圖 3. 集群拓撲圖
圖 4 數據負載表中可以看出，數據平衡之前機架 A 基本達到高負荷，機架 B 內的三台機器數據沒有分布均勻，機架 C 內的兩台機器使用率達到平均值。
表 4. 數據負載表
基於兩種演算法的數據平衡測試結果顯示，Hadoop 演算法運行了 7.56 分鐘，改進演算法運行了 6.96 分鐘。Hadoop 演算法最終平衡了機架 A 上的數據，但是花費了 7.56 分鐘。改進演算法在任務運行 2.05 分鐘後即平衡了機架 A 上的數據。所以對比可以看出改進演算法的效率較高。具體數據圖 4 數據負載分析圖。
圖 4. 數據負載分析圖
結束語
通過本文的學習，讀者了解了使用 Hadoop 自帶工具對節點內機器數據存儲進行平衡工作的方式。本文對其工作原理、工作流程等做了詳細描述，從程式碼角度、交互角度等對數據平衡的設計原理做了深入探討。讀者了解到已經有針對 Hadoop 現有數據平衡演算法的優化演算法產生，並且通過論文提供的測試數據可以看到改進演算法的效率相較 Hadoop 自帶演算法而言，更快速、更高效。
