Map器的数量取决于框架计算的输入拆分的数量，而不是构成文件的块的数量。输入拆分可以超过一个块。在这种情况下，超出块大小的数据仍将由单个Map任务处理。输入分割是逻辑计算单元（通过Map器），而块是逻辑存储单元（通过hdfs）。
也就是说，如果文件有第二个输入拆分，则需要第二个Map器。

一旦越过128mb边界，就需要第二个块。
例如，文件130mb将显示为2个块：第一个128块，第二个128块是文件的其余部分
hdfs是用来处理大文件的。假设您有一个1000mb的文件。对于4k块大小，您必须发出256000个请求才能获取该文件（每个块1个请求）。在hdfs中，这些请求通过一个网络并带来大量开销。每个请求都必须由name节点进行处理，以确定在何处可以找到该块。交通太拥挤了！如果使用64mb块，请求数将减少到16个，从而大大降低了name节点的开销和负载成本。

我认为您对hdfs和mapreduce之间的关系有误解。hdfs是底层文件系统，mapreduce是计算框架。hdfs本身根本不使用mapreduce框架进行操作。mapreduce作业在查找作业jar、写入临时处理数据、将文件拉入处理或任何其他文件操作时使用hdfs作为文件系统。Map器/还原器的数量在作业提交时设置，并由提交作业的mapreduce客户端决定。
如果有一个500mb的文件被拆分为4个128mb的块，并且要运行一个字数计数mapreduce作业，该作业读取文件并输出每个出现的字的计数，然后使用4个Map器和2个还原器运行该作业，则每个map任务将处理4 x 128mb块中的一个块。作业将与hdfs namenode通信以请求文件，namenode将响应构建文件所需的所有块，并给出块的位置。Map阶段将从其数据节点读取这些文件，并在处理后生成4个文件（例如，part-0000、part-0001、part-0002、part-0003），reduce阶段将对每个文件中的字进行排序和汇总，并给出最终输出。
你不需要仅仅因为你的文件比块大就把块变大。这会破坏分布式文件系统或任何现有文件系统的用途。hdfs（以及我使用过的所有文件系统）可以有一个8gb的文件—它仍然会将它分解为128mb的块或任何您设置为块大小的块。