Hadoop生态圈的基石有两个，一个是HDFS文件系统，一个是MR编程框架: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的性能状况。例如执行：

　　这个命令会在/terasort/output下生成100个10G大小的文件，文件的blocksize是128MB。这就类似于我们在测试单机磁盘IO的时候，分别要获取零碎文件吞吐率和整块大文件吞吐率数据一样。控制teragen生成的文件个数，文件大小，虽然总数据量一致，但是terasort的排序时间是有差异的。与普通磁盘不一样的地方在于，在集群资源不成为瓶颈的时候，文件越零碎，由于可以启动更多的map并行排序，相当于并发度提高了，terasort的总耗时就会变得更少。

　　SliveTest

　　SliveTest位于hadoop的test包中，代码结构清晰，其主要功能是通过大量map制造多种rpc请求，检测Namenode的性能。我们可以设定map数量，每个map发起的rpc请求次数，每一种rpc操作占总操作的百分比，以及读写数据量、block size等配置。下面列出slive可以调用的rpc操作种类：

原文转自：http://www.ltesting.net