Shuffle過程是MapReduce的核心，描述着數據從map task輸出到reduce task輸入的這段過程。
Hadoop的集群環境，大部分的map task和reduce task是執行在不同的節點上的，那么reduce就要取map的輸出結果。那么集群中運行多個Job時，task的正常執行會對集群內部的網絡資源消耗嚴重。雖說這種消耗是正常的，是不可避免的，但是，我們可以采取措施盡可能的減少不必要的網絡資源消耗。另一方面，每個節點的內部，相比於內存，磁盤IO對Job完成時間的影響相當的大，。
所以：從以上分析，shuffle過程的基本要求：
1.完整地從map task端拉取數據到reduce task端
2.在拉取數據的過程中，盡可能地減少網絡資源的消耗
3.盡可能地減少磁盤IO對task執行效率的影響
那么，Shuffle的設計目的就要滿足以下條件：
1.保證拉取數據的完整性
2.盡可能地減少拉取數據的數據量
3.盡可能地使用節點的內存而不是磁盤
一、map階段
map節點執行map task任務生成map的輸出結果
shuffle的工作內容：
從運算效率的出發點，map輸出結果優先存儲在map節點的內存中。每個map task都有一個內存緩沖區，存儲着map的輸出結果，當緩沖區塊滿時，需要將緩沖區中的數據以一個臨時文件的方式存到磁盤，當整個map task結束后再對磁盤中這個map task所產生的所有臨時文件做合並，生成最終的輸出文件。最后，等待reduce task來拉取數據。當然，如果map task的結果不大，能夠完全存儲到內存緩沖區，且未達到內存緩沖區的閥值，那么就不會有寫臨時文件到磁盤的操作，也不會有后面的合並。
圖解如下：
環形緩沖區：是使用指針機制把內存中的地址首尾相接形成一個存儲中間數據的緩存區域，默認100MB;80M閾值,20M緩沖區,是為了解決寫入環形緩沖區數據的速度大於寫出到spill文件的速度是數據的不丟失;
Spill文件：spill文件是環形緩沖區到達閾值后寫入到磁盤的單個文件.這些文件在map階段計算結束時,會合成分好區的一個merge文件供給給reduce任務抓取;spill文件過小的時候,就不會浪費io資源合並merge;默認情況下3個以下spill文件不合並;對於在環形緩沖區中的數據,最終達不到80m但是數據已經計算完畢的情況,map任務將會調用flush將緩沖區中的數據強行寫出spill文件。
二、reduce階段
當mapreduce任務提交后，reduce task就不斷通過RPC從JobTracker那里獲取map task是否完成的信息，如果獲知某台TaskTracker上的map task執行完成，Shuffle的后半段過程就開始啟動。其實呢，reduce task在執行之前的工作就是：不斷地拉取當前job里每個map task的最終結果，並對不同地方拉取過來的數據不斷地做merge，過程如下：
reduce階段分三個步驟：
抓取，合並，排序
1 reduce 任務會創建並行的抓取線程（fetcher）負責從完成的map任務中獲取結果文件，是否完成是通過rpc心跳監聽，通過http協議抓取；默認是5個抓取線程，可調，為了是整體並行，在map任務量大，分區多的時候，抓取線程調大；
2 抓取過來的數據會先保存在內存中，如果內存過大也溢出，不可見，不可調，但是單位是每個merge文件，不會切分數據；每個merge文件都會被封裝成一個segment的對象，這個對象控制着這個merge文件的讀取記錄操作，有兩種情況出現：
在內存中有merge數據 •
在溢寫之后存到磁盤上的數據 •
通過構造函數的區分，來分別創建對應的segment對象
3 這種segment對象會放到一個內存隊列中MergerQueue，對內存和磁盤上的數據分別進行合並，內存中的merge對應的segment直接合並，磁盤中的合並與一個叫做合並因子的factor有關（默認是10）
4 排序問題
MergerQueue繼承輪換排序的接口，每一個segment 是排好序的，而且按照key的值大小邏輯（和真的大小沒關系）；每一個segment的第一個key都是邏輯最小，而所有的segment的排序是按照第一個key大小排序的，最小的在前面，這種邏輯總能保證第一個segment的第一個key值是所有key的邏輯最小文件合並之后，最終交給reduce函數計算的，是MergeQueue隊列，每次計算的提取數據邏輯都是提取第一個segment的第一個key和value數據，一旦segment被調用了提取key的方法，MergeQueue隊列將會整體重新按照最小key對segment排序，最終形成整體有序的計算結果；