關於作者

本文內容整理自阿里雲實時計算 Flink 產品團隊的技術分享，由李昊哲主講。李昊哲負責 Flink 平台的控制枱體驗、企業級能力建設，包括開放性、權限管理和可觀測性等方向。

在企業數字化轉型的浪潮中，實時計算已經成為核心技術能力之一。然而，一個強大的實時計算引擎如何才能真正融入企業複雜的技術生態?答案在於"被集成能力"——讓平台不僅僅是一個獨立的服務，而是能夠無縫嵌入到企業現有的開發流程、運維體系和數據架構中。

阿里雲實時計算 Flink 在這方面進行了系統性的探索和實踐。從 OpenAPI 的全面開放，到 Git 集成的原生支持，再到多維度的數據投遞能力，Flink 正在構建一個真正開放、可編程、可治理的實時計算平台。

四層開放架構:從控制面到計算面的全面兼容

過去十年，Apache Flink 從一個開源的流處理框架，演進為支撐企業核心業務的實時計算平台。隨着用户規模的擴大，對深度集成、自動化運維和統一入口的需求愈發強烈。為此，阿里雲 Flink 構建了一個由內到外的四層開放架構，確保企業可以在不同層面靈活地集成 Flink 能力。

這個架構從底層到上層，層層開放:

控制面 (Control Plane) 是最核心的開放層。通過提供100餘個 OpenAPI、多語言 SDK (Java、Python) 以及 Terraform 支持，開發者可以實現對 Flink 資源的程序化管理。無論是批量創建工作空間、動態調整資源配置，還是通過基礎設施即代碼 (IaC) 的方式管理整個 Flink 集羣，都可以通過簡潔的 API 調用完成。

數據面 (Data Plane) 提供了強大的數據集成能力。除了系統內置的豐富 Connector 和 Catalog，平台還支持開發者以開源開放的方式集成自定義組件。無論是自研的數據源、特殊的文件系統，還是企業內部的元數據管理系統，都可以通過標準接口無縫接入 Flink。

開發面 (Development Plane) 打破了傳統 Web 控制枱的侷限。通過 VS Code 插件，開發者可以在本地熟悉的 IDE 環境中進行 Flink 作業的開發、調試和發佈。更重要的是，全新的 Git 集成能力將代碼版本控制與 Flink 作業管理深度融合，實現了從代碼提交到生產上線的自動化閉環。

運維面 (Operations Plane) 強調可觀測性和可控性。平台上的所有關鍵信息——指標 (Metrics)、日誌 (Logs)、事件 (Events)——都可以投遞到企業自有的監控系統 (如 Prometheus、Grafana) 或日誌平台 (如 SLS)。開發者還可以上傳自定義的 Log4j 配置，實現更精細化的日誌管理。

OpenAPI:構建企業自有數據平台的基石

OpenAPI 是 Flink 被集成能力的核心。目前已開放的100餘個 API 覆蓋了從資源管理到作業運維的全鏈路場景，可以分為三大類:

這些 API 如同樂高積木，開發者可以根據企業需求自由組合。例如，某造車新勢力客户完全基於 OpenAPI 構建了自己的實時計算門户。通過批量調用開户接口、循環提交作業 API 實現大規模作業的平滑上線，再結合指標回刷和日誌自動上報，該客户實現了免登錄 Flink 控制枱的集中化運維，同時獲得了近兩倍的性能提升。

Git 集成:數據開發的工程化治理革命

傳統的數據開發往往面臨三大痛點:

多團隊協作混亂。 數據、算法、運維等多個團隊並行開發同一套數據鏈路，缺乏統一的分支管理機制和代碼審查 (Code Review) 流程，導致代碼衝突頻發、責任邊界模糊。

開發流程不規範。 "改完就上線"成為常態，沒有統一的開發-測試-生產流程，缺乏自動化的語法校驗、權限檢查和依賴管理，質量風險極高。

作業質量風險高。 沒有版本依據，作業被覆蓋後無法找回歷史邏輯。審計追溯困難，線上事故發生時無法將問題與具體的代碼 Commit 關聯，責任歸屬不清。

實時計算 Flink 版 的 Git 集成能力正是為解決這些問題而生。其核心設計理念是:Git 倉庫是唯一的真實來源 (Single Source of Truth)。平台不再保存代碼的主副本，所有代碼變更必須遵循標準的 Git 工作流:

