/*版權(quán)聲明：可以任意轉(zhuǎn)載，轉(zhuǎn)載時(shí)請(qǐng)務(wù)必標(biāo)明文章原始出處和作者信息 .*/????

??????????????????????????????????????? 張俊林
????????????????????? timestamp:2006年11月26日

設(shè)計(jì)要素

nutch包含以下幾個(gè)部分：

輔助類

• Log:記載運(yùn)行信息；

• Time:記載時(shí)間信息；

協(xié)議類

• 目的：各種進(jìn)程之間的通信協(xié)議

Client和M/R系統(tǒng)通信協(xié)議：完成客戶端和M/R系統(tǒng)的通信；

Job和Task系統(tǒng)通信協(xié)議：由于一個(gè)任務(wù)要分布完成，所以需要任務(wù)和子任務(wù)之間的通信協(xié)議；

MapTask和ReduceTask通信協(xié)議：由于MAP和REDUCE是一個(gè)任務(wù)的順序執(zhí)行過(guò)程，所以需要兩者之間的通信協(xié)議來(lái)對(duì)兩個(gè)步驟進(jìn)行協(xié)調(diào)，主要是文件輸入輸出協(xié)調(diào)；

進(jìn)程通信協(xié)議：子進(jìn)程和父進(jìn)程通信協(xié)議；

?

任務(wù)管理

????? 3.1任務(wù)定義與管理(JOB)：運(yùn)行，狀態(tài)管理，JOB和GOOGLE的MASTER是一個(gè)概念么？好像不一樣；JOB應(yīng)當(dāng)?shù)葍r(jià)于MapReduceSpecification類，那么nutch的master在哪里呢？

????? 3.2map管理；（運(yùn)行，狀態(tài)管理）

????? 3.3Reduce管理；（運(yùn)行，狀態(tài)管理）

????? 3.4map和Reduce協(xié)調(diào)管理；

????? 3.5.任務(wù)文件切割以及記錄讀寫等管理；（文件由記錄組成，切割時(shí)候注意邊界）；輸入輸出文件讀寫等管理；??

????關(guān)系定義：

• • 一個(gè)M/R系統(tǒng)同時(shí)并行處理若干個(gè)JOB，每個(gè)JOB需要記載其運(yùn)行狀態(tài)等；
  • 每個(gè)JOB對(duì)應(yīng)一個(gè)大型輸入文件，通過(guò)文件切割，建立若干個(gè)TASK分布在不同機(jī)器上處理切割過(guò)的文件片段，達(dá)到并行處理的目的；
  • 每個(gè)TASK可以分為順序執(zhí)行的兩部分：MAP/REDUCE，MAP階段分布在M個(gè)機(jī)器執(zhí)行，負(fù)責(zé)把輸入文件的《KEY,VALUE>轉(zhuǎn)換為《key1,value1>形式，不負(fù)責(zé)數(shù)據(jù)整理，只負(fù)責(zé)數(shù)據(jù)形式轉(zhuǎn)換；REDUCE階段分布在K個(gè)機(jī)器執(zhí)行，負(fù)責(zé)對(duì)MAP階段的輸出結(jié)果進(jìn)行排序和統(tǒng)計(jì)等整理，形成《key1,list(value1)>輸出形式；

?
?

Nutch和GOOGLE的區(qū)別與聯(lián)系：

大體上Nntch是按照GOOGLE的論文做的，但是有幾點(diǎn)區(qū)別，總體感覺(jué)Nntch在完整性和復(fù)雜性方面還不如GOOGLE的系統(tǒng)；

GOOGLE更像一個(gè)軟件框架，客戶在這個(gè)框架下寫自己的程序，而nutch更像一個(gè)固定功能的系統(tǒng)，當(dāng)然之所以nutch的mapper和reducer類基本只起到一個(gè)接口的作用，也是為了體現(xiàn)框架的意圖，由用戶繼承并定義新類來(lái)使用框架完成自己的任務(wù)，但是nutch的 jobclient和jobsubmission使得它更像一個(gè)靜態(tài)的功能而非框架；

