Apache Flink 2.0 新特性解读与迁移指南

Apache Flink 2.0 于 2025 年 3 月正式发布，包含 6 个核心 breaking changes，其中 DataSet API 的彻底移除和 Source/Sink V2 的统一是最具冲击力的变更。本文以实操视角梳理每个 breaking change 的影响范围、迁移步骤和兼容性检查方法，帮助团队制定可落地的升级计划。

Breaking Change 一：DataSet API 彻底移除

Flink 2.0 移除了整个 org.apache.flink.api.java 包下的 DataSet API。这是从 Flink 1.15 开始就标记为 deprecated 的 API，2.0 版本正式删除。

影响范围：所有使用 ExecutionEnvironment.execute()、DataSet.map()、DataSet.reduce() 等接口的 Java/Scala 代码。Python 代码不受影响，因为 PySpark 和 PyFlink 本身就只暴露了 Table API 和 DataStream API。

迁移路径：将 DataSet 代码转换为 DataStream API 或 Table API。对于简单的 ETL 作业（读取 → 转换 → 写入），推荐迁移到 Table API，代码量更少且性能更好。对于需要精细控制并行度或使用自定义 Partitioner 的场景，迁移到 DataStream API。

具体的迁移步骤：将 ExecutionEnvironment 替换为 StreamExecutionEnvironment；将 DataSet<T> 替换为 DataStream<T>；将批处理的 map、flatMap 等算子替换为 DataStream 的对应算子；将 DataSet.writeAsText() 替换为 DataStream.sinkTo() 或 DataStream.addSink()。如果代码中使用了 GroupReduce、Combine 等批处理特有的算子，需要找到 DataStream API 的等价实现。

一个常见的误区是认为 DataSet API 移除后所有批处理作业都无法运行。实际上 Flink 2.0 的 Table API 和 SQL 对批处理有完整支持，大量批处理作业可以直接用 SQL 重写而不需要逐行翻译。

Breaking Change 二：Source/Sink 接口统一为 V2

Flink 2.0 将 Source 和 Sink 接口统一为 V2 版本，V1 接口（org.apache.flink.streaming.api.functions.source.SourceFunction 和 org.apache.flink.streaming.api.functions.sink.SinkFunction）被移除。

影响范围：所有自定义 Source 和 Sink 实现。如果你的团队维护了自定义的数据源 Connector（如对接内部消息队列或私有存储系统），需要按照新接口重写。已有的社区 Connector（如 Kafka、MySQL CDC、Elasticsearch）的新版本已经适配了 V2 接口。

迁移步骤：首先确认你使用的 Connector 是否已有 V2 版本。Kafka Connector 从 Flink 1.17 开始提供 V2 版本（KafkaSource 和 KafkaSink），MySQL CDC Connector 从 2.4 版本开始支持。如果 Connector 已经有 V2 版本，将代码中的 FlinkKafkaConsumer 替换为 KafkaSource、FlinkKafkaProducer 替换为 KafkaSink 即可。

对于自定义 Connector，V2 接口的核心变化是引入了 SplitEnumerator 和 SourceReader 的分离架构，允许更灵活的分片分配策略。迁移时需要将原来的 run() 方法拆分为 SplitEnumerator 的 run() 和 SourceReader 的 pollNext() 两个部分。

Breaking Change 三：Java 版本要求提升至 17

Flink 2.0 要求 Java 17 作为最低运行版本。Java 11 和 Java 8 不再被支持。

影响评估：如果你的集群当前运行 Java 11，需要先升级 JDK。Java 17 是 LTS 版本，升级到 Java 17 是合理的长期选择。需要注意的是，Java 17 的 ZGC 和 Shenandoah GC 相比 Java 11 有显著性能提升，这对 Flink 作业的延迟表现有正面影响。

迁移步骤：在所有 Flink 节点上安装 Java 17；更新 JAVA_HOME 环境变量；重新编译所有自定义 UDF 和 Connector（确保编译目标为 Java 17）；在测试环境验证所有作业在 Java 17 下的运行表现。特别注意检查使用了反射或字节码操作的自定义代码，Java 17 的模块系统对反射访问有更严格的限制。

Breaking Change 四：Configuration 系统重构

Flink 2.0 重新设计了配置系统，移除了大量已废弃的配置项，统一了配置项的命名规范。部分配置项的键名发生了变化（如 state.backend 改为 execution.state-backend.type）。

迁移方法：Flink 2.0 提供了配置迁移工具（flink-migrate-config），可以自动检测并转换旧版配置。运行该工具后，它会输出所有需要修改的配置项和推荐的新值。建议在升级前先运行此工具，提前修复所有配置问题。

特别注意 state.backend 的变更。如果你使用 RocksDB 作为状态后端，原来的 state.backend: rocksdb 需要改为 execution.state-backend.type: rocksdb。同时 state.checkpoints.dir 和 state.savepoints.dir 的配置路径也可能有调整。

Breaking Change 五：Checkpoint 和 Savepoint 格式变更

Flink 2.0 使用了新的 checkpoint 和 savepoint 序列化格式。旧版（Flink 1.x）的 savepoint 不能直接在 2.0 版本上恢复。

影响范围：所有依赖 savepoint 做作业升级或故障恢复的场景。如果你计划从 Flink 1.x 直接升级到 2.0，需要先在 1.x 版本上触发一次完整的 savepoint，然后在 2.0 版本上从该 savepoint 恢复。

迁移步骤：在 Flink 1.x 集群上对所有正在运行的作业触发 savepoint；升级到 Flink 2.0；在 2.0 集群上从 1.x 的 savepoint 恢复作业。如果 savepoint 格式不兼容（跨大版本通常不兼容），需要接受状态丢失的风险，从外部存储系统（如 Kafka）重新消费数据。

Breaking Change 六：SQL 和 Table API 行为调整

Flink 2.0 对 SQL 语法和 Table API 行为做了一系列调整，包括：移除了 GROUP BY 中对非聚合列的隐式去重；调整了时间窗口函数的语义（TUMBLE、HOP、SESSION 的参数顺序变更）；MATCH_RECOGNIZE 语法更严格地遵循 SQL 标准。

排查方法：在测试环境中运行所有 Flink SQL 作业，收集所有语法错误和语义异常。重点关注窗口聚合作业和 CEP（复杂事件处理）作业，这两类作业受语法调整的影响最大。

Connector 适配计划

升级前需要为每个使用的 Connector 制定适配计划。核心步骤：列出所有使用的 Connector 及其当前版本；查阅每个 Connector 的 release notes，确认哪些版本支持 Flink 2.0；如果当前版本不支持，评估升级 Connector 版本的兼容性；在测试环境验证 Connector 的新版本是否正常工作。

以常见 Connector 为例：Kafka Connector 需要升级到 3.2+（支持 Flink 2.0 的 V2 接口）；MySQL CDC Connector 需要升级到 3.1+（原生支持 Flink 2.0）；Elasticsearch Connector 需要升级到 4.0+（适配新的 Sink V2 接口）；Hive Connector 需要确认与 Flink 2.0 的兼容性矩阵。

迁移 Checklist

升级前完成以下检查项：确认所有节点的 Java 版本为 17+；运行 flink-migrate-config 工具修复配置项；确认所有自定义 UDF 和 Connector 已适配 2.0 API；确认所有 Connector 版本已升级到支持 Flink 2.0 的版本；在 1.x 环境上对所有作业触发 savepoint；在测试环境部署 Flink 2.0 并恢复作业验证；确认 SQL 作业在新版本上的语法和语义兼容性；保留 Flink 1.x 集群的快速回滚能力。

建议的升级顺序是：先升级非核心的开发测试作业，运行稳定后再升级分析查询类作业，最后升级核心实时 ETL 作业。每个阶段至少观察 3 个工作日再进入下一阶段。