Mikio L. Braun柏林工業(yè)大學(xué)機器學(xué)習(xí)學(xué)博士后，TWIMPACT聯(lián)合創(chuàng)始人兼首席數(shù)據(jù)科學(xué)家。在其個人博客上簡述了主流SPF(Stream Processing Framework)與MapReduce的區(qū)別 —— 并沒有查詢層。

以下為譯文：

當著手實時大數(shù)據(jù)時，SPF不失為MapReduce很好的替代。取代對數(shù)據(jù)進行批處理，它們在數(shù)據(jù)出現(xiàn)時就會進行處理;如果你處理的是事件流，使用SPF顯然會比MapReduce來的合理。而類似Storm(Twitter)和S4(Yahoo!)這樣的框架，顯然更適合擴展類似(流處理)的計算。類似于MapReduce作業(yè)，你只要指定小的工作線程，然后這線線程會被自動的監(jiān)視和部署從而提供穩(wěn)健的擴展性。

所以開始你會覺得“SPF是基于MapReduce的事件版本”，然而這里存在著顯著的差別：在流處理中是沒有查詢層的(最少在Storm和S4中是沒有的)。

查詢層，你可以通過指令查詢出你想要的結(jié)果;然而就流處理來說，意味著指令會一直運行，因為你處理的是一個隨時都有新時間加入的事件流。

舉個例子，著眼隨處可見的“單詞計數(shù)用例”，絡(luò)繹不絕的導(dǎo)入句子(比如說，推特)，那么你該如何查詢出在一個指定的時間某個指定單詞的個數(shù)。

答案可能與大部分人所想的不同：沒有任何方法可以計算出結(jié)果(至少在現(xiàn)有的SPF中)。原因是：每個線程都會被分配數(shù)據(jù)流的一部分，然而卻沒有方法去訪問這些信息。取而代之的是：結(jié)果只能定期的輸出，不管是到屏幕或者是持久化儲存。

不錯，這只是一個比較業(yè)余的例子;然而這同樣意味著現(xiàn)實中的應(yīng)用程序，你需要一些數(shù)據(jù)庫后端做結(jié)果的儲存。取決于你處理的數(shù)據(jù)量和你所做的聚合程度(或者是不做)，這同樣意味著你的持久化數(shù)據(jù)庫MySQL可能滿足不了流處理集群。

在MapReduce中也同樣如此，對數(shù)據(jù)進行一些定期的修改，而區(qū)別在于MapReduce需要做兩倍流處理額外后端的儲存方案。

Mikio L. Braun認為以下的幾個環(huán)境適合流處理：

針對高頻度的事件流

每個獨立的事件都需要處理高復(fù)雜度的分析

高聚合度，以至于數(shù)據(jù)的體積會大量的減少

而在以下的情況可能就不會很適用：

每個時間你都需要做許多的持久層修改

在分析進行的同時，可能會去做某些結(jié)果的查詢

顯然在IT領(lǐng)域沒有通吃的算法及框架，把握自己的程序及數(shù)據(jù)類型，為其選擇合適的分析工具才是王道。