为什么 Hadoop 洗牌时间比预期的要长答案

【问题标题】：why Hadoop shuffling time takes longer than expected为什么 Hadoop 洗牌时间比预期的要长
【发布时间】：2013-11-22 02:01:51
【问题描述】：

我试图弄清楚在简单的 hadoop wordcount 示例中哪些步骤需要花费多少时间。在这个例子中，使用了 3 个 map 和 1 个 reducer，每个 map 生成约 7MB 的 shuffle 数据。我有一个通过 1Gb 交换机连接的集群。当我查看作业详细信息时，意识到在所有地图任务完成后洗牌大约需要 7 秒，这超出了传输如此小的数据的预期。这背后的原因可能是什么？谢谢

【问题讨论】：

经过几个小时的调试，我想我找到了 7 秒洗牌时间的原因。当reduce任务准备好获取中间数据时，它检查是否有任何中间数据准备好获取，如果没有，则等待硬编码5秒，然后再次检查if (numInFlight == 0 && numScheduled == 0) { reporter.progress(); Thread.sleep(5000); }

标签： hadoop

【解决方案1】：

Hadoop 使用心跳与节点通信。默认情况下，hadoop 使用最小心跳间隔等于 3 秒。因此，hadoop 在两次心跳（大约 6 秒）内完成了您的任务。

【讨论】：

感谢您的回答，但我已经在 MRConstants.java 中使用心跳间隔 300ms code public static final int HEARTBEAT_INTERVAL_MIN = 300;

【解决方案2】：

在映射步骤之后，传输并不是唯一要完成的事情。每个映射器在本地输出给定拆分的部分并对其进行排序。然后，负责特定拆分任务的 reducer 从每个 mapper 输出中收集部分，每个部分需要 7 MB 的传输。然后，reducer 必须将这些段合并到最终排序的文件中。

不过，老实说，您正在测试的规模绝对很小。我不知道 Hadoop shuffle 步骤的所有部分，据我了解，其中包含一些相关细节，但您不应期望此类小文件的性能能够指示大文件的实际性能。

【讨论】：

【解决方案3】：

我认为改组是在第一个映射器启动之后开始的。但是等待接下来的两个映射器。

在所有映射器完成后，可以选择启动 reduce 阶段（从 shuffle 开始）。但这并不能真正加速任何事情。

（顺便说一句。7 秒在 Hadoop 中被认为很快。Hadoop 的性能很差。尤其是对于小文件。除非有人为此付费。不要使用 Hadoop。）

【讨论】：