引言
  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的排序时间是有差异的。与普通磁盘不一样的地方在于,在集群资源不成为瓶颈的时候,文件越零碎,由于可以启动更多的map并行排序,相当于并发度提高了,terasort的总耗时会变得更少。