什么是MapReduce

分布式離線的計算框架，是一個分布式運算程序的編程框架，是用戶開發基于hadoop的數據分析應用的核心框架，mapreduce的核心功能是將用戶編寫的業務邏輯代碼和自帶的默認組件整合成一個完整的分布式運算程序，并發運行在一個hadoop集群上。

hdfs–解決的是海量數據的存儲問題。

mapreduce—解決的是海量數據的計算以及索引問題。

為什么說，MapReduce系統架構，顛覆了互聯網分層架構的本質？

下圖是一個典型的，互聯網分層架構：

• 客戶端層：典型調用方是瀏覽器browser或者手機App
• 站點應用層：實現核心業務邏輯，從下游獲取數據，對上游返回html或者json
• 服務層：業務服務，數據服務，基礎服務，對上游提供友好的RPC接口
• 數據緩存層：緩存加速訪問存儲
• 數據固化層：數據庫固化數據存儲

同一個層次的內部，例如端上的APP，以及web-server，也都會進行MVC分層：

• view層：展現
• control層：邏輯
• model層：數據

工程師骨子里，都潛移默化的實施著分層架構設計。

互聯網分層架構的本質究竟是什么呢？

如果我們仔細思考會發現，不管是跨進程的分層架構，還是進程內的MVC分層，都是一個“數據移動”，然后“被處理”和“被呈現”的過程。

如上圖所示：

數據處理和呈現，需要CPU計算，而CPU是固定不動的：

• db/service/web-server都部署在固定的集群上
• 端上，不管是browser還是APP，也有固定的CPU處理

而數據是移動的：

• 跨進程的：數據從數據庫和緩存里，轉移到service層，到web-server層，到client層
• 同進程的：數據從model層，轉移到control層，轉移到view層

歸根結底一句話：互聯網分層架構，是一個CPU固定，數據移動的架構。

MapReduce的架構，是不是也遵循這個架構特點呢？

假如MapReduce也使用類似的的分層架構模式：

提前部署服務：

• map服務層：接收輸入數據，產出“分”的數據，集群部署M=1W個實例
• reduce服務層：接受“合”的數據，產出最終數據，集群部署R=1W個實例

當用戶提交作業時：

(1) 把數據數據傳輸給map服務集群；

(2) map服務集群產出結果后，把數據傳輸給reduce服務集群；

(3) reduce服務集群把結果傳輸給用戶；

存在什么問題？

將有大量的時間浪費在大量數據的網絡傳輸上。

畫外音：輸入給map，map給reduce，reduce給用戶。

會發現，“固定CPU，移動數據”的架構并不適合。

google MapReduce工程架構是如何思考這一個問題的呢？

問了減少數據量的傳輸：

(1) 輸入數據，被分割為M塊后，master會盡量將執行map函數的worker實例，啟動在輸入數據所在的服務器上；

畫外音：不需要網絡傳輸了。

(2) map函數的worker實例輸出的的結果，會被分區函數劃分成R塊，寫到worker實例所在的本地磁盤；

畫外音：不需要網絡傳輸了。

(3) reduce函數，由于有M個輸入數據源（M個map的輸出都有一部分數據可能對應到一個reduce的輸入數據），所以，master會盡量將執行reduce函數的worker實例，啟動在離這些輸入數據源盡可能“近”的服務器上；

畫外音：目的也是最小化網絡傳輸；

服務器之間的“近”，可以用內網IP地址的相似度衡量。

所以，對于MapReduce系統架構，“固定數據，移動CPU”更為合理。

這是為什么呢？

互聯網在線業務的特點是：

• 總數據量大
• 吞吐量比較大，同時發起的請求多
• 每個請求，處理的數據相對比較小
• 用戶對處理時延比較敏感

這類業務，使用“固定CPU，移動數據”的分層架構是合理的。

MapReduce離線業務的特點是：

• 吞吐量比較小，同時發起的任務比較少
• 每個任務，處理的數據量非常大
• 用戶對處理時延容忍性大

這類業務，使用“固定數據，移動CPU”的分層架構是合理的。

總結：

任何脫離業務的架構設計，都是耍流氓。