MapReduce概要

背景

幾個小時要處理完TB的數(shù)據(jù)，但是這些程序一般都不是分布式系統(tǒng)人員開發(fā)的，使用起來因為一些分布式的系統(tǒng)問題，會非常的痛苦

總體目標(biāo)

非專業(yè)的分布式系統(tǒng)開發(fā)人員可以輕松的開發(fā)高效的處理大數(shù)據(jù)的程序，開發(fā)人員只需要定義好map和reduce函數(shù)，然后就可以在成千上萬的機器上運行了，完全可以不去關(guān)心分布式系統(tǒng)的細(xì)節(jié)。

優(yōu)勢

模型容易編程，將一些分布式系統(tǒng)中的頭痛問題隱藏起來：

• 并發(fā)：和順序執(zhí)行一樣的結(jié)果
• 如何在服務(wù)器上啟動worker和sever
• 在不同機器之間移動數(shù)據(jù)
• 容錯

模型的擴展性好，map和reduce函數(shù)彼此之間不需要等待，數(shù)據(jù)獲取上彼此也不干擾，因此可以并行執(zhí)行，因此可以通過簡單的加機器就提升系統(tǒng)性能

限制

那什么會是限制性能的因素呢？CPU?內(nèi)存？硬盤？網(wǎng)絡(luò)？一般來說會是網(wǎng)絡(luò)帶寬，要處理的數(shù)據(jù)傳輸會遠大于網(wǎng)絡(luò)帶寬，因此MR在設(shè)計會盡量減少網(wǎng)絡(luò)上的數(shù)據(jù)傳輸。

容錯

如果一個server在執(zhí)行MR job的時候掛了怎么辦？

我們可以簡單的重新執(zhí)行一遍任務(wù)，這是基于一個基本的假設(shè)：map和reduce函數(shù)都是純函數(shù)，不會改變輸入的數(shù)據(jù)、不會保持狀態(tài)、不共享內(nèi)存、不存在map和map，或者reduce和reduce之間的聯(lián)系。

所以重新執(zhí)行也會產(chǎn)生相同的輸出。純函數(shù)的這個特點是MR相對于其他并行編程方案的主要不同，然后也是因為這個特性使得MR非常簡單。

更多的一些細(xì)節(jié)

• master分配任務(wù)給worker，對于map函數(shù)會記錄住中間輸出位置
• 每個輸入都存儲在GFS中，一共存3份
• 所有的server同時運行GFS和MR workers，讓map worker從本機的GFS中讀取數(shù)據(jù)，減少網(wǎng)絡(luò)傳輸
• 輸入的分片會遠遠大于workers的數(shù)量，master在每臺機器上面執(zhí)行Map任務(wù)，當(dāng)原來的任務(wù)完成之后map會處理新的任務(wù)
• worker將輸出按key散列映射輸出到R分區(qū)保存在本地磁盤上
• 當(dāng)全部沒有Map執(zhí)行的時候Reduce將會執(zhí)行
• master告訴Reducers去獲取Map workers產(chǎn)生的中間數(shù)據(jù)分區(qū)，Reduce worker將最終的結(jié)果輸出到GFS

負(fù)載均衡

怎么讓任務(wù)均衡的在worker上運行？因為每個分片處理的時間都是不同的，不同的內(nèi)容和大小，機器性能也不同，因此分片的個數(shù)要大于worker，不會因為某個分片處理的特別慢和影響整個的完成時間，早完成的worker會接著處理下一個分片，最后所有worker一起完成任務(wù)。

容錯

mr怎么處理worker崩潰？

• map worker崩潰

  master重新執(zhí)行，將task重新分配給GFS上的其他副本的的機器上去，即使workers可能實際上已經(jīng)完成了任務(wù)，但是reducer需要中間文件，因此需要重新執(zhí)行map任務(wù)。這個時候，可能有些reducer可能已經(jīng)讀取了crashed worker產(chǎn)生的中間文件，這個時候也沒有關(guān)系，因為map和reduce函數(shù)都是無副作用的，因此重新執(zhí)行就可

• reduce worker在產(chǎn)生output之前崩潰：master將任務(wù)分配給其他worker執(zhí)行即可
• reduce worker在產(chǎn)生output的時候崩潰：GFS的atomic rename能夠保證在完成之前臨時文件都是不可見的，因此master重新分配任務(wù)即可

其他的一些問題

• 假如master意外的開啟兩個Ｍap worker處理同一個輸入會怎么樣？ 它只會告訴Reduce worker其中的一個。
• 假如兩個Reduce worker處理中間數(shù)據(jù)的同一個分區(qū)會怎么樣？ 它們都會將同一份數(shù)據(jù)寫到GFS上面，GFS的原子重命名操作會觸發(fā)，先完成的獲勝將結(jié)果寫到GFS.
• 假如一個ｗorker非常慢怎么辦 — 一個掉隊者？ 產(chǎn)生原因可能是非常糟糕的硬件設(shè)施。 master會對這些最后的任務(wù)創(chuàng)建第二份副本任務(wù)執(zhí)行。
• 假如一個worker因為軟件或者硬件的問題導(dǎo)致計算結(jié)果錯誤怎么辦？ 太糟糕了！MR假設(shè)是建立在"fail-stop"的cpu和軟件之上。
• 假如master崩潰怎么辦？

不適合哪些應(yīng)用

首先必須明確并不是所以應(yīng)用都適合map/shuffle/reduce這種模式

• 小數(shù)據(jù)不適合，因為成本太高
• 對于大數(shù)據(jù)的更新，例如：在大索引中增加些新的文件
• 不確定的讀（Map 和 Reduce都不能確定輸入）
• 多次shuffles，例如：page-rank

總結(jié)

MapReduce的出現(xiàn)使得集群計算變的流行，但是MapReduce也有優(yōu)缺點：

缺點：不是最有效或者靈活的

有點：擴展性好，容易編程，錯誤處理和數(shù)據(jù)移動都被隱藏了