Apache 的流处理技术概述

阅读数:5086 2016 年 5 月 20 日 19:00

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

(点击放大图像)

Apache的流处理技术概述

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

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 )关注我们。

收藏

评论

微博

用户头像
发表评论

注册/登录 InfoQ 发表评论