来源:IBM 本文章介绍HDFS数据平衡以及测试结果,我觉得写得非常不错,建议食用
Hadoop 分布式文件系统(Hadoop Distributed FilSystem),简称 HDFS,被设计成适合运行在通用硬件上的分布式文件系统。它和现有的分布式文件系统有很多的共同点。HDFS 是一个高容错性的文件系统,提供高吞吐量的数据访问,非常适合大规模数据集上的应用。HDFS 是 Apache Hadoop Core 项目一部分。
当集群内新增、删除节点,或者某个节点机器内硬盘存储达到饱和值时,我们需要对 Hadoop 底层负责存储数据的 HDFS 进行数据的负载均衡调整,也可以说是各节点机器上数据的存储分布调整。当数据不平衡时,由于 Map 任务可能会被分配给没有存储数据的机器,这会最终导致网络带宽的消耗。另一方面,当一些数据节点数据完全满载时,新的数据块只会被存放在有空余数据的节点机器上,造成了并行读取的可能性。
我们所希望的方式必须满足先决条件:
Hadoop 提供的自带工具可以来完成这个任务,并且该工具可以做到热插拔,即无须重启计算机和 Hadoop 服务。$Hadoop_Home/bin 目录下的 start-balancer.sh 脚本就是该任务的启动脚本。
数据平衡过程由于平衡算法的原因造成它是一个迭代的、周而复始的过程。每一次迭代的最终目的是让高负载的机器能够降低数据负载,所以数据平衡会最大程度上地使用网络带宽。下图 1 数据平衡流程交互图显示了数据平衡服务内部的交互情况,包括 NameNode 和 DataNode。
图 1. 数据平衡流程交互图
图 1 所示步骤分析如下:
HDFS 数据在各个数据节点间可能保存的格式不一致。当存放新的数据块 (一个文件包含多个数据块) 时,NameNode 在选择数据节点作为其存储地点前需要考虑以下几点因素:
运行 start-balancer.sh 脚本
格式:$Hadoop_home/bin/start-balancer.sh –threshold<threshold>
$Hadoop_home/bin/start-balancer.sh
启动数据平衡,默认阈值为 10%
bin/start-balancer.sh –threshold 5
启动数据平衡,阈值 5%
如何停止数据平衡:
$Hadoop_home/bin/stop-balancer.sh
hdfs-site.xml 文件里可以设置每秒钟数据节点间移动数据块的最大速度。
<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,速度越快完成任务时间也越短,但是这也对机器进程速度有要求。
注意事项:
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
该脚本不允许多进程运行。
失败原因包括下述因素:
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 和类型 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 自带算法而言,更快速、更高效。