生成的map()的数量等于输入数据的64MB块的数量。假设我们有两个1MB大小的输入文件，这两个文件都将存储在一个块中。但是当我用1个namenode和2个jobnode运行我的MR程序时，我看到生成了2个map()，每个文件一个。那么，这是因为系统试图在2个节点之间分割作业，即
Number of map() spawned = number of 64MB blocks of input data * number of jobnodes ?
同样，在mapreduce教程中，它编写了一个10TB的文件，块大小为128KB，将生成82000个映射。然而，根据映射数量仅取决于块大小的逻辑，必须生成78125个作业(10TB/128MB)。我不明白有多少额外的工作被创造出来?如果有人能分享一下你的想法，那就太好了。谢谢。:)
默认情况下，每个输入文件生成一个映射器，如果输入文件的大小大于split大小(通常与块大小保持相同)，则该文件的映射器数量将为filesize/split大小的上限。
现在假设你有5个输入文件，分割大小保持为64mb
file1 - 10 MB
file2 - 30 MB
file3 - 50 MB
file4 - 100 MB
file5 - 1500 MB
启动的映射器数量
file1 - 1
file2 - 1
file3 - 1
file4 - 2
file5 - 24
总映射器- 29
此外，输入分割大小和块大小并不总是受到尊重。如果输入文件是gzip文件，则不可分割。因此，如果其中一个gzip文件是1500mb，它将不会被分割。最好使用块压缩与Snappy或LZO以及序列文件格式。
同样，如果输入是HBASE表，则不使用输入分割大小。对于HBase表，拆分只是为了维护表的正确区域大小。
映射器的数量取决于一件事，您正在使用的InputFormat创建的InputSplits的no(默认是TextInputFormat，它创建以n作为分隔符的拆分)。它不依赖于no。节点的数量或文件或块大小(64MB或其他)。如果分割等于块，那就太好了。但这只是ideal的情况cannot be guaranteed总是。mapreduce框架会尽力优化这个过程。在这个过程中，只会为整个文件创建一个映射器(如果文件大小小于块大小)。另一种优化可能是创建较少数量的映射器，而不是分割的数量。For example如果你的文件有20行，你正在使用TextInputFormat那么你可能会认为你会得到20个映射器(如no。映射器=没有。的分割和TextInputFormat创建分割基于n)。但这并没有发生。为这么小的文件创建20个映射器会有不必要的开销。
如果分割的大小大于块的大小，则剩余的数据将从另一台机器上的另一个远程块移进来以便进行处理。
关于MapReduce教程:如果您有10TB的数据，则-(10*1024*1024)/128 = 81,920个映射器，几乎= 82,000
希望这能澄清一些问题。