工欲善其事必先利其器——第二弹 HDFS性能压测工具浅析

引言

Hadoop生态圈的基石有两个，一个是HDFS文件系统，一个是MR编程框架。第一弹中提到应用MR编程框架实现大规模多机联合负载压测场景的方案，则突出了MR的能力，实际上HDFS作为这一切的基础，所起的作用是不容忽视的。

HDFS分布式文件系统与一般的文件系统，从本质构成上来说并没有太大的区别，普通磁盘上的文件系统，例如ext3有数据块（block），HDFS也有这个概念，ext3的分区表记录了文件与block、block与扇区的对应关系，同样HDFS的fsimage文件中也包含了这类信息。对于一个整体的分布式系统来说，HDFS包含两个重要角色，一个是中心节点Namenode，一个是数据节点Datanode。其中Namenode用来记录文件目录结构树，即元数据fsimag，和各种修改操作信息，即editlog。而Datanode则是数据真正存放的地方，Namenode获得RPC请求后会将这些请求根据特定算法分发到一些Datanode上。

由于存在单点结构，因此Namenode机器的性能必须远超Datanode机器，因为其负载了所有RPC访问请求，每个RPC请求引起的查询、IO、audit等动作都会消耗系统资源，Namenode的性能将会极大影响HDFS文件系统的整体性能。而相对来说Datanode的性能就不是那么重要了，当然这也区分具体的应用，例如对于HBase来说，由于Regionserver和Datanode同处于一台机器，彼此之间存在数据的交换，因此与Datanode的IO性能是有关联的，性能好坏成正比关系。

自从诞生HDFS开始，相关的性能压测工具就出现了，其中一些堪称经典之作更是检验HDFS性能的必用神器。例如Terasort，Slive，DFSIO，下面我就这几个工具的共同点和各自的特点做一个简单分析。

 

求同存异

         Terasort

从文件系统角度出发的性能测试工具，大多不离吞吐率这个指标。转化到HDFS这边，则是rpc次数、opt次数、sync时长这样的指标信息，然而Terasort是个异类。这个工具不仅考验文件系统的性能，更是对MR自动排序能力的一种检测。Terasort位于hadoop的example包中，是SortBenchmark（http://sortbenchmark.org）排序比赛使用的标准工具，它使用了Hadoop默认的IdentityMapper和IdentityReducer，利用MR自有的sort机制来保证每个partition内数据是有序的。

显然我们使用Terasort，判断HDFS文件系统（其实还包含了MR）性能好坏的依据与SortBenchmark是一致的，即计算数据量和运行时长的比值，根据单位时间的排序数据量来判断不同HDFS版本之间的性能差异。

Terasort包含三个工具，分别是teragen：用来生成供排序的随机数据；terasort：用来将随机数据排序；teravalidate：校验terasort的排序结果是否正确。

通过控制teragen的map数和block size，我们得以检验多种测试场景下HDFS的性能状况。例如执行：

hadoop jar hadoop-current/hadoop-0.19.1-dc-examples.jar teragen -Dmapred.map.tasks=100 -Ddfs.block.size=134217728 10000000000 /terasort/output

这个命令会在/terasort/output下生成100个10G大小的文件，文件的blocksize是128MB。这就类似于我们在测试单机磁盘IO的时候，分别要获取零碎文件吞吐率和整块大文件吞吐率数据一样。控制teragen生成的文件个数，文件大小，虽然总数据量一致，但是terasort