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