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 倍。
