对比Flink与Storm效能分散式实时计算框架该这样选最新消息

一、背景

Apache Flink 和 Apache Storm 是当前业界广泛使用的两个分散式实时计算框架。其中 Apache Storm（以下简称“Storm”）在美团点评实时计算业务中已有较为成熟的运用，有管理平台、常用 API 和相应的文件，大量实时作业基于 Storm 构建。

Apache Storm参考连结：http://storm.apache.org/

而 Apache Flink（以下简称“Flink”）在近期倍受关注，具有高吞吐、低延迟、高可靠和精确计算等特性，对事件视窗有很好的支援，目前在美团点评实时计算业务中也已有一定应用。

Apache Flink参考连结：https://flink.apache.org/

为深入熟悉了解 Flink 框架，验证其稳定性和可靠性，评估其实时处理效能，识别该体系中的缺点，找到其效能瓶颈并进行优化，给使用者提供最适合的实时计算引擎，我们以实践经验丰富的 Storm 框架作为对照，进行了一系列实验测试 Flink 框架的效能。

计算 Flink 作为确保“至少一次”和“恰好一次”语义的实时计算框架时对资源的消耗，为实时计算平台资源规划、框架选择、效能调优等决策及 Flink 平台的建设提出建议并提供资料支援，为后续的 SLA 建设提供一定参考。

Flink 与 Storm 两个框架对比：

二、测试目标

评估不同场景、不同资料压力下 Flink 和 Storm 两个实时计算框架目前的效能表现，获取其详细效能资料并找到处理效能的极限；了解不同配置对 Flink 效能影响的程度，分析各种配置的适用场景，从而得出调优建议。

1、测试场景

1）“输入-输出”简单处理场景通过对“输入-输出”这样简单处理逻辑场景的测试，尽可能减少其它因素的干扰，反映两个框架本身的效能。

同时测算框架处理能力的极限，处理更加复杂的逻辑的效能不会比纯粹“输入-输出”更高。

2）使用者作业耗时较长的场景如果使用者的处理逻辑较为复杂，或是访问了数据库等外部元件，其执行时间会增大，作业的效能会受到影响。因此，我们测试了使用者作业耗时较长的场景下两个框架的排程效能。

3）视窗统计场景实时计算中常有对时间视窗或计数视窗进行统计的需求，例如一天中每五分钟的访问量，每 100 个订单中有多少个使用了优惠等。Flink 在视窗支援上的功能比 Storm 更加强大，API 更加完善，但是我们同时也想了解在视窗统计这个常用场景下两个框架的效能。

4）精确计算场景（即讯息投递语义为“恰好一次”）Storm 仅能保证“至多一次” (At Most Once) 和“至少一次” (At Least Once) 的讯息投递语义，即可能存在重复传送的情况。

有很多业务场景对资料的精确性要求较高，希望讯息投递不重不漏。Flink 支援“恰好一次” (Exactly Once) 的语义，但是在限定的资源条件下，更加严格的精确度要求可能带来更高的代价，从而影响效能。

因此，我们测试了在不同讯息投递语义下两个框架的效能，希望为精确计算场景的资源规划提供资料参考。

2、效能指标

1）吞吐量（Throughput）

单位时间内由计算框架成功地传送资料的数量，本次测试吞吐量的单位为：条/秒。

反映了系统的负载能力，在相应的资源条件下，单位时间内系统能处理多少资料。

吞吐量常用于资源规划，同时也用于协助分析系统性能瓶颈，从而进行相应的资源调整以保证系统能达到使用者所要求的处理能力。假设商家每小时能做二十份午餐（吞吐量 20 份/小时），一个外卖小哥每小时只能送两份（吞吐量 2 份/小时），这个系统的瓶颈就在小哥配送这个环节，可以给该商家安排十个外卖小哥配送。

2）延迟（Latency）

资料从进入系统到流出系统所用的时间，本次测试延迟的单位为：毫秒。

反映了系统处理的实时性。

金融交易分析等大量实时计算业务对延迟有较高要求，延迟越低，资料实时性越强。

假设商家做一份午餐需要 5 分钟，小哥配送需要 25 分钟，这个流程中使用者感受到了 30 分钟的延迟。如果更换配送方案后延迟变成了 60 分钟，等送到了饭菜都凉了，这个新的方案就是无法接受的。

三、测试环境

为 Storm 和 Flink 分别搭建由 1 台主节点和 2 台从节点构成的 Standalone 丛集进行本次测试。其中为了观察 Flink 在实际生产环境中的效能，对于部分测内容也进行了 on Yarn 环境的测试。

