建站
咨詢
售后
建站咨詢
新聞中心
下圖是一個典型的，互聯(lián)網(wǎng)分層架構(gòu)：
“只有客戶發(fā)展了，才有我們的生存與發(fā)展！”這是成都創(chuàng)新互聯(lián)的服務(wù)宗旨！把網(wǎng)站當(dāng)作互聯(lián)網(wǎng)產(chǎn)品，產(chǎn)品思維更注重全局思維、需求分析和迭代思維，在網(wǎng)站建設(shè)中就是為了建設(shè)一個不僅審美在線，而且實用性極高的網(wǎng)站。創(chuàng)新互聯(lián)對成都網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)、網(wǎng)站制作、網(wǎng)站開發(fā)、網(wǎng)頁設(shè)計、網(wǎng)站優(yōu)化、網(wǎng)絡(luò)推廣、探索永無止境。
- 客戶端層：典型調(diào)用方是瀏覽器browser或者手機APP
- 站點應(yīng)用層：實現(xiàn)核心業(yè)務(wù)邏輯，從下游獲取數(shù)據(jù)，對上游返回html或者json
- 服務(wù)層：業(yè)務(wù)服務(wù)，數(shù)據(jù)服務(wù)，基礎(chǔ)服務(wù)，對上游提供友好的RPC接口
- 數(shù)據(jù)緩存層：緩存加速訪問存儲
- 數(shù)據(jù)固化層：數(shù)據(jù)庫固化數(shù)據(jù)存儲
同一個層次的內(nèi)部，例如端上的APP，以及web-server，也都會進行MVC分層：
- view層：展現(xiàn)
- control層：邏輯
- model層：數(shù)據(jù)
工程師骨子里，都潛移默化的實施著分層架構(gòu)設(shè)計。
互聯(lián)網(wǎng)分層架構(gòu)的本質(zhì)究竟是什么呢?
如果我們仔細(xì)思考會發(fā)現(xiàn)，不管是跨進程的分層架構(gòu)，還是進程內(nèi)的MVC分層，都是一個“數(shù)據(jù)移動”，然后“被處理”和“被呈現(xiàn)”的過程。
如上圖所示：數(shù)據(jù)處理和呈現(xiàn)，需要CPU計算，而CPU是固定不動的：
- db/service/web-server都部署在固定的集群上
- 端上，不管是browser還是APP，也有固定的CPU處理
而數(shù)據(jù)是移動的：
- 跨進程的：數(shù)據(jù)從數(shù)據(jù)庫和緩存里，轉(zhuǎn)移到service層，到web-server層，到client層
- 同進程的：數(shù)據(jù)從model層，轉(zhuǎn)移到control層，轉(zhuǎn)移到view層
歸根結(jié)底一句話：互聯(lián)網(wǎng)分層架構(gòu)，是一個CPU固定，數(shù)據(jù)移動的架構(gòu)。
MapReduce的架構(gòu)，是不是也遵循這個架構(gòu)特點呢?
假如MapReduce也使用類似的的分層架構(gòu)模式：
提前部署服務(wù)：
- map服務(wù)層：接收輸入數(shù)據(jù)，產(chǎn)出“分”的數(shù)據(jù)，集群部署M=1W個實例
- reduce服務(wù)層：接受“合”的數(shù)據(jù)，產(chǎn)出最終數(shù)據(jù)，集群部署R=1W個實例
當(dāng)用戶提交作業(yè)時：
- 把數(shù)據(jù)數(shù)據(jù)傳輸給map服務(wù)集群;
- map服務(wù)集群產(chǎn)出結(jié)果后，把數(shù)據(jù)傳輸給reduce服務(wù)集群;
- reduce服務(wù)集群把結(jié)果傳輸給用戶;
存在什么問題?
將有大量的時間浪費在大量數(shù)據(jù)的網(wǎng)絡(luò)傳輸上。
畫外音：輸入給map，map給reduce，reduce給用戶。
會發(fā)現(xiàn)，“固定CPU，移動數(shù)據(jù)”的架構(gòu)并不適合。
Google MapReduce工程架構(gòu)是如何思考這一個問題的呢?
為了減少數(shù)據(jù)量的傳輸：
(1) 輸入數(shù)據(jù)，被分割為M塊后，master會盡量將執(zhí)行map函數(shù)的worker實例，啟動在輸入數(shù)據(jù)所在的服務(wù)器上;
畫外音：不需要網(wǎng)絡(luò)傳輸了。
(2) map函數(shù)的worker實例輸出的的結(jié)果，會被分區(qū)函數(shù)劃分成R塊，寫到worker實例所在的本地磁盤;
畫外音：不需要網(wǎng)絡(luò)傳輸了。
(3) reduce函數(shù)，由于有M個輸入數(shù)據(jù)源(M個map的輸出都有一部分?jǐn)?shù)據(jù)可能對應(yīng)到一個reduce的輸入數(shù)據(jù))，所以，master會盡量將執(zhí)行reduce函數(shù)的worker實例，啟動在離這些輸入數(shù)據(jù)源盡可能“近”的服務(wù)器上;
- 畫外音：目的也是最小化網(wǎng)絡(luò)傳輸;
- 服務(wù)器之間的“近”，可以用內(nèi)網(wǎng)IP地址的相似度衡量。
所以，對于MapReduce系統(tǒng)架構(gòu)，“固定數(shù)據(jù)，移動CPU”更為合理。
這是為什么呢?
互聯(lián)網(wǎng)在線業(yè)務(wù)的特點是：
- 總數(shù)據(jù)量大
- 吞吐量比較大，同時發(fā)起的請求多
- 每個請求，處理的數(shù)據(jù)相對比較小
- 用戶對處理時延比較敏感
這類業(yè)務(wù)，使用“固定CPU，移動數(shù)據(jù)”的分層架構(gòu)是合理的。
MapReduce離線業(yè)務(wù)的特點是：
- 吞吐量比較小，同時發(fā)起的任務(wù)比較少
- 每個任務(wù)，處理的數(shù)據(jù)量非常大
- 用戶對處理時延容忍性大
這類業(yè)務(wù)，使用“固定數(shù)據(jù)，移動CPU”的分層架構(gòu)是合理的。
任何脫離業(yè)務(wù)的架構(gòu)設(shè)計，都是耍流氓。
思考問題的本質(zhì)，希望大家有收獲。
【本文為專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
戳這里，看該作者更多好文
分享標(biāo)題：為何說，MapReduce，顛覆了互聯(lián)網(wǎng)分層架構(gòu)的本質(zhì)？
瀏覽地址：http://www.5511xx.com/article/dpcepsj.html
