引言

現代數據環境要求架構能夠無縫融合數據湖的靈活性與傳統數據倉庫的性能特徵。隨着企業越來越多地採用實時分析來驅動業務決策，Apache Flink作為流處理引擎與Apache Paimon作為湖存儲格式的結合，已成為構建強大實時湖倉平台的引人注目的解決方案。

本文整理自 Apache CommunityOverCode Asia 2025 大會上，阿里雲技術專家，Apache Flink Committer 蘇軒楠分享了基於 Paimon構建的 Flink 實時湖倉解決方案持續演進的深刻見解。這一技術深度解析探討了為解決大規模流式分析平台實施過程中面臨的現實挑戰而開發的關鍵優化和架構改進。

隨着需要處理日益增長的結構化和半結構化數據量，傳統的數據處理方法在性能、成本效益和運營複雜性方面往往力不從心。所討論的增強功能代表了在生產環境中經過測試和完善的實用解決方案，為尋求現代化數據基礎設施的組織提供了具體的實施路徑。

實時湖倉架構格局

在深入技術優化之前，有必要了解圍繞Flink和Paimon集成而形成的典型架構模式。實時湖倉方法代表了從傳統批處理導向的數據倉庫模式的根本轉變，擁抱了數據到達時連續處理的模型。

基礎架構組件

基於Flink和Paimon構建的現代實時湖倉通常由幾個相互連接的處理層組成，每個層都服務於不同的目的，同時在整個系統中保持無縫的數據流。在基礎層，Flink CDC（變更數據捕獲）在建立統一的全量和增量數據同步能力方面發揮着關鍵作用。

Flink CDC在彌合操作數據庫和分析系統之間的差距方面已被證明特別有價值。與需要在固定時間表上運行的複雜ETL管道不同，Flink CDC使組織能夠實時捕獲來自MySQL等源系統的變更，並直接將其流式傳輸到Paimon的ODS（操作數據存儲）層。這種方法不僅減少了延遲，還通過消除對中間暫存區和複雜協調機制的需要來簡化整體架構。

這些能力超越了簡單的數據複製。現代實現支持完整的數據庫同步場景，其中整個數據庫模式可以遷移到湖倉格式，並完整支持自動模式演化處理。這意味着當源系統模式發生變化時——無論是通過添加新列、修改數據類型還是重構關係——下游Paimon表都可以自動適應，無需手動干預或管道重建。

數據處理與轉換層

一旦數據通過攝取層進入湖倉，它就會經歷一系列處理階段，逐步完善和豐富信息。數據倉庫明細（DWD）層代表第一個主要轉換階段，原始操作數據在此經歷清洗、標準化和豐富操作。

這些轉換通常涉及複雜的數據連接操作，通過組合來自多個源系統的信息來創建"寬表"。例如，電子商務組織可能會將客户檔案數據與交易歷史、產品目錄和營銷活動信息連接起來，以創建全面的客户行為數據集。這種處理的實時特性意味着隨着源數據的變化，這些豐富的視圖保持最新，為分析師和應用程序提供新鮮的見解，而沒有傳統批處理方法固有的延遲。

處理繼續進展到數據倉庫彙總（DWS）層，聚合計算產生業務指標和關鍵績效指標。與傳統數據倉庫中這些聚合可能每天或每小時計算一次不同，實時湖倉方法能夠在事件發生時連續計算業務指標。這種能力對於需要實時監控業務績效、快速響應運營問題或基於分析見解觸發自動化操作的組織來説是變革性的。

湖倉管理與優化

湖倉內的數據管理帶來了與傳統數據倉庫管理顯著不同的獨特挑戰。Paimon通過一套全面的湖倉管理工具和優化技術來解決這些挑戰，這些工具和技術透明地運行以維持系統性能和效率。

小文件管理代表了任何基於湖的存儲系統中最關鍵的運營挑戰之一。隨着流數據的連續到達，自然傾向於創建大量小文件，這會降低讀取性能並增加元數據開銷。Paimon的自動文件合併功能通過基於可配置策略智能合併小文件來解決這一挑戰，確保存儲保持優化而無需手動干預。

這些功能協同工作，在保持查詢性能的同時最大限度地降低存儲成本，這對於處理大量歷史數據和實時流的組織來説是特別重要的考慮因素。

技術演進：應對現實世界的挑戰

