Disaggregated State Management in Apache Flink® 2.0 论文解读

老周聊架构

发布于 2025-11-19 15:16:14

一、前言

阿里巴巴将Apache Flink应用于所有核心业务场景，充分展现了其在处理海量、大规模实时数据流方面的多功能性。从支撑个性化推荐、大促期间实时仪表盘等动态电商功能，到通过欺诈检测和信用评分实现金融风控，Flink的毫秒级数据处理能力至关重要。该平台还通过实时路线优化和仓储管理提升物流效率，借助动态广告投放和效果追踪增强营销能力，并依靠实时日志与异常检测保障系统稳定性。通过大规模实践及对开源社区的持续贡献，阿里巴巴确立了Flink作为领先流处理引擎的地位[43]。在2024年双11购物节期间，阿里巴巴的Flink基础设施承载了超过440亿TPS的实时数据流。

过去十年间，Flink的部署模式和负载特征发生了显著变革，这既受硬件进步推动，也受益于云计算发展。我们经历了从Map-Reduce时代（计算与存储耦合的分布式集群）到云原生环境的转变——如今基于Kubernetes的容器化部署已成常态。与此同时，网络带宽提升和低成本对象存储的普及，催生了新的解耦架构可能。这些趋势暴露出Flink当前架构的局限性，主要体现在计算与状态的紧耦合设计上：虽然嵌入式状态管理为超内存状态应用提供了高吞吐解决方案，但检查点状态迁移的要求阻碍了低停机自动扩缩容和动态重构机制的设计；面对当前应用中多TB级状态规模时，其效率也面临挑战。

图1展示了阿里巴巴物流业务中数百个作业的状态规模累计分布与CPU利用率对应关系。我们采用20GB/CPU核心的状态规模阈值（相当于阿里云单计算单元CU）来区分CPU密集型与磁盘密集型作业。数据显示35%的作业属于磁盘密集型，其资源扩展仅需解决存储限制问题。

本文提出的Flink 2.0采用解耦状态架构，专为现代云基础设施和新兴应用需求设计。其核心创新包括：

远程分布式文件系统（DFS）主存储：将状态存储迁移至DFS，本地磁盘作为可选缓存层，持续流式更新状态至DFS，实现快速检查点、恢复与重构
状态共享机制：通过DFS共享活动状态与检查点状态，避免昂贵的状态迁移过程

该设计面临三大技术挑战：

远程DFS访问的延迟增加与性能优化
同步执行模型与远程后端结合导致的吞吐量下降
故障容忍与弹性伸缩机制的重构

Flink 2.0通过两项核心技术突破解决问题：

异步记录执行框架：支持非阻塞状态访问，利用乱序执行提升性能
解耦状态存储ForSt：提供LSM树抽象层，无缝统一本地/远程状态访问

本文主要贡献包括：

揭示Flink 1.x嵌入式状态管理架构对超大状态和云原生支持的局限性；
详述异步执行模型如何通过带宽优化和延迟隐藏维持处理顺序正确性；
介绍ForSt存储引擎及统一文件系统层实现的轻量级检查点机制；
通过生产负载和Nexmark基准测试验证架构改进效果。

二、基础概念

Apache Flink采用分布式数据流执行模型，将流计算表示为有向无环图（DAG）任务。Flink作业包含持续处理记录并更新本地状态的有状态算子（如窗口聚合和连接操作），这些算子并行运行在集群节点上。核心特性：

按键顺序处理
精确一次处理
低水位事件时间排序

2.1 分布式数据流架构

2.1.1 系统概述

如图2所示，Flink 1.x部署包含两个核心组件：

Job Manager (JM)：作为系统入口节点，负责应用编译、任务调度、检查点协调及生命周期管理。通过Zookeeper或etcd-Kubernetes实现高可用（HA），元数据包含对分布式文件系统（如HDFS/S3/OSS）中持久化检查点的引用。
Task Managers (TMs)：执行有状态数据流程序，每个TM通过专用流任务执行分布式计算。

2.1.2 同步任务执行

流任务为单线程实体，遵循同步FIFO执行模式：拉取输入元素→执行逻辑→原子化更新状态与输出。

