物化表管理 - Realtime Compute for Apache Flink

傳統數倉架構（如Lambda/Kappa）面臨三大核心痛點：流批處理架構的分離導致開發與維護成本的增加，多副本儲存造成儲存資源的浪費，以及跨層資料口徑對齊的複雜性引發一致性風險。為應對這些挑戰，引入了物化表（Materialized Table），其基於資料的新鮮度（分鐘/天級）和查詢語句自動產生表結構（Schema），並建立持續重新整理的資料管道。此機制將流批處理邏輯統一為單一路徑，不僅消除了冗餘儲存副本，而且保障了全鏈路資料口徑的一致性，從而顯著簡化了即時數倉的營運複雜度。

物化表核心概念

資料新鮮度

定義：資料新鮮度是物化表的核心參數，表示物化表資料相對於基礎資料表（源表）更新的最大允許延隔時間。它並非絕對保證，而是Flink嘗試達到的目標。資料新鮮度決定了資料重新整理的時效性要求，是自動化資料管道管理的關鍵依據。
作用：
- 決定資料重新整理模式（持續模式或全量模式）。
- 平衡時效性與資源消耗（例如：分鐘級新鮮度適用於即時大屏，小時級或天級適用於離線分析）。

重新整理模式

物化表支援兩種資料重新整理模式，根據業務情境靈活選擇：

重新整理模式	機制描述	可見度	使用情境
持續模式	通過流作業累加式更新物化表資料，僅處理變化部分。	下遊資料在Checkpoint完成後可見（確保一致性）或立即可見（低延遲情境）。	即時性要求高（如風控、即時推薦）。
全量模式	調度器按固定周期（如每天、每小時）觸發批次工作，全量覆蓋物化表資料。若定義分區欄位（如時間分區），可僅重新整理最新分區，避免全表重寫。	全量資料更新後可見。	歷史資料修正、定期產生報表等情境。

查詢定義

支援所有Flink SQL查詢語句，定義物化表的資料來源和計算邏輯。

動態更新：

持續模式下，查詢結果即時更新至物化表。
全量模式下，每次調度執行查詢並覆蓋舊資料，確保結果準確性。

Schema管理

物化表的列名、類型會從查詢語句自動解析產生，無需手動聲明。

擴充能力：

支援顯式聲明主鍵（如PRIMARY KEY）最佳化查詢效能。
通過分區欄位（如時間欄位）實現資料分層管理，提升重新整理效率。

物化表工作原理

物化表需明確定義兩個核心參數：資料新鮮度（FRESHNESS）和查詢語句（AS SELECT）。Flink引擎通過查詢結果自動推導Schema，並在Catalog中註冊物化表結構，同時根據新鮮度配置自動建立流式或批次工作來維護資料更新。

如圖所示，當物化表C的新鮮度設定為30分鐘時，系統會最大限度地保證該表資料相對於基表（如物化表A）的延隔時間不超過該閾值，且下遊表的新鮮度必須為上遊的整數倍（如60分鐘或90分鐘）。通過延長新鮮度參數（最大支援1天），可降低高頻更新帶來的資源消耗，例如將分鐘級更新調整為小時級批次更新。

應用情境

物化表通過流批一體的湖倉範式設計，在以下情境中具有顯著的技術與成本優勢：

歷史資料修正。
由於資料轉送延時等問題可能導致最終資料存在部分失真，因此通常需要離線作業對資料進行修正。物化表的重新整理能力允許在任意時間更新資料，同時對下遊所有關聯的物化表進行統一更新。
資料口徑對齊。
在Lambda架構中，離線和即時資料需分別儲存於不同的業務系統中，處理邏輯與建表欄位難以實現自然對齊。物化表可以確保資料僅儲存一份，避免了複雜的拼接計算。這不僅有效節省了儲存資源，還顯著減少了資料對齊口徑問題的。
動態資料大屏即時統計。
動態資料大屏在不同業務情境下對資料重新整理的時間要求存在顯著差異。物化表可以通過簡單調整資料的新鮮度，實現從天級到分鐘級的資料重新整理能力，無需單獨建立即時鏈路，從而使即時化過程變得更加便捷。

如何使用物化表

文檔	說明
建立及使用物化表	瞭解如何建立物化表，以及進行歷史資料回刷、修改新鮮度、查看物化表的血緣關係。
物化錶快速入門（構建流批一體湖倉）	瞭解如何基於Paimon和物化表，構建流批一體的湖倉分析處理鏈路，以及通過修改表資料新鮮度，完成由批到流的切換，實現資料即時更新。

Realtime Compute for Apache Flink：物化表管理