可能的答案，
工作节点将如何分割此文件以进行处理。不同的工作节点将分别处理341（1024/3）kb。或者单个工作节点将处理该文件？
hadoop分布式文件系统（hdfs）通常比windows中可用的ntfs和fat等普通文件系统具有更大的块大小。hdfs中的块通过复制分散在多个节点（机器）上，如果提供了机架拓扑脚本，则可以更好地处理复制，并且这些块的位置更具策略性，以防止数据丢失（例如，如果hadoop在不知情的情况下将复制因子为2的块放置在同一机架中，而整个机架出现故障，则oops！。一个好的策略可能是将一个块存储在一个机架中，而将另一个复制块存储在另一个机架中）。默认情况下，一个块的大小是64mb。因此，一个1 mb的文件可能会驻留在一个块中，当然，它会跨不同的节点进行复制。通常，一个单独的Map工作在一个叫做分裂的东西上，分裂可以由一个或多个块组成。不同的Map可以处理不同的分裂。textinputformat通常处理以endline作为分隔符的文本文件，并为每次拆分触发Map，其大小大致相当于单个块的大小。为确保端点边界，拆分大小可以略大于或小于块大小。总之，在正常情况下，驻留在64mb单个块中的1MB文件将由单个Map任务处理。
如果我处理100个这样的文件。工作节点会在它们之间划分要处理的文件数吗？
如果存在100个单独的此类文件，则有可能会调用100 map task，除非您使用类似于combineinputformat的方法，该方法可以将多个块合并并处理为一个map的拆分。
另一种选择是，如果可能的话，将这100个文件合并到一个文件和进程中。
如果我处理一个100mb的文件呢？
同样，假设块大小为64mb，一个100mb的textinputformat文件应该由两个map任务大致处理。就像我说的，不同的输入格式可以用不同的方式处理！
注（节选自此）：
推测性执行：hadoop系统的一个问题是，通过将任务划分到多个节点上，少数慢速节点可能会限制程序的其余部分。例如，如果一个节点有一个慢磁盘控制器，那么它可能只以所有其他节点10%的速度读取其输入。因此，当99个map任务已经完成时，系统仍在等待最后一个map任务签入，这比所有其他节点都要花费更长的时间。
通过强制任务彼此独立运行，单个任务不知道其输入来自何处。任务信任hadoop平台来提供适当的输入。因此，相同的输入可以并行处理多次，以利用机器能力的差异。由于作业中的大多数任务即将结束，hadoop平台将跨多个没有其他工作要执行的节点调度剩余任务的冗余副本。这个过程称为推测执行。当任务完成时，他们会向jobtracker宣布这一事实。任务的任何一个副本先完成，就成为最终副本。如果其他副本是推测性执行的，hadoop会告诉tasktracker放弃任务并放弃它们的输出。