MapReduce map個數設置

版權聲明：本文為博主原創文章，轉載請加上原文地址，謝謝！ https://blog.csdn.net/Dr_Guo/article/details/51150278

看了很多博客，感覺沒有一個說的很清楚，所以我來整理一下。

先看一下這個圖

 

 

 

輸入分片（Input Split）：在進行map計算之前，mapreduce會根據輸入文件計算輸入分片（input split），每個輸入分片（input split）針對一個map任務，輸入分片（input split）存儲的並非數據本身，而是一個分片長度和一個記錄數據的位置的數組。

Hadoop 2.x默認的block大小是128MB，Hadoop 1.x默認的block大小是64MB，可以在hdfs-site.xml中設置dfs.block.size，注意單位是byte。

分片大小范圍可以在mapred-site.xml中設置，mapred.min.split.size mapred.max.split.size，minSplitSize大小默認為1B，maxSplitSize大小默認為Long.MAX_VALUE = 9223372036854775807

那么分片到底是多大呢？

 

minSize=max{minSplitSize,mapred.min.split.size} 

maxSize=mapred.max.split.size

splitSize=max{minSize,min{maxSize,blockSize}}

我們再來看一下源碼

所以在我們沒有設置分片的范圍的時候，分片大小是由block塊大小決定的，和它的大小一樣。比如把一個258MB的文件上傳到HDFS上，假設block塊大小是128MB，那么它就會被分成三個block塊，與之對應產生三個split，所以最終會產生三個map task。我又發現了另一個問題，第三個block塊里存的文件大小只有2MB，而它的block塊大小是128MB，那它實際占用Linux file system的多大空間？

答案是實際的文件大小，而非一個塊的大小。

有大神已經驗證這個答案了：http://blog.csdn.net/samhacker/article/details/23089157

 

1、往hdfs里面添加新文件前，hadoop在linux上面所占的空間為 464 MB：

2、往hdfs里面添加大小為2673375 byte(大概2.5 MB)的文件：

2673375 derby.jar

3、此時，hadoop在linux上面所占的空間為 467 MB——增加了一個實際文件大小(2.5 MB)的空間，而非一個block size(128 MB)：

4、使用hadoop dfs -stat查看文件信息： 

這里就很清楚地反映出： 文件的實際大小(file size)是2673375 byte， 但它的block size是128 MB。

5、通過NameNode的web console來查看文件信息: 

結果是一樣的： 文件的實際大小(file size)是2673375 byte， 但它的block size是128 MB。

6、不過使用‘hadoop fsck’查看文件信息，看出了一些不一樣的內容——  ‘1（avg.block size 2673375 B）’: 

值得注意的是，結果中有一個 ‘1（avg.block size 2673375 B）’的字樣。這里的 'block size' 並不是指平常說的文件塊大小(Block Size)—— 后者是一個元數據的概念，相反它反映的是文件的實際大小(file size)。以下是Hadoop Community的專家給我的回復： 

 

“The fsck is showing you an "average blocksize", not the block size metadata attribute of the file like stat shows. In this specific case, the average is just the length of your file, which is lesser than one whole block.”

最后一個問題是： 如果hdfs占用Linux file system的磁盤空間按實際文件大小算，那么這個”塊大小“有必要存在嗎？

其實塊大小還是必要的，一個顯而易見的作用就是當文件通過append操作不斷增長的過程中，可以通過來block size決定何時split文件。以下是Hadoop Community的專家給我的回復： 

“The block size is a meta attribute. If you append tothe file later, it still needs to know when to split further - so it keeps that value as a mere metadata it can use to advise itself on write boundaries.” 

補充：我還查到這樣一段話

原文地址：http://blog.csdn.net/lylcore/article/details/9136555

一個split的大小是由goalSize, minSize, blockSize這三個值決定的。computeSplitSize的邏輯是，先從goalSize和blockSize兩個值中選出最小的那個（比如一般不設置map數，這時blockSize為當前文件的塊size，而goalSize是文件大小除以用戶設置的map數得到的，如果沒設置的話，默認是1）。

 

hadooop提供了一個設置map個數的參數mapred.map.tasks，我們可以通過這個參數來控制map的個數。但是通過這種方式設置map的個數，並不是每次都有效的。原因是mapred.map.tasks只是一個hadoop的參考數值，最終map的個數，還取決於其他的因素。

     為了方便介紹，先來看幾個名詞：

block_size : hdfs的文件塊大小，默認為64M，可以通過參數dfs.block.size設置

total_size : 輸入文件整體的大小

input_file_num : 輸入文件的個數

 

（1）默認map個數

     如果不進行任何設置，默認的map個數是和blcok_size相關的。

     default_num = total_size / block_size;

 

（2）期望大小

     可以通過參數 mapred.map.tasks來設置程序員期望的map個數，但是這個個數只有在大於default_num的時候，才會生效。

     goal_num =  mapred.map.tasks;

 

（3）設置處理的文件大小

     可以通過mapred.min.split.size 設置每個task處理的文件大小，但是這個大小只有在大於 block_size的時候才會生效。

     split_size = max( mapred.min.split.size,  block_size );

     split_num = total_size / split_size;

 

（4）計算的map個數

compute_map_num = min(split_num,  max(default_num, goal_num))

 

     除了這些配置以外，mapreduce還要遵循一些原則。 mapreduce的每一個map處理的數據是不能跨越文件的，也就是說min_map_num >= input_file_num。 所以，最終的map個數應該為：

     final_map_num = max(compute_map_num, input_file_num)

 

     經過以上的分析，在設置map個數的時候，可以簡單的總結為以下幾點：

（1）如果想增加map個數，則設置mapred.map.tasks 為一個較大的值。

（2）如果想減小map個數，則設置mapred.min.split.size 為一個較大的值。

（3）如果輸入中有很多小文件，依然想減少map個數，則需要將小文件merger為大文件，然后使用准則2。