Storm和Flink的延迟和吞吐

Storm延迟极低，但是吞吐量不高，Flink则拥有较低的延迟和较高的吞吐量，关于这个说法的准确性，是放在特定时间和特定条件下的，现在不一定准确。如今的Storm和Flink，在经历多次迭代的取长补短后，具备各自的特点，都已经成为非常优秀的流处理框架。

但是我们还是有必要考究一下以上说法存在的缘由。关于Storm和Flink在延迟和吞吐量方面的基准测试，有以下两篇文章：

• 2015年-Yahoo的流计算引擎对比测试
  结论：Storm延迟优于Flink，吞吐量略逊于Flink，禁用ack机制时吞吐量可优于Flink。
• 2017年-美团-流计算框架Flink与Storm的性能对比
  结论：Flink吞吐量约为Storm的3-5倍。低吞吐情况下延迟与Storm相当，高吞吐情况下延迟低于Storm。
• 5年后的2022年，两个框架（Storm v2.3.0和Flink v1.14.0）的功能和性能比较有待进一步研究。

延迟和吞吐量的定义

延迟是指一条数据从进入流处理系统，到输出结果所消耗的时间。
吞吐量是指流处理系统在单位时间处理的数据量。

延迟和吞吐量的关系

• 在单体系统中，延迟与吞吐量成反比，即低延迟=高吞吐。

• 在分布式系统中，延迟与吞吐量不一定强相关。比如系统中有A->B->C处理链路，A、B和C均为单体系统，A吞吐量为30/s，B吞吐量为10/s，C吞吐量为20/s，系统的性能瓶颈在B，因而呈现出来的整体吞吐量是10/s。假设优化A的处理逻辑，使得A的延迟降低（吞吐量变高为50/s），系统整体处理延迟也随之降低，但是由于性能瓶颈仍然在B，因此整体吞吐量没变。由此可知，分布式系统中，降低延迟，并不一定能够提高吞吐量。所以我们第一眼看到Storm的低延迟特性，从而咬定Storm是高吞吐，是不正确的。

影响延迟的因素

• 流处理框架的一些特性（如是否攒批、消息传输保障机制等）
• 每个流处理节点的处理逻辑
• 每个流处理节点所分配的计算资源
• 流处理系统的链路长度
• 外部因素，如网络传输，第三方系统访问等

影响吞吐量的因素

• 流处理框架的一些特性（如是否攒批、消息传输保障机制等）
• 吞吐量最低的流处理节点的处理逻辑
• 吞吐量最低的节点所分配的计算资源
• 外部因素，如第三方系统访问等

Storm和Flink的延迟和吞吐影响分析

（1）延迟影响分析

Storm是Native Streaming（原生流处理，每条数据单独处理，不攒批）实现，可以达到毫秒级别的延迟。Storm Trident是基于微批实现的，延迟较高。

Flink也是Native Streaming实现，也可以达到毫秒级别的延迟，但是略逊色与Storm。Flink主要是为了吞吐量、容错和Exactly-Once语义而采取的一些策略，从而牺牲了部分实时性：

• 数据在发送给下一个算子前进行攒批。
• Flink状态存取时的攒批策略。
• Flink容错机制（checkpoint级别的容错），开启checkpoint。checkpoint barrier插入后，算子识别到barrier后，需要触发状态保存，会带来部分延迟；如果要保障Exactly-Once语义的话，还需要对来自多个输入的barrier进行对齐，这部分工作也比较耗时。

（2）吞吐量影响分析

Storm的吞吐量主要受容错机制（实现At-Least-Once语义）的影响，对每条数据进行记录级别ack的容错（Storm的ack机制即， Spout发送的每一条消息，① 在规定的时间内，Spout收到Acker对于该消息的ack响应，即认为消息在整个流程中处理成功；② 在规定的时间内，没有收到Acker对于该消息的ack响应，就触发fail动作，即认为处理失败；③ 或者收到Acker发送对于该消息的fail响应，也认为失败，触发fail动作。顺带提一下，Storm只能提供At-Least-Once语义，而不能提供Exactly-Once语义，主要是因为Spout会对超时未收到ack的消息进行重发，而该条消息有可能还在处理链路中，因此造成了数据的重复处理。ack的基本原理详见：基本原理），容错开销对吞吐量影响巨大：

• Spout会缓存所有发送出去但是尚未ack的数据，受缓存容量限制。
• Acker Bolt要处理来自Spout和其他所有Bolt的ack消息，处理能力受限。

Flink的高吞吐主要是由于局部攒批策略：

• 数据在发送给下一个算子前进行攒批，减少报文传输
• Flink状态存取时的攒批策略。在设计和实现 Flink 的流计算算子时，我们一般会把“面向状态编程”作为第一准则。因为在流计算中，为了保证状态（State）的一致性，需要将状态数据存储在状态后端（StateBackend），由框架来做分布式快照。而目前主要使用的RocksDB状态后端都会在每次read和write操作时发生序列化和反序列化操作，甚至是磁盘的 I/O 操作。因此状态的相关操作通常都会成为整个任务的性能瓶颈，状态的数据结构设计以及对状态的每一次访问都需要特别注意。微批的核心思想就是缓存一小批数据，在访问状态状态时，多个同 key 的数据就只需要发生一次状态的操作。当批次内数据的 key 重复率较大时，能显著降低对状态的访问频次，从而大幅提高吞吐。（参见：Flink SQL 核心解密 —— 提升吞吐的利器 MicroBatch）