方法也是借鉴各种谷歌和实际实验经验整理的，希望能帮到需要的朋友
map task 的数量即mapred.map.tasks的参数值，用户不能直接设置这个参数。 由Input Split的大小决定，我们可以通过设置 dfs.block.size的值来调整 默认是（64M）如果我们分析的文件是 大文件 建议将该参数调大点，注意每次修改都要重新格式化才能生效，但这样会导致所有数据丢失
reduce task的数量由mapred.reduce.tasks这个参数设定，默认值是1。
合适的reduce task数量 = 0.95或者0.75* 节点数 * mapred.tasktracker.reduce.tasks.maximum
比如我的 就是 0.95 * 6 *4 （我有6个节点 每个节点的cpu数量是4颗）
mapred.tasktracker.tasks.reduce.maximum的数量一般设置为各节点cpu core数量，即能同时计算的slot数量。
对于0.95，当map结束时，所有的reduce能够立即启动；
对于0.75，较快的节点结束第一轮reduce后，可以开始第二轮的reduce任务，从而提高负载均衡。
分享：
对一 个job的map数和reduce数的设定对一个job的运行是非常重要的，并且非常简单。以下是一些设 置这几个值的经验总结：
-
- 如果job的每个map或者 reduce task的运行时间都只有30-40秒钟，那么就减少该job的map或者reduce数，每一个task(map|reduce)的setup和加入到 调度器中进行调度，这个中间的过程可能都要花费几秒钟，所以如果每个task都非常快就跑完了，就会在task的开始和结束的时候浪费太多的时间。JVM 的reuse方式也可以解决 这个问题。
- 如 果某个input的文件 非常的大，比如 1TB，可以考虑将hdfs上的每个block size设大，比如设成256MB或者512MB，这样map和reduce的数据 可以减小。而且用户还可以通过命令 ：hadoop
distcp -Ddfs.block.size=$[256*1024*1024] /path/to/inputdata /path/to/inputdata-with-largeblocks的方式来将已经存在咋hdfs上的数据进行大块化。然后删除掉原先的文件。 - 只 要每个task都运行至少30-40秒钟，就可以考虑将mapper数扩大，比如集群的map slots为100个，那么就不要将一个job的mapper设成101，这样前100个map能够并行完成，而最后一个map要在前100个 mapper结束后才开始，因此在reduce开始运行前，map阶段的时间几乎就要翻倍。
- 尽量不要运行太多的reduce task。对大多数job来说，最好rduce的个数最多和集群中的reduce持平，或者比集群的 reduce slots小。这个对于小集群而言，尤其重要。