Question

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

经过很长一段时间，他们获得了输入记录，开始处理它们。有些甚至在较长时间内显示0个输入记录，并且由于任务尝试未能报告600毫秒的状态而被杀死。

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

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

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

Answer 1

是的我相信分布式缓存的读取是您延迟的原因。但如果您在configure()之前或之后保留reduce()，则不会产生任何影响，因为如果您看到configure()，则必须首先调用run()方法如下所示的reducer（新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()完成，否则实际的减少任务将无法启动（这不会解释您看到显示的任何输入记录数。）

现在，对于百分比：66%，您会看到减少阶段实际上遵循子部分：

复制
排序
减少

所以，既然你的前两个步骤已经完成，第三个步骤已经开始，但是等待configure()完成（要读取的分布式缓存），你的降低百分比为66％。

Reducer节点需要很长时间才能接收其记录

1 个答案: