一個MapReduce作業是一個用戶希望被執行的工作單元：它包括輸入數據，MapReduce程序和配置信息。Hadoop通過把作業分成任務（tasks，分為map tasks 和reduce tasks兩種）的形式來運行該作業。
有兩種節點用來控制每個作業的執行： jobtracker通過把tasks分發到各個tasktrackers來運行，並協調系統上運行的所有作業。tasktrackers運行任務，並向jobtracker報告進度信息，jobtracker保持了每個作業的全局進度。如果一個任務失敗了，jobtracker會把這個任務重新分發到另一個tasktracker上（也就是說，jobtracker不僅負責全局的作業調度，還要負責所有作業的所有task的維護，負擔比較大，所以因為這個問題而產生了MapReduce2--YARN，這個后面會做詳細介紹）。
Hadoop把一個MapReduce作業的輸入分成固定大小的分片，叫做input splits，也叫splits。Hadoop為每個split創建一個map任務。這樣可以很好地利用Hadoop的並發處理特性，如果一個節點的處理速度比較快，我們可以給它分配更多的splits。但split並不是越多越好，因為如果splits太小的話，管理splits和創建map task的額外開銷會在作業的執行時間中占很大比例，對於大多數作業來說，一個好的splits大小默認為HDFS的block大小，也就是64MB（這個值可以在集群層面上改變，這樣會影響到以后所有新創建的文件；也可以為以后每個新創建的文件設置一個特定的重載的值）。
如果map task運行的節點上剛好有輸入數據的冗余備份（replica），此時Hadoop可以發揮出它的最大性能（因為不需要額外的數據傳輸從而節省了時間），這叫做data locality optimization（數據本地最優化）。然而有時情況並不是如此理想，因為有可能存放replica的節點此時都在滿負荷運行着其他tasks，那么這個task就要被分發到其他節點上運行了，然后再從存放replica的最近的節點上取replica。總的來說，有以下三種情況：
Data-local (a), rack-local (b), and off-rack (c) map tasks
這是我們應該很清楚為什么splits的大小應剛好等於block的大小了吧，因為這是HDFS能保證的存放在一個節點上的最大數據量，如果splits的大小超過了block的大小，他就會占用兩個block，這兩個block又同時保存在一個節點上的概率是很小的，這樣就不可避免的要進行網絡傳輸了，從而增加了執行時間。
Map tasks把他們的輸出數據寫到本地文件系統，而不是HDFS上，這么做的原因是大多數Map任務的輸出都是中間數據：它接着會被reduce任務處理以產生最終輸出，而且一旦作業成功完成，這些中間數據就被刪除了，如果把他們存放到HDFS上的話會造成很大的額外開銷。如果運行map task的節點在reduce task取走map任務輸出的中間數據之前當機了（相應的，中間數據也就丟失了），Hadoop會在另一個節點上自動的重啟這個map task以重新生成這些中間數據。
Reduce masks並沒有數據本地化的優勢，因為單個reduce task的輸入數據通常是來自所有mapper的輸出的。因此，經排序的map輸出必須經由網絡傳送給reducer。reduce的輸出為了可靠性一般會存放到HDFS上去（第一個replica存放在本地節點上，其他兩個存放到與本地節點不同的機架上去）。
只有一個reduce task 的數據流如下所示（虛線箭頭表示本地數據流向，實線箭頭表示集群間數據流向）：
reduce task是的個數並不是由輸入數據的大小決定的，而是由用戶獨立設定的。當有很多reducer時，map tasks會把他們的輸出數據分區（partition），為每一個reducer創建一個分區（partition）。一個分區內可能有多個keys（以及與他們相連的values），但是每個給定的key所對應的的記錄（records）都保存在一個分區中。分區時使用的分區方法可以由用戶指定，但通常情況下，會使用一個默認的分區器（partitionor），它使用hash函數來對記錄進行分區。擁有多個reduce 的數據流表示如下：
從上圖中我們也可以看出，為什么從map到reduce的數據流會被稱為shuffle(有“洗牌，混亂”的意思)，因為每個reduce的輸入都是由很多map的輸出。shuffle階段遠比上圖演示的要復雜，此階段如果調優做的好的話，會對作業的執行時間有很大影響，具體細節以后再做討論。
轉載請注明出處：http://www.cnblogs.com/beanmoon/archive/2012/12/06/2805636.html