宏觀上，Hadoop每個作業要經歷兩個階段：Map phase和reduce phase。對於Map phase，又主要包含四個子階段：從磁盤上讀數據-》執行map函數-》combine結果-》將結果寫到本地磁盤上；對於reduce phase，同樣包含四個子階段：從各個map task上讀相應的數據（shuffle）-》sort-》執行reduce函數-》將結果寫到HDFS中。
Hadoop處理流程中的兩個子階段嚴重降低了其性能。第一個是map階段產生的中間結果要寫到磁盤上，這樣做的主要目的是提高系統的可靠性，但代價是降低了系統的性能，實際上，Hadoop的改進版–MapReduce Online去除了這個階段，而採用其他更高效的方式提高系統可靠性（見參考資料[1]）；另一個是shuffle階段採用HTTP協議從各個map task上遠程拷貝結果，這種設計思路（遠程拷貝，協議採用http）同樣降低了系統性能。實際上，Baidu公司正試圖將該部分代碼替換成C++代碼來提高性能（見參考資料[2]）。
本文首先着重分析shuffle階段的具體流程，然後分析了其低效的原因，最後給出了可能的改進方法。
http://dongxicheng.org/wp-content/uploads/2011/03/hadoop_shuffle11.jpg
如圖所示，每個reduce task都會有一個後臺進程GetMapCompletionEvents，它獲取heartbeat中（從JobTracker）傳過來的已經完成的task列表，並將與該reduce task對應的數據位置信息保存到mapLocations中，mapLocations中的數據位置信息經過濾和去重（相同的位置信息因爲某種原因，可能發過來多次）等處理後保存到集合scheduledCopies中，然後由幾個拷貝線程（默認爲5個）通過HTTP並行的拷貝數據，同時線程InMemFSMergeThread和LocalFSMerger會對拷貝過來的數據進行歸併排序。
主要有兩個方面影響shuffle階段的性能：（1）數據完全是遠程拷貝 （2）採用HTTP協議進行數據傳輸。對於第一個方面，如果採用某種策略（修改框架），讓你reduce task也能有locality就好了；對於第二個方面，用新的更快的數據傳輸協議替換HTTP，也許能更快些, 如UDT協議（見參考資料[3]）， 它在MapReduce的另一個C++開源實現Sector/Sphere（見參考資料[4]）中被使用，效果不錯！
————————————————————————————————————————-
【參考資料】
【1】http://code.google.com/p/hop/
【2】http://wenku.baidu.com/view/8225e73f0912a21614792947.html
【3】http://udt.sourceforge.net/
【4】http://sector.sourceforge.net/
原創文章，轉載請註明： 轉載自董的博客
本文鏈接地址: http://dongxicheng.org/mapreduce/hadoop-shuffle-phase/