為何說，MapReduce，顛覆了互聯(lián)網(wǎng)分層架構(gòu)的本質(zhì)？

下圖是一個(gè)典型的，互聯(lián)網(wǎng)分層架構(gòu)：

• 客戶端層：典型調(diào)用方是瀏覽器browser或者手機(jī)APP
• 站點(diǎn)應(yīng)用層：實(shí)現(xiàn)核心業(yè)務(wù)邏輯，從下游獲取數(shù)據(jù)，對上游返回html或者json
• 服務(wù)層：業(yè)務(wù)服務(wù)，數(shù)據(jù)服務(wù)，基礎(chǔ)服務(wù)，對上游提供友好的RPC接口
• 數(shù)據(jù)緩存層：緩存加速訪問存儲(chǔ)
• 數(shù)據(jù)固化層：數(shù)據(jù)庫固化數(shù)據(jù)存儲(chǔ)

?

同一個(gè)層次的內(nèi)部，例如端上的APP，以及web-server，也都會(huì)進(jìn)行MVC分層：

• view層：展現(xiàn)
• control層：邏輯
• model層：數(shù)據(jù)

?

工程師骨子里，都潛移默化的實(shí)施著分層架構(gòu)設(shè)計(jì)。

?

互聯(lián)網(wǎng)分層架構(gòu)的本質(zhì)究竟是什么呢？

如果我們仔細(xì)思考會(huì)發(fā)現(xiàn)，不管是跨進(jìn)程的分層架構(gòu)，還是進(jìn)程內(nèi)的MVC分層，都是一個(gè)“數(shù)據(jù)移動(dòng)”，然后“被處理”和“被呈現(xiàn)”的過程。

如上圖所示：

數(shù)據(jù)處理和呈現(xiàn)，需要CPU計(jì)算，而CPU是固定不動(dòng)的：

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

?

而數(shù)據(jù)是移動(dòng)的：

• 跨進(jìn)程的：數(shù)據(jù)從數(shù)據(jù)庫和緩存里，轉(zhuǎn)移到service層，到web-server層，到client層
• 同進(jìn)程的：數(shù)據(jù)從model層，轉(zhuǎn)移到control層，轉(zhuǎn)移到view層

?

歸根結(jié)底一句話：互聯(lián)網(wǎng)分層架構(gòu)，是一個(gè)CPU固定，數(shù)據(jù)移動(dòng)的架構(gòu)。

?

MapReduce的架構(gòu)，是不是也遵循這個(gè)架構(gòu)特點(diǎn)呢？

?

假如MapReduce也使用類似的的分層架構(gòu)模式：

提前部署服務(wù)：

• map服務(wù)層：接收輸入數(shù)據(jù)，產(chǎn)出“分”的數(shù)據(jù)，集群部署M=1W個(gè)實(shí)例
• reduce服務(wù)層：接受“合”的數(shù)據(jù)，產(chǎn)出最終數(shù)據(jù)，集群部署R=1W個(gè)實(shí)例

?

當(dāng)用戶提交作業(yè)時(shí)：

(1) 把數(shù)據(jù)數(shù)據(jù)傳輸給map服務(wù)集群；

(2) map服務(wù)集群產(chǎn)出結(jié)果后，把數(shù)據(jù)傳輸給reduce服務(wù)集群；

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

?

存在什么問題？

將有大量的時(shí)間浪費(fèi)在大量數(shù)據(jù)的網(wǎng)絡(luò)傳輸上。

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

?

會(huì)發(fā)現(xiàn)，“固定CPU，移動(dòng)數(shù)據(jù)”的架構(gòu)并不適合。

?

Google MapReduce工程架構(gòu)是如何思考這一個(gè)問題的呢？

為了減少數(shù)據(jù)量的傳輸：

(1) 輸入數(shù)據(jù)，被分割為M塊后，master會(huì)盡量將執(zhí)行map函數(shù)的worker實(shí)例，啟動(dòng)在輸入數(shù)據(jù)所在的服務(wù)器上；

畫外音：不需要網(wǎng)絡(luò)傳輸了。

(2) map函數(shù)的worker實(shí)例輸出的的結(jié)果，會(huì)被分區(qū)函數(shù)劃分成R塊，寫到worker實(shí)例所在的本地磁盤；

畫外音：不需要網(wǎng)絡(luò)傳輸了。

