Flink,Storm,SparkStreaming性能对比

Yahoo 的 Storm 团队曾发表了一篇博客文章 ，并在其中展现了 Storm、Flink 和 Spark Streaming 的性能测试结果。该测试对于业界而言极 具价值，由于它是流处理领域的第一个基于真实应用程序的基准测试。

该应用程序从 Kafka 消费广告曝光消息，从 Redis 查找每一个广告对应的广 告宣传活动，并按照广告宣传活动分组，以 10 秒为窗口计算广告浏览量。 10 秒窗口的最终结果被存储在 Redis 中，这些窗口的状态也按照每秒记录 一次的频率被写入 Redis，以方便用户对它们进行实时查询。

在最初的性能 测评中，由于 Storm 是无状态流处理器（即它不能定义和维护状态），因此 Flink 做业也按照无状态模式编写。全部状态都被存储在 Redis 中。

在性能测评中，Spark Streaming 遇到了吞吐量和延迟性难 两全的问题。随着批处理做业规模的增长，延迟升高。若是为了下降延迟而缩减规模，吞吐量就会减小。Storm 和 Flink 则能够在吞吐量增长时维持低延迟。

为了进一步测试 Flink 的性能，测试人员设置了一系列不一样的场景，并逐步测试。

最初的性能测评专一于在相对较低的吞吐量下，测量端到端的延迟，即 使在极限状态下，也不关注容错性。此外，应用程序中的 key 基数很是小 （100），这使得测试结果没法反映用户量大的状况，或者 key 空间随着时间增加的状况.

因为最初的测试结果显示 Spark Streaming 的性能欠佳，所以此次的测试对 象只有 Storm 和 Flink，它们在最初的测试中有着相似的表现。

第 1 个变化是利用 Flink 提供的状态容错特性从新实现应用程序，如图 5-15 所示。这使得应用程序能保证 exactly-once。

第 2 个变化是经过用每秒能够生成数百万事件的数据生成器来增长输入流 的数据量。

结果以下：

使用高吞吐数据生成器的结果：（A）当Storm 与 Kafka 一块儿使用时，应用程序能够保持每秒 40 万事件的处理速度，而且瓶颈在于 CPU；当 Flink 与 Kafka 一块儿使用时，应用程序能够保持每秒300 万事件的处理速度，而且瓶颈在于网络；（B）当消除网络瓶颈时，Flink 应用程序能够保持每秒1500 万事件的处理速度；（C）在额外的测试中，消息队列由MapR Streams 提供，而且采用10 个高性能网络节点（硬件与前两种状况中的不一样）；Flink 应用程序能够保持每秒1000 万事件的处理速度.Storm 可以承受每秒 40 万事件，但受限于 CPU；Flink 则能够达到每秒 300 万事件（7.5 倍），但受限于 Kafka 集群和 Flink 集群之间的网络。

为了看看在没有网络瓶颈问题时 Flink 的性能如何，咱们将数据生成器移到 Flink 应用程序的内部。在这样的条件下，Flink 能够保持每秒 1500 万事件的处理速度（这是 Storm 的 37.5 倍）

将数据生成器整合到 Flink 应用程序中，能够测试性能极限，但这种 作法并不现实，由于现实世界中的数据必须从应用程序的外部流入。

值得注意的是，这绝对不是 Kafka 的极限（Kafka 能够支撑比这更大的吞吐量），而仅仅是测试所用的硬件环境的极限——Kafka 集群和 Flink 集群 之间的网络链接太慢。

最后一个变化是增长 key 基数（广告宣传活动的数量）。在最初的测试中， key 基数只有 100。这些 key 每秒都会被写入 Redis，以供查询。当 key 基数 增长到 100 万时，系统的总体吞吐量减小到每秒 28 万事件，由于向 Redis写入成了系统瓶颈。使用 Flink 可查询状态的一个早期原型能够消除这种瓶颈，使系统的处理速度恢复到每秒 1500 万事件，并 且有 100 万个 key 可供查询.

经过将查询功能移入Flink 可查询状态的一个原型，系统甚至能够在key 基数很是大的状况下仍然维持每秒 1500 万事件的处理速度.

本例说明了什么呢？经过避免流处理瓶颈，同时利用 Flink 的有状态流处理 能力，可使吞吐量达到Storm 的 30 倍左右，同时还能保证exactly-once 和高可用性。大体来讲，这意味着与 Storm 相比，Flink 的硬件成本或云计算成本仅为前者的 1/30，一样的硬件能处理的数据量则是前者的 30 倍。

更多Flink相关文章：

穿梭时空的实时计算框架——Flink对时间的处理

Flink快速入门--安装与示例运行

大数据实时处理的王者-Flink

更多实时计算，Flink,Kafka的技术文章欢迎关注实时流式计算