嘿，这个问题刚好戳中HDFS存储和MapReduce分片的一个常见优化点，我给你拆解明白～

为什么会生成4个输入分片？ #

咱们一步步捋清楚计算逻辑：

1. 先算HDFS的块拆分：HDFS默认块大小是64MB，260MB的文件如果单纯按块拆分，会得到 4个完整的64MB块（4×64=256MB），加上1个4MB的小尾块，总共5个HDFS块。
2. 但MapReduce的FileInputFormat有个默认的优化逻辑：为了避免启动太多小型Map任务——毕竟小任务的调度开销远大于它的计算开销——当剩余的文件片段大小小于块大小的10%（这里64MB的10%是6.4MB）时，会把这个小片段合并到前一个输入分片里。
3. 这里的4MB尾块明显小于6.4MB的阈值，所以它被合并到第4个分片里。最终就生成了4个输入分片：前3个分片对应完整的64MB块，第4个分片对应64MB+4MB=68MB的内容。

那“剩余的4MB”去哪里了？ #

其实它根本没“消失”，只是被MapReduce的分片优化逻辑合并到最后一个输入分片里了。当第4个Map任务运行时，它会处理这个包含原第4个64MB块和4MB尾块的分片，这部分数据会被正常读取、处理，完全不会丢失。

额外补充：这个合并阈值是可以自定义调整的，比如通过修改mapreduce.input.fileinputformat.split.minsize或mapreduce.input.fileinputformat.split.maxsize参数，就能改变分片的大小规则，但默认情况下是按块大小的10%来判断是否合并小片段。

内容的提问来源于stack exchange，提问作者TheCodeCache