Flink和Paimon生態系統的成熟導致了越來越複雜的優化，這些優化解決了生產部署中遇到的特定性能瓶頸和運營挑戰。從這一演進中出現了兩個特別重要的改進：半結構化數據的增強處理和優化的Lookup Join操作。

半結構化數據挑戰

現代數據環境的特點是半結構化數據格式的激增，其中JSON是最普遍的。Web應用程序、移動設備、物聯網傳感器和API驅動集成的興起使JSON在企業數據管道中無處不在。然而，在使用傳統流處理方法時，這種普遍性帶來了顯著的性能影響。

根本挑戰在於JSON的自描述特性。與結構化數據中模式信息與數據本身分離不同，JSON直接在數據有效負載中嵌入類型和結構信息。雖然這提供了巨大的靈活性並啓用了動態模式演化，但在流環境中處理大量JSON數據時會創建大量的計算開銷。

Flink中JSON處理的傳統方法將半結構化數據視為簡單的字符串值，每次需要訪問任何字段時都需要完整的解析操作。這種架構決策雖然實現簡單，但性能不太理想。即使訪問JSON對象中的第一個字段也需要解析整個文檔，由於數據作為字符串值在Flink的作業中分發，每個需要處理JSON的下游算子都必須重複完整的解析操作。

存儲也有同樣的問題。JSON的基於文本的格式雖然人類可讀且廣泛支持，但消耗的存儲空間比等效的二進制表示形式多得多。這種增加的存儲佔用直接轉化為更高的成本和在隨機操作期間增加的網絡帶寬消耗，其中數據在流處理管道中的算子之間移動。

Variant數據類型解決方案

Variant數據類型的引入代表了Flink處理半結構化數據處理方法的根本轉變。Variant不是將JSON視為不透明文本，而是提供了一種原生二進制表示，保持了半結構化數據的靈活性，同時提供了更接近結構化數據處理的性能特徵。

Variant格式從更廣泛的數據處理生態系統中的類似努力中汲取靈感，特別是Parquet提議的半結構化數據格式。通過採用開放標準方法，實現確保了與其他處理引擎的兼容性。

Variant採用的二進制編碼策略通過幾種機制實現性能改進。模式信息不是在整個數據中重複嵌入，而是在元數據部分中編碼一次，顯著減少存儲開銷。字段訪問操作可以利用這些元數據直接導航到特定字段，而不解析數據結構的無關部分，大大提高了選擇性查詢的訪問性能。

增強的開發者體驗

除了性能改進之外，Variant在處理半結構化數據時為開發者體驗引入了顯著的增強。傳統方法要求開發者使用複雜的SQL函數進行字段訪問，創建冗長且容易出錯的查詢。Variant啓用了更直觀的語法模式，與開發者從其他編程環境的期望一致。

使用熟悉的括號表示法和點語法的直接字段訪問簡化了查詢開發並使代碼更易維護。數組元素訪問遵循類似的模式，使開發者能夠使用自然語法處理嵌套結構。類型轉換功能允許與強類型下游處理的無縫集成，其中Variant字段可以根據需要轉換為特定的數據類型。

JSON字符串和Variant類型之間的轉換函數為現有系統提供了遷移路徑，同時啓用了新格式的漸進採用。PARSE_JSON和TRY_PARSE_JSON函數處理從基於文本的JSON到二進制Variant格式的轉換，後者為格式錯誤的輸入數據提供錯誤處理功能。JSON_STRING函數在與尚未採用Variant支持的系統接口時啓用轉換回文本格式。

Variant Shredding：針對現實世界模式的優化

Variant實現中最複雜的優化解決了半結構化數據中的一個常見模式：經常訪問的公共字段與真正動態部分的存在。雖然JSON的靈活性允許完全任意的結構，但生產系統經常表現出某些字段在記錄中一致出現的模式，即使數據結構的其他部分變化顯著。

Variant Shredding通過將經常訪問的字段作為單獨的物理列存儲在主Variant二進制結構之外來利用這一觀察。這種混合方法結合了半結構化數據的靈活性與經常訪問字段的列式存儲性能特徵。以這種方式 shredding 的字段可以以幾乎與常規結構化列相同的性能進行訪問。

這種優化的影響超越了簡單的字段訪問性能。shredding 字段可以完全參與Flink的查詢優化，包括 projection 下推（其中僅從存儲中讀取所需列）和 filter 下推（其中謂詞在儘可能接近數據源的地方進行評估）。這些優化可以大大減少I/O需求，在處理大型歷史數據集和實時流時特別重要。

