HDFS 输入文件避免切分

•  自定义InputFormat的子类，并把重载方法isSplitable()返回值设为false

• 增加最小分片的大小，设置成大于要处理文件中最大文件的大小，简单的设成Long.MAX_VALUE即可

      一般来说，分片大小计算公式如下：

      Max(minimumSize,min(maximumSize,blockSize))

      minimumSize < blockSize < maximumSize

      如果将分片大小设置成比HDFS块更大，会增加对于map任务来说不是本地文件的块数，也就是说map要跨块读取文件。如果分片大小的设置的比较小的话，那么一个文件就会有很多map任务，那么大量的mapper任务会造成mapper任务所涉及的任务管理和启动开销大量增加，造成hadoop效率的下降，一般来说分片大小设置成块大小，也可以设置块大小的整数倍。

       对于许多小文件的话，hadoop的处理效率是低下的，一种方法是我们使用Hadoop 存档工具把许多小文件打包成一个Har文件，但是这样会要求至少需要与原文件大小相同的另一份磁盘空间，而且har文件不能修改或者删除里面的文件，不过InputFormat类并不知道文件已经存档，所以处理效率仍然不好；另一种方法是使用CombineFileInputFormat类，同样这个类对大文件也有很好的效果，这对于HDFS中已经存在很多小文件的情况下值得一试。还有一种方法就是使用SequeneceFile 合并许多小文件，键是文件名，值是文件内容。

     尽量避免许多小文件的情况：

•  处理小文件会增加运行作业需要的寻址次数

•  浪费namenode的内存

 

     reducer个数选择

• reducer最优个数与集群中可用的reducer任务槽数相关。

• 总槽数=集群中节点数*每个节点的任务槽数。

• 总槽数可以在mapred.tasktracker.reduce.tasks.maximun属性设置

 

 常用方法

1.  设置比总槽数稍微少一些的reducer数，给任务留余地（容忍一些错误发生而不需要次延长作业运行时间），比如说计划性任务或者推测性任务。

2.  如果reduce任务很大，较好的做法是使用更多reducer，使任务粒度变小，这样任务的失败才不至于显著影响作业执行时间。