1、丛集引数

2、框架引数

四、测试方法

1、测试流程

1）资料生产

Data Generator 按特定速率生成资料，带上自增的 id 和 eventTime 时间戳写入 Kafka 的一个 Topic（Topic Data）。

2）资料处理

Storm Task 和 Flink Task （每个测试用例不同）从 Kafka Topic Data 相同的 Offset 开始消费，并将结果及相应 inTime、outTime 时间戳分别写入两个 Topic（Topic Storm 和 Topic Flink）中。

3）指标统计

Metrics Collector 按 outTime 的时间视窗从这两个 Topic 中统计测试指标，每五分钟将相应的指标写入 MySQL 表中。

Metrics Collector 按 outTime 取五分钟的滚动时间视窗，计算五分钟的平均吞吐（输出资料的条数）、五分钟内的延迟（outTime - eventTime 或 outTime - inTime）的中位数及 99 线等指标，写入 MySQL 相应的资料表中。最后对 MySQL 表中的吞吐计算均值，延迟中位数及延迟 99 线选取中位数，绘制图像并分析。

2、预设引数

Storm 和 Flink 预设均为 At Least Once语义。

Storm 开启 ACK，ACKer 数量为 1。

Flink 的 Checkpoint 时间间隔为 30 秒，预设 StateBackend 为 Memory。

保证 Kafka 不是效能瓶颈，尽可能排除 Kafka 对测试结果的影响。

测试延迟时资料生产速率小于资料处理能力，假设资料被写入 Kafka 后立刻被读取，即 eventTime 等于资料进入系统的时间。

测试吞吐量时从 Kafka Topic 的最旧开始读取，假设该 Topic 中的测试资料量充足。

3、测试用例

1）IdentityIdentity 用例主要模拟“输入-输出”简单处理场景，反映两个框架本身的效能。

输入资料为“msgId, eventTime”，其中 eventTime 视为资料生成时间。单条输入资料约 20 B。

进入作业处理流程时记录 inTime，作业处理完成后（准备输出时）记录 outTime。

作业从 Kafka Topic Data 中读取资料后，在字串末尾追加时间戳，然后直接输出到 Kafka。

输出资料为“msgId, eventTime, inTime, outTime”。单条输出资料约 50 B。

Identity 流程图

2）SleepSleep 用例主要模拟使用者作业耗时较长的场景，反映复杂使用者逻辑对框架差异的削弱，比较两个框架的排程效能。

输入资料和输出资料均与 Identity 相同。

读入资料后，等待一定时长（1 ms）后在字串末尾追加时间戳后输出

Sleep 流程图

3）Windowed Word CountWindowed Word Count 用例主要模拟视窗统计场景，反映两个框架在进行视窗统计时效能的差异。

此外，还用其进行了精确计算场景的测试，反映 Flink 恰好一次投递的效能。

输入为 JSON 格式，包含 msgId、eventTime 和一个由若干单词组成的句子，单词之间由空格分隔。单条输入资料约 150 B。

读入资料后解析 JSON，然后将句子分割为相应单词，带 eventTime 和 inTime 时间戳发给 CountWindow 进行单词计数，同时记录一个视窗中最大最小的 eventTime 和 inTime，最后带 outTime 时间戳输出到 Kafka 相应的 Topic。

Spout/Source 及 OutputBolt/Output/Sink 并发度恒为 1，增大并发度时仅增大 JSONParser、CountWindow 的并发度。

由于 Storm 对 window 的支援较弱，CountWindow 使用一个 HashMap 手动实现，Flink 用了原生的 CountWindow 和相应的 Reduce 函式。

Windowed Word Count 流程图

五、测试结果

① Identity 单执行绪吞吐量

Identity 单执行绪吞吐量

上图中蓝色柱形为单执行绪 Storm 作业的吞吐，橙色柱形为单执行绪 Flink 作业的吞吐。

Identity 逻辑下，Storm 单执行绪吞吐为 8.7万条/秒，Flink 单执行绪吞吐可达35万条/秒。

当 Kafka Data 的 Partition 数为 1 时，Flink 的吞吐约为 Storm 的 3.2 倍；当其 Partition 数为 8 时，Flink 的吞吐约为 Storm 的 4.6 倍。

由此可以看出，Flink 吞吐约为 Storm 的 3-5 倍。

② Identity 单执行绪作业延迟

Identity 单执行绪作业延迟

采用 outTime - eventTime 作为延迟，图中蓝色折线为 Storm，橙色折线为 Flink。虚线为 99 线，实线为中位数。