GOOGLE的實(shí)現(xiàn)版本框架，其中的變化點(diǎn)在于

用戶自定義mapper;

用戶自定義reducer;

用戶可以對(duì)輸入文件格式解析進(jìn)行自定義；

用戶通過(guò)一個(gè)類來(lái)設(shè)定系統(tǒng)參數(shù)并將map/reduce類和輸入文件綁定起來(lái)；

用戶自定義partition類，該類主要由reducer調(diào)用，功能是通過(guò)HASH(KEY)使得同一個(gè)KEY的能夠映射到一臺(tái)機(jī)器上，這樣方便統(tǒng)計(jì)處理；

?

其中的不變點(diǎn)，也就是框架本身提供的功能:

????a.系統(tǒng)運(yùn)行流程：首先將輸入文件切割，然后分布到不同機(jī)器執(zhí)行map運(yùn)算，運(yùn)算結(jié)果通知master,master通知reducer去累計(jì)結(jié)果輸出；這個(gè)基本上是固定的；

????b.系統(tǒng)通信協(xié)議：master通過(guò)周期性的ping workers來(lái)判斷是否該進(jìn)程還有效；map運(yùn)算結(jié)果要傳送給master; master通知reducer輸入數(shù)據(jù)所在位置；reducer通過(guò)RPC調(diào)用來(lái)獲得輸入數(shù)據(jù)等；

????c.容錯(cuò)處理：自動(dòng)發(fā)現(xiàn)硬件錯(cuò)誤并提供補(bǔ)償措施，主要的補(bǔ)償措施是如果發(fā)現(xiàn)某個(gè)任務(wù)失效，則將任務(wù)調(diào)配到另外一臺(tái)機(jī)器重新計(jì)算；

????d.master記載控制信息并承擔(dān)控制工作：比如記錄任務(wù)分配信息；每個(gè)子任務(wù)（map/reduce）狀態(tài)信息；輪詢子任務(wù)獲得狀態(tài)信息；負(fù)責(zé)通信工作（類似于設(shè)計(jì)模式中的“中介者”模式）；發(fā)現(xiàn)錯(cuò)誤的話進(jìn)行調(diào)整工作（放置到一臺(tái)好的機(jī)器重新運(yùn)行）；?

GOOGLE的方案有一些優(yōu)化工作，比如計(jì)數(shù)器的實(shí)現(xiàn)，backup（就是往往最后完成的幾個(gè)子任務(wù)拖整個(gè)任務(wù)的后腿，GOOGLE的策略是：當(dāng)發(fā)現(xiàn)一個(gè)任務(wù)接近完成時(shí)候，啟動(dòng)幾個(gè)后備子任務(wù)，哪個(gè)先完成算哪個(gè)，可以有效提高速度），partition函數(shù)；master的 checkpoint為了恢復(fù)master的工作等；這些工作nutch還沒(méi)有實(shí)現(xiàn)；

GOOGLE方案的一些類：

????Counter:累計(jì)計(jì)數(shù)器；

????MapReduceSpecification:參數(shù)設(shè)定等；方法見論文；

????MapReduceInput:輸入文件參數(shù)設(shè)定以及mapper綁定；

????MapReduceOutput:輸出文件參數(shù)設(shè)定以及reducer 類綁定；

????Mapper:抽象類，用戶繼承進(jìn)行自定義；Emit()函數(shù)

????Reducer: 抽象類，用戶繼承進(jìn)行自定義；Emit()函數(shù)

????MapReduceResult:存放結(jié)果的類；?

????MapReduce(MapReduceSpecification, MapReduceResult)方法，是啟動(dòng)整個(gè)MAPREDUCE的控制流程函數(shù)；

總結(jié)

以上是生活随笔為你收集整理的MAP/REDUCE:Google和Nutch实现异同及其他的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。