適合 shredding 的字段識別可以通過兩種方法發生。手動配置允許開發者和數據工程師基於他們對數據訪問模式和業務需求的理解明確指定 shredding 字段。對於處理多樣化或不斷髮展的半結構化數據的組織，自動化發現機制可以分析傳入的數據樣本以識別出現頻率足以從 shredding 優化中受益的字段。

Lookup Join優化：解決可擴展性瓶頸

第二個主要優化領域解決了實時分析中的一個常見架構模式：使用Lookup Join用存儲在Paimon表中的維度信息來豐富流數據。

理解Lookup Join挑戰

Lookup Join代表了流分析中的關鍵操作，其中實時事件數據需要用相對靜態的維度信息進行豐富。常見示例包括用客户檔案信息豐富交易事件、向購買事件添加產品詳細信息或用配置數據增強日誌條目。挑戰在於高效訪問可能分佈在多個存儲分區中的維度數據，同時保持實時處理所需的低延遲特徵。

Flink中的Lookup Join通常涉及三個階段：基於連接鍵分發事實表數據的隨機操作、從遠程存儲檢索維度數據的獲取操作，以及維護維度數據本地副本以供快速訪問的緩存操作。

這種方法在傳統的維度數據存儲如Redis中運行得相當不錯，因為其中數據本質上不分區，所有的算子都需要讀取完整的數據。然而，Paimon的數據存儲分桶策略與這種方法產生了根本性的不匹配，導致性能的浪費。

分桶不匹配問題

Paimon使用分桶策略組織數據，其中記錄基於基於鍵的哈希函數分佈在多個分桶中。這種方法提供了出色的可擴展性並啓用了高效的數據組織，但它在傳統Lookup Join實現中創造了顯著的低效率。

核心問題是Flink的 Lookup 算子不知道Paimon的分桶策略。每個併發 Lookup 算子假設它可能需要與維度表中的任何記錄連接，導致每個算子需要維護所有維度數據的完整副本。這意味着無論有多少並行算子處理Lookup Join，每一個都需要讀取整個Paimon表並在本地緩存所有維度數據。

這種方法的影響在大規模部署中變得嚴重。作業啓動時間可能延長到數十分鐘，因為每個算子拉取完整的維度數據集。內存消耗隨算子並行度提高，因為每個算子維護所有維度數據的重複副本。由於管理這些大型本地緩存的開銷和為每個查找操作搜索完整數據集的計算成本，整體Lookup Join性能受到影響。

自定義Shuffle策略解決方案

該解決方案涉及擴展Flink的Lookup Join架構以支持自定義 shuffle 策略。這確保了預期到特定Paimon分桶的記錄由負責該分桶維度數據的相同 Lookup 算子處理。

有了這種對齊，每個 Lookup 算子可以專門關注其分配的分桶數據。算子只需要維護其分配分桶數據的本地副本，而不是讀取和緩存整個維度表。這大大減少了每個算子需要管理的數據量，並消除了算子之間的冗餘存儲。

性能改進效果非常明顯，在高並行性場景中，作業啓動時間也可以從數十分鐘減少到幾秒鐘。每個算子的內存消耗顯著下降，允許更高效的資源利用。由於較小的本地緩存和更集中的數據訪問模式，整體Lookup Join性能提高。

其他關鍵優化特性

除了Variant數據類型和Lookup Join優化這兩個核心改進之外，Flink和Paimon的集成還包含了一系列其他重要的優化特性，這些功能共同構成了完整的實時湖倉解決方案優化體系。

Paimon Action/Procedure 易用性優化

Paimon Action和Procedure功能的易用性優化代表了用户體驗的重大改進。傳統的湖倉管理操作往往需要複雜的配置和深度的技術專業知識，這對於開發者和運維人員來説構成了顯著的使用門檻。

新的易用性優化簡化了常見的湖倉管理任務，包括表的創建、數據的壓縮、快照的管理和元數據的維護等操作。用户可以通過簡單的SQL語句完成複雜的湖倉管理任務。

Materialized Table 物化表支持

物化表（Materialized Table）是 Flink 新引入的功能，主要是為了讓用户能夠通過  Flink SQL 寫業務的代碼，Flink 會自動根據用户指定的數據新鮮度需求來決定啓動流作業或者批作業來生成 materialized table，保證表中的數據符合新鮮度的需求。用户免去了配置作業，以及維護作業的工作。

