宏觀上，Hadoop每個作業要經歷兩個階段：Map phase和reduce phase。對于Map phase，又主要包含四個子階段：從磁盤上讀數據-》執行map函數-》combine結果-》將結果寫到本地磁盤上；對于reduce phase，同樣包含四個子階段：從各個map task上讀相應的數據（shuffle）-》sort-》執行reduce函數-》將結果寫到HDFS中。

（注：本文介紹的shuffle階段非常粗略，如果想了解shuffle實現細節以及當前主流的優化方法，可閱讀我的最新書籍《Hadoop技術內幕：深入解析MapReduce架構設計與實現原理》（購買說明）第8章 “Task運行過程分析”以及第8.5.2節 “系統優化”）

Hadoop處理流程中的兩個子階段嚴重降低了其性能。第一個是map階段產生的中間結果要寫到磁盤上，這樣做的主要目的是提高系統的可靠性，但代價是降低了系統的性能，實際上，Hadoop的改進版–MapReduce Online去除了這個階段，而采用其他更高效的方式提高系統可靠性（見參考資料[1]）；另一個是shuffle階段采用HTTP協議從各個map task上遠程拷貝結果，這種設計思路（遠程拷貝，協議采用http）同樣降低了系統性能。實際上，Baidu公司正試圖將該部分代碼替換成C++代碼來提高性能（見參考資料[2]）。

本文首先著重分析shuffle階段的具體流程，然后分析了其低效的原因，最后給出了可能的改進方法。

如圖所示，每個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/

總結

以上是生活随笔為你收集整理的Hadoop中shuffle阶段流程分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。