有谁能帮助我理解以下与我对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节点正在处理/输入/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电子病历观察到的。
2条答案
按热度按时间mu0hgdu01#
简短的回答-因为hadoop调度程序很糟糕。它没有预先的全局计划，文件拆分应该放在哪里。当节点请求工作时，它会查看可用的拆分，并给出最佳匹配。有一些参数可以调整hadoop在寻找最佳匹配方面的积极性（即，当工作请求到达时，它是否提供了当时可用的最佳匹配）？或者它是否会等待一段时间来查看其他匹配更好的节点是否也发送请求？）
默认情况下（我很确定emr就是这种情况）-调度器总是会将一些工作返回给请求节点-如果有任何工作可用。您可以看到，如果您的输入很小（仅跨越几个块/节点），但是节点的数量较大（相比之下），那么您将获得非常差的局部性。另一方面，如果输入的大小很大，那么获得良好位置的几率就会大大增加。
fairscheduler有参数来延迟调度，从而获得更好的局部性。然而，我不认为这是默认的计划与电子病历。
pjngdqdw2#
我不确定这是否能完全回答你的问题，但我会努力给你一些启示。
您在上面遇到的网络流量可能受到mapreduce框架提交作业的过程的影响；其中一部分在集群中默认传输作业jar的10个副本和包含在其中的所有库（在像您这样没有10个节点的情况下，我不确定它会如何运行）：有热拍和获取输入分割信息以及报告进度，这看起来像是小带宽操作，尽管我不知道他们的网络资源消耗的细节。
关于您正在运行的作业：如果它是一个仅Map的作业，那么hadoop会尝试（尝试是因为数据本地节点上可能存在运行的资源限制因素）进行数据本地优化，并在输入拆分所在的位置运行作业。听起来像是在你的例子中，文件小于默认的64mb，所以1个分割应该等于你的数据，这反过来应该会导致一个Map，因为Map的数量与你的分割数量成正比，但是，如果您的作业是map and reduce作业，那么网络流量可能会占用一些reduce copy and sort阶段的http网络流量，这些流量最终可能会出现在不同的节点上。
n input splits=n maps—输出-->m partitions=m reducer
当然，网络流量和数据位置优化取决于节点资源的可用性，因此您的测试假设应该考虑到这一点。
希望我能帮点忙。