我今天在AWS上运行了我的Hadoop程序，使用了不同数量的reducer，但是我观察到随着reducer数量的增加，时间非但没有减少，反而增加了。对于时间，我的意思是从Map 100%， Reduce 30%到Map 100%， Reduce 100%
请记住，数据需要通过网络发送到reducer，如果您从映射器输出的数据没有那么大，以增加reducer的数量可能会影响性能，结果需要传输到不同的reducer, I/O操作增加，因为您需要创建更多的文件，因为每个reducer创建自己的文件。
每个reduce都需要启动并在节点中创建/实例化，这导致启动时间增加。此外，数据需要在整个减少器中进行分割，这需要更多的网络传输时间和解析时间。
另外，有一个最佳实践是将reducer的数量设置为零，如果你不使用Hadoop，就不需要担心创建它们，整个过程将更快
雅虎开发者参考
减少的效率在很大程度上是由shuffle的性能。
为应用程序配置的reduce个数(r)为，很明显，一个至关重要的因素。
太多或太少的reduce都是反生产的:
过少的reduce会导致在调度reduce的节点上产生不适当的负载——在极端情况下，我们已经看到了reduce处理超时100 gb每次reduce。这也会导致非常糟糕的故障恢复由于单个减少失败，会产生重大的不利影响，对作业延迟的影响。
太多的减少会对洗牌横条产生不利影响。此外，在极端情况下，它会导致创建太多的小文件作为输出这对NameNode和的性能都有影响后续的Map-Reduce应用程序需要处理大量的小数据文件。