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

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

如圖所示，每個(gè)reduce task都會(huì)有一個(gè)后臺(tái)進(jìn)程GetMapCompletionEvents，它獲取heartbeat中（從JobTracker）傳過來的已經(jīng)完成的task列表，并將與該reduce task對應(yīng)的數(shù)據(jù)位置信息保存到mapLocations中，mapLocations中的數(shù)據(jù)位置信息經(jīng)過濾和去重（相同的位置信息因?yàn)槟撤N原因，可能發(fā)過來多次）等處理后保存到集合scheduledCopies中，然后由幾個(gè)拷貝線程（默認(rèn)為5個(gè)）通過HTTP并行的拷貝數(shù)據(jù)，同時(shí)線程InMemFSMergeThread和LocalFSMerger會(huì)對拷貝過來的數(shù)據(jù)進(jìn)行歸并排序。

主要有兩個(gè)方面影響shuffle階段的性能：（1）數(shù)據(jù)完全是遠(yuǎn)程拷貝 （2）采用HTTP協(xié)議進(jìn)行數(shù)據(jù)傳輸。對于第一個(gè)方面，如果采用某種策略（修改框架），讓你reduce task也能有l(wèi)ocality就好了；對于第二個(gè)方面，用新的更快的數(shù)據(jù)傳輸協(xié)議替換HTTP，也許能更快些, 如UDT協(xié)議（見參考資料[3]）， 它在MapReduce的另一個(gè)C++開源實(shí)現(xiàn)Sector/Sphere（見參考資料[4]）中被使用，效果不錯(cuò)！

————————————————————————————————————————-

【參考資料】

【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/