重磅升级！袋鼠云数栈全面拥抱 Flink 2.0：架构革新、性能飞跃，开启实时数据处理新时代

FlinkSql 是袋鼠云内部基于 Flink 的数据计算以及实时采集框架，提供了对上百个插件的支持，能够连接市面上常见的数据源，并具备脏数据处理、自定义 Metric 等扩展功能。

技术升级动因与战略价值

数栈在 2023 年将 Flink 从 1.12 升级到 1.16 后再未进行内核升级，集中于插件功能和生态的完善。但如今插件层次的丰富不能掩盖内核特性的落后。

随着 Flink 社区的快速发展，尤其是 Flink 2.0 的推出，带来了许多新特性以及接口，架构的变化，如 Materialized Table 流批一体 ETL 新方式，存算分离新架构。因此升级 Flink 2.0 将作为数栈 V7.x 版本的核心功能之一。

这一升级将为企业用户带来更高效、更稳定、更智能的数据处理体验。

Flink 2.0 升级实施路径

Flink 2.0 废弃了 SourceFunction 和 SinkFunction，转而要求使用 Source 和 Sink V2 接口进行开发。

FlinkSql 升级 Flink 2.0 首要就要面对上百插件接口的不兼容。丰富的插件给引擎团队也带来较大维护压力，只能对重点插件进行功能演进，导致部分插件的功能演进较慢，例如谓词下推等功能尚未开发。此外，客户常反馈数栈插件不支持某些开源插件的功能，兼容性问题成为痛点。因此决定在 Flink 2.0 升级中，通过复用社区优质插件（如 JDBC Connector、Starrocks Connector）进行二开，减少自研插件冗余，并将企业级能力（如性能优化、稳定性优化）迁移至开源插件，可以实现稳定性与功能的双重保障，同时根治客户痛点。

未来引擎团队会更关注于 Flink 2.0 本身特性和 FlinkSql 进行结合，提供更多的特色功能以及降低 Flink 使用门槛，不仅仅局限于脏数据、自定义 Metric 等。

关键技术收益与创新点

架构革新

具体而言，在 Flink 2.0 升级过程中，我们在架构上主要做了如下几件事情：

• 开源生态深度融合：复用社区优质插件（如 JDBC Connector、Starrocks Connector），减少自研插件冗余，避免重复开发。

• 企业级能力迁移：将多年积累的性能优化、稳定性优化等核心能力迁移至开源插件，提升插件稳定性和功能性。

• 客户痛点解决：通过直接复用社区插件，实现功能对齐度达 100%，彻底消除客户对兼容性的疑虑。

• 反哺开源社区：将内部演进的功能特性和稳定性改进贡献给开源社区，推动社区共同进步。

实时采集升级：Flink CDC 的深度实践

Flink CDC 作为 Flink 生态中公认的 CDC 标准方案，随着 CDC 3.0 的快速发展，在数据集成方面提供了诸多功能拓展，如 Schema Evolution、Transform 等。FlinkSql 将实时采集能力全面迁移至 Flink CDC，以利用其强大的功能和生态优势。然而，开源 Flink CDC 源端在具体插件上仅 MySQL 在生产环境中可用，其他插件（如 Oracle CDC、PostgreSQL CDC）在稳定性和企业级要求方面存在较大差距。因此，为了提升插件稳定性、降低使用门槛，并满足企业级需求，FlinkSql 在 Flink CDC 结合中进行了深度优化和适配。主要内容如下：

• Flink 2.0 内核适配：完成 Flink CDC 各个插件的新 Source 和 Sink 接口适配，确保与 Flink 2.0 的兼容性。

• FlinkSql 内部业务代码迁移：将 Flinksql 内部的 Cdc 业务逻辑迁移至 Flink CDC，提供更多功能支持。

• 插件稳定性优化：将 FlinkSql 中积累的稳定性代码（如 LogMiner 优化）迁移到 Flink CDC，提升 Oracle CDC、PostgreSQL CDC 等插件的稳定性，使其达到生产可用水平。

• 降低使用门槛：通过数栈的可视化配置功能，简化 CDC 配置流程，降低使用门槛；同时完善 Metric 监控页面，提供可视化运维能力，实现问题及时预警。

批流一体：Materialized Table 重构数据处理范式

随着大数据场景对实时性和开发效率的要求日益提升，传统流批分离的开发模式逐渐暴露出以下问题：

• 开发复杂度高：用户需要分别理解流处理和批处理的概念，维护两套代码逻辑，学习成本高。

• 资源利用率低：批量作业无法增量更新数据，重复计算导致资源浪费。

• 实时性不足：传统 ETL 流程难以满足业务对数据新鲜度的要求（如分钟级甚至秒级更新）。

Flink 2.0 推出的 Materialized Table（物化表） 通过统一流批处理范式、自动化数据刷新机制，旨在解决上述痛点，加速企业实时数据管道的构建。

Materialized Table 是一种通过 SQL 定义的表，其数据由查询结果动态生成，并通过“数据新鲜度规范”（如 FRESHNESS = INTERVAL '5' MINUTE）控制刷新频率。核心原理：

• 流批统一：用户只需用 SQL 定义查询逻辑，通过统一 SQL 定义流批任务，无需区分流或者批开发场景。

• 增量更新：基于 Flink 状态管理和 Checkpoint 机制，仅处理增量数据，避免全量重复计算，提升了资源利用率。

• 数据刷新管道：引擎自动创建并维护数据刷新作业，确保结果表满足用户定义的新鲜度要求。

FlinkSql 升级到 Flink 2.0 之后，将会基于 Materialized Table 和 Paimon,助力企业快速构建实时数据管道，并结合数栈平台进行视图查询与管理，进一步降低了开发与运维门槛。

未来技术路线图

除了以上主要工作内容外，FlinkSql 未来基于 Flink 高版本特性，会进行更多扩展，而不仅仅是插件的丰富，如云原生适配( Flink 的动态扩缩容，弹性调度），Sql Gateway 在 OLAP 的探索等等。以下是 Flink 1.16 升级到 Flink 2.0 的主要特性：

• 废弃 java8，至少 java11

• DataSetApi SourceFunction SinkFunction SinkV1 等旧接口废弃，统一使用新版 source sink 接口

• Materialized Table：简化批流数据管道

• Flink webui 支持 JobManager/TaskManager Profiling

• sqlGateway 支持 JDBC 协议进行交互

• sql 支持存储过程，catalog 增强，支持元数据获取和增强

• sql 引入 Bucketing 概念，支持 Bucket 语法

• sql 支持 Time Traveling（时间旅行）语法

• sql 支持配置源端并行度，SQL Hint 单独设置 operator 级 State TTL

• 更快的状态恢复 Faster Rescaling with RocksDB

• 检查点的统一合并机制 Unified File Merging Mechanism for Checkpoints 以及 Compaction of Small SST Files

• 当源正在处理积压时使用更大的检查点间隔：Using Larger Checkpointing Interval When Source is Processing Backlog 

• 更好的云原生支持，状态存储在外部存储系统（如 S3、HDFS 等）

• 云原生弹性伸缩，支持 REST API 进行动态细粒度重新缩放