Apache 的流处理技术概述

对于流数据的处理存在很多技术：简单的事件处理器，流处理器和复杂的事件处理器。即使在开源社区中，也存在很多扑朔迷离的选择，其中很多的差异并没有被很好的记载，也不容易发现。这就是为什么我决定写这篇 Apache 流技术概述的文章的原因，包括 Flume ， NiFi ， Apex ， Kafka 流， Spark 流， Storm ， Flink ， Samza ， Ignite 和 Beam 。

(点击放大图像)

我原来写过很多篇幅很大的博客，并很受欢迎，但今天我打算破例一次。事不宜迟，马上开始这篇概述吧（点击查看全屏图片）：

Flume 和 NiFi 确切地属于数据收集（DC）和单事件处理器（SEP），而其它的是多事件流处理器（ESP）引擎或复杂的事件处理器（CEP）。显然，Spark 本身和 Ignite 确切来说不仅仅是流处理器，但我还是在这里把它们列出来，因为它们提供流媒体功能。Apex 也是同样的情况，这是一个统一批次和流数据的平台，它应该是介于一个数据收集引擎、一个基本 ETL 工具与一个事件流处理器之间。

在撰写本文时，Kafka 流还没有正式发布。它有望在 2016 年 4 月发布，即将发布的是 0.10 版本。带有“back-pressure”的一行中标注“N/A”表示没有“back-pressure”，因为队列由 Kafka 管理，本身仅仅受限于可用的磁盘空间。毕竟，Kafka 允许消息闲置重播。

Kafka 流的预览当前可获得。Kafka 流是一个Kafka 的Java 库，是最初由LinkedIn 开发的消息传递系统。Kafka 目前在LinkedIn、Netflix 和Spotify 中被广泛应用。

自动扩展有时也被称为弹性扩展，动态扩展，动态的（资源）分配和动态工作重平衡。注意，自动扩展并不等同于一个负载平衡器。一个负载平衡器是“简单地”对工作量进行分配，但是当工作负荷相对cluster 来说变得太大，或者可用资源超过需求的时候，负载平衡器不会扩张或收缩。

in-flight 修改表示在流动当中修改数据的能力，即没有任何停机或应用程序重新提交的情况。有时也被称为零停机扩容，和即席或动态应用程序修改。对于 in-flight 修改， Spooker 是一个值得多看一眼的项目。

为了平衡起见，我不得不提，在 CEP 市场上当然还有许多其他选择，例如： Software AG 的 Apama ，微软的StreamInsight ， Oracle 事件处理， SAP ESP ， Tibco 的 BusinessEvents ＆ Streambase 。它们列出时并没有按具体的顺序！另外还有 Esper ，其中有一个可获取的开源版本，是 GNU GPL 许可的。

表中的信息已经从官方项目页面中被编辑，通过挖掘源代码，主要有下列来源：

• 流媒体技术的蛋糕解决方案的两部分组成比较。
• 流媒体技术的 MapR概述。
• 谷歌的数据流和 Spark 流比较，这是我在 Read 上做的总结。
• Taylor Goetz 的 Storm vs Spark 流幻灯片。
• 有关 Flink vs Storm 的 StackOverflow 的讨论。
• Databricks 有关 Spark 流中的改进容错的帖子。
• Artisans 关于 Flink 设计的文章。
• MapR 关于 Flink 的文章。
• MapR 关于 Apex 的文章。
• Hortonworks 关于站点到站点数据流中 NiFi 容错的信息，以及后续作品。
• Kafka 流的汇合文档。
• Guozhang Wang 关于 Kafka 流的报告。

这个表并不完整，也不太可能是完全准确的，有些可能也有些过时。如果你确实发现了万有引力的错误，请让我知道，我会尽力以正视听。

如果您对 Hadoop 的文件格式和 SerDes 的类似概述有兴趣，请查看我以前关于这些主题的帖子。

阅读英文原文： AN OVERVIEW OF APACHE STREAMING TECHNOLOGIES

感谢杜小芳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。