2.1.3 嵌入式状态管理

状态预分配在虚拟分区（key-groups）中，通过keyBy算子确保相同键的记录由同一任务处理
状态后端模块（如RocksDB或堆内存）管理本地状态读写
检查点状态通过DFS外部存储恢复

2.2 核心系统保证机制

2.2.1 按键FIFO顺序

尽管Flink不保证不同输入流之间的全局有序性，但会确保相同键值的记录严格遵循FIFO顺序处理。这源于其FIFO通道与流任务严格顺序执行的组合机制。此外，状态分区机制保证相同键值的记录始终由同一流任务处理，从而实现独占访问和单写入者语义。

2.2.2 精确一次处理

Flink采用异步两阶段提交（2PC）机制来提交两个连续检查点标记之间的所有状态变更。在第一阶段，检查点协调器（JM）将检查点标记插入所有输入流中，网络层会将这些标记对齐至任务输入端的单个对齐检查点标记。当任务消费该标记后，Task Manager的后端模块会异步启动检查点，包括将持久化物理副本写入外部DFS并向协调器发送确认。待收集所有确认后，协调器进入协议提交阶段，通知所有流任务检查点完成。这使得事务型接收器等特殊任务能够将预写日志中的待处理变更提交至输出文件或消费者。

2.2.3 低水位事件时间顺序

水位标记（Watermark）是用于在子流记录乱序到达时建立进度一致性的机制。流任务通过该机制推进其事件时间时钟并触发定时操作，随后将相同水位标记输出至下游算子。此外，Flink 1.x的同步任务执行保证完整性——即每个任务在接收水位标记前，所有定时计算均保证完成。

三、解耦式状态管理架构‌

本节通过真实案例揭示Flink嵌入式状态设计的局限性，并阐述计算与存储解耦的必要性。随后概述Flink 2.0的解耦式状态管理架构，并讨论其正确性与性能挑战。

‌3.1 现实场景驱动案例

图3展示了阿里巴巴流处理生态中实时物流管理的典型用例。该用例由Flink作业实现，通过跟踪订单包裹在供应链中的全生命周期状态，包含两个有状态转换阶段：

去重算子阶段处理来自多电商平台（如天猫、淘宝、全球速卖通）的原始订单事件。当订单生成时，创建物流订单事件，包含订单ID、地址、商品等初始数据，此时配送时间与状态字段为空。该阶段通过聚合算子保留最新订单记录作为状态。
流式连接算子阶段将订单更新事件与物流更新事件进行匹配，生成实时更新的完整订单记录。每当包裹经过转运节点（如配送、揽收、清关）时，即生成包含进度信息的物流更新事件。该连接算子维护两种内部状态：
- (i) 聚合后的订单更新（左流）
- (ii) 实时物流更新（右流）

‌状态规模挑战‌：

常规配送周期为一周内完成更新，但海关、天气等异常情况可能导致更长的更新周期
去重与连接算子需维护60天的历史数据，形成TB级作业状态
状态规模与订单/事件基数成正比，大促期间（如双11）订单量激增时，状态规模可达数百GB至TB级

‌3.2 嵌入式状态管理的局限性‌

基于近十年的大规模Flink部署经验，我们识别出嵌入式状态管理架构的若干关键缺陷。这些挑战在物流用例等大状态作业及容器化部署场景中尤为显著，具体表现为以下三方面：

3.2.1 本地存储容量带来的状态规模限制

Flink 1.x通过嵌入式RocksDB实例实现超内存状态管理，但对于物流用例等需要TB级存储的场景，本地磁盘迅速成为性能瓶颈。在容器化部署中，动态调整磁盘容量尤为困难——云服务商（如阿里云实时计算服务、AWS Kinesis）提供的计算单元通常采用静态资源配置（如1核CPU+20GB/50GB固定磁盘）。这种刚性存储架构无法满足波动性资源需求，亟需通过远程弹性存储扩展存储层级。

3.2.2 状态后端操作引发的资源争用

