MapReduce优化程序.doc

? Cloudera提供给客户的服务内容之一就是调整和优化MapReduce job执行性能。MapReduce和HDFS组成一个复杂的分布式系统，并且它们运行着各式各样用户的代码，这样导致没有一个快速有效的规则来实现优化代码性能的目的。在我看来，调整cluster或job的运行更像一个医生对待病人一样，找出关键的“症状”，对于不同的症状有不同的诊断和处理方式。???????? 在医学领域，没有什么可以代替一位经验丰富的医生；在复杂的分布式系统上，这个道理依然正确—有经验的用户和操作者在面对很多常见问题上都会有“第六感”。我曾经为Cloudera不同行业的客户解决过问题，他们面对的工作量、数据集和cluster硬件有很大区别，因此我在这方面积累了很多的经验，并且想把这些经验分享给诸位。???????? 在这篇blog里，我会高亮那些提高MapReduce性能的建议。前面的一些建议是面向整个cluster的，这可能会对cluster 操作者和开发者有帮助。后面一部分建议是为那些用Java编写MapReduce job的开发者而提出。在每一个建议中，我列出一些“症状”或是“诊断测试”来说明一些针对这些问题的改进措施，可能会对你有所帮助。???????? 请注意，这些建议中包含很多我以往从各种不同场景下总结出来的直观经验。它们可能不太适用于你所面对的特殊的工作量、数据集或cluster，如果你想使用它，就需要测试使用前和使用后它在你的cluster环境中的表现。对于这些建议，我会展示一些对比性的数据，数据产生的环境是一个4个节点的cluster来运行40GB的Wordcount job。应用了我以下所提到的这些建议后，这个job中的每个map task大概运行33秒，job总共执行了差不多8分30秒。?第一点? 正确地配置你的Cluster?诊断结果/症状：?1. Linux top命令的结果显示slave节点在所有map和reduce slot都有task运行时依然很空闲。?2. top命令显示内核的进程，如RAID(mdX_raid*)或pdflush占去大量的CPU时间。?3. Linux的平均负载通常是系统CPU数量的2倍。?4. 即使系统正在运行job，Linux平均负载总是保持在系统CPU数量的一半的状态。?5. 一些节点上的swap利用率超过几MB???? 优化你的MapReduce性能的第一步是确保你整个cluster的配置文件被调整过。对于新手，请参考这里关于配置参数的一篇blog：配置参数。 除了这些配置参数 ，在你想修改job参数以期提高性能时，你应该参照下我这里的一些你应该注意的项：?1.? 确保你正在DFS和MapReduce中使用的存储mount被设置了noatime选项。这项如果设置就不会启动对磁盘访问时间的记录，会显著提高IO的性能。?2. 避免在TaskTracker和DataNode的机器上执行RAID和LVM操作，这通常会降低性能?3. 在这两个参数mapred.local.dir和dfs.data.dir?配置的值应当是分布在各个磁盘上目录，这样可以充分利用节点的IO读写能力。运行 Linux sysstat包下的iostat -dx 5命令可以让每个磁盘都显示它的利用率。?4. 你应该有一个聪明的监控系统来监控磁盘设备的健康状态。MapReduce job的设计是可容忍磁盘失败，但磁盘的异常会导致一些task重复执行而使性能下降。如果你发现在某个TaskTracker被很多job中列入黑名单，那么它就可能有问题。?5. 使用像Ganglia这样的工具监控并绘出swap和网络的利用率图。如果你从监控的图看出机器正在使用swap内存，那么减少mapred.child.java.opts属性所表示的内存分配。?基准测试：???? 很遗憾我不能为这个建议去生成一些测试数据，因为这需要构建整个cluster。如果你有相关的经验，请把你的建议及结果附到下面的留言区。?第二点? 使用LZO压缩?诊断结果/症状：?1. 对 job的中间结果数据使用压缩是很好的想法。?2. MapReduce job的输出数据大小是不可忽略的。?3. 在job运行时，通过linux top 和 iostat命令可以看出slave节点的iowait利用率很高。???? 几乎每个Hadoop job都可以通过对map task输出的中间数据做LZO压缩获得较好的空间效益。尽管LZO压缩会增加一些CPU的负载，但在shuffle过程中会减少磁盘IO的数据量，总体上总是可以节省时间的。???? 当一个job需要输出大量数据时，应用LZO压缩可以提高输出端的