请记住，数据需要通过网络发送到还原器，如果您从Map器输出的数据不太大，增加还原器的数量可能会影响性能，因为结果需要传输到不同的还原器，i/o操作会增加，因为您需要创建更多的文件，因为每个还原器都创建自己的文件。
每个reduce都需要启动并在节点中创建/示例化，这会导致启动时间的增加。此外，数据需要在需要更多网络传输时间和解析时间的整个缩减器上进行拆分。
另外，有一个最佳实践是将reducer的数量设置为零，如果您不使用hadoop，那么不需要担心创建它们，整个过程会更快
雅虎开发者的参考资料
reduces的效率在很大程度上取决于shuffle的性能。
显然，为应用程序配置的reduce的数量（r）是一个关键因素。
减少太多或太少都是反生产的：
太少的reduce会在调度reduce的节点上造成不适当的负载—在极端情况下，我们看到每个reduce的处理量会减少超过100gb。这也会导致非常糟糕的故障恢复场景，因为一个失败的reduce对作业的延迟有显著的、不利的影响。
减少过多会对随机交叉杆产生不利影响。此外，在极端情况下，它会导致创建太多的小文件作为作业的输出—这会影响需要处理大量小文件的后续map reduce应用程序的namenode和性能。