前情回顧

Google MapReduce到底解決什么問題？

Google MapReduce是Google產(chǎn)出的一個編程模型，同時Google也給出架構(gòu)實現(xiàn)，它能夠解決“能用分治法解決的問題”。

?

Google MapReduce有啥巧妙優(yōu)化？

• 分區(qū)函數(shù)：保證不同map輸出的相同key，落到同一個reduce里

• 合并函數(shù)：在map結(jié)束時，對相同key的多個輸出做本地合并，節(jié)省總體資源

• 輸入文件到map如何切分：隨意，切分均勻就行

畫外音：看懂了這個流程，對工程架構(gòu)的理解，會容易很多。

?

上述執(zhí)行流程，Google MapReduce通過怎樣的工程架構(gòu)實現(xiàn)的呢？

先看下總體架構(gòu)圖，有個直觀的印象。

?

用戶使用GoogleMR系統(tǒng)，必須輸入的是什么？

• 輸入數(shù)據(jù)，必選

畫外音：否則系統(tǒng)處理啥。

• map函數(shù)，必選

• reduce函數(shù)，必選

畫外音：分治法，分與合的業(yè)務(wù)邏輯。

• 分區(qū)函數(shù)，必選

畫外音：保證同一個key，在合并階段，必須落到同一個reduce上，系統(tǒng)提供默認hash(key)法。

• 合并函數(shù)，可選

畫外音：看用戶是否需要在map結(jié)束階段進行優(yōu)化。

?

用戶提供各個輸入后，GoogleMR的執(zhí)行流程是什么？

畫外音：

不妨假設(shè)，用戶設(shè)置了M個map節(jié)點，R個reduce節(jié)點；例如：M=500，R=200

(1) 在集群中創(chuàng)建大量可執(zhí)行實例副本(fork)；

(2) 這些副本中有一個master，其他均為worker，任務(wù)的分配由master完成， M個map實例和R個reduce實例由worker完成；

(3) 將輸入數(shù)據(jù)分成M份，然后被分配到map任務(wù)的worker，從其中一份讀取輸入數(shù)據(jù)，執(zhí)行用戶的map函數(shù)處理，并在本地內(nèi)存生成臨時數(shù)據(jù)；

(4) 本地內(nèi)存臨時數(shù)據(jù)，通過分區(qū)函數(shù)，被分成R份，周期性的寫到本地磁盤，由master調(diào)度，傳給被分配到reduce任務(wù)的worker；

(5) 負責(zé)reduce任務(wù)的worker，從遠程讀取多個map輸出的數(shù)據(jù)，執(zhí)行用戶的reduce函數(shù)處理，處理結(jié)果寫入輸出文件；

畫外音：可能對key要進行外部排序。

(6) 所有map和reduce的worker都結(jié)束工作后，master喚醒用戶程序，MapReduce調(diào)用返回，結(jié)果被輸出到了R個文件中。

?

GoogleMR系統(tǒng)里的master和worker是啥？

(1)?master：單點master會存儲一些元數(shù)據(jù)，監(jiān)控所有map與reduce的狀態(tài)，記錄哪個數(shù)據(jù)要給哪個map，哪個數(shù)據(jù)要給哪個reduce，掌控全局視野，做中控；

畫外音：是不是和GFS的master非常像？

(2)?worker：多個worker進行業(yè)務(wù)邏輯處理，具體一個worker是用來執(zhí)行map還是reduce，是由master調(diào)度的；

畫外音：是不是和工作線程池非常像？這里的worker是分布在多臺機器上的而已。

?

master的高可用是如何保證的？

一個簡單的方法是，將元數(shù)據(jù)固化到磁盤上，用一個shadow-master來做高可用。

畫外音：GFS不就是這么干的么？

?

然而現(xiàn)實情況是：沒有將元數(shù)據(jù)固化到磁盤上，元數(shù)據(jù)被存放在master的內(nèi)存里用以提高工作效率，當(dāng)master掛掉后，通知用戶“任務(wù)執(zhí)行失敗”，讓其選擇重新執(zhí)行。

畫外音：

(1) 單點master，掌控全局視野，能讓系統(tǒng)的復(fù)雜性降低非常多；

(2) master掛掉的概率很小；

(3) 不做高可用，能讓系統(tǒng)的復(fù)雜性降低非常多；

?

worker的高可用是如何保證的？

master會周期性的ping每個worker，如果超時未返回，master會把對應(yīng)的worker置為無效，把這個worker的工作任務(wù)重新執(zhí)行：

• 如果重新執(zhí)行的是reduce任務(wù)，不需要有額外的通知

• 如果重新執(zhí)行的是map任務(wù)，需要通知執(zhí)行reduce的worker節(jié)點，輸入數(shù)據(jù)換了一個worker

?

隨時都可能有map或者reduce掛掉，任務(wù)完成前重新被執(zhí)行，會不會影響MR的最終結(jié)果？

在用戶輸入不變的情況下，MR的輸出一定是不變的，這就要求MR系統(tǒng)必須具備冪等性：

• 對相同的輸入，不管哪個負責(zé)map的worker執(zhí)行的結(jié)果，一定是不變的，產(chǎn)出的R個本地輸出文件內(nèi)容也一定是不變的

• 對于M個map，每個map輸出的R個本地文件，只要這些輸入不變，對應(yīng)接收這些數(shù)據(jù)的reduce的worker執(zhí)行結(jié)果，一定是不變的，輸出文件內(nèi)容也也一定是不變的

?

長尾效應(yīng)怎么解決？

一個MR執(zhí)行時間的最大短板，往往是“長尾worker”。

導(dǎo)致“長尾worker”的原因有很多：

(1) 用戶的分區(qū)函數(shù)設(shè)計得不合理，導(dǎo)致某些reduce負載不均，要處理大量的數(shù)據(jù)；

畫外音：

最壞的情況，所有數(shù)據(jù)最終都落到一個reduce上，分布式并行處理，轉(zhuǎn)變?yōu)榱藛螜C串行處理；

所以，分區(qū)函數(shù)的負載均衡性，是用戶需要考慮的。

(2) 因為系統(tǒng)的原因，worker所在的機器磁盤壞了，CPU有問題，也可能導(dǎo)致任務(wù)執(zhí)行很慢；

GoogleMR有一個“備用worker”的機制，當(dāng)某些worker的執(zhí)行時間超出預(yù)期時，會啟動另一個worker執(zhí)行相同的任務(wù)，以嘗試解決長尾效應(yīng)。

?

總結(jié)

Google MapReduce架構(gòu)，提現(xiàn)了很多經(jīng)典架構(gòu)實踐：

• 單點master簡化系統(tǒng)復(fù)雜度

• 單點master不高可用，簡化系統(tǒng)復(fù)雜度

• master對worker的監(jiān)控以及重啟，保證worker高可用

• 冪等性，保證結(jié)果的正確性

• 多個worker執(zhí)行同一個任務(wù)優(yōu)化長尾問題

總結(jié)

以上是生活随笔為你收集整理的Google MapReduce架构设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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