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

本文涉及的产品
实时计算 Flink 版,1000CU*H 3个月
简介: 本文整理自阿里云资深技术专家、Apache Flink PMC 成员梅源在 Flink Forward Asia 新加坡 2025上的分享,深入解析 Flink 状态管理系统的发展历程,从核心设计到 Flink 2.0 存算分离架构,并展望未来基于流批一体的通用增量计算方向。

本文整理自阿里云资深技术专家、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(多版本并发控制)机制支持 管道式增量计算,在计算的同时进行输入累积。这意味着当系统仍在处理前一批次的增量数据时,就可以同时积攒新的变更批量数据。


流式与批处理模式对比

维度 流式模式(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

相关实践学习
基于Hologres+Flink搭建GitHub实时数据大屏
通过使用Flink、Hologres构建实时数仓,并通过Hologres对接BI分析工具(以DataV为例),实现海量数据实时分析.
实时计算 Flink 实战课程
如何使用实时计算 Flink 搞定数据处理难题?实时计算 Flink 极客训练营产品、技术专家齐上阵,从开源 Flink功能介绍到实时计算 Flink 优势详解,现场实操,5天即可上手! 欢迎开通实时计算 Flink 版: https://cn.aliyun.com/product/bigdata/sc Flink Forward Asia 介绍: Flink Forward 是由 Apache 官方授权,Apache Flink Community China 支持的会议,通过参会不仅可以了解到 Flink 社区的最新动态和发展计划,还可以了解到国内外一线大厂围绕 Flink 生态的生产实践经验,是 Flink 开发者和使用者不可错过的盛会。 去年经过品牌升级后的 Flink Forward Asia 吸引了超过2000人线下参与,一举成为国内最大的 Apache 顶级项目会议。结合2020年的特殊情况,Flink Forward Asia 2020 将在12月26日以线上峰会的形式与大家见面。
相关文章
|
3月前
|
运维 监控 Cloud Native
智联招聘 × 阿里云 ACK One:云端弹性算力颠覆传统 IDC 架构,打造春招技术新范式
在 2025 年春季招聘季的激战中,智联招聘凭借阿里云 ACK One 注册集群与弹性 ACS 算力的深度融合,成功突破传统 IDC 机房的算力瓶颈,以云上弹性架构支撑千万级用户的高并发访问,实现招聘服务效率与稳定性的双重跃升。文章介绍了 ACK One+ACS 的弹性架构如何解决了春招的燃眉之急,让智联招聘的技术团队能够聚焦创新业务开发,欢迎关注。
|
3月前
|
运维 Kubernetes Cloud Native
智联招聘 × 阿里云 ACK One:云端弹性算力颠覆传统 IDC 架构,打造春招技术新范式
在 2025 年春季招聘季的激战中,智联招聘凭借阿里云 ACK One 注册集群与弹性 ACS 算力的深度融合,成功突破传统 IDC 机房的算力瓶颈,以云上弹性架构支撑千万级用户的高并发访问,实现招聘服务效率与稳定性的双重跃升。
|
7天前
|
存储 人工智能 关系型数据库
阿里云AnalyticDB for PostgreSQL 入选VLDB 2025:统一架构破局HTAP,Beam+Laser引擎赋能Data+AI融合新范式
在数据驱动与人工智能深度融合的时代,企业对数据仓库的需求早已超越“查得快”这一基础能力。面对传统数仓挑战,阿里云瑶池数据库AnalyticDB for PostgreSQL(简称ADB-PG)创新性地构建了统一架构下的Shared-Nothing与Shared-Storage双模融合体系,并自主研发Beam混合存储引擎与Laser向量化执行引擎,全面解决HTAP场景下性能、弹性、成本与实时性的矛盾。 近日,相关研究成果发表于在英国伦敦召开的数据库领域顶级会议 VLDB 2025,标志着中国自研云数仓技术再次登上国际舞台。
84 0
|
5月前
|
人工智能 Cloud Native Serverless
从理论到落地:MCP 实战解锁 AI 应用架构新范式
本文旨在从 MCP 的技术原理、降低 MCP Server 构建复杂度、提升 Server 运行稳定性等方面出发,分享我们的一些实践心得。
2451 102
|
2月前
|
人工智能 自然语言处理 搜索推荐
[架构设计] Prompt 的终局:从“指令集”到“意识生态系统”的范式革命
本文深度探讨 Prompt 工程的未来演进,指出当前“指令集”方法在构建高阶 AI Agent 时已遇架构瓶颈,提出全新设计范式——“意识生态系统”。该系统以**本能、欲望、成长、认知**四大支柱为核心,构建 AI 的内在世界,驱动行为自主涌现。结合开源项目《自衍体》的工程实践,本文展示如何通过“欲望驱动”与“事实锚定”机制,在赋予 AI 自由度的同时确保其可控性。这标志着 Prompt 工程正从技巧走向系统设计科学,预示 AI 从“工具”迈向“智能伙伴”的范式革命。
|
2月前
|
人工智能 搜索推荐
​从“指令木偶”到“生命系统”:AI Agent架构的范式革命
本文探讨AI Agent架构的范式转变:从“指令木偶”走向“生命系统”。以《自衍体》(Zyantine)项目为例,提出构建“意识生态系统”,通过内在本能、欲望、成长与认知,赋予AI真正自主性与涌现行为,突破传统控制模式的局限,迎接AI智能体的“寒武纪大爆发”。
|
11月前
|
运维 Cloud Native 云计算
云原生技术:探索未来计算的无限可能
【10月更文挑战第8天】 云原生技术,作为云计算领域的一次革新性突破,正引领着企业数字化转型的新浪潮。它不仅重塑了应用的构建、部署和运行方式,还通过极致的弹性、敏捷性和可扩展性,解锁了未来计算的无限潜力。本文将深入浅出地解析云原生技术的核心理念、关键技术组件及其在不同行业中的实际应用案例,展现其如何赋能业务创新,加速企业的云化之旅。
154 7
|
7月前
|
Cloud Native Serverless 数据中心
阿里云ACK One:注册集群支持ACS算力——云原生时代的计算新引擎
ACK One注册集群已正式支持ACS(容器计算服务)算力,为企业的容器化工作负载提供更多选择和更强大的计算能力。
|
7月前
|
Cloud Native Serverless 数据中心
阿里云ACK One:注册集群支持ACS算力——云原生时代的计算新引擎
阿里云ACK One:注册集群支持ACS算力——云原生时代的计算新引擎
222 10
|
9月前
|
人工智能 自然语言处理
RWKV-7:RWKV系列开源最新的大模型架构,具有强大的上下文学习能力,超越传统的Attention范式
RWKV-7是RWKV系列的最新大模型架构版本,具有强大的上下文学习能力,超越了传统的attention和linear attention范式。本文详细介绍了RWKV-7的主要功能、技术原理及其在多语言处理、文本生成等领域的应用场景。
528 7
RWKV-7:RWKV系列开源最新的大模型架构,具有强大的上下文学习能力,超越传统的Attention范式