Flink 的性能

Flink 的性能测试基于 Yahoo! Streaming Benchmark 及其一系列变体进行。

5.5.1　Yahoo! Streaming Benchmark

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

图5-13：Yahoo! Streaming Benchmark 所采用的作业。被测试的流处理器有 Storm、

Flink 和 Spark Streaming（本图中只有 Flink 的 logo）

注1： https://yahooeng.tumblr.com/post/135321837876/benchmarking-streaming-computation-engines-at

66 ｜ 第 5 章

图5-14 展示了测试结果。

99百分位数延迟（秒）

每秒事件数（千）

图5-14：Yahoo! Streaming Benchmark 的结果。横轴表示每秒的事件吞吐量，以 千为单位。纵轴表示端到端的99 百分位数延迟（即 99% 的事件在延迟时间段内到 达），以秒为单位。详见博客文章Benchmarking Streaming Computation Engines at Yahoo! ²

如图5-14 所示，在性能测评中，Spark Streaming 遇到了吞吐量和延迟性难 两全的问题。随着批处理作业规模的增加，延迟升高。如果为了降低延迟 而缩减规模，吞吐量就会减少。Storm 和 Flink 则可以在吞吐量增加时维持 低延迟。

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

5.5.2　变化1：使用Flink状态

最初的性能测评专注于在相对较低的吞吐量下，测量端到端的延迟，即 使在极限状态下，也不关注容错性。此外，应用程序中的key 基数非常小

（100），这使得测试结果无法反映用户量大的情况，或者 key 空间随着时间

注2： https://yahooeng.tumblr.com/post/135321837876/benchmarking-streaming-computation-engines-at

有状态的计算 ｜ 67 增长的情况（如tweet）。2016 年 2 月，data Artisans 的博客发表了一篇文 章³，对Yahoo! Streaming Benchmark 进行了拓展，并专注于解决上述问题。

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

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

数据 生成

输入

解析/过滤/

转换 按照id

分组

窗口/聚合 查询

图5-15：重新实现的应用程序利用了 Flink 内置的状态机制，并且可以保持每秒 300 万事件的吞吐量，同时保证 exactly-once。此时，应用程序的瓶颈在于 Flink 集 群与Kafka 集群的连接（图中以粗箭头表示）

5.5.3　变化2：改进数据生成器并增加吞吐量

第2 个变化是通过用每秒可以生成数百万事件的数据生成器来增加输入流 的数据量。结果如图5-16 所示。

注3： https://data-artisans.com/blog/extending-the-yahoo-streaming-benchmark

68 ｜ 第 5 章

Storm与Kafka

Flink与Kafka

Flink与内部 数据生成器

每秒事件数

（百万）

Flink与MapR Streams

图5-16：使用高吞吐数据生成器的结果：（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 集群之间的网络。

5.5.4　变化3：消除网络瓶颈

为了看看在没有网络瓶颈问题时Flink 的性能如何，我们将数据生成器移到 Flink 应用程序的内部。图 5-17 展示了这个流程。在这样的条件下，Flink 可以保持每秒1500 万事件的处理速度（这是 Storm 的 37.5 倍），如图 5-16 所示。将数据生成器整合到Flink 应用程序中，可以测试性能极限，但这种 做法并不现实，因为现实世界中的数据必须从应用程序的外部流入。

有状态的计算 ｜ 69

数据

生成 解析/

过滤/

转换 按照id

分组

窗口/聚合 查询

图5-17：通过将数据生成器整合到 Flink 应用程序中，可以消除网络瓶颈，并且使 系统支撑每秒1500 万事件的吞吐量。在增加 key 基数之后，瓶颈又转移到每秒对 Redis 的写入上。该测试并不符合生产环境的配置，它的目的是测试 Flink 的极限 值得注意的是，这绝对不是Kafka 的极限（Kafka 可以支撑比这更大的吞 吐量），而仅仅是测试所用的硬件环境的极限——Kafka 集群和 Flink 集群 之间的网络连接太慢。

5.5.5　变化4：使用MapR Streams

另一种避免网络瓶颈并测试Flink 性能的方法是使用 MapR Streams。在另一 个测试中，同样的Flink 应用程序通过 MapR Streams 接收数据。

使用MapR Streams 之后，流处理被整合进整个平台，从而使得 Flink 可以 与数据生成任务和数据传输任务一起运行，这样就避免了连接Kafka 集群 和Flink 集群时遇到的大部分问题。在这种高性能配置和更快的网络硬件环 境下，Flink 能够支撑每秒 1000 万事件的处理速度。

5.5.6　变化5：增加key基数

最后一个变化是增加key 基数（广告宣传活动的数量）。在最初的测试中，

key 基数只有 100。这些 key 每秒都会被写入 Redis，以供查询。当 key 基数 增加到100 万时，系统的整体吞吐量减少到每秒 28 万事件，因为向 Redis

70 ｜ 第 5 章

写入成了系统瓶颈。使用Flink 可查询状态的一个早期原型（如图 5-18 所 示），可以消除这种瓶颈，使系统的处理速度恢复到每秒1500 万事件，并 且有100 万个 key 可供查询，如图 5-19 所示。

数据 生成

解析/

过滤/ 转换

按照id 分组

窗口/聚合

查询

图5-18：为 key 基数较大的场景消除系统瓶颈

100个key

100万个key

100万个key 可查询状态

每秒事件数

（百万）

图5-19：通过将查询功能移入 Flink 可查询状态的一个原型，系统甚至可以在 key 基数非常大的情况下仍然维持每秒1500 万事件的处理速度

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