迭代式MapReduce框架介紹

轉載自董的博客

 

一、  概述

傳統的MapReduce框架（見博文：傳統MapReduce框架）把一個做業的執行過程分爲兩個階段：map和reduce，在map階段，每一個map task讀取一個block，並調用map()函數進行處理，而後將結果寫到本地磁盤（注意，不是HDFS）上；在reduce階段，每一個reduce task遠程的從map task所在節點上讀取數據，調用reduce()函數進行數據處理，並將最終結果寫到HDFS。從以上過程能夠看出，map階段和reduce階段的結果均要寫磁盤，這雖然會下降系統性能，但能夠提升可靠性。正是因爲這個緣由，傳統的MapReduce不能顯式地支持迭代編程，若是用戶硬要在傳統MapReduce上運行迭代式做業，性能將很是低。爲此，很多改進型的MapReduce出現了，它們能很好地支持迭代式開發。本文組織結構以下：下一節將介紹幾個常見的迭代式做業並分析它們的特色；第3節介紹迭代式MapReduce框架須要解決的幾個難題；第4節介紹如今比較有名的迭代式MapReduce框架；第5節介紹迭代式MapReduce框架仍未解決的問題；最後一節給出了一些迭代式MapReduce框架的資料。

二、  迭代式做業

在數據挖掘，信息檢索等領域，有不少算法須要屢次迭代，本節介紹兩個常見的做業，一個是PageRank，另外一個是SSSP（Single Source Shortest Path）。PageRank是一個很是有名的網頁重要性衡量因素，它是一個屢次迭代的過程，以下圖所示，每次迭代，PageRank由兩個做業MR1和MR2完成，這樣迭代屢次，直到相鄰的兩次迭代中PR之差小於某一個閾值。

                                                                       

 

單源最短路徑問題實際上也是屢次迭代的過程，主要思想是：設G=(V,E)是一個帶權有向圖，R是G的鄰接矩陣。整個算法始終把圖中頂點集合V分紅兩組，第一組爲已求出最短路徑的頂點集合（用S表示，初始時S中只有一個源點，在每次迭代中求得一條最短路徑 , 並將該路徑的另外一頂點加入到集合S中，直到所有頂點都加入到S中，算法就結束了），第二組爲其他未肯定最短路徑的頂點集合（用U表示）。在每次迭代中，從U中選擇一個當前路徑最短的頂點，轉存到S中，直到U爲空。

更多迭代式做業以及在Hadoop上的實現方法，請參見Apache開源項目Mahout 以及它的論壇。

三、  技術難點

從PageRank和SSSP的整個計算過程能夠看出：

（1）       輸入數據由動態數據和靜態數據兩部分組成。對於PageRank， L屬於靜態數據，而R屬於動態數據；對於SSSP，R屬於靜態數據，S和U屬於動態數據。傳輸動態數據是不可避免的，而靜態數據能夠採用某種策略避免重複傳輸。怎樣避免傳輸靜態數據？

（2）       每次迭代，若是全部task重複從新建立，代價將很是高。怎樣重用task以提升效率（task pool）？

（3）       每次迭代，數據怎麼樣存儲？若是老是寫磁盤，代價將很是高。

（4）       什麼時候迭代終止，怎樣改變編程模型，容許用戶指定合適終止迭代.

四、  迭代式MapReduce框架

如今出現了很多迭代式MapReduce框架，比較有名的是Twister和Haloop（Ha，loop）。下面分別給予介紹。

Twister是由一個印度人開發的，其架構以下：

 

在Twister中，大文件不會自動被切割成一個一個block，於是用戶需提早把文件分紅一個一個小文件，以供每一個task處理。在map階段，通過map（）處理完的結果被放在分佈式內存中，而後經過一個broker network（NaradaBroking系統）將數據push給各個reduce task（Twister假設內存足夠大，中間數據能夠所有放在內存中）；在reduce階段，全部reduce task產生的結果經過一個combine操做進行歸併，此時，用戶能夠進行條件斷定， 肯定迭代是否結束。combine後的數據直接被送給map task，開始新一輪的迭代。爲了提升容錯性，Twister每隔一段時間會將map task和reduce task產生的結果寫到磁盤上，這樣，一旦某個task失敗，它能夠從最近的備份中獲取輸入，從新計算。

爲了不每次迭代從新建立task，Twister維護了一個task pool，每次須要task時直接從pool中取。在Twister中，全部消息和數據都是經過broker network傳遞的，該broker network是一個獨立的模塊，目前支持NaradaBroking和ActiveMQ。

整體上說，Twister仍是一個研究性項目，它的一些設計策略決定了它不太可能在實際中應用，如數據所有放在分佈式內存中；沒有分佈式文件系統，只提供了一個tool進行文件存取和訪問；計算模型抽象程度不夠，支持的應用類型不夠多。

Haloop是在Hadoop基礎上擴展而來的，其架構以下：

Haloop進行的改進有：

（1）       提供了一套新的編程接口，以方便用戶進行迭代式程序開發。

（2）       master node（jobtracker）包含一個循環控制模塊，它不斷的啓動map-reduce計算直到知足迭代終止條件。

（3）       設計了新的Task scheduler，以便更好的利用data locality特性。

（4）       數據在各個task tracker會被緩存（cache）和建索引（index）。

下面介紹技術創新點：

（1）       HaLoop 將全部迭代式任務抽象爲：，其中R0是初始輸入，L是每次迭代不變的數據，Ri是第i次迭代產生的結果。主要編程接口是：

SetFixedPointThreshold：設置兩次迭代的終止條件，即距離差是否達到某一個閾值

setMaxNumOfIterations：設置迭代次數

setIterationInput：設置變化的輸入數據

AddInvariantTable：設置不變的輸入數據

（2）       Loop-aware 任務調度。Haloop在第一次迭代時會將不變的輸入數據保存到該計算節點上，之後每次調度task，儘可能放在固定的那些節點上（locality）。這樣，每次迭代，不變的數據就沒必要重複傳輸了。

（3）       Cache和Index。Map task的輸入與輸出，Reduce task的輸出都會被建索引和緩存，以加快數據處理速度。其中，緩存是指數據被寫到本次磁盤，以供下一輪循環迭代時直接使用。

整體上說，Haloop比Twister抽象度更高，支持更多的計算，同時，因爲是在Hadoop基礎上修改上，於是繼承了Hadoop的不少優勢。

五、  總結

目前在迭代式MapReduce研究方面，還處於發展階段。Twister和Haloop的模型抽象度不夠高，支持的計算有限。

六、  參考資料

（1）       Twister主頁：http://www.iterativemapreduce.org/

（2）       Twister論文：Twister: A Runtime for Iterative MapReduce

(http://www.iterativemapreduce.org/hpdc-camera-ready-submission.pdf)

（3）       Haloop主頁：http://code.google.com/p/haloop/

（4）       Haloop論文：HaLoop: Efficient Iterative Data Processing on Large Clusters（http://www.ics.uci.edu/~yingyib/papers/HaLoop_camera_ready.pdf）