Reducer 节点需要很长时间才能接收到它的记录

Question

查看 Hadoop GUI 时，我发现一些 reduce 任务已经达到了 66.66%，并且在那里停留了很长时间。当我检查柜台时，我发现没有。输入记录数显示为零。

很长一段时间后，他们得到他们的输入记录，开始处理它们。 有些甚至在更长的时间内显示 0 个输入记录，并被任务尝试杀死，无法报告状态达 600 毫秒。

但一些 reducer 会立即在其计数器中显示输入记录并立即开始处理它们。

我不知道，为什么某些 reducer 在获取输入记录时会有这么多的延迟。这只发生在这个程序中，而不是其他程序。

在这个mapreduce作业中，我在reduce的reduce方法之前的configure方法中，从分布式缓存中读取了很多数据。这是原因吗？我不确定。

Answer 1

是的，我相信从分布式缓存中读取是您延迟的原因。但是，如果您在 reduce() 之前或之后保留 configure() 并没有什么不同，因为最终必须首先调用 configure() 方法，如果您看到减速器的 run() 它看起来如下（新 API）：

public void run(Context context) throws IOException, InterruptedException {

    setup(context); // This is the counterpart of configure() from older API

    while (context.nextKey()) {
        reduce(context.getCurrentKey(), context.getValues(), context);
    }
    cleanup(context);
}

如您所见，setup() 在 reduce() 之前被调用，类似地，在旧 API 中，除非configure() 完成实际的 reduce 任务，否则不会启动（这说明您看不到任何输入记录数显示)。

现在关于百分比：66%，您会看到 reduce 阶段实际上有以下子部分：

1. 复制
2. 排序
3. 减少

因此，由于您的前两个步骤已完成，第三个步骤已开始但正在等待 configure() 完成（要读取分布式缓存），因此您的减少百分比为 66%。