Maps與Reduces是什么

這篇文章將為大家詳細講解有關Maps與Reduces是什么，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

map和reduce是hadoop的核心功能，hadoop正是通過多個map和reduce的并行運行來實現任務的分布式并行計算。

        從這個觀點來看，如果將map和reduce的數量設置為1，那么用戶的任務就沒有并行執行，但是map和reduce的數量也不能過多，數量過多雖然可以提高任務并行度，但是太多的map和reduce也會導致整個hadoop框架因為過度的系統資源開銷而使任務失敗。所以用戶在提交map/reduce作業時應該在一個合理的范圍內，這樣既可以增強系統負載勻衡，也可以降低任務失敗的開銷。

    極端情況：一個極端是1個map、1個reduce的情況，這樣沒有任務并行。另一個極端是1,000,000個map、1,000,000個reduce的情況，會由于 框架的開銷過大而使得系統資源耗盡。

    so,合理地選擇Job中 Tasks數的大小能顯著的改善Hadoop執行的性能。增加task的個數會增加系統框架的開銷，但同時也會增強負載均衡并降低任務失敗的開銷。

• map的數量

        map的數量通常是由hadoop集群的DFS塊大小確定的，也就是輸入文件的總塊數。正常的map數量的并行規模大致是每一個Node是10~100個，對于CPU消耗較小的作業可以設置Map數量為300個左右，但是由于hadoop的沒一個任務在初始化時需要一定的時間，因此比較合理的情況是每個map執行的時間至少超過1分鐘。

        具體的數據分片是這樣的，InputFormat在默認情況下會根據hadoop集群的DFS塊大小進行分片，每一個分片會由一個map任務來進行處理，當然用戶還是可以通過參數mapred.min.split.size參數在作業提交客戶端進行自定義設置。還有一個重要參數就是mapred.map.tasks，這個參數設置的map數量僅僅是一個提示，只有當InputFormat 決定了map任務的個數比mapred.map.tasks值小時才起作用【可跟蹤源代碼查看理解】。同樣，Map任務的個數也能通過使用JobConf 的conf.setNumMapTasks(int num)方法來手動地設置。這個方法能夠用來增加map任務的個數，但是不能設定任務的個數小于Hadoop系統通過分割輸入數據得到的值。當然為了提高集群的并發效率，可以設置一個默認的map數量，當用戶的map數量較小或者比本身自動分割的值還小時可以使用一個相對交大的默認值，從而提高整體hadoop集群的效率。

•         MapReduce從HDFS中分割讀取split文件,通過InputFormat交給Mapper來處理。split是 MapReduce中最小的計算單元，一個split文件對應一個Map Task。

•         default,HDFS中的一個block,對應一個split。

•        當執行WordCount時：

1.  一個輸入文件若小于64M,default則保存在hdfs中的一個block中，對應一個split文件，so， 產生一個Map Task。

2. 一個輸入文件若為150M,default則保存在hdfs中的三個block中，對應三個split文件，so ，產生三個Map Task。

3. 若有三個輸入文件都小于64M,default會保存在hdfs中的三個block中，對應三個split文件，so ，產生三個Map Task。

• 用戶可自行指定block與split之間的關系，HDFS中的一個block，一個split可以對應多個block,split與block的關系 是一對多的關系。

• 總結MapReduce作業中Map Task數目是由：

1. 輸入文件的個數和大小；

2. ?hadoop設置split與block的關系來決定的。      ? 

• reduece的數量

        reduce在運行時往往需要從相關map端復制數據到reduce節點來處理，因此相比于map任務。