Nested Projection Pushdown 

Nested Projection Pushdown優化專門針對複雜嵌套數據結構的查詢性能問題。在現代數據環境中，JSON、Avro、Parquet等格式經常包含深層嵌套的數據結構，傳統的查詢處理往往需要讀取整個嵌套對象，即使查詢只需要其中的少數幾個字段。

Nested Projection Pushdown技術能夠分析查詢中對嵌套字段的訪問模式，並將字段選擇操作推送到數據讀取的最早階段。這意味着在從存儲系統讀取數據時，就可以只提取查詢實際需要的嵌套字段，而不是讀取完整的嵌套結構。

這種優化對於包含大量嵌套字段的數據特別有效。例如，對於包含數百個字段的用户行為事件數據，如果查詢只需要其中的幾個關鍵字段，Nested Projection Pushdown能夠將I/O開銷降低一個數量級。同時，這種優化還能減少網絡傳輸的數據量和內存使用量，從而提升整個查詢處理管道的效率。

Partial Update Sink Reuse 和性能優化

Paimon 的 partial update 也是非常常用的功能。但是在做 partial update 的時候，通常需要在一個作業中有多個數據源寫入同一張 Paimon 表，當 Flink 作業做 checkpoint 的時候，會有 sink 同時做 compaction，這會導致作業一直 Failover。為此我們對 Flink 的 sql planner 做了改動，讓它能夠識別出相同的 sink 進行復用，從而避免這種問題

技術發展路線圖與版本規劃

Flink和Paimon的集成發展遵循着清晰的技術路線圖，不同的優化特性按照成熟度和優先級被分配到不同的版本發佈週期中。

已發佈功能特性

在當前已發佈的版本中，核心的優化功能已經投入生產使用，包括前面詳細討論的Lookup Join優化、Paimon Action/Procedure的易用性改進、物化表支持、Nested Projection Pushdown，以及Partial Update Sink Reuse等關鍵特性。這些功能已經通過了大規模生產環境的驗證，能夠為企業級實時湖倉部署提供穩定可靠的性能保障。

Flink 2.1 與 Paimon 1.3 版本特性

在Flink 2.1和Paimon 1.3的版本發佈中，重點關注Variant數據類型的基礎支持能力。這個版本將提供完整的Variant類型讀寫功能，使得用户能夠在Flink和Paimon中原生處理半結構化數據，而不需要依賴複雜的字符串解析操作。

同時，這個版本還將支持Variant配置的shredding字段功能，允許用户根據數據訪問模式手動配置哪些字段需要進行shredding優化。這為有明確數據訪問模式的企業用户提供了精細控制的能力，能夠針對具體的業務場景進行深度的性能調優。

Flink 2.2 版本增強功能

Flink 2.2版本將進一步完善Variant數據類型的功能，重點提供更加靈活和強大的字段訪問能力。用户將能夠使用直觀的語法訪問Variant類型中的嵌套字段，同時支持靈活的類型轉換操作，使得Variant類型能夠與現有的強類型處理流程無縫集成。

這個版本的Variant類型支持將使得半結構化數據的處理體驗接近傳統結構化數據，同時保持了半結構化數據的靈活性優勢。

展望未來：技術創新的新方向

半結構化數據處理的智能化發展

在半結構化數據處理領域，未來的發展將更加註重自動化和智能化。Variant shredding功能將支持自動設置shredding字段，系統能夠通過分析歷史查詢模式和數據訪問頻率，自動識別哪些字段適合進行shredding優化，無需用户手動配置。

更進一步，Flink將支持Variant字段訪問的下推優化到數據源層面，結合讀裁剪優化技術，能夠在數據讀取階段就完成字段的選擇和過濾操作。這種源端優化將大大減少數據傳輸和處理的開銷，特別是在處理大規模半結構化數據時能夠帶來顯著的性能提升。

非結構化數據處理能力擴展

Flink的發展規劃還包括對非結構化數據處理能力的重要擴展。未來版本將能夠處理文本、圖像、音頻等非結構化數據類型，這為構建更加全面的數據處理平台奠定了基礎。

非結構化數據處理能力的引入將使得Flink不僅能夠處理傳統的業務數據，還能夠支持內容分析、多媒體處理、文檔解析等更廣泛的應用場景。這種擴展將進一步鞏固Flink作為統一數據處理平台的地位。

更多內容

活動推薦

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