当reduce任务较少时，Hadoop reduce变得更慢

Posted 2023-03-16

【中文标题】当reduce任务较少时，Hadoop reduce变得更慢

【英文标题】：Hadoop reduce become slower when there are less reduce task

【发布时间】：2012-05-10 16:50:57

【问题描述】：

当我对 Hadoop 进行一些性能调整时，我遇到了一个非常奇怪的情况。我正在运行一个具有大量中间输出的作业（例如没有组合器的 InvertedIndex 或 WordCount），网络和计算资源都是同质的。根据mapreduce的工作原理，当reduce任务的WAVES较多时，由于map和shuffle之间的重叠较少，整体运行时间应该会变慢，但事实并非如此。事实证明，具有 5 WAVES 减少任务的作业比仅具有 1 个 WAVE 任务的作业快 10%。我检查了日志，结果发现当reduce任务较少时，map任务的执行时间较长，而且当任务较少时，reduce阶段的整体计算时间（不是shuffle或merge）较长。我试图通过将reduce slow-start factor设置为1来排除其他因素，这样map和shuffle之间就没有重叠，我还将它限制为同时执行一个reduce任务，所以没有重叠在 reduce 任务之间，我修改了调度程序以强制 mapper 和 reducer 定位在不同的机器上，这样就不会出现 I/O 拥塞。即使采用上述方法，同样的事情仍然会发生。 （我还将map内存缓冲区设置得足够大，io.sort.factor设置为32甚至更大，io.sort.mb相应地大于320）

我真的想不出任何其他原因导致这个问题，所以任何建议将不胜感激！

以防万一，我遇到的问题是：

0。我正在比较在所有其他相同配置下运行同一作业的 1 个减少任务与 5 个减少任务的性能。 reduce 计算只有一个 tasktracker。

1.我已经强制所有reduce任务按顺序执行，在这两种情况下只有一个tasktracker用于redcue任务，mapred.tasktracker.reduce.tasks.maximum=1，所以在reduce阶段不会有任何并行性

2。我已经设置了 mapred.reduce.slowstart.completed.maps=1 所以在所有地图完成之前没有一个 reducer 会开始提取数据

3.事实证明，拥有一个 reduce 任务比拥有 5 个 SEQUENTIAL 任务要慢！

4.即使我设置了 set mapred.reduce.slowstart.completed.maps=0.05 以允许 map & shuffle 之间的重叠，（因此当只有一个reduce任务时，重叠应该更多并且它应该运行得更快，因为5个reduce任务正在按顺序执行）5-reduce-task 仍然比 1-reduce 任务快，1-reduce 任务的 map 阶段变得更慢！

【参考方案1】：

这不是问题。您拥有的 reduce 任务越多，处理数据的速度就越快。

map阶段的输出被发送到reducers。如果您有两个减速器，则负载将分布在两个减速器之间。

在 wordcount 示例中，您将拥有两个单独的文件，它们之间的计数分开。因此，如果您有很多 reduce 任务，您将不得不手动添加总数，或者运行另一个 map reduce 作业来计算总数。

【讨论】：

抱歉，我的描述有些混乱。我强迫reduce任务之间没有并行性，因为我只使用一个tasktracker进行reduce，并且我设置了mapred.tasktracker.reduce.tasks.maximum=1，因此不会同时执行任何两个reduce任务。无论如何感谢您的回复。

【参考方案2】：

这正如预期的那样，如果您只有一个减速器而不是您的作业有单点故障。您的减速器数量应设置为大约 90% 的容量。你可以通过将你的 reduce 槽数乘以你的节点总数来找到你的 reduce 容量。我发现如果适用的话，使用组合器也是一个好习惯。

【讨论】：

感谢您的回复。但是根据作业日志，没有任务或节点级别的故障，并且我在reduce阶段关闭了推测执行，因为我需要找出原因，有更多的reduce任务甚至可以更快。

【参考方案3】：

如果您只有 1 个 reduce 任务，则该 reducer 必须等待所有 mapper 完成，并且 shuffle 阶段必须收集所有中间数据以重定向到该一个 reducer。因此，如果只有一个 reducer，map 和 shuffle 时间自然会变大，总时间也会变长。

但是，如果您有更多的 reducer，您的数据会得到并行处理，这会使其更快。同样，如果你有太多的 reducer，那么就会有太多的数据被打乱，导致网络流量增加。因此，您必须找到最佳数量的减速器，以达到良好的平衡。

【讨论】：

对不起，我认为对减少任务的“波”有一些误解。当我说1波reduce任务时，每个tasktracker上有一个reduce任务，如果每个tasktracker上有3个reduce任务，每个tasktracker一次最多可以处理一个任务，这称为3波reduce任务.在这里，我只使用一个 tasktracker 进行 reduce，并且我将每个 tasktracker 上可以运行的最大 reduce 任务设置为一个，因此不应该有任何您描述的并行度因素。很抱歉让您感到困惑，并感谢您的回复。

【参考方案4】：

reduce 的正确数量似乎是 0.95 或 1.75 * (nodes * mapred.tasktracker.tasks.maximum)。在 0.95 时，所有 reduce 可以立即启动，并在地图完成时开始传输地图输出。在 1.75 时，更快的节点将完成其第一轮 reduce 并启动第二轮 reduce，从而更好地实现负载平衡。

礼貌：

http://wiki.apache.org/hadoop/HowManyMapsAndReduces

Setting the number of map tasks and reduce tasks

（类似的问题和已解决的答案）

希望这会有所帮助！