使用Hadoop进行 GraySort基准排序时，Yahoo!的研究人员将上面的map/reduce应用...

菜鸟之家

    使用Hadoop进行 GraySort基准排序时，Yahoo!的研究人员将上面的map/reduce应用程序稍加修改以适应新的规则，整个程序分为4个部分，分别为：

    TeraGen是产生数据的map/reduce程序；

    TeraSort进行数据取样，并使用map/reduce对数据进行排序；

    TeraSum是map/reduce程序，用来计算每个键/值对的CRC32，共128位校验和；

    TeraValidate是用来验证输出数据是否有序的map/reduce程序，并且计算校验和的总和。

    TeraGen和TeraSort与上面介绍的一样，TeraValidate除了增加了计算输出目录校验和总和的任务以外，其他都一样，这里不再赘述。

    TeraSum计算每个键/值对的CRC32的校验和，每个map任务计算输入的校验和并输出，然后一个reduce任务将每个map生成的校验和相加。这个程序用来计算输入目录下每个键/值对校验和的和，还用来检查排序输出后的正确性。

（点击查看大图）图3-10　每个阶段的任务数

    这次基准测试运行在Yahoo!的Hammer集群上，集群的具体细节如下：

    将近3800个节点（在这样大规模的集群中，一些节点会坏掉）；

    每个节点两个双核2.5GHz的Xeons处理器；

    每个节点4个SATA硬盘；

    每个节点8GB内存（在PB级排序前会升级到16GB）；

    每个节点1GB的以太网带宽；

    每个rack拥有40个节点；

    每个节点到核心有8GB的以太网带宽；

    操作系统为Red Hat Enterprise Linux Server Realease 5.1（kernel 2.6.18）；

    JDK为Sun Java JDK（1.6.0 05-b13 and 1.6.0 13-b03）（32 and 64 bit）。

    对于较大规模的排序，这里NameNode和JobTracker使用的是64位的JVM。排序测试所用的Hadoop平台也做了一些变化，主要有：

    重新实现了Hadoop shuffle阶段的reducer部分，在重新设计后提高了shuffle的性能，解除了瓶颈，而且代码也更容易维护和理解了；

    新的shuffle过程从一个节点获取多个map的结果，而不是之前的一次只取一个结果。这样防止了多余的连接和传输开销；

    允许配置shuffle连接的超时时间，在小规模排序时则可以将其减小，因为一些情况下shuffle会在超时时间到期后停止，这会增加任务的延迟时间；

    设置TCP为无延迟并增加TaskTracker和TaskTracker之间ping的频率，以减少发现问题的延迟时间；

    增加一些代码，用来检测从shuffle传输数据的正确性，防止引起reduce任务的失败。

    在map输出的时候使用LZO压缩，LZO能压缩45%的数据量；

    在shuffle阶段，在内存中将map的结果聚集输出的时候实现了reduce需要的内存到内存的聚集，这样减少了reduce运行时的工作量；

    使用多线程实现抽样过程，并编写一个基于键值平均分布的较为简单的分配器；

    在较小规模的集群上，配置系统在TaskTracker和JobTracker之间拥有较快的心跳频率，以减少延迟（默认为10秒/1000节点，配置为2秒/1000节点）；

    默认的JobTracker按照先来先服务策略为TaskTracker分配任务，这种贪心的任务分配方法并不能很好地分布数据。从全局的角度来 看，如果一次性为map分配好任务，系统会拥有较好的分布，但是为所有的Hadoop程序实现全局调度策略是非常困难的，这里只是实现了TeraSort 的全局调度策略；

    Hadoop 0.20增加了安装和清除任务的功能，但是在排序基准测试里这并不需要，可以设置为不启动来减少开始和结束任务的延迟；

    删除了框架中与较大任务无关的一些硬编码等待循环，因为它会增加任务延迟时间；

    允许为任务设置日志的级别，这样通过配置日志级别可以从INFO到WARN减少日志的内容，减少日志的内容对系统的性能有较大的提高，但是增加了调试和分析的困难；

    优化任务分配代码，但还未完成。目前，对输入文件使用RPC请求到NameNode上会花费大量的时间。

    Hadoop与上面的测试相比有了很大的改进，可以在更短的时间内执行更多的任务。值得注意的是，在大集群和分布式应用程序中需要转移大量数据，这 会导致执行时间有很大的变化。但是随着Hadoop的改进，它能够更好地处理硬件故障，这种时间变化也就微不足道了。不同规模的数据排序所需的时间如表 3-2所示。

    因为较小规模的数据需要更短的延迟和更快的网络，所以使用集群中的部分节点来进行计算。将较小规模计算的输出副本数设置为1，因为整个过程较短且运 行在较小的集群上，节点坏掉的可能性相对较小。而在较大规模的计算上，节点坏掉是难免的，于是将节点副本数设置为2。HDFS保证节点换掉后数据不会丢 失，因为不同的副本放在不同的节点上。

    Yahoo!的研究人员统计了JobTracker上从任务提交状况获得的任务数随时间的变化，图3-11、图3-12、图3-13、图3-14显 示了每个时间点下的任务数。maps只有一个阶段，而reduces拥有三个阶段：shuffle、merge和reduce。shuffle是从 maps中转移数据的，merge在测试中并不需要；reduce阶段进行最后的聚集并写到HDFS上。如果将这些图与图3-6进行比较，你会发现建立任 务的速度变快了。图3-6中每次心跳建立一个任务，那么所有任务建立起来需要40秒，现在Hadoop每次心跳可以设置好一个TaskTracker，可 见减少任务建立的开销是非常重要的。

    运行大规模数据时，数据传输的次数对任务性能的影响也是非常大的。在PB级数据排序中，每个map处理15GB的数据而不是默认的128MB，每个 reduce处理50GB的数据。如果按照1.5GB/map进行处理，需要 40个小时才能完成。因此，为了增加吞吐量，增加每个块的大小是非常重要的。

图3-11　数据量为500GB时任务数随时间的变化

图3-12　数据量为1TB时任务数随时间的变化

（点击查看大图）图3-13　数据量为100TB时任务数随时间的变化

（点击查看大图）图3-14　数据量为1PB时任务数随时间的变化