hadoop 文档指出：
reduce 的正确数量似乎是 0.95 或 1.75 乘以 ( * mapred.tasktracker.reduce.tasks.maximum)。
使用 0.95 时，所有 reduce 都可以立即启动并开始 在地图完成时传输地图输出。 1.75 越快 节点将完成第一轮减少并启动第二轮 减少的浪潮在负载平衡方面做得更好。
这些值是否相当恒定？当您在这些数字之间或之外选择一个值时，结果是什么？
【问题讨论】：
标签： configuration hadoop mapreduce
这些值应该是您的情况所需要的值。 :)
以下是我对价值观好处的理解：
.95 是为了最大限度地利用可用的减速器。如果 Hadoop 默认使用单个 reducer，则不会有 reducer 的分布，导致它花费的时间比预期的要长。减速器的增加和时间的减少几乎是线性的（在我的有限情况下）。如果 1 个减速器需要 16 分钟，那么 8 个减速器需要 2 分钟。
1.75 是一个试图优化节点中机器性能差异的值。它将创建不止一次的减速器，因此速度较快的机器将使用额外的减速器，而较慢的机器则不会。
这个数字 (1.75) 需要根据您的硬件进行更多调整，而不是 0.95 值。如果您有 1 台快速机器和 3 台较慢的机器，也许您只需要 1.10。这个数字需要更多的实验才能找到适合您的硬件配置的值。如果reducer的数量太多，那么慢的机器又会成为瓶颈。
【讨论】：
补充一下Nija上面所说的，还有一点个人经验：
0.95 有点意义，因为您正在利用集群的最大容量，但同时，您要考虑一些空任务槽，以防某些减速器发生故障。如果您使用 1 倍的 reduce 任务槽数，则失败的 reduce 必须 等待至少一个 reducer 完成。如果您使用 0.85 或 0.75 个减少任务槽，则说明您没有尽可能多地利用集群。
【讨论】：
我们可以说这些数字不再有效。现在根据“Hadoop：权威指南”一书和hadoop wiki，我们的目标是使reducer 处理时间缩短5 分钟。
书中的片段：
选择减速器的数量单个减速器的默认值是 Hadoop 新用户的一个陷阱。几乎所有现实世界的工作都应该 将此设置为更大的数字；否则，工作会很慢 因为所有的中间数据都流经一个reduce任务。 为一项工作选择减速器的数量更像是一门艺术，而不是一门艺术 科学。增加reducer的数量使得reduce阶段 更短，因为你得到更多的并行性。但是，如果你也接受这个 到目前为止，您可能有很多小文件，这是次优的。一条规则 经验是针对每个运行五分钟左右的减速器， 并产生至少一个 HDFS 块的输出。
【讨论】：