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

MapReduce結構圖

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

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

公交車PK大火車

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

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

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

MapReduce真的要讓位？

這么看來，流式計算比MapReduce更加靈活，MapReduce應該被盡快替代。51CTO認為這樣的觀點有其片面的理解。

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

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

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

【編輯推薦】

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