hadoop之 mapreduce data flow

注：隨筆 取自於 hadoop權威指南第四版

Hadoop 會講MapReduce輸入的數據切分紅大小相等的數據塊（fixed-size 固定大小，我認爲翻譯成相等大小比較合適），或者稱之爲分片。Hadoop會未每個分片建立一個map 任務，並由該任務來運行用戶自定義的map函數。

一個輸入數據能夠切分紅許多切片，咱們可使用map並行處理這些切片，縮短整個任務處理過程的時間。固然分片並非切分的越小越好，越多的分片就須要花費越多的時間去管理分片以及 增長構建map的時間。然而對於大多數的做業來講，比較合理的方式是 分片的大小是等於 block size。

若是在存有數據集的節點上運行map任務，hadoop將會得到更好的性能，由於這無需使用集羣的帶寬資源。這被稱爲data locality optimization。可是，有時候會有這麼一種狀況，當前map任務的輸入數據存儲的三個HDFS節點上都有其餘map任務在運行，此時，做業調度會在三個備份中的某個數據尋求同個機架中空閒的機器運行該map任務。固然若是未尋找到合適的機器，會使用其餘機架中的機器運行該map任務，不過這種狀況發生的機率比較小。下圖展現了這三種可能性。

It should now be clear why the optimal split size is the same as the block size: it is the largest size of input that can be guaranteed to be stored on a single node.
分片的大小不超過block size，能夠確保輸入的數據存儲在單個節點上。若是分片跨越兩個數據塊，在一個HDFS節點上，幾乎不可能同時存儲這兩個block，那麼部分輸入數據須要經過網絡進行傳輸。與使用本地數據相比，這種方法明顯不夠明智。

Map 函數產生的中間文件不會寫入HDFS，而是寫在了本地。緣由是map輸出的是中間結果，須要通過reduce的處理後才能產生最終結果。看成業完成時，map輸出的結果能夠刪除。所以，若是將中間結果存儲在HDFS並備份，overkill（過分，或者叫小題大作）。若是該節點運行的map任務在將結果傳輸到reduce以前失敗，hadoop會自動在其餘節點重現運行map任務，併產生中間結果。

reduce任務並不具有本地化優點。單個的reduce任務的輸入一般來自於全部mapper的輸出。在http://www.cnblogs.com/re-myself/p/5518283.html 例子中，只有一個reduce任務，其輸入是全部map任務的輸出。通過排序的map輸出需經過網絡傳輸發送到運行reduce任務的節點，並在reduce函數中進行合併、運算。reduce的輸出結果存儲在HDFS中。reduce輸出時，第一個replica 會存儲在本地節點，其餘replica會存儲在其餘的機架節點中。所以，reduce輸出確定會佔用網絡帶寬，可是和正常的寫入消耗是同樣的。
下圖是一個reduce任務的 MapReduce 數據流

reduce任務的數量並不是由輸入數據決定，須要獨立指定。
the map tasks partition their output, each creating one partition for each reduce task
若是有多個reducers，map會將其輸出進行分區，每個reduce任務都會建立一個分區。每一個分區都會有許多個鍵（還有其對應的值），可是每一個鍵值對記錄都在同一個分區中（There can be many keys (and their associated values)in each partition, but the records for any given key are all in a single partition）。分區由用戶定義partition函數控制。默認的partitioner是經過hash函數分區。

上圖未多個reduce任務的數據流圖

mapreduce能夠沒有reduce。數據處理能夠徹底並行，不須要shuffle。在這種狀況下，惟一的非本節點的傳輸是map任務將結果寫入HDFS。（In this case, the only off-node data transfer is when the map tasks write to HDFS）