Page 266 - 《软件学报》2025年第7期

秦政 等: 面向 Apache Flink 流式分析应用的高吞吐优化技术 3187

使用的分布式流式处理系统, 包括 Storm [21] 、Spark Streaming [22] 、Flink. 这些流式处理系统都利用分布式集群上的
计算节点并行计算, 使用有向无环图描述计算过程, 具有相似的计算模式和流程, 其典型特征如表 1 典型流式系统
所示. 其中, Flink 是一个流批一体、高效、分布式的处理引擎, 支持连续数据的流式处理. Flink 支持状态管理和
灵活的窗口机制, 支持“恰好一次”交付保证, 通过异步快照机制支持错误容忍 [23] .

表 1 典型流式系统

核心特征 Storm Spark Streaming Flink
处理模式 连续流 微批 连续流/微批
交付保证 至少一次 恰好一次 恰好一次
状态管理 无 有 有
吞吐率 低 高 高
延迟 毫秒级 秒级 毫秒级

目前, Flink 已经连续两年蝉联 Apache 社区最活跃项目, 并被绝大多数的互联网企业作为流计算的事实标准
来采用, 包括美团、字节跳动等. 因此, 本文将 Flink 作为主要的研究对象, 并将相关的优化设计基于 Flink 完成原
型系统实现与实验. 需要注意的是, 由于第 3 代流式处理系统具有相似的数据处理模式和流程, 因此本文设计的优
化策略具有一定的通用性.

2.2 流式处理系统性能优化
面对流式处理应用吞吐率低和处理延迟高的问题, 已有的研究从垂直可扩展性、控制平面、系统算子实现、
多查询信息共享、水平可扩展性这 5 个方面对系统吞吐率和处理延迟进行优化. 与已有工作不同, 本文从数据流
的角度出发, 不关注于局部特征优化, 从整体计算流程的角度尝试分析现有系统瓶颈并提出优化策略, 优化系统整
体吞吐能力, 同时降低处理延迟.

2.2.1 面向垂直可扩展性的研究
Zeuch 等人 [24] 对流计算框架在单机上的性能表现和性能瓶颈展开研究, 发现 Flink 等现代流式处理系统并不
能充分发挥硬件的性能, Flink 仅能发挥硬件理论性能的 1.5%, 而使用更接近底层硬件的 C++实现相同的计算任
务, 可以更充分利用机器性能, 使用无锁队列等设计对实现进行优化, 可以更进一步逼近理论极限, 达到理论性能
的 91.4%, 相当于 Flink 的单机性能的 61.4 倍. 但该研究聚焦于单机上的性能瓶颈和垂直可扩展性, 没有关注于分
布式情况下的性能瓶颈和水平可扩展性, 而实际应用中分布式的部署和运行模式已成为当前流计算系统的主流.
SABER [25] 是一个混合架构的流式处理系统, 支持在 GPU 上执行流计算任务, 允许在 CPU 和 GPU 上混合调
度执行流计算任务. 实验表明拥有大量流处理器的 GPU 的吞吐率往往高于 CPU, 而同时调度使用 CPU 和 GPU,
在多种任务下能比单独使用 CPU 或 GPU 具有更高的吞吐率. 但 SABER 关注于基于窗口的流式 SQL 处理, 不能
覆盖其他的流计算任务, 也不适用于无 GPU 的计算集群.

2.2.2 面向流式处理系统控制平台的研究
Chi [26] 提供一个控制平台, 对 Flink 流计算系统进行持续的监控, 允许在线动态重配置系统参数, 例如算子并行
度. Chi 引入一种新的响应式编程模型和设计机制, 采用异步执行控制策略, 避免全局同步. 相关实验表明, 在动态
扩缩容和错误恢复时, Chi 相对于 Flink 具有更高的吞吐率, 且能更快地恢复低处理延迟. 但 Chi 没有考虑数据通
路上的问题, 例如数据传输所导致的网络瓶颈. 同时, Chi 需要用户学习其编程模型并对目标场景进行实现和适配,
使用门槛较高.
Varga 等人 [27] 和 Arkian 等人 [28] 关注于 Flink 集群计算资源的自动扩缩容, 相对稀缺的计算资源和不平稳的工
作负载使得不可能为每个应用程序分配一组静态资源. 自动扩缩容可以保证流式处理应用保持足够的吞吐率来处
理高峰时的工作负载, 同时不会使用超过严格限制的资源, 也可以在工作负载较低时释放不必要的计算资源. 自动
扩缩容关注于集群视角下资源的调度, 而非有限计算资源下的性能优化, 而且自动扩缩容的过程伴随流式计算任
务的重启, 会导致扩缩容过程中的系统不可用.