這張是官方對shuffle過程的描述。但我可以肯定的是，單從這張圖你基本不可能明白shuffle的過程，因為它與事實相差挺多，細節也是錯亂的。後面我會具體描述shuffle的事實情況，所以這裡你只要清楚shuffle的大致範圍就成－怎樣把map task的輸出結果有效地傳送到reduce端。也可以這樣理解， shuffle描述著資料從map task輸出到reduce task輸入的這段過程。
在hadoop這樣的集群環境中，大部分map task與reduce task的執行是在不同的節點上。當然很多情況下reduce執行時需要跨節點去拉取其它節點上的map task結果。如果集群正在執行的job有很多，那麼task的正常執行對集群內部的網路資源消耗會很嚴重。這種網路消耗是正常的，我們不能限制，能做的就是最大化地減少不必要的消耗。還有在節點內，相比於記憶體，磁碟io對job完成時間的影響也是可觀的。從最基本的要求來說，我們對shuffle過程的期望可以有：
ok，看到這裡時，大家可以先停下來想想，如果是自己來設計這段shuffle過程，那麼你的設計目標是什麼。我想能優化的地方主要在於減少拉取資料的量及盡量使用記憶體而不是磁碟。
我的分析是基於hadoop0.21.0的原始碼，如果與你所認識的shuffle過程有差別，不吝指出。我會以wordcount為例，並假設它有8個map task和3個reduce task。從上圖看出，shuffle過程橫跨map與reduce兩端，所以下面我也會分兩部分來展開。
先看看map端的情況，如下圖：
MapReduce 詳解Shuffle過程
這張是官方對shuffle過程的描述。但我可以肯定的是，單從這張圖你基本不可能明白shuffle的過程，因為它與事實相差挺多，細節也是錯亂的。後面我會具體描述shuffle的事實情況，所以這裡你只要清楚shuffle的大致範圍就成 怎樣把map task的輸出結果有效地傳送到reduce端。也可以這...
MapReduce 詳解Shuffle過程
原文 這張是官方對shuffle過程的描述。但我可以肯定的是，單從這張圖你基本不可能明白shuffle的過程，因為它與事實相差挺多，細節也是錯亂的。後面我會具體描述shuffle的事實情況，所以這裡你只要清楚shuffle的大致範圍就成 怎樣把map task的輸出結果有效地傳送到reduce端。也...
MapReduce 詳解Shuffle過程
這張是官方對shuffle過程的描述。但我可以肯定的是，單從這張圖你基本不可能明白shuffle的過程，因為它與事實相差挺多，細節也是錯亂的。後面我會具體描述shuffle的事實情況，所以這裡你只要清楚shuffle的大致範圍就成 怎樣把map task的輸出結果有效地傳送到reduce端。也可以這...