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 進行動態細粒度重新縮放