我正在阅读 hadoop 权威指南，其中清楚地解释了输入拆分。 就像
输入拆分不包含实际数据，而是包含存储 HDFS 上数据的位置
和
通常，输入分割的大小与块大小相同
1) 假设一个 64MB 的块在节点 A 上，并在其他 2 个节点（B，C）之间复制，map-reduce 程序的输入拆分大小是 64MB，这个拆分只有节点A的位置？或者它是否具有所有三个节点 A、b、C 的位置？
2) 由于数据对于所有三个节点都是本地的，因此框架如何决定（选择）在特定节点上运行的 maptask？
3) 如果 Input Split 大小大于或小于块大小如何处理？
【问题讨论】：
@user1668782 的回答很好地解释了这个问题，我将尝试对其进行图形描述。
假设我们有一个 400MB 的文件，其中包含 4 条记录（例如：400MB 的 csv 文件，它有 4行，每行 100MB）
这正是输入拆分解决的问题。 输入拆分遵守逻辑记录边界。
假设 输入拆分 大小为 200MB
因此，输入拆分 1 应该同时具有记录 1 和记录 2。并且输入拆分 2 不会从记录 2 开始，因为记录 2 已分配给输入拆分 1。输入拆分 2 将从记录 3 开始。
这就是为什么输入拆分只是数据的逻辑块。它用 in 块指向开始和结束位置。
希望这会有所帮助。
【讨论】：
块是数据的物理表示。 Split 是 Block 中数据的逻辑表示。
可以在属性中更改块和分割大小。
Map 通过拆分从 Block 读取数据，即拆分充当 Block 和 Mapper 之间的代理。
考虑两个块：
第 1 块
aa bb cc dd ee ff gg hh ii jj
第 2 块
ww ee yy uu oo ii oo pp kk ll nn
现在 map 读取块 1 直到 aa 到 JJ 并且不知道如何读取块 2，即块不知道如何处理不同的信息块。这里出现了一个拆分，它将块 1 和块 2 形成一个逻辑分组作为单个块，然后它使用输入格式和记录读取器形成偏移量（键）和行（值），并发送映射以进行进一步处理。
如果您的资源有限并且您想限制地图的数量，您可以增加拆分大小。 例如： 如果我们有 640 MB 的 10 个块，即每个 64 MB 的块和资源是有限的，那么您可以将拆分大小设置为 128 MB，然后形成 128 MB 的逻辑分组，并且仅执行 5 个大小为 128 MB 的映射。
如果我们指定分割大小为假，那么整个文件将形成一个输入分割并由一个映射处理，当文件很大时需要更多时间来处理。
【讨论】：
输入拆分是记录的逻辑划分，而 HDFS 块是输入数据的物理划分。当它们相同时它非常有效，但在实践中它永远不会完美对齐。记录可以跨越块边界。 Hadoop 保证所有记录的处理。处理特定拆分的机器可能会从除其“主”块之外的块中获取记录的片段，并且该块可能位于远程。获取记录片段的通信成本无关紧要，因为它很少发生。
【讨论】：
至 1) 和 2)：我不是 100% 确定，但如果任务无法完成 - 无论出于何种原因，包括输入拆分是否有问题 - 然后它会被终止并在它的位置启动另一个：所以每个maptask都得到一个带有文件信息的拆分（您可以通过对本地集群进行调试以查看输入拆分对象中包含哪些信息来快速判断是否是这种情况：我似乎记得它只是一个位置）。
to 3)：如果文件格式是可拆分的，那么 Hadoop 将尝试将文件切割成“inputSplit”大小的块；如果不是，那么无论文件大小如何，每个文件都是一项任务。如果你改变 minimum-input-split 的值，那么如果你的每个输入文件被分成块大小，你可以防止产生太多的映射器任务，但你只能组合如果您对组合器类做了一些魔术，则输入（我认为这就是它的名称）。
【讨论】：
Hadoop 框架的优势在于它的数据局部性。因此，每当客户端请求 hdfs 数据时，框架总是会检查局部性，否则它会寻找很少的 I/O 利用率。
【讨论】：
输入拆分是馈送到每个映射器的逻辑数据单元。数据在有效记录之间进行拆分。输入拆分包含块地址和字节偏移量。
假设您有一个跨越 4 个块的文本文件。
文件：
a b c d
e f g h
我 j k l
m n o p
方块：
block1: a b c d e
块 2：f g h i j
块 3：k l m n o
块4：p
拆分：
拆分1：a b c d e f h
拆分2：i j k l m n o p
观察拆分与文件中的边界（记录）内联。现在，每个拆分都被馈送到映射器。
如果输入拆分大小小于块大小，您最终将使用更多的映射器，反之亦然。
希望对您有所帮助。
【讨论】：
HDFS 块大小是一个准确的数字，但输入分割大小是基于我们的 数据逻辑可能与配置的数字略有不同
【讨论】：