Mikio L. Braun柏林工业大学机器学习学博士后，TWIMPACT联合创始人兼首席数据科学家。在其个人博客上简述了主流SPF(Stream Processing Framework)与MapReduce的区别 —— 并没有查询层。
以下为译文：
当着手实时大数据时，SPF不失为MapReduce很好的替代。取代对数据进行批处理，它们在数据出现时就会进行处理;如果你处理的是事件流，使用SPF显然会比MapReduce来的合理。而类似Storm(Twitter)和S4(Yahoo!)这样的框架，显然更适合扩展类似(流处理)的计算。类似于MapReduce作业，你只要指定小的工作线程，然后这线线程会被自动的监视和部署从而提供稳健的扩展性。
所以开始你会觉得“SPF是基于MapReduce的事件版本”，然而这里存在着显著的差别：在流处理中是没有查询层的(最少在Storm和S4中是没有的)。
查询层，你可以通过指令查询出你想要的结果;然而就流处理来说，意味着指令会一直运行，因为你处理的是一个随时都有新时间加入的事件流。
举个例子，着眼随处可见的“单词计数用例”，络绎不绝的导入句子(比如说，推特)，那么你该如何查询出在一个指定的时间某个指定单词的个数。
答案可能与大部分人所想的不同：没有任何方法可以计算出结果(至少在现有的SPF中)。原因是：每个线程都会被分配数据流的一部分，然而却没有方法去访问这些信息。取而代之的是：结果只能定期的输出，不管是到屏幕或者是持久化储存。
不错，这只是一个比较业余的例子;然而这同样意味着现实中的应用程序，你需要一些数据库后端做结果的储存。取决于你处理的数据量和你所做的聚合程度(或者是不做)，这同样意味着你的持久化数据库MySQL可能满足不了流处理集群。
在MapReduce中也同样如此，对数据进行一些定期的修改，而区别在于MapReduce需要做两倍流处理额外后端的储存方案。
Mikio L. Braun认为以下的几个环境适合流处理：
针对高频度的事件流
每个独立的事件都需要处理高复杂度的分析
高聚合度，以至于数据的体积会大量的减少
而在以下的情况可能就不会很适用：
每个时间你都需要做许多的持久层修改
在分析进行的同时，可能会去做某些结果的查询
显然在IT领域没有通吃的算法及框架，把握自己的程序及数据类型，为其选择合适的分析工具才是王道。
