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

Question

当我检查Hadoop GUI时，发现某些reduce任务已达到66.66％，并且他们在那里呆了很长时间。当我查看柜台时，我发现没有。的输入记录显示为零。

经过很长时间，他们得到他们的输入记录，开始处理它们。 一些显示0输入记录甚至更长的时间，并被任务尝试失败报告600毫秒的状态。

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

我不知道，为什么在获取某些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%，你看，简化阶段实际上下面的子部分：

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

所以，既然你的第一个完成了两个步骤，第三个步骤已经开始，但正在等待configure()完成（分布式缓存被读取），您的减少百分比为66％。