Hadoop HDFS 数据平衡原理

来源：IBM 本文章介绍HDFS数据平衡以及测试结果，我觉得写得非常不错，建议食用

Hadoop 分布式文件系统（Hadoop Distributed FilSystem），简称 HDFS，被设计成适合运行在通用硬件上的分布式文件系统。它和现有的分布式文件系统有很多的共同点。HDFS 是一个高容错性的文件系统，提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS 是 Apache Hadoop Core 项目一部分。

数据平衡期望满足的需求

当集群内新增、删除节点，或者某个节点机器内硬盘存储达到饱和值时，我们需要对 Hadoop 底层负责存储数据的 HDFS 进行数据的负载均衡调整，也可以说是各节点机器上数据的存储分布调整。当数据不平衡时，由于 Map 任务可能会被分配给没有存储数据的机器，这会最终导致网络带宽的消耗。另一方面，当一些数据节点数据完全满载时，新的数据块只会被存放在有空余数据的节点机器上，造成了并行读取的可能性。

我们所希望的方式必须满足先决条件：

1. 数据平衡不会导致数据块减少，数据块备份丢失；
2. 管理员可以中止数据平衡进程；
3. 每次数据块移动的大小应该是可控的，这样可以放置阻塞网络；
4. namenode 不会因为数据平衡服务而导致过于繁忙。

Hadoop 提供的自带工具可以来完成这个任务，并且该工具可以做到热插拔，即无须重启计算机和 Hadoop 服务。$Hadoop_Home/bin 目录下的 start-balancer.sh 脚本就是该任务的启动脚本。

Hadoop HDFS 数据自动平衡原理

数据平衡过程由于平衡算法的原因造成它是一个迭代的、周而复始的过程。每一次迭代的最终目的是让高负载的机器能够降低数据负载，所以数据平衡会最大程度上地使用网络带宽。下图 1 数据平衡流程交互图显示了数据平衡服务内部的交互情况，包括 NameNode 和 DataNode。

图 1. 数据平衡流程交互图

图 1 所示步骤分析如下：

1. 数据平衡服务首先要求 NameNode 生成 DataNode 数据分布分析报告。
2. 选择所有的 DataNode 机器后，要求 NameNode 汇总数据分布的具体情况。
3. 确定具体数据块迁移路线图，保证网络内最短路径，并且确保原始数据块被删除。
4. 实际开始数据块迁移任务。
5. 数据迁移任务完成后，通过 NameNode 可以删除原始数据块。
6. NameNode 在确保满足数据块最低副本条件下选择一块数据块删除。
7. NameNode 通知数据平衡服务任务全部完成。

HDFS 数据在各个数据节点间可能保存的格式不一致。当存放新的数据块 (一个文件包含多个数据块) 时,NameNode 在选择数据节点作为其存储地点前需要考虑以下几点因素：

1. 当数据节点正在写入一个数据块时，会自动在本节点内保存一个副本。
2. 跨节点备份数据块。
3. 相同节点内的备份数据块可以节约网络消耗。
4. 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，速度越快完成任务时间也越短，但是这也对机器进程速度有要求。

注意事项：

1. 阈值越小表示集群内各节点的 DFS 使用率越相近，每次需要的数据均衡时间也越久。
2. 当应用程序正在使用集群，即对集群进行读写文件操作时，无法达到过于小的阈值。
3. 每次数据节点的数据迁移交互不会超过 10GB 或者指定的阈值大小数据块。每一个交互过程不会大于 20 分钟。
4. 上文说明的修改最大移动数据块速度值需要重新启动 HDFS 服务才能生效。
5. 数据平衡是一个逐渐迭代的过程，可以通过查看输出日志知道这个过程，

清单 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

该脚本不允许多进程运行。

失败原因包括下述因素：

1. 脚本自动退出条件
2. 集群内数据已经达到平衡条件了。
3. 没有数据块可以被移动。
4. 连续三次迭代中都没有数据块移动。
5. NameNode 交互失败；
6. 另外已经有数据平衡进程启动。

清单 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 个类型，

1. 大于平均使用；
2. 过度使用；
3. 小于平均使用；
4. 几乎没有被使用。

跨机架数据平衡步骤如下所示：

1. 首先，数据从类型 2 机器移动到类型 4 机器；
2. 其次，数据从类型 2 机器移动到类型 3 机器；
3. 最后，数据从类型 1 机器移动到类型 3 机器。

以上步骤在负载没有达到指定阈值前会迭代式执行。

从实际测试过程来看，如果一个机架内某些机器负载均衡 (属于类型 1 和类型 3)，剩余的机器一部分高负载 (属于类型 2)，一部分几乎没有数据 (属于类型 4)，但从整体来看该机架可能属于平均负载 (类型 1 和类型 3)，所以在迭代过程中，机架内部信息没有被完整地收集清楚并且数据平衡前，该集群不会被加入到本轮迭代的平衡任务中。但是问题是如果错过本轮数据平衡，也许到下一轮迭代时部分机器已经数据超负荷，甚至导致更严重的宕机。

经过一番数学论证后，学者们给出了解决方案，

1. 过度使用的机器和大于平均使用的机器以升序形式排序；
2. 小于平均使用的机器和几乎没有使用的机器以降序形式排序。

结合上述算法上的改动后做了一些实验，实验集群包括 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 自带算法而言，更快速、更高效。