Hadoop性能调优

最近看了些Hadoop性能调优的文章，现总结如下。

1、关于集群物理机器：

配置noatime选项。（配置方式：/etc/fstab）(相关知识点：atime，ctime，mtime。)

对于datanode/tasktracker机器，不需要配置raid或lvm。

尽量避免使用到tasktracker的swap。

磁盘问题会导致task重试，降低效率。在blacklist中的node大多是因为磁盘问题，smart monitor 在磁盘资源。

2、使用数据压缩配置：

在mapred的中间结果（map输出）或有后续任务的mapred任务的输出，使用压缩配置选项。(mapred.compress.map.output,mapred.output.compress)

增加一部分的CPU开销，减少IO开销（包括网络IO和磁盘IO）

3、合理的设置task的数目：

任务的input过大时，split的数量很多，会导致过多的map task。可以通过加大hdfs block size来减小maptask的数量。（ hadoop distcp -Ddfs.block.size=$[256*1024*1024] /path/to/inputdata /path/to/inputdata-with-largeblocks）

如果任务数多且小，比如在一分钟之内完成，减少task数量以减少任务初始化的消耗。可以通过配置JVM重用选项减少task的消耗。(mapred.job.reuse.jvm.num.tasks表示一个job的task可利用相同的JVM顺序执行多少个)

任务数和集群slot数目之间应满足一定的关系。比如slot的数量是100个，那么最好不要有101个mapper（类似于图中的关键路径的理念，不论你那100个mapper多快，最后一个不做完，reduce就不能起，也就是说，近似相当于调度两轮map的时耗）。reduce task的数量有两种方案推荐，比如0.95*reduce slot。一轮reduce完成，预留的reduce task是用作重做的。或1.75*reduce slot,同样道理，只不过调度两轮reduce，负载更均衡

4、合理的利用combiner：

首先，从业务场景出发，reduce的结果应该不受影响。其次，combiner所带来的性能消耗要远小于网络传输和排序所带来的消耗。这个的判断可以从几个方面来：shuffle的数据量；spill的counter。(理解shuffle sort的过程)

5、使用合理的数据类型：

非文本类型的数据可选择非Text类型的二进制writable类型，避免类如数值类型转换到string的CPU性能消耗。可根据自己的业务特点定义高效的writable类型。

采用intwritable或者longwritable时，若数值大小差异很大，可以采用变长的类型，减少磁盘和IO消耗。

6、在map或reduce中注意重用writable对象