map和reduce是hadoop的核心功能,hadoop正是經過多個map和reduce的並行運行來實現任務的分佈式並行計算,從這個觀點來看,若是將map和reduce的數量設置爲1,那麼用戶的任務就沒有並行執行,可是map和reduce的數量也不能過多,數量過多雖然能夠提升任務並行度,可是太多的map和reduce也會致使整個hadoop框架由於過分的系統資源開銷而使任務失敗。因此用戶在提交map/reduce做業時應該在一個合理的範圍內,這樣既能夠加強系統負載勻衡,也能夠下降任務失敗的開銷。web
1 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集羣的效率。負載均衡
2 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)方法來增長任務個數。分佈式
3 reduce數量爲0oop
有些做業不須要進行歸約進行處理,那麼就能夠設置reduce的數量爲0來進行處理,這種狀況下用戶的做業運行速度相對較高,map的輸出會直接寫入到 SetOutputPath(path)設置的輸出目錄,而不是做爲中間結果寫到本地。同時Hadoop框架在寫入文件系統前並不對之進行排序。orm