Google MapReduce架構設計

前情回顧

Google MapReduce到底解決什麼問題？
Google MapReduce是Google產出的一個編程模型，同時Google也給出架構實現，它可以解決「能用分治法解決的問題」。

Google MapReduce有啥巧妙優化？

• 分區函數：保證不一樣map輸出的相同key，落到同一個reduce裏
• 合併函數：在map結束時，對相同key的多個輸出作本地合併，節省整體資源
• 輸入文件到map如何切分：隨意，切分均勻就行
  畫外音：看懂了這個流程，對工程架構的理解，會容易不少。

上述執行流程，Google MapReduce經過怎樣的工程架構實現的呢？

先看下整體架構圖，有個直觀的印象。

用戶使用GoogleMR系統，必須輸入的是什麼？

• 輸入數據，必選
  畫外音：不然系統處理啥。
• map函數，必選
• reduce函數，必選
  畫外音：分治法，分與合的業務邏輯。
• 分區函數，必選
  畫外音：保證同一個key，在合併階段，必須落到同一個reduce上，系統提供默認hash(key)法。
• 合併函數，可選
  畫外音：看用戶是否須要在map結束階段進行優化。

用戶提供各個輸入後，GoogleMR的執行流程是什麼？

畫外音：
不妨假設，用戶設置了M個map節點，R個reduce節點；例如：M=500，R=200

(1) 在集羣中建立大量可執行實例副本(fork)；

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

(3) 將輸入數據分紅M份，而後被分配到map任務的worker，從其中一份讀取輸入數據，執行用戶的map函數處理，並在本地內存生成臨時數據；

(4) 本地內存臨時數據，經過分區函數，被分紅R份，週期性的寫到本地磁盤，由master調度，傳給被分配到reduce任務的worker；

(5) 負責reduce任務的worker，從遠程讀取多個map輸出的數據，執行用戶的reduce函數處理，處理結果寫入輸出文件；
畫外音：可能對key要進行外部排序。

(6) 全部map和reduce的worker都結束工做後，master喚醒用戶程序，MapReduce調用返回，結果被輸出到了R個文件中。

GoogleMR系統裏的master和worker是啥？

(1) master：單點master會存儲一些元數據，監控全部map與reduce的狀態，記錄哪一個數據要給哪一個map，哪一個數據要給哪一個reduce，掌控全局視野，作中控；
畫外音：是否是和GFS的master很是像？
(2) worker：多個worker進行業務邏輯處理，具體一個worker是用來執行map仍是reduce，是由master調度的；
畫外音：是否是和工做線程池很是像？這裏的worker是分佈在多臺機器上的而已。

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

一個簡單的方法是，將元數據固化到磁盤上，用一個shadow-master來作高可用。
畫外音：GFS不就是這麼幹的麼？

然而現實狀況是：沒有將元數據固化到磁盤上，元數據被存放在master的內存裏用以提升工做效率，當master掛掉後，通知用戶「任務執行失敗」，讓其選擇從新執行。
畫外音：
(1) 單點master，掌控全局視野，能讓系統的複雜性下降很是多；
(2) master掛掉的機率很小；
(3) 不作高可用，能讓系統的複雜性下降很是多；

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

master會週期性的ping每一個worker，若是超時未返回，master會把對應的worker置爲無效，把這個worker的工做任務從新執行：

• 若是從新執行的是reduce任務，不須要有額外的通知
• 若是從新執行的是map任務，須要通知執行reduce的worker節點，輸入數據換了一個worker

隨時均可能有map或者reduce掛掉，任務完成前從新被執行，會不會影響MR的最終結果？

在用戶輸入不變的狀況下，MR的輸出必定是不變的，這就要求MR系統必須具有冪等性：

• 對相同的輸入，無論哪一個負責map的worker執行的結果，必定是不變的，產出的R個本地輸出文件內容也必定是不變的
• 對於M個map，每一個map輸出的R個本地文件，只要這些輸入不變，對應接收這些數據的reduce的worker執行結果，必定是不變的，輸出文件內容也也必定是不變的

長尾效應怎麼解決？

一個MR執行時間的最大短板，每每是「長尾worker」。

致使「長尾worker」的緣由有不少：
(1) 用戶的分區函數設計得不合理，致使某些reduce負載不均，要處理大量的數據；
畫外音：
最壞的狀況，全部數據最終都落到一個reduce上，分佈式並行處理，轉變爲了單機串行處理；
因此，分區函數的負載均衡性，是用戶須要考慮的。

(2) 由於系統的緣由，worker所在的機器磁盤壞了，CPU有問題，也可能致使任務執行很慢；

GoogleMR有一個「備用worker」的機制，當某些worker的執行時間超出預期時，會啓動另外一個worker執行相同的任務，以嘗試解決長尾效應。

總結
Google MapReduce架構，提現了不少經典架構實踐：

• 單點master簡化系統複雜度
• 單點master不高可用，簡化系統複雜度
• master對worker的監控以及重啓，保證worker高可用
• 冪等性，保證結果的正確性
• 多個worker執行同一個任務優化長尾問題

架構師之路-分享可落地的技術文章

相關推薦：
《GFS架構啓示》
《Google MapReduce解決什麼問題？》
《Google MapReduce巧妙優化思路？》
《過載保護+異構服務器的負載均衡》
《程序員養女兒的四大要點！》

做業：MR中有大量的數據進行傳輸，如何進行優化呢？