【51CTO獨(dú)家特稿】流式計(jì)算？云計(jì)算？最近各種計(jì)算讓技術(shù)人員，特別是開發(fā)人員很頭疼。其實(shí)這些名字已經(jīng)慢慢變成現(xiàn)實(shí)，比如MapReduce，就已經(jīng)成為了大型搜索引擎進(jìn)行數(shù)據(jù)挖掘，數(shù)據(jù)分析的工具。

MapReduce結(jié)構(gòu)圖

互聯(lián)網(wǎng)企業(yè)每天都在存儲海量的非結(jié)構(gòu)化數(shù)據(jù)和結(jié)構(gòu)化數(shù)據(jù)，這些數(shù)據(jù)需要在短時(shí)間內(nèi)被處理，否則就會讓用戶體驗(yàn)處于崩潰的邊緣。好吧，MapReduce就被企業(yè)用來分布式處理這些數(shù)據(jù)，按照調(diào)度批量任務(wù)來操作靜態(tài)數(shù)據(jù)。

流式計(jì)算呢？也跟MapReduce處理機(jī)制一樣，把數(shù)據(jù)包分割成小塊，然后通過并行計(jì)算的方式將這些數(shù)據(jù)快速處理。其實(shí)兩者的差別在哪兒呢？

公交車PK大火車

MapReduce是嚴(yán)格按照調(diào)度命令來執(zhí)行的，也就是說每一單位時(shí)間處理的數(shù)據(jù)量似乎是可定的。這就像鐵路上的調(diào)度命令一輛18節(jié)的火車?yán)每徒?jīng)過一個(gè)火車站，不管這個(gè)火車站上來多少人，火車還必須開走。這樣的好處就是一次處理的數(shù)據(jù)量可以得到保證，但實(shí)時(shí)性較低，不能隨著數(shù)據(jù)量的高低進(jìn)行靈活變化。這一點(diǎn)似乎對于有些網(wǎng)站來說有些不可接受，因?yàn)檫@些站點(diǎn)經(jīng)常會面對突如其來的流量高峰。

流式計(jì)算，根據(jù)定義的意思是可以理解為公交車。在開始的時(shí)候并沒有乘客，經(jīng)過若干站后數(shù)據(jù)進(jìn)入到系統(tǒng)中，并被處理。流式計(jì)算希望乘客越快到達(dá)目的地越好，不用擔(dān)心調(diào)度的相關(guān)命令。數(shù)據(jù)來了就盡快處理，不留下隱患。

這樣流式計(jì)算就更能適應(yīng)網(wǎng)站的流量高峰，因?yàn)椴粫鶕?jù)調(diào)度命令死板的安排計(jì)算過程，數(shù)據(jù)被處理的速度很快。用戶端的響應(yīng)很快，讓用戶幾乎沒有抱怨的時(shí)間。

MapReduce真的要讓位？

這么看來，流式計(jì)算比MapReduce更加靈活，MapReduce應(yīng)該被盡快替代。51CTO認(rèn)為這樣的觀點(diǎn)有其片面的理解。

誠然，流式計(jì)算更靈活，但勢必比MapReduce多一些處理成本。MapReduce中的Hadoop已經(jīng)被優(yōu)化到***，其效率也不容小覷。在有些企業(yè)應(yīng)用環(huán)境下，MapReduce這樣更固定一些的處理機(jī)制意味著成本的控制度更好。

未來的分布式計(jì)算，MapReduce與流式計(jì)算代表的是不同需求下的不同方案。讓這兩者PK，還是要根據(jù)不同企業(yè)的不同需求。兩者沒有絕對意義上的優(yōu)劣，只是在處理數(shù)據(jù)流程原則上的差異。

所以，要采用MapReduce還是流式計(jì)算，還是要看企業(yè)的數(shù)據(jù)來源具備什么樣的特征。

【編輯推薦】

1. Apache .htaccess文件的8個(gè)用法
2. Hadoop 從Yahoo向Google的技術(shù)轉(zhuǎn)折
3. Hadoop集群與Hadoop性能優(yōu)化
4. Facebook實(shí)時(shí)信息系統(tǒng)：HBase每月存儲1350億條信息