从图中可以看出随着资料量逐渐增大，Identity 的延迟逐渐增大。其中 99 线的增大速度比中位数快，Storm 的增大速度比 Flink 快。

其中 QPS 在 80000 以上的测试资料超过了 Storm 单执行绪的吞吐能力，无法对 Storm 进行测试，只有 Flink 的曲线。

对比折线最右端的资料可以看出，Storm QPS 接近吞吐时延迟中位数约 100 毫秒，99 线约 700 毫秒，Flink 中位数约 50 毫秒，99 线约 300 毫秒。Flink 在满吞吐时的延迟约为 Storm 的一半。

③ Sleep吞吐量

Sleep 吞吐量

从图中可以看出，Sleep 1 毫秒时，Storm 和 Flink 单执行绪的吞吐均在 900 条/秒左右，且随着并发增大基本呈线性增大。

对比蓝色和橙色的柱形可以发现，此时两个框架的吞吐能力基本一致。

④ Sleep 单执行绪作业延迟（中位数）

Sleep 单执行绪作业延迟（中位数）

依然采用 outTime - eventTime 作为延迟，从图中可以看出，Sleep 1 毫秒时，Flink 的延迟仍低于 Storm。

⑤ Windowed Word Count 单执行绪吞吐量

Windowed Word Count 单执行绪吞吐量

单执行绪执行大小为 10 的计数视窗，吞吐量统计如图。

从图中可以看出，Storm 吞吐约为 1.2 万条/秒，Flink Standalone 约为 4.3 万条/秒。Flink 吞吐依然为 Storm 的 3 倍以上。

⑥ Windowed Word Count Flink At Least Once 与 Exactly Once 吞吐量对比

Windowed Word Count Flink At Least Once 与 Exactly Once 吞吐量对比

由于同一算子的多个并行任务处理速度可能不同，在上游算子中不同快照里的内容，经过中间并行算子的处理，到达下游算子时可能被计入同一个快照中。这样一来，这部分资料会被重复处理。因此，Flink 在 Exactly Once 语义下需要进行对齐，即当前最早的快照中所有资料处理完之前，属于下一个快照的资料不进行处理，而是在快取区等待。当前测试用例中，在 JSON Parser 和 CountWindow、CountWindow 和 Output 之间均需要进行对齐，有一定消耗。为体现出对齐场景，Source/Output/Sink 并发度的并发度仍为 1，提高了 JSONParser/CountWindow 的并发度。具体流程细节参见前文 Windowed Word Count 流程图。

上图中橙色柱形为 At Least Once 的吞吐量，黄色柱形为 Exactly Once 的吞吐量。对比两者可以看出，在当前并发条件下，Exactly Once 的吞吐较 At Least Once 而言下降了 6.3%。

⑦ Windowed Word Count Storm At Least Once 与 At Most Once 吞吐量对比

Windowed Word Count Storm At Least Once 与 At Most Once 吞吐量对比

Storm 将 ACKer 数量设定为零后，每条讯息在传送时就自动 ACK，不再等待 Bolt 的 ACK，也不再重发讯息，为 At Most Once 语义。

上图中蓝色柱形为 At Least Once 的吞吐量，浅蓝色柱形为 At Most Once 的吞吐量。对比两者可以看出，在当前并发条件下，At Most Once 语义下的吞吐较 At Least Once 而言提高了 16.8%。

⑧ Windowed Word Count 单执行绪作业延迟

Windowed Word Count 单执行绪作业延迟

Identity 和 Sleep 观测的都是 outTime - eventTime，因为作业处理时间较短或 Thread.sleep 精度不高，outTime - inTime 为零或没有比较意义；Windowed Word Count 中可以有效测得 outTime - inTime 的数值，将其与 outTime - eventTime 画在同一张图上，其中 outTime - eventTime 为虚线，outTime - InTime 为实线。

观察橙色的两条折线可以发现，Flink 用两种方式统计的延迟都维持在较低水平；观察两条蓝色的曲线可以发现，Storm 的 outTime - inTime 较低，outTime - eventTime 一直较高，即 inTime 和 eventTime 之间的差值一直较大，可能与 Storm 和 Flink 的资料读入方式有关。

蓝色折线表明 Storm 的延迟随资料量的增大而增大，而橙色折线表明 Flink 的延迟随着资料量的增大而减小（此处未测至 Flink 吞吐量，接近吞吐时 Flink 延迟依然会上升）。

即使仅关注 outTime - inTime（即图中实线部分），依然可以发现，当 QPS 逐渐增大的时候，Flink 在延迟上的优势开始体现出来。

⑨ Windowed Word Count Flink At Least Once 与 Exactly Once 延迟对比

