Mapreduce 映射任务的数量是否取决于作业节点的数量？

生成的map（）数等于64MB的输入数据块数。假设我们有两个1MB大小的输入文件，两个文件都将存储在一个块中。但当我用1个namenode和2个jobnodes运行MR程序时，我看到生成了2个map（），每个文件对应一个。这是因为系统试图在两个节点之间分割作业，即

Number of map() spawned = number of 64MB blocks of input data * number of jobnodes ?

---

此外，在mapreduce教程中，如果编写的是块大小为128KB的10TB文件，则会生成82000个贴图。但是，根据映射数量仅取决于块大小的逻辑，必须生成78125个作业（10TB/128MB）。我不明白有多少额外的工作已经产生？如果有人能分享你对此的想法，那就太好了？谢谢。：）

默认情况下，每个输入文件生成一个映射器，如果输入文件的大小大于拆分大小（通常与块大小相同），则该文件的映射器数量将为filesize/split size的ceil

现在假设您有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

创建的inputflit的数量（默认为TextInputFormat，它创建以\n作为分隔符的拆分）。它不取决于节点数、文件或块大小（64MB或其他）。如果分割等于块，这是非常好的。但这只是一种理想的情况，不能保证总是这样。MapReudce框架尽最大努力优化流程。在这个过程中，只需要为整个文件创建一个映射器（如果文件大小小于块大小）。另一个优化可能是创建的映射器数量少于拆分的数量

例如

如果您的文件有20行，并且您使用的是TextInputFormat，那么您可能会认为您将获得20个映射器（映射器的数量=拆分的数量，TextInputFormat根据\n创建拆分）。但事实并非如此。为这样一个小文件创建20个映射器会产生不必要的开销

如果分割的大小大于块大小，则剩余的数据将从另一台机器上的另一个远程块移入以进行处理

关于MapReduce教程：

如果您有10TB的数据，那么- （10*1024*1024）/128=81920映射者，几乎等于82000

希望这能澄清一些事情