@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 保证所有记录的处理。处理特定拆分的机器可能会从除其“主”块之外的块中获取记录的片段，并且该块可能位于远程。获取记录片段的通信成本无关紧要，因为它很少发生。
Hadoop framework strength is its data locality.So whenever a client request for the hdfs data, framework always checks for the locality else it looks for little I/O utilization.
对于 1) 和 2)：我不是 100% 确定，但是如果任务无法完成 - 无论出于何种原因，包括输入拆分是否有问题 - 那么它会被终止并在它的位置启动另一个：所以每个maptask 与文件信息恰好得到一个拆分（您可以通过对本地集群进行调试以查看输入拆分对象中包含哪些信息来快速判断是否是这种情况：我似乎记得它只是一个位置）。
to 3)：如果文件格式是可拆分的，那么 Hadoop 将尝试将文件缩减为“inputSplit”大小的块；如果不是，那么无论文件大小如何，每个文件都是一项任务。如果您更改 minimum-input-split 的值，那么如果您的每个输入文件都被划分为块大小，您可以防止生成过多的映射器任务，但是如果您使用一些魔术，您只能组合输入组合器类（我认为这就是它的名称）。
HDFS 块大小是一个确切的数字，但输入拆分大小基于我们的数据逻辑，可能与配置的数字略有不同
输入拆分是馈送到每个映射器的逻辑数据单元。数据被拆分为有效记录。输入拆分包含块地址和字节偏移量。
假设您有一个跨越 4 个块的文本文件。
文件：
abcd
efgh
ijkl
mnop
块：
区块1：abcde
区块2：fghij
区块3：klmno
区块4：p
拆分：
拆分 1：abcdefh
拆分 2：ijklmnop
观察拆分与文件中的边界（记录）内联。现在，每个拆分都被馈送到映射器。
如果输入拆分大小小于块大小，您最终将使用更多的映射器，反之亦然。
希望有帮助。