嵌入式RocksDB在管理大状态时，后台操作（如Compaction和Checkpointing）会周期性抢占主任务资源。实验表明，即便在Flink 1.20中异步执行这些操作，仍会导致CPU/磁盘/网络I/O使用率尖峰，进而影响查询性能。为缓解该问题，必须预先预留超额资源，但这又造成资源利用率下降。

3.2.3 检查点与重构的耗时瓶颈

物流用例的容错机制要求Flink定期将状态持久化存储。Flink 1.x的检查点包含两个串行阶段：

(i) 同步阶段‌：锁定本地状态表并拷贝至临时存储
‌(ii) 异步阶段‌：将本地副本传输至分布式文件系统

当状态规模增长时（如物流用例中1.89GB增量检查点耗时1分钟，290GB全量重构超5分钟），这些操作的资源消耗与耗时呈线性增长，严重制约了Flink对负载变化的快速响应能力，并影响端到端的精确一次处理保障。

3.3 Flink 2.0架构概述

为克服前文所述缺陷，Flink 2.0采用解耦式状态架构（图4中新增组件以红色标注），其核心设计原则是在运行时执行层与状态管理层双重解耦计算密集型状态操作。新架构依托分布式文件系统（DFS）作为主存储，实现三大优势：

快速重构能力‌：支持超单节点存储容量的TB级状态扩展
性能隔离保障‌：最小化查询性能干扰
平滑兼容性‌：在保留Flink 1.x核心处理语义（§2.2）的前提下，通过异步执行控制器（AEC）与解耦状态后端ForSt实现无缝迁移

3.3.1 ‌运行时层：异步执行模型

AEC通过以下机制实现计算与状态访问的解耦：

‌双轨调度机制‌：将记录处理（用户定义转换）与DFS状态访问分离，规避远程存储延迟
‌完全兼容性‌：支持按需禁用异步执行或状态访问，直接沿用Flink 1.x执行模型

3.3.2 ‌状态管理层：ForSt存储引擎‌

ForSt作为新型解耦状态后端，通过统一文件系统（UFS）抽象实现：

‌存储解耦‌：活跃工作状态直接存储于DFS的Working Directory，消除本地磁盘限制
‌逻辑文件视图‌：为Flink引擎提供标准化文件操作接口，支持跨分布式文件系统的行为统一
‌高效检查点‌：通过UFS建立活跃状态文件与检查点文件的物理共享链路，实现秒级检查点完成

3.3.3 ‌创新特性‌

‌轻量化元数据‌：检查点仅需更新元数据链接，保留原有生命周期管理
‌远程压缩实验‌：减少后台操作对主任务的干扰（当前为实验性特性）
‌快速恢复‌：通过UFS直接复用远程状态文件，避免大状态加载耗时

四、异步执行模型

从本地状态迁移至远程存储必然带来读取延迟的挑战（如表1所示，HDFS/OSS等远程存储的访问延迟比本地磁盘高两个数量级）。Flink 2.0通过任务级并行化与乱序处理机制，将CPU密集型计算与远程I/O操作重叠执行，从而分摊延迟惩罚并提升吞吐量。

‌4.1 异步执行架构

新模型将记录处理生命周期重构为三阶段流水线：

无状态转换‌：主线程执行用户定义逻辑
‌状态访问‌：由独立线程池异步处理，支持多状态操作链式调用
回调处理‌：优先于新记录处理，确保状态操作完成

‌4.2 编程模型升级

以物流用例中的流式连接算子为例，开发者需通过API标记异步操作：

updateState()触发状态更新
then()定义回调链，确保依赖操作的顺序性
独立状态表（如OrderTable与ShippingTable）支持并发访问

‌4.3 核心保障机制‌

‌异步执行控制器（AEC）‌ 通过键级调度维护FIFO顺序，避免乱序处理影响业务逻辑。
‌异步排水机制‌ 在检查点期间隔离排水流量，确保精确一次语义。
‌纪元管理器‌ 强制实施事件时间低水位线顺序，保障窗口计算正确性。

该设计在兼容Flink 1.x编程模型的同时，通过线程级资源隔离，使远程存储带宽利用率提升至92%。

