2

谁能帮助我理解以下与我对 Hadoop 数据局部性的理解相反的观察。

具有 3 个节点的 Hadoop 集群：

主人：10.28.75.146

从站1：10.157.6.202

从机2：10.31.130.224

成功运行任务。从作业控制台：

Task Attempts:attempt_201304030122_0003_m_000000_0
Machine: /default-rack/10.31.130.224<p>
Task log: INFO: consuming hdfs://10.28.75.146:9000/input/22.seq

我们知道 224 节点正在处理 /input/22.seq 数据。通过命令：

$hadoop fsck /input -files -blocks  -locations |grep -A 1 "22.seq"
/input/22.seq 61731242 bytes, 1 block(s):  OK
0. blk_-8703092405392537739_1175 len=61731242 repl=1 [10.157.6.202:9200]

22.seq 适合一个小于默认 HDFS 块大小 (64MB) 的块，并且不会复制到其他节点。

问题：既然22.seq不是224节点本地的，为什么Hadoop分配224节点在202上远程处理数据？

注意：这也不例外。我注意到许多数据文件是远程获取的，并且在两个节点的 eth0 上观察到巨大的网络流量。我期望两个节点之间的流量接近于零，因为我所有的数据文件都小于 64MB，并且数据应该在本地处理。

仅供参考：这是在亚马逊的 AWS EMR 上观察到的。

4

2 回答 2

1

我不确定这是否会完全回答您的问题，但我会尝试发光。

你上面遇到的网络流量，可能是受到了mapreduce框架提交作业的流程的影响；默认情况下，其中一部分传输您的作业 jar 的 10 个副本以及其中包含的所有库在集群中（在像您这样没有 10 个节点的情况下，我不确定它会如何表现）：有热跳动并获取输入拆分信息和报告进度，这似乎是小带宽操作，尽管我不知道他们的网络资源消耗的细节。

关于您正在运行的作业：如果它是仅映射作业，则 Hadoop 尝试（尝试因为可能在数据本地节点上运行的资源限制因素）进行数据局部性优化并运行输入拆分所在的作业。听起来在您的情况下，该文件小于默认的 64MB，因此 1 拆分应该等于您的数据，这反过来应该导致一张地图，因为地图的数量与您拥有的拆分数量成正比，但是如果您的工作是一个 Map 和 Reduce 作业，那么网络流量可能会占用一些 reduce 复制和排序阶段 HTTP 网络流量，这些流量最终可能会出现在不同的节点上。

N 个输入拆分 = N 个映射 --output--> M 个分区 = M 个 Reducer

当然，网络流量和数据局部性优化取决于节点资源的可用性，因此您的测试假设应该考虑到这一点。

希望我有点帮助。

于 2013-04-03T16:12:15.727 回答
0

简短的回答 - 因为 Hadoop 调度程序很烂。它没有关于文件拆分应该去哪里的预先全球计划。当节点要求工作时 - 它会查看可用的拆分 - 并给出最佳匹配。有一些参数可以调整 Hadoop 在寻找最佳匹配方面的积极性（即 - 当工作请求到达时 - 它是否提供当时可用的最佳匹配？还是等待某个时间看看是否有其他更好的匹配节点也发送请求？）

默认情况下（我很确定 EMR 就是这种情况）——调度程序总是会将一些工作返还给请求节点——如果有任何可用的工作。您可以看到，如果您的输入很小（仅跨越几个块/节点），但节点数量较大（相比之下） - 那么您将获得非常差的局部性。另一方面——如果输入的大小很大——那么你获得良好位置的几率就会增加很多。

FairScheduler 具有延迟调度的参数 - 以获得更好的局部性。但是我不认为这是 EMR 的默认调度程序。

于 2013-04-25T08:40:44.470 回答