Windowed Word Count Flink At Least Once 与 Exactly Once 延迟对比

图中黄色为 99 线，橙色为中位数，虚线为 At Least Once，实线为 Exactly Once。图中相应颜色的虚实曲线都基本重合，可以看出 Flink Exactly Once 的延迟中位数曲线与 At Least Once 基本贴合，在延迟上效能没有太大差异。

⑩ Windowed Word Count Storm At Least Once 与 At Most Once 延迟对比

Windowed Word Count Storm At Least Once 与 At Most Once 延迟对比

图中蓝色为 99 线，浅蓝色为中位数，虚线为 At Least Once，实线为 At Most Once。QPS 在 4000 及以前的时候，虚线实线基本重合；QPS 在 6000 时两者已有差异，虚线略高；QPS 接近 8000 时，已超过 At Least Once 语义下 Storm 的吞吐，因此只有实线上的点。

可以看出，QPS 较低时 Storm At Most Once 与 At Least Once 的延迟观察不到差异，随着 QPS 增大差异开始增大，At Most Once 的延迟较低。

⑪Windowed Word Count Flink 不同 StateBackends 吞吐量对比

Windowed Word Count Flink 不同 StateBackends 吞吐量对比

Flink 支援 Standalone 和 on Yarn 的丛集部署模式，同时支援 Memory、FileSystem、RocksDB 三种状态储存后端（StateBackends）。由于线上作业需要，测试了这三种 StateBackends 在两种丛集部署模式上的效能差异。其中，Standalone 时的储存路径为 JobManager 上的一个档案目录，on Yarn 时储存路径为 HDFS 上一个档案目录。

对比三组柱形可以发现，使用 FileSystem 和 Memory 的吞吐差异不大，使用 RocksDB 的吞吐仅其余两者的十分之一左右。

对比两种颜色可以发现，Standalone 和 on Yarn 的总体差异不大，使用 FileSystem 和 Memory 时 on Yarn 模式下吞吐稍高，使用 RocksDB 时 Standalone 模式下的吞吐稍高。

⑫Windowed Word Count Flink 不同 StateBackends 延迟对比

Windowed Word Count Flink 不同 StateBackends 延迟对比

使用 FileSystem 和 Memory 作为 Backends 时，延迟基本一致且较低。

使用 RocksDB 作为 Backends 时，延迟稍高，且由于吞吐较低，在达到吞吐瓶颈前的延迟陡增。其中 on Yarn 模式下吞吐更低，接近吞吐时的延迟更高。

六、结论及建议

1、框架本身效能

由①、⑤的测试结果可以看出，Storm 单执行绪吞吐约为 8.7 万条/秒，Flink 单执行绪吞吐可达 35 万条/秒。Flink 吞吐约为 Storm 的 3-5 倍。

由②、⑧的测试结果可以看出，Storm QPS 接近吞吐时延迟（含 Kafka 读写时间）中位数约 100 毫秒，99 线约 700 毫秒，Flink 中位数约 50 毫秒，99 线约 300 毫秒。Flink 在满吞吐时的延迟约为 Storm 的一半，且随着 QPS 逐渐增大，Flink 在延迟上的优势开始体现出来。

综上可得，Flink 框架本身效能优于 Storm。

2、复杂使用者逻辑对框架差异的削弱

对比①和③、②和④的测试结果可以发现，单个 Bolt Sleep 时长达到 1 毫秒时，Flink 的延迟仍低于 Storm，但吞吐优势已基本无法体现。

因此，使用者逻辑越复杂，本身耗时越长，针对该逻辑的测试体现出来的框架的差异越小。

3、不同讯息投递语义的差异

由⑥、⑦、⑨、⑩的测试结果可以看出，Flink Exactly Once 的吞吐较 At Least Once 而言下降 6.3%，延迟差异不大；Storm At Most Once 语义下的吞吐较 At Least Once 提升 16.8%，延迟稍有下降。

由于 Storm 会对每条讯息进行 ACK，Flink 是基于一批讯息做的检查点，不同的实现原理导致两者在 At Least Once 语义的花费差异较大，从而影响了效能。而 Flink 实现 Exactly Once 语义仅增加了对齐操作，因此在算子并发量不大、没有出现慢节点的情况下对 Flink 效能的影响不大。Storm At Most Once 语义下的效能仍然低于 Flink。

4、Flink 状态储存后端选择

Flink 提供了内存、档案系统、RocksDB 三种 StateBackends，结合⑪、⑫的测试结果，三者的对比如下：

5、推荐使用 Flink 的场景