reduce節點資源是相對比較缺少的，同時相對運行較慢，正確的reduce任務的個數應該是0.95或者1.75 *（節點數 ×mapred.tasktracker.tasks.maximum參數值）。如果任務數是節點個數的0.95倍，那么所有的reduce任務能夠在 map任務的輸出傳輸結束后同時開始運行。如果任務數是節點個數的1.75倍，那么高速的節點會在完成他們第一批reduce任務計算之后開始計算第二批 reduce任務，這樣的情況更有利于負載均衡。同時需要注意增加reduce的數量雖然會增加系統的資源開銷，但是可以改善負載勻衡，降低任務失敗帶來的負面影響。同樣，Reduce任務也能夠與 map任務一樣，通過設定JobConf 的conf.setNumReduceTasks(int num)方法來增加任務個數。

• reduce數量為0

        有些作業不需要進行歸約進行處理，那么就可以設置reduce的數量為0來進行處理，這種情況下用戶的作業運行速度相對較高，map的輸出會直接寫入到 SetOutputPath(path)設置的輸出目錄，而不是作為中間結果寫到本地。同時Hadoop框架在寫入文件系統前并不對之進行排序。

        map red.tasktracker.map.tasks.maximum 這個是一個task tracker中可同時執行的map的最大個數，默認值為2，

看《pro hadoop》：it is common to set this value to the effective number of CPUs on the node  把job分割成map和reduce,合理地選擇Job中 Tasks數的大小能顯著的改善Hadoop執行的性能。增加task的個數會增加系統框架的開銷，但同時也會增強負載均衡并降低任務失敗的開銷。一個極端是1個map、1個reduce的情況，這樣沒有任務并行。另一個極端是1,000,000個map、1,000,000個reduce的情況，會由于框架的開銷過大而使得系統資源耗盡。 

•  Map任務的數量 
      Map的數量經常是由輸入數據中的DFS塊的數量來決定的。這還經常會導致用戶通過調整DFS塊大小來調整map的數量。正確的map任務的并行度似乎應該是10-100 maps/節點，盡管我們對于處理cpu運算量小的任務曾經把這個數字調正到300maps每節點。Task的初始化會花費一些時間，因此最好控制每個 map任務的執行超過一分鐘。 
  實際上控制map任務的個數是很 精妙的。mapred.map.tasks參數對于InputFormat設定map執行的個數來說僅僅是一個提示。InputFormat的行為應該把輸入數據總的字節值分割成合適數量的片段。但是默認的情況是DFS的塊大小會成為對輸入數據分割片段大小的上界。一個分割大小的下界可以通過一個mapred.min.split.size參數來設置。因此，如果你有一個大小是10TB的輸入數據，并設置DFS塊大小為 128M，你必須設置至少82K個map任務，除非你設置的mapred.map.tasks參數比這個數還要大。最終InputFormat 決定了map任務的個數。 
  Map任務的個數也能通過使用JobConf 的 conf.setNumMapTasks(int num)方法來手動地設置。這個方法能夠用來增加map任務的個數，但是不能設定任務的個數小于Hadoop系統通過分割輸入數據得到的值。 

• Reduce任務的個數 
  正確的reduce任務的 個數應該是0.95或者1.75 ×（節點數 ×mapred.tasktracker.tasks.maximum參數值）。如果任務數是節點個數的0.95倍，那么所有的reduce任務能夠在 map任務的輸出傳輸結束后同時開始運行。如果任務數是節點個數的1.75倍，那么高速的節點會在完成他們第一批reduce任務計算之后開始計算第二批 reduce任務，這樣的情況更有利于負載均衡。 
  目前reduce任務的數量 由于輸出文件緩沖區大小(io.buffer.size × 2 ×reduce任務個數 << 堆大小)，被限制在大約1000個左右。直到能夠指定一個固定的上限后，這個問題最終會被解決。 
  Reduce任務的數量同時也控制著輸出目錄下輸出文件的數量，但是通常情況下這并不重要，因為下一階段的 map/reduce任務會把他們分割成更加小的片段。 
  Reduce任務也能夠與 map任務一樣，通過設定JobConf 的conf.setNumReduceTasks(int num)方法來增加任務個數。

關于“Maps與Reduces是什么”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。