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