任何人都可以帮助我理解与我对Hadoop数据位置的理解相反的观察结果。
具有3个节点的Hadoop集群：
主人：10.28.75.146
slave1：10.157.6.202
slave2：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会在202上远程分配224个节点处理数据？
注意：这不是例外。我注意到远程获取了许多数据文件，并观察到两个节点上eth0的巨大网络流量。我预计两个节点之间的流量几乎为零，因为我的所有数据文件都是<64MB，数据应该在本地处理。
仅供参考：这是在亚马逊的AWS EMR上观察到的。
答案 0 :(得分：1)
我不确定这是否会完全回答你的问题，但我会尝试发光。
您在上面遇到的网络流量可能受到mapreduce框架提交作业的过程的影响;其中一部分默认情况下会传输10个工作jar副本以及整个集群中包含的所有库（如果没有10个节点我不知道它会如何表现）：有热点并获得输入拆分信息和尽管我对网络资源消耗的具体细节一无所知，但报告的进展似乎是小带宽操作。
关于您正在运行的作业：如果它是仅映射作业，则Hadoop尝试（尝试因为可能存在数据本地节点上运行的资源限制因素）进行数据局部性优化并运行输入拆分为的作业位于。听起来在你的情况下，文件小于默认的64MB，所以1分割应该等于你的数据，这反过来应该导致一个地图，因为数字是地图与你拥有的分割数量成正比，但是如果你的工作是一个Map和Reduce工作，然后网络流量可能会收集一些减少复制和排序阶段的HTTP网络流量，这些流量最终会出现在不同的节点上。
N输入分割= N地图 - 输出 - ＆gt; M分区= M减速器
当然，网络流量和数据位置优化取决于节点资源的可用性，因此您的测试假设应考虑到这一点。
希望我有点帮助。
答案 1 :(得分：0)
简短回答 - 因为Hadoop调度程序很糟糕。它没有前期全局计划，文件拆分应该放在哪里。当节点要求工作时 - 它会查看可用的拆分 - 并给出最佳匹配。有些参数可以调整Hadoop在寻找最佳匹配方面的积极程度（即 - 当工作请求到达时 - 它是否提供当时可用的最佳匹配？还是等待某个时间来查看其他更好的匹配节点还发送请求？）
默认情况下（我很确定这是EMR的情况） - 调度程序总是会向请求节点返回一些工作 - 如果任何工作可用。您可以看到，如果您的输入很小（仅跨越几个块/节点），但节点数量较大（相比之下） - 那么您将获得非常差的局部性。另一方面 - 如果输入的大小很大 - 那么你获得好地方的几率会上升很多。
FairScheduler具有延迟调度的参数 - 以便获得更好的位置。但是我不认为这是EMR的默认调度程序。