五、ForSt：解耦式状态后端

Flink 2.0通过ForSt（For Streaming）重构状态管理层，该解耦式状态后端专为流数据设计，通过存储与计算分离的架构突破本地化状态的三大瓶颈：

容量限制‌：直接操作DFS中的活跃状态，结合本地缓存消除单节点存储约束
‌资源争用‌：通过远程压缩避免检查点触发的CPU尖峰
‌恢复延迟‌：基于文件共享机制实现秒级重构与恢复

‌5.1 统一文件系统（UFS）

ForSt采用LSM-tree管理状态文件，通过UFS层将数据直接流式传输至DFS。该设计通过逻辑文件抽象层（图7）屏蔽不同分布式存储系统的行为差异：

跨平台兼容‌：统一HDFS（即时可见性）与S3（最终一致性）的API
‌高效共享‌：通过维护逻辑文件与物理位置的映射关系，实现硬链接等效功能，避免数据复制开销
‌检查点优化‌：利用文件共享机制建立活跃状态与检查点文件的物理关联，使元数据更新成为唯一必需操作

UFS作为多DFS后端的统一入口，其引用计数机制确保跨存储系统的对象可见性一致性，为轻量级检查点和快速恢复提供底层支持。

‌5.2 快速检查点与重构

Flink 1.x的检查点机制需将本地状态文件复制上传至DFS，该过程在大状态场景下资源消耗显著且耗时长。ForSt通过解耦设计优化检查点流程：

硬链接共享机制‌：利用UFS的硬链接功能，将工作状态目录与检查点目录共置，使检查点操作从数据复制转变为轻量级引用创建（图8①）。
‌生命周期管理‌：JobManager（JM）通过硬链接引用管理检查点文件生命周期，删除操作仅触发引用计数减少（图8③⑥），物理删除仅在引用归零时执行。
‌秒级恢复‌：新实例可直接通过硬链接恢复状态，避免290GB状态场景下3分钟以上的传统恢复耗时。

小结：

该架构通过‌硬链接轻量化快照‌、‌引用计数自动回收‌和‌统一逻辑视图‌三大机制，实现了高效、低开销的 checkpoint 管理，适用于需要频繁创建和删除快照的分布式系统或数据处理场景（如大数据计算框架、数据库备份等）。‌最终答案‌该架构图展示了基于统一文件系统的快速检查点（Checkpoint）管理机制，核心通过硬链接、引用计数和统一逻辑视图实现高效快照与资源回收，适用于需频繁快照的分布式系统场景。

‌5.3 远程压缩

Flink 1.x的本地压缩导致CPU与I/O资源争用，而ForSt通过以下实现解耦：

‌服务化压缩‌：将LSM-Tree的压缩过程卸载为独立服务，由无状态压缩器节点处理DFS上的状态文件。
‌弹性调度‌：采用轮询策略分配压缩任务，与计算节点资源解耦，支持跨作业错峰执行以稳定CPU利用率。
元数据驱动‌：压缩请求仅需传输元数据，完成后更新LSM元数据，避免干扰主任务处理。

‌5.4 本地缓存管理

在解耦式架构中，缓存机制对于加速读取操作至关重要。ForSt采用多级缓存层次结构，结合计算节点上的内存和本地磁盘资源，包含广泛采用的基于块的LRU（最近最少使用）内存缓存以及基于文件的二级本地磁盘缓存。该二级缓存从远程存储复制SSTable文件，并采用历史访问策略进行管理。

历史访问策略基于文件的历史使用统计数据来管理缓存文件。在驱逐环节，采用LRU机制跟踪所有当前缓存文件，当缓存达到容量且需要加载新文件时，驱逐最久未访问的文件；在加载环节，监控前一分钟内文件的访问频率，对于远程存储中访问频率超过预设阈值的文件，会定期重新加载回缓存。基于LRU的驱逐策略虽然简单，但在生产部署中已被证明有效，而基于频率的加载策略则能有效缓解缓存颠簸问题。

该历史策略是Flink 2.0及阿里云Flink服务的默认缓存策略，其设计采用可插拔架构，便于替换其他缓存策略。