hadoop:任务不是本地文件？

Question

我运行了一个 hadoop 作业，当我查看一些 map task 时，我发现它们没有在文件 block 所在的位置运行。例如，map 任务在 slave1 上运行，但文件 block (所有)都在 slave2 中。这些文件都是 gzip。

为什么会这样，如何解决？

更新:注意有很多待处理的任务，所以这不是节点空闲的情况，因此托管从其他节点读取的任务。

Answer 1

Hadoop 的默认 (FIFO) 调度程序是这样工作的:当节点有空闲容量时，它会联系主节点并请求更多工作。 master 尝试分配数据本地任务或机架本地任务，但如果不能，它将(等待任务的)队列中的任何任务分配给该节点。然而，当这个节点被分配这个非本地任务(我们称之为任务 X)时，另一个节点可能也有空闲容量并联系主节点请求工作。即使这个节点实际上有 X 所需数据的本地副本，它也不会被分配该任务，因为另一个节点能够比后者节点稍微快一点地获得主节点的锁。这导致数据局部性差，但任务分配快速。

相比之下，Fair Scheduler 使用一种称为 delayed scheduling 的技术通过延迟“一点点”(可配置)的非本地任务分配来实现更高的本地性。它实现了更高的局部性，但代价是延迟了一些任务。

其他人正在研究更好的调度器，这在未来可能会得到改进。目前，如果您希望获得更高的数据局部性，您可以选择使用 Fair Scheduler。

我不同意@donald-miner 的结论，即“在默认复制因子为 3 的情况下，您不会看到很多非本地数据的任务。”他正确地指出更多的副本会提高你的局部性百分比，但数据局部性任务的百分比可能仍然很低。我自己也进行了实验，发现 FIFO 调度程序的数据局部性非常低。如果你的工作很大(有很多任务)，你可以实现高局部性，但对于更常见、更小的工作，它们会遇到称为“线头调度”的问题。引自 this paper :

The first locality problem occurs in small jobs (jobs that have small input files and hence have a small number of data blocks to read). The problem is that whenever a job reaches the head of the sorted list [...] (i.e. has the fewest running tasks), one of its tasks is launched on the next slot that becomes free, no matter which node this slot is on. If the head-of-line job is small, it is unlikely to have data on the node that is given to it. For example, a job with data on 10% of nodes will only achieve 10% locality.

该论文继续引用了 Facebook 生产集群的数据，他们报告称在大型生产环境中仅观察到 5% 的数据局部性。

最后的说明:您是否应该关心数据本地化程度低？不要太多。 您的作业的运行时间可能由 stragglers 支配(需要更长时间才能完成的任务)和 shuffle phase ，因此改进数据局部性只会对运行时间有非常适度的改进(如果有的话)。