流式計算pk MapReduce，這唱的是哪一出？
原創【51CTO獨家特稿】流式計算？云計算？最近各種計算讓技術人員，特別是開發人員很頭疼。其實這些名字已經慢慢變成現實，比如MapReduce，就已經成為了大型搜索引擎進行數據挖掘，數據分析的工具。
MapReduce結構圖
互聯網企業每天都在存儲海量的非結構化數據和結構化數據，這些數據需要在短時間內被處理，否則就會讓用戶體驗處于崩潰的邊緣。好吧，MapReduce就被企業用來分布式處理這些數據，按照調度批量任務來操作靜態數據。
流式計算呢？也跟MapReduce處理機制一樣，把數據包分割成小塊，然后通過并行計算的方式將這些數據快速處理。其實兩者的差別在哪兒呢？
公交車PK大火車
MapReduce是嚴格按照調度命令來執行的，也就是說每一單位時間處理的數據量似乎是可定的。這就像鐵路上的調度命令一輛18節的火車拉著旅客經過一個火車站，不管這個火車站上來多少人，火車還必須開走。這樣的好處就是一次處理的數據量可以得到保證，但實時性較低，不能隨著數據量的高低進行靈活變化。這一點似乎對于有些網站來說有些不可接受，因為這些站點經常會面對突如其來的流量高峰。
流式計算，根據定義的意思是可以理解為公交車。在開始的時候并沒有乘客，經過若干站后數據進入到系統中，并被處理。流式計算希望乘客越快到達目的地越好，不用擔心調度的相關命令。數據來了就盡快處理，不留下隱患。
這樣流式計算就更能適應網站的流量高峰，因為不會根據調度命令死板的安排計算過程，數據被處理的速度很快。用戶端的響應很快，讓用戶幾乎沒有抱怨的時間。
MapReduce真的要讓位？
這么看來，流式計算比MapReduce更加靈活，MapReduce應該被盡快替代。51CTO認為這樣的觀點有其片面的理解。
誠然，流式計算更靈活，但勢必比MapReduce多一些處理成本。MapReduce中的Hadoop已經被優化到***，其效率也不容小覷。在有些企業應用環境下，MapReduce這樣更固定一些的處理機制意味著成本的控制度更好。
未來的分布式計算，MapReduce與流式計算代表的是不同需求下的不同方案。讓這兩者PK，還是要根據不同企業的不同需求。兩者沒有絕對意義上的優劣，只是在處理數據流程原則上的差異。
所以，要采用MapReduce還是流式計算，還是要看企業的數據來源具備什么樣的特征。
【編輯推薦】
