对比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领域没有通吃的算法及框架，把握自己的程序及数据类型，为其选择合适的分析工具才是王道。

更多阅读：

Mikio L. Braun上一篇文章：那些年Google公开的大数据领域论文

原文链接： Stream Processing has no Query Layer （编译/仲浩 王旭东/审校）

欢迎 @CSDN云计算 微博参与讨论，了解更多云信息。