我试图了解与 Hadoop 的 Map/Reduce 框架相关的数据局部性。特别是我试图了解哪个组件处理数据局部性（即它是输入格式吗？）
雅虎的开发者网络页面指出“Hadoop 框架然后使用来自分布式文件系统的知识将这些进程安排在靠近数据/记录位置的位置。” 这似乎意味着 HDFS 输入格式可能会查询名称节点以确定哪些节点包含所需的数据，并在可能的情况下在这些节点上启动映射任务。可以想象，HBase 也可以采用类似的方法，通过查询来确定哪些区域正在为某些记录提供服务。
如果开发人员编写自己的输入格式，他们会负责实现数据局部性吗？
你是对的。如果您正在查看FileInputFormat类和getSplits()方法。它搜索块位置：
BlockLocation[] blkLocations = fs.getFileBlockLocations(file, 0, length);
这意味着 FileSystem 查询。这发生在 内部JobClient，结果被写入 SequenceFile（实际上它只是原始字节码）。因此 Jobtracker 稍后会在初始化作业时读取此文件，并且几乎只是将任务分配给输入拆分。
但是数据的分布是 NameNodes 工作。
现在回答您的问题：通常您是从FileInputFormat. 因此，您将被迫返回一个列表InputSplit，并且在初始化步骤中，需要设置拆分的位置。例如FileSplit：
public FileSplit(Path file, long start, long length, String[] hosts)
所以实际上你并没有实现数据局部性本身，你只是告诉在哪个主机上可以找到拆分。这很容易通过FileSystem界面查询。
mu的理解是数据局部性是由HDFS和InputFormat共同决定的。前者确定（通过机架感知）并跨数据节点存储 HDFS 块的位置，而后者将确定哪些块与哪个拆分相关联。jobtracker 将尝试通过确保与每个 split 关联的块（1 split 到 1 map task 映射）对于 tasktracker 是本地的，来优化将哪些 split 传递给哪个 map 任务。
不幸的是，这种保证局部性的方法保留在同构集群中，但会在非同构集群中崩溃，即每个数据节点有不同大小的硬盘。如果您想深入了解这一点，您应该阅读这篇论文（通过异构 hadoop 集群中的数据放置来提高 MapReduce 性能），该论文还涉及与您的问题相关的几个主题。