(3) reduce函數(shù)，由于有M個(gè)輸入數(shù)據(jù)源（M個(gè)map的輸出都有一部分?jǐn)?shù)據(jù)可能對應(yīng)到一個(gè)reduce的輸入數(shù)據(jù)），所以，master會(huì)盡量將執(zhí)行reduce函數(shù)的worker實(shí)例，啟動(dòng)在離這些輸入數(shù)據(jù)源盡可能“近”的服務(wù)器上；

畫外音：目的也是最小化網(wǎng)絡(luò)傳輸；

服務(wù)器之間的“近”，可以用內(nèi)網(wǎng)IP地址的相似度衡量。

?

所以，對于MapReduce系統(tǒng)架構(gòu)，“固定數(shù)據(jù)，移動(dòng)CPU”更為合理。

?

這是為什么呢？

?

互聯(lián)網(wǎng)在線業(yè)務(wù)的特點(diǎn)是：

• 總數(shù)據(jù)量大
• 吞吐量比較大，同時(shí)發(fā)起的請求多
• 每個(gè)請求，處理的數(shù)據(jù)相對比較小
• 用戶對處理時(shí)延比較敏感

這類業(yè)務(wù)，使用“固定CPU，移動(dòng)數(shù)據(jù)”的分層架構(gòu)是合理的。

MapReduce離線業(yè)務(wù)的特點(diǎn)是：

• 吞吐量比較小，同時(shí)發(fā)起的任務(wù)比較少
• 每個(gè)任務(wù)，處理的數(shù)據(jù)量非常大
• 用戶對處理時(shí)延容忍性大

這類業(yè)務(wù)，使用“固定數(shù)據(jù)，移動(dòng)CPU”的分層架構(gòu)是合理的。

任何脫離業(yè)務(wù)的架構(gòu)設(shè)計(jì)，都是耍流氓。

思考問題的本質(zhì)，希望大家有收獲。

福利來了?。。?/span>

免費(fèi)直播，大數(shù)據(jù)MapReduce升級(jí)版Spark。

事件：京東商城大數(shù)據(jù)實(shí)戰(zhàn)

人物：鳳凰金融大數(shù)據(jù)一把手，王端陽老師

時(shí)間：7月29日，20:00（沒錯(cuò)，今晚8點(diǎn)）

分享提綱是什么？

（1）企業(yè)級(jí)大數(shù)據(jù)開發(fā)流程分析；

（2）大數(shù)據(jù)分布式計(jì)算的核心思想傾囊相授；

（3）Spark體系架構(gòu)和任務(wù)提交流程分析；

（4）手把手帶你使用 Spark 實(shí)現(xiàn)企業(yè)日志分析

（5）常見的大數(shù)據(jù)分布式計(jì)算引擎對比分析；

有技術(shù)資料么（以下所有課程，免費(fèi)）？

大數(shù)據(jù)開發(fā)&架構(gòu)，20項(xiàng)核心攻略：

《Linux基礎(chǔ)命令及使用》

《Scala視頻》

《Hadoop集群搭建》

《HDFS?架構(gòu)設(shè)計(jì)》

《手寫簡單實(shí)現(xiàn)Hadoop》

《實(shí)現(xiàn)RPC》

《實(shí)現(xiàn)HDFS》

《實(shí)現(xiàn)MR》

《Hive底層執(zhí)行引擎剖析》

《Hive性能調(diào)優(yōu)實(shí)戰(zhàn)》

《大數(shù)據(jù)集群資源如何評估》

《Kafka消息引擎底層架構(gòu)剖析》

《Kafka源碼講解》

《Kafka高性能的消息封裝》

《Kafka客戶端容錯(cuò)體系源》

《Kafka服務(wù)端高性能架構(gòu)設(shè)計(jì)》

《Kafka數(shù)據(jù)管理》

《數(shù)據(jù)中臺(tái)的建設(shè)》

《數(shù)據(jù)中臺(tái)建設(shè)數(shù)據(jù)治理篇》

《ZooKeeper企業(yè)實(shí)戰(zhàn)&原理剖析》

如何參加免費(fèi)訓(xùn)練營，領(lǐng)取千元課程資料？

掃碼獲取直播地址，免費(fèi)領(lǐng)資料

祝大家在P8之路上前行，閱讀原文，福利等你。