本文整理自阿里云资深技术专家、Apache Flink PMC 成员梅源在 Flink Forward Asia 新加坡 2025—— 实时分析专场中的主题分享。
引言
Apache Flink 已成为实时处理领域的事实标准,在分布式大规模流式环境中展现出卓越的性能表现。但究竟是什么支撑了 Flink 在流计算领域中的先进性?答案在于其状态管理系统——这是让流式应用能够“记住过去事件”并影响未来处理过程的“记忆机制”。
在本文中,我们将深入探索 Flink 状态管理的演进历程:从最初的核心设计,到 Flink 2.0 革命性的云原生存算分离架构,再到未来展望基于流批一体存储的下一代增量计算。
理解 Flink 中的“状态”
流式处理中的“状态”是什么?
“状态”代表了无限流式计算的记忆,它是使应用程序能够精确的记住过去事件,并利用这些历史上下文来影响未来处理决策的基础机制。如果没有状态管理,流式系统将只能执行简单的 ETL 操作,无法完成现代实时应用所需的复杂关联与分析。早期的流计算系统只能借助外部数据库来进行关联操作,不仅效率低下而且有复杂的系统维护以及数据一致性问题,以至于流计算一直作为大数据领域的二等公民直到 Flink 的一致性状态管理出现。
状态在流式应用中以多种形式存在。它可以表示窗口聚合中的累计值,例如总和、计数、平均值;也可以存储用于流与历史数据关联的 Join 参数;在复杂事件处理(CEP)中用于维护交易历史以进行欺诈检测;还能保存机器学习模型参数,支持实时推理。
变革性突破:有状态计算的引入
Flink 引入强大的状态管理机制,标志着流式处理能力的一次根本性跃迁,并于 2017 年在 VLDB 数据库顶会发表这一关键成果,成为 Flink 乃至一致性状态管理的奠基之作。在此之前,开发者不得不依赖外部数据库来实现历史数据的关联,这带来了部署复杂、维护成本高以及数据一致性难以保障等问题。
Flink 的自维护状态管理机制彻底改变了这一局面——系统可以在内部自主记忆信息,无需依赖外部存储,同时确保数据的正确性与一致性。
现实复杂性:阿里巴巴物流场景的实践案例
我们来看一个复杂的实际案例:阿里巴巴菜鸟的实时物流追踪系统。
该系统处理来自多个电商平台(天猫、淘宝、速卖通)的订单包裹,通过一个复杂的处理流程:
- 合并与去重:通过聚合操作将不同来源的订单合并并去重;
- 双流驱动 Join:将物流更新信息与订单数据关联以及订单更新信息和物流信息关联,生成最新的物流状态;
- 复杂事件处理(CEP):基于 CEP 检测物流异常;
- 实时分析:按订单来源聚合来计算准时送达率等指标。
Flink 状态管理的核心能力
Flink 的状态管理系统提供了四项关键能力
Exactly-Once 语义
Flink 通过全局检查点机制,确保在整个分布式拓扑中创建一致的状态快照。当发生故障时,系统执行原子恢复,保证数据一致性。通过在所有节点间协调状态快照,Flink 实现了端到端的数据完整性保障。
事件时间与乱序处理
现实中的数据流很少按完美顺序到达,但 Flink 仍能提供准确的基于时间的计算结果。系统通过水位线(Watermark)协调机制,在容忍延迟数据的同时,确保分布式算子间的时间一致性,维持处理的正确性。
可扩展性与弹性
Flink 的状态架构通过互不重叠的键组(key groups)对状态进行分区并分布到计算节点上,支持独立的扩缩容决策。这种设计使得应用可以在动态调整规模,无缝适应不断变化的工作负载。
性能与可靠性
系统提供低延迟的状态访问能力,满足实时性要求,同时通过分布式快照机制保障强容错能力。这种组合确保了在不同负载条件下的一致性能表现,使 Flink 能够胜任严苛的生产环境需求。
演进之路:从嵌入式到解耦式架构
第一代:嵌入式本地状态(Flink 1.x)
最初的架构将状态以 JVM Heap 对象的形式存储在 TaskManager 的内存中。对于小规模数据集,这种方式效果良好,但随着状态大小的增长超出内存,将所有状态保存在内存中变得成本高昂且不稳定。
为了解决状态规模增长的问题,引入了一种利用本地磁盘的嵌入式状态后端。在这种方法中,状态内置于计算节点中(Task Manager),使用本地盘实现快速访问,同时通过定期的分布式文件系统(DFS)快照来保证一致性。
第二代:云原生存算分离状态(Flink 2.0)
核心架构创新
Apache Flink 2.0 引入 ForSt 存算分离状态后端代表 Flink 状态管理方式的根本转变:
- 无限且独立的状态容量:通过将分布式文件系统作为 active state 的主存储,系统实现了不受本地磁盘限制的无限状态容量。
- 高效轻量的 Checkpoint:以 DFS 为基础,ForSt 实现 active state 的工作目录与 checkpoint 目录之间共享物理文件,避免了在 Checkpointing 期间上传或拷贝大量文件,从而显著降低开销。
- 即时容错恢复和扩缩容:通过直接 DFS 访问,消除了状态下载延迟,实现即时作业恢复
- 平滑资源使用:远程 Compaction 服务将文件整理操作从核心数据处理链路中剥离,使得资源使用平滑稳定。
这种架构实现了真正意义上的独立可扩展性:处理能力可独立于状态大小进行调整,存储也可在不改变计算资源的情况下扩展,带来了显著的资源优化与高效利用。
Flink 2.0 架构深度解析
Flink 2.0 架构升级涵盖两个关键部分:
Runtime 层:异步执行模型
Runtime 层引入了异步执行模型,将状态访问与数据处理解耦,防止状态访问阻塞主线程。异步执行模型的引入主要为了解决因 active state 直接存储在远程 DFS 所带来的延迟变长执行性能下降的问题。Flink 2.0 引入的异步执行模型可以完全兼容 Flink 1.x 的语义和核心保障,并为现有应用提供平滑迁移路径。
上图中我们可以看到,远程 DFS(分布式文件系统)访问的速度大约比本地盘读取慢100倍。异步执行模型通过重新定义输入数据生命周期来解决这一问题,它将处理过程分为三个不同的阶段:
- 无状态数据处理:这是 CPU 密集型工作,在任务主线程中执行。
- 状态访问操作:这是 I/O 密集型工作,由独立的线程池处理。
- 状态访问后回调数据处理:这部分将 CPU 密集型工作返回给任务主线程。
Flink 2.0 引入异步执行控制器(AEC)负责协调上述复杂的流程,同时仍然保证流处理的可靠性:
- 保持按 Key 输入的 FIFO 顺序:为流处理的正确性奠定基础。
- 保持 exactly-once 处理语义:保持数据的一致性。
- 保持 event time 语义:确保时间处理的准确性。
ForSt 解耦状态后端特性
ForSt 后端将 active state 直接存储在分布式文件系统(DFS)上,并引入 UFS 统一文件系统视图,物理共享 active state 和 checkpoint 文件,以实现在制作检查点和容错恢复以及扩缩容的情况下的零拷贝。通过消除昂贵的数据传输和复制操作,轻量级检查点成为可能。
ForSt 还支持直接在(DFS)上访问活跃状态,因此通过取消传统的本地下载,实现即时恢复。Remote Compaction 将繁重的数据文件整理操作从关键数据处理路径中移除,从而避免干扰正常数据处理,平滑资源使用。分层缓存的实现进一步提升存算分离整体数据处理性能。尽管架构复杂,使用却极为简单:只需一个配置参数 state.backend.type: forst
即可启用。
性能结果与验证
真实场景性能:菜鸟物流案例研究
本段落描述了 Flink 2.0 在 Kubernetes 容器化部署环境中的显著优势,主要体现在成本效率和操作性能两方面。整体测试基于阿里云服务定价模型,其中 1 CU(计算单元)等于 1 个核心、4GB 内存和 20GB ESSD PL1 磁盘。成本效益方面,在阿里巴巴生产级物流系统作业上(总状态量 290GB),Flink 2.0 展现出 50% 的总成本节省。
操作方面,
- 恢复、伸缩和扩容:现在这些操作均可在 10 秒内完成,与 Flink 1.x 相比,速度提升了 40 倍。
- 制作检查点(Checkpointing):Flink 2.0 展示了轻量级的检查点流程,无论状态大小如何,检查点都能始终在 3-4 秒内完成。
- 资源利用:如图 4 所示,Flink 2.0 还显示出统一且平滑的资源利用率。
基准测试性能:Nexmark 查询
上面介绍了 Flink 2.0 在架构上的优势,在 Checkpointing 和扩缩容方面能力都有显著提升,Flink 2.0 的性能表现如何呢?
核心性能表现:根据标准的 Nexmark 流式基准测试结果,Flink 2.0 在 DFS 上直接存储 active state,其性能与在本地 SSD 上运行的 Flink 1.x 相当。这意味着 Flink 2.0 的分布式架构没有引入显著的性能开销。
不同场景:
- 对于无状态算子,Flink 2.0 直接绕过了异步框架,因此不会产生任何开销。
- I/O 密集度较低的查询,异步框架引入的额外开销占比不大
- I/O 密集的场景下,配置 1GB 本地盘 + Async 执行 的Flink 2.0 可超越 Flink 1.x
因此,用户在将应用迁移到 Flink 2.0 后,在获得云原生特性加持(轻量 CP,快速扩缩容)的同时,不会看到明显的性能差异。从 Flink 1.x 到 2.0 的升级路径也保持无缝,ForSt 后端也支持同步执行,可以作为Flink 1.x 中的 RocksDB 一个直接的替代方案。
未来方向:通用增量计算
在大规模状态挑战被解决后,我们下一步目标是通用增量计算,让实时计算编程“Everyone Affordable”。
通用增量计算
近年来,增量计算这个概念被反复提及,但增量计算并非新生事物,它在十年前就已经出现。增量计算的优势显而易见:近实时、成本降低以及批流一体。这些都是巨大的优点。然而,真正的难点在于如何让增量计算变得通用。仅针对特定简单场景解决问题并不能提供一个系统性的解决方案。本次演讲,我们将退一步,重新审视什么是增量计算,以及一个系统性的解决方案应该是什么样的。
计算范式对比
批处理 / 全量计算:
流式计算:
让我们首先将增量计算与全量计算或批处理计算进行比较,以此来理解什么是增量计算。
全量计算(Full Compute):全量计算处理的是完整的输入数据集。这些数据一次性全部处理,生成一个完整的输出,然后覆盖**原有的结果表。
增量计算(Incremental Compute):增量计算只处理增量的输入数据集,例如,过去 5 分钟的数据。这个增量数据集会关联历史数据并一起执行,从而生成一个需要合并到现有结果表中的增量输出**。
可以看出,增量计算与批处理计算在输入、执行和输出上都大相径庭。
流式计算(Stream Compute):流式计算处理的也是增量输入,但通常是一次处理一条记录。它基于历史数据进行计算,并将增量输出合并到结果表中。
流式计算其实就是增量为 1 的增量计算。这一洞见揭示了流式计算是实现通用增量处理的天然基础。
实现架构
区别于传统批处理,增量计算需要三项核心能力:
- 捕获数据变更:识别并收集自上次处理以来的增量输入;
- 带状态处理:将新信息与历史状态关联,确保处理准确性;
- 输出变更日志:生成符合合并语义的 changelog(+I 表示插入,-U 表示更新删除,+U 表示更新插入,-D 表示删除)。
这些能力在流式处理模型中早已存在——我们的创新之处在于通过流水线处理来处理批量输入。
ForSt 增量状态
扩展解耦架构可实现三项先进能力,推动增量计算的边界:
计算下推 (Compute Pushdown):计算下推将计算逻辑直接融入 Remote Compaction 中,避免了不必要的中间计算和输出,从而提高了效率。
异步批量执行 (Async Bulk Execution):异步批量执行提供了灵活的 状态间组合,使得系统能够支持更丰富的查询类型,而不仅仅是简单的聚合,例如 COUNT DISTINCT
(去重后计数)。
多版本并发控制 (MVCC):MVCC(多版本并发控制)机制支持 管道式增量计算,在计算的同时进行输入累积。这意味着当系统仍在处理前一批次的增量数据时,就可以同时积攒新的变更批量数据。
流式与批处理模式对比
维度 | 流式模式(STREAM Mode) | 批处理模式(BATCH Mode) |
---|---|---|
执行方式 | 流水线式持续执行 | 周期性调度执行 |
数据时效性 | 时效性可调且有保障 | 无严格时效保证 |
算子复杂度 | 支持复杂算子,灵活性高 | 算子相对简单,逻辑固定 |
查询支持能力 | 支持全场景查询,覆盖完整 | 无法完整覆盖所有算子 |
资源成本 | 整体成本低,资源利用率高 | 整体成本低,但资源无法保证 |
核心总结与未来影响
Flink 状态的能力
Flink 的状态管理充当了应用的“记忆”,提供持久化的上下文,让流式应用能够维护复杂的历史关系。使流式应用能够维持复杂的时序关系。这项能力使得有状态系统能够进行复杂的关联处理,这是简单 ETL 系统无法实现的。同时,它也向应用开发者屏蔽了底层数据一致性和正确性的复杂性。
解决大规模状态挑战
ForSt 解耦架构从根本上解决了大规模状态管理的难题:通过分离计算与状态的扩展维度,检查点可稳定在秒级完成,与状态大小无关;恢复与重缩容操作实现即时执行。这些改进直接转化为显著的成本和稳定性优化。
下一个前沿
通用增量计算代表了下一阶段的重大演进,实现流式与批处理范式的统一,融合两者优势:既有流式的实时能力,又有批处理的成本效率。计算下推将处理与存储紧密结合,最大化效率;而成本普惠化的目标,是让各类规模的企业都能负担得起实时处理。
Flink 2.0 存算分离
Apache Flink 从嵌入式状态管理向解耦式架构的演进,标志着流式处理系统向云原生时代的根本性转变。Flink 2.0 创新性地提出并实现了“解耦式状态管理”(Disaggregated State Management)架构,从根本上解决了传统存算一体模式下快照开销大、状态恢复慢、资源耦合与成本高昂等长期痛点。
这一重大突破源于论文《Disaggregated State Management in Apache Flink® 2.0》(VLDB 2025 收录),由阿里云实时计算 Flink 团队、Apache Flink 社区及学术界研究人员共同推动。新架构通过将状态存储与计算资源分离,利用高性价比的对象存储实现状态的持久化与共享,显著提升了系统的可扩展性、容错效率和资源利用率。
论文信息
- 标题:《Disaggregated State Management in Apache Flink® 2.0》
- 作者:Yuan Mei, Zhaoqian Lan, Lei Huang, Yanfei Lei, Han Yin, Rui Xia, Kaitian Hu, Paris Carbone, Vasiliki Kalavri, Feng Wang
- 原文地址:https://www.vldb.org/pvldb/vol18/p4846-mei.pdf
了解更多请前往 热烈祝贺 Flink 2.0 存算分离入选 VLDB 2025
未来,通用增量计算将进一步弥合流式与批处理之间的鸿沟,提供两全其美的解决方案:兼具流式的实时性与批处理的经济性。这一演进使 Apache Flink 不再仅仅是一个流式引擎,而是成为满足所有实时数据处理需求的综合性平台。
流式处理的未来,在于让强大的实时分析能力触达每一家企业,无论其规模或预算如何。随着这些架构创新的落地,这一未来正在迅速变为现实。
更多内容
活动推荐
阿里云基于 Apache Flink 构建的企业级产品-实时计算 Flink 版现开启活动:
新用户复制点击下方链接或者扫描二维码即可0元免费试用 Flink + Paimon
实时计算 Flink 版(3000CU*小时,3 个月内)
了解活动详情:https://free.aliyun.com/?utm_content=g_1000395379&productCode=sc