開發者本地修改 → Fork 分支 → 提交 MR (Merge Request) 
→ 觸發 CI 校驗 → Code Owner 審批 → 合併到主分支 
→ Flink 平台自動 Fetch 更新

Flink 支持主流的 Git 平台 (GitHub、GitLab、Bitbucket、Gitee、雲效、CODING 等)，通過一鍵授權綁定，無需手動下載上傳代碼。平台提供了兩種同步模式:自動同步模式下，代碼更新後自動觸發平台同步;手動同步模式下，可通過控制枱的 Pull/Push 按鈕一鍵觸發。更重要的是，Flink 可以無縫集成到企業現有的 CI/CD 流水線中。通過 Flink OpenAPI 與 Jenkins、GitLab CI/CD、GitHub Actions 等工具配合，可以實現從代碼提交、自動構建、測試驗證到生產發佈的全自動化流程。

實戰案例:頭部互聯網企業的 Flink 工程化實踐

某頭部互聯網平台在使用 Flink 時面臨着典型的大規模代碼管理挑戰。該平台的單個 Git 倉庫大小達到十幾個GB，包含 600 多個文件夾和 3000 多個 Flink 作業。如此龐大的代碼庫，如何高效同步成為首要問題。更棘手的是，團隊已經建立了完善的 GitLab CI + Code Owner 審核機制，但開發者在通過 MR 流程後，仍需手動將 SQL 代碼拷貝到 Flink 控制枱，不僅效率低下，還存在合規風險。傳統的發佈流程需要人工上傳代碼、手動創建作業、逐個配置參數，平均每次發佈耗時 30 分鐘。回滾時需要翻找歷史文件，定位困難且耗時長。

通過引入 Flink Git 集成，該客户實現了顯著的突破。首次全量 Fetch 3000 多個作業僅需 2 分鐘，後續的增量 Pull/Push 操作達到秒級響應，這得益於 Flink 團隊在代碼同步算法上的持續優化。在合規性方面，平台完全沿用企業既有的 GitLab 審核鏈路，所有代碼變更都有完整的審計日誌，每次發佈都能精確對應到具體的 Commit SHA，滿足了嚴格的內部合規要求。效率方面的提升更加顯著，發佈時長從小時級縮短到分鐘級，回滾粒度精確到 Commit，出現問題時可以快速定位到具體的代碼變更，大幅降低了故障恢復時間。更重要的是，Flink 作業被當作一種特殊的"語言"，接入到企業現有的 Sonar 代碼掃描、Owner 審批、簽名校驗等 CI/CD 鏈路中，實現了數據開發與軟件工程的統一治理。

這個案例充分説明，Flink 的 Git 集成不是簡單地提供一個代碼上傳功能，而是真正尊重並融入企業既有的研發流程，讓數據開發進入"工程化治理"時代。

未來規劃:邁向更開放的實時計算生態

Flink 的被集成能力仍在持續演進，未來的重點方向包括:

OpenAPI 的深度擴展。 除了現有的基礎運維能力，將逐步開放 Autopilot 自動調優、Hot Update 熱更新、動態擴縮容等高階能力，並保持與產品功能發佈同步的迭代節奏。

Terraform 的全面覆蓋。 在已支持工作空間和項目空間的基礎上，進一步開放作業級別的啓停、開發運維等操作，將"基礎設施即代碼"的理念貫徹到每一個 Flink 作業。

Git 集成的語言擴展。 從目前支持的 SQL 作業，逐步擴展到 Python 作業、DataStream 作業，讓所有類型的 Flink 開發都能享受到版本控制和 CI/CD 的便利。

信息投遞的標準化。 建立統一的事件模型，豐富投遞內容 (如用户操作觸發的審計事件)，並提供更靈活的過濾和路由能力，幫助企業在獲取全面監控數據的同時，有效控制成本。

通過這些持續的努力，阿里雲實時計算 Flink 版正在成為一個真正可編程、可嵌入、可治理的實時計算平台。無論是初創團隊還是大型企業，都能夠根據自身的技術棧和工作流，靈活地集成 Flink 的強大能力，釋放實時數據的價值。

更多內容

活動推薦

複製下方鏈接或者掃描二維碼
即可快速體驗 “一體化的實時數倉聯合解決方案”
瞭解活動詳情：https://www.aliyun.com/solution/tech-solution/flink-hologres