从嵌入式状态管理到云原生架构：Apache Flink 的演进与下一代增量计算范式

本文整理自阿里云资深技术专家、Apache Flink PMC 成员梅源在 Flink Forward Asia 新加坡 2025—— 实时分析专场中的主题分享。

引言

Apache Flink 已成为实时处理领域的事实标准，在分布式大规模流式环境中展现出卓越的性能表现。但究竟是什么支撑了 Flink 在流计算领域中的先进性？答案在于其状态管理系统——这是让流式应用能够“记住过去事件”并影响未来处理过程的“记忆机制”。

在本文中，我们将深入探索 Flink 状态管理的演进历程：从最初的核心设计，到 Flink 2.0 革命性的云原生存算分离架构，再到未来展望基于流批一体存储的下一代增量计算。

理解 Flink 中的“状态”

流式处理中的“状态”是什么？

“状态”代表了无限流式计算的记忆，它是使应用程序能够精确的记住过去事件，并利用这些历史上下文来影响未来处理决策的基础机制。如果没有状态管理，流式系统将只能执行简单的 ETL 操作，无法完成现代实时应用所需的复杂关联与分析。早期的流计算系统只能借助外部数据库来进行关联操作，不仅效率低下而且有复杂的系统维护以及数据一致性问题，以至于流计算一直作为大数据领域的二等公民直到 Flink 的一致性状态管理出现。

状态在流式应用中以多种形式存在。它可以表示窗口聚合中的累计值，例如总和、计数、平均值；也可以存储用于流与历史数据关联的 Join 参数；在复杂事件处理（CEP）中用于维护交易历史以进行欺诈检测；还能保存机器学习模型参数，支持实时推理。

变革性突破：有状态计算的引入

Flink 引入强大的状态管理机制，标志着流式处理能力的一次根本性跃迁，并于 2017 年在 VLDB 数据库顶会发表这一关键成果，成为 Flink 乃至一致性状态管理的奠基之作。在此之前，开发者不得不依赖外部数据库来实现历史数据的关联，这带来了部署复杂、维护成本高以及数据一致性难以保障等问题。

Flink 的自维护状态管理机制彻底改变了这一局面——系统可以在内部自主记忆信息，无需依赖外部存储，同时确保数据的正确性与一致性。

现实复杂性：阿里巴巴物流场景的实践案例

我们来看一个复杂的实际案例：阿里巴巴菜鸟的实时物流追踪系统。

该系统处理来自多个电商平台（天猫、淘宝、速卖通）的订单包裹，通过一个复杂的处理流程：

1. 合并与去重：通过聚合操作将不同来源的订单合并并去重；
2. 双流驱动 Join：将物流更新信息与订单数据关联以及订单更新信息和物流信息关联，生成最新的物流状态；
3. 复杂事件处理（CEP）：基于 CEP 检测物流异常；
4. 实时分析：按订单来源聚合来计算准时送达率等指标。

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 状态管理方式的根本转变：

1. 无限且独立的状态容量：通过将分布式文件系统作为 active state 的主存储，系统实现了不受本地磁盘限制的无限状态容量。
2. 高效轻量的 Checkpoint：以 DFS 为基础，ForSt 实现 active state 的工作目录与 checkpoint 目录之间共享物理文件，避免了在 Checkpointing 期间上传或拷贝大量文件，从而显著降低开销。
3. 即时容错恢复和扩缩容：通过直接 DFS 访问，消除了状态下载延迟，实现即时作业恢复
4. 平滑资源使用：远程 Compaction 服务将文件整理操作从核心数据处理链路中剥离，使得资源使用平滑稳定。

这种架构实现了真正意义上的独立可扩展性：处理能力可独立于状态大小进行调整，存储也可在不改变计算资源的情况下扩展，带来了显著的资源优化与高效利用。

Flink 2.0 架构深度解析

Flink 2.0 架构升级涵盖两个关键部分：

Runtime 层：异步执行模型

Runtime 层引入了异步执行模型，将状态访问与数据处理解耦，防止状态访问阻塞主线程。异步执行模型的引入主要为了解决因 active state 直接存储在远程 DFS 所带来的延迟变长执行性能下降的问题。Flink 2.0 引入的异步执行模型可以完全兼容 Flink 1.x 的语义和核心保障，并为现有应用提供平滑迁移路径。

上图中我们可以看到，远程 DFS（分布式文件系统）访问的速度大约比本地盘读取慢100倍。异步执行模型通过重新定义输入数据生命周期来解决这一问题，它将处理过程分为三个不同的阶段：

1. 无状态数据处理：这是 CPU 密集型工作，在任务主线程中执行。
2. 状态访问操作：这是 I/O 密集型工作，由独立的线程池处理。
3. 状态访问后回调数据处理：这部分将 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 的增量计算。这一洞见揭示了流式计算是实现通用增量处理的天然基础。

实现架构

区别于传统批处理，增量计算需要三项核心能力：

1. 捕获数据变更：识别并收集自上次处理以来的增量输入；
2. 带状态处理：将新信息与历史状态关联，确保处理准确性；
3. 输出变更日志：生成符合合并语义的 changelog（+I 表示插入，-U 表示更新删除，+U 表示更新插入，-D 表示删除）。

这些能力在流式处理模型中早已存在——我们的创新之处在于通过流水线处理来处理批量输入。

ForSt 增量状态

扩展解耦架构可实现三项先进能力，推动增量计算的边界：

计算下推 (Compute Pushdown)：计算下推将计算逻辑直接融入 Remote Compaction 中，避免了不必要的中间计算和输出，从而提高了效率。

异步批量执行 (Async Bulk Execution)：异步批量执行提供了灵活的 状态间组合，使得系统能够支持更丰富的查询类型，而不仅仅是简单的聚合，例如 COUNT DISTINCT（去重后计数）。

多版本并发控制 (MVCC)：MVCC（多版本并发控制）机制支持 管道式增量计算，在计算的同时进行输入累积。这意味着当系统仍在处理前一批次的增量数据时，就可以同时积攒新的变更批量数据。

流式与批处理模式对比

核心总结与未来影响

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