2026 年 6 月 25 日发布 · 15 个 FLIP · 原生 S3 文件系统 · 物化表可原地演进 · 应用级生命周期管理
🔥 一、速览：这一版专治"SQL 用户被 DataStream API 卡脖子"
Apache Flink PMC 于 2026 年 6 月 25 日正式发布 Flink 2.3.0，实现 15 个 FLIP 的完整或核心功能。公告开宗明义给出四大主题：SQL 能力大幅扩展、物化表更灵活、实验性高性能原生 S3 文件系统、应用级生命周期管理。
🧩 二、十大核心新特性
1️⃣ FROM_CHANGELOG / TO_CHANGELOG：终于能在 SQL 里玩转 changelog
这是本版最具"解绑"意义的功能。TO_CHANGELOG 是 Flink 首个 SQL 级算子，能把 retract / upsert 流转回 append 格式——过去这件事只能下到 DataStream API 手写。FROM_CHANGELOG 则反向：把带 operation 列的纯追加流转成动态表，并支持自定义 CDC 格式、控制"未映射操作码"的行怎么处理。适用场景：数据归档、审计留痕、写入只接受 append 的 sink。官方说明 2.3 只覆盖基础用例，后续版本扩展。
2️⃣ 物化表可"原地演进"，省的都是真金白银
过去改一个物化表的查询定义，必须删表重建 + 重算全部历史数据。2.3 解决了两件事：
DDL 对齐：
CREATE MATERIALIZED TABLE支持显式列定义（含水印、主键），并支持ALTER TABLE与CREATE OR REPLACE；刷新控制：新子句可精确指定刷新管道从哪开始，还支持从上次作业停止的精确 source offset 恢复——加个可空列、做兼容的逻辑修改，不必再重跑历史数据。对按云账单付费的团队，这是直接省下来的成本。
3️⃣ SinkUpsertMaterializer：把"隐式黑洞"变成显式选择
当 upsert key 与主键不一致（多阶段转换、投影、join 场景常见）时才会用到它，而旧实现要保留主键完整更新历史，状态无界增长、性能差。2.3 改为：默认在规划期直接报错，强制你显式选择冲突策略——把隐患摊到编译期，而不是生产上炸。
4️⃣ 原生 S3 文件系统（实验性）：甩掉 Hadoop / Presto 的历史包袱
全新 flink-s3-fs-native 基于 AWS SDK v2 从零构建，功能完整，带来：支持 IRSA（Service Account 的 IAM 角色） 与现代凭证提供者、异步操作提升吞吐、依赖更干净、体积更小；另支持 SSE-KMS 加密、分块编码、校验和验证、熵注入。
5️⃣ 自适应分区 + 作业恢复期可 checkpoint
自适应分区：按下游任务负载动态分发数据，缓解背压与延迟（
taskmanager.network.adaptive-partitioner.enabled）；恢复期间可 checkpoint：以前必须等所有恢复的 channel state 消费完才能打新 checkpoint，in-flight 状态大时可能几小时无法完成检查点；现在恢复早期就能打点，跨重启与扩缩容保住已有工作，Exactly-once 语义不变。
6️⃣ 运维可观测性补强
AdaptiveScheduler 扩缩容历史：记录并行度变化、slot 分配、调度状态、终止原因，Web UI 新增 "Rescales" 标签页与百分位时长统计；
水位线对齐重设计：引入 alignment buffer（默认 3），解决"公告延迟反向限制积压处理速度"的老问题；
OTel exporter 健壮性：支持 gzip 压缩与分批导出，避免大指标载荷被 gRPC 后端拒收而丢数据；
另修复一个MiniBatch 聚合静默丢记录的严重 Bug。
7️⃣ 处理表函数（PTF）向 DataStream API 看齐
Flink 2.1 引入的 PTF 在这版补了两块关键能力：可响应迟到记录（而非静默丢弃），让用户能在 SQL 层自定义迟到数据策略；表参数支持 ORDER BY，确保 PTF 在每个分区内按确定的时间顺序收到行。FLIP-565 里更进阶的状态访问与广播状态改进，留待后续版本。
8️⃣ UDF 的 ARTIFACT 关键字：为 Python wheel 铺路
新增 ARTIFACT 关键字作为 JAR 的未来替代，语法完全向后兼容，但为将来接入 Python wheels 等生态资产预留了扩展位——这是 PyFlink 体验要翻身的前置动作。
9️⃣ 应用级生命周期管理：从"集群-作业"到"集群-应用-作业"
把原来 cluster-job 两层模型升级为 cluster-application-job 三层，Web UI 新增 Applications 标签页并重做首页，作业可反链回父应用。对生产环境的收益很实际：一批作业的归属、状态与生命周期第一次被显式建模，而不是散落成一个个孤立 job。
🔟 文档大重构
Flink SQL 从 Table API 中独立成顶级章节、关系流式概念（changelog、动态表、状态）提升到更高层级、Python 文档并入对应 API 章节、贡献者内容移出用户文档。老 URL 用重定向兜底。
🔌 三、Connector 生态：官方 18 个独立仓库在跑
Flink 的外置 connector 已全面拆仓维护（2026 年秋仍在密集更新，说明维护活跃）：
一句话评价：连接器覆盖面是 Flink 最深的护城河——从 Kafka 到 Paimon 到 Iceberg，主流数据栈几乎没有它连不上的。2.3 的重点不是"新增连接器"，而是把 S3 这个最高频的存储底座换成自研实现。
⚔️ 四、与其它流计算引擎对比
Flink 的特色亮点：
🏆 状态与容错的绝对优势：大状态、精确一次、unaligned checkpoint、恢复期可 checkpoint——这些是大规模实时业务真正依赖的东西；
🏆 真正的"流批一体"：同一套 API 跑实时与离线回刷；
🏆 生态最全：连接器 + 数据湖格式几乎无死角。
Flink 的短板也很清楚：
⚠️ 运维门槛高：资源配置、状态后端、水位线、背压调优都是"专家活"，小团队上手成本大；
⚠️ 资源占用偏重：相比 Kafka Streams 这种"库"型方案，Flink 是重型平台，轻量场景反而吃亏；
⚠️ SQL 曾有历史欠账：本版大篇幅补 SQL，恰恰说明此前 changelog 转换、物化表演进等方面落后于 RisingWave 这类"流式数据库"；
⚠️ Java 生态绑定深：Python 支持（PyFlink）体验仍不如原生 SQL 方案。
🔮 五、未来技术演进方向
已明确的 2.4 主线（Q2 社区更新披露，本季度工程大头）：
Calcite 五连升级 + 生成 SQL 代码的公共子表达式消除——继续给 SQL 引擎做性能与正确性加固；
JDK 25 基础工作——跟着 JDK 升级走；
AI 原生：社区已接受一份 umbrella proposal，定义 Flink 中 AI 原生、多模态处理的更广方向；
Flink Agents：0.3.0 已交付可复用 skills、跨语言 action、可靠性、可观测性，并向 1.0 推进、采纳 AI 生态新兴标准。
中长期三个判断：
流处理与 AI 的边界在消融——Agents + 多模态处理意味着 Flink 想做的是"实时数据管道 + 实时 AI 决策"的统一底座；
物化表与 changelog 之争会持续——Flink 在向"流式数仓"靠拢，与 RisingWave、Materialize 的正面竞争将更直接；
原生云化——原生 S3 FS 只是开始，逐步摆脱 Hadoop 依赖是必然方向。
📌 六、总结：三个核心信号
🏆 2.3 是一次"补短板"的版本——changelog 转换、物化表演进、SinkUpsertMaterializer，全都在还 SQL 侧的历史欠账；
🏆 "省钱"成了新卖点——避免历史数据重算、原生 S3 降依赖、自适应分区省资源，Flink 开始认真算客户的账；
🏆 AI 原生已进入路线图——Agents 0.3.0 与多模态 umbrella proposal，暗示 Flink 的下一步不只是"更快的流处理"，而是"实时 AI 的数据底座"。
📌 一句话总结：Flink 2.3.0 没有惊艳的新概念，但把 SQL、存储、运维三块"工程地基"都夯了一遍——对真在生产上跑实时业务的人来说，这种版本比发布会上的花活值钱得多。
本文原创作者：易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。
原文链接
欢迎访问 小易撩挨踢