【硬核大師班】PARTITION BY 的末日！深入拆解 Liquid Clustering 與 UniForm 的底層儲存演算法

前言：那個被「分區策略」詛咒的資料工程師

在過去十年的大數據架構中，當我們建立一張 TB 級別的資料表時，架構師必須面臨一個靈魂拷問：「這張表該用什麼欄位做分區 (Partition)？」

最經典的悲劇是：為了加速時間查詢，工程師設定了 PARTITION BY (year, month, day)。一開始跑得很順，但隨著業務發展，行銷部開始頻繁查詢 customer_id。因為資料是按日期切成實體資料夾的，查詢 customer_id 時，Spark 引擎被迫掃描過去三年的每一個資料夾（Full Table Scan），效能瞬間崩盤。

如果你試圖增加分區欄位 PARTITION BY (date, country, department)，又會引發更可怕的「小檔案地獄 (Small File Problem)」與「維度詛咒 (Curse of Dimensionality)」。HDFS 或 S3 會被幾百萬個只有幾 KB 的檔案塞爆，NameNode 直接癱瘓。

在 2026 年的現代化儲存架構中，傳統的 Hive-style 靜態分區已經被宣告死亡。未來的解答是動態、多維度的 Liquid Clustering。

硬核解析一：Liquid Clustering (液態聚簇) 的數學與演算法

Liquid Clustering 不是簡單的 ORDER BY，它是基於空間填充曲線 (Space-Filling Curves) 的降維演算法，其核心目的是實現「多維度的資料跳過 (Multi-dimensional Data Skipping)」。

1. 突破維度詛咒：從 Z-Order 到 Hilbert Curves

• 技術痛點：資料表是二維的（列與欄），但硬碟儲存是線性的一維空間。當我們希望同時針對 timestamp、user_id 和 device_id 進行快速查詢時，傳統線性排序只能滿足第一個欄位。
• 底層數學：Liquid Clustering 利用了空間填充曲線（如 Z-Order 曲線或更進階的 Hilbert 曲線），將高維度的資料點 $X = (x_1, x_2, …, x_n)$ 映射到一維的連續數值 $d$ 上。
• 運作機制：這種演算法確保了在多維空間中相近的資料點（例如：同一天且同一個客戶的交易），在實體硬碟的 Parquet 檔案中也會被存放在相近的區塊。當引擎執行查詢時，會讀取 Delta Log 中的檔案級別 Min/Max 統計資訊，透過數學計算，直接跳過 (Skip) 99% 不包含目標資料的檔案。

2. 液態的動態重組 (Dynamic & Incremental Clustering)

• 傳統痛點：過去的 Z-Ordering 是一個極度昂貴的全局運算 (Global Operation)。你需要鎖住整張表，耗費大量算力重寫所有檔案。
• 架構革命：Liquid 顧名思義是「液態的」。當新資料 (Streaming 或 Batch) 寫入時，它不需要立刻完美排序。Databricks 會在背景（結合 Predictive Optimization）進行增量聚簇 (Incremental Clustering)。
• 無縫演進：最可怕的是，如果你今天決定改變聚簇的欄位（例如從按 user_id 聚簇改成按 store_id），你不需要重寫舊資料！ALTER TABLE ... CLUSTER BY (store_id) 執行後，新寫入的資料會自動採用新的曲線排列，而舊資料會在背景逐步被「融化並重塑」，完全不中斷前端的查詢服務。

硬核解析二：UniForm (通用格式) 的元數據魔術

解決了效能，接下來要解決的是「政治問題」。

Iceberg、Delta Lake、Apache Hudi 三大開源格式的戰爭，讓許多企業陷入「廠商綁架 (Vendor Lock-in)」的恐懼。CIO 害怕今天選了 Delta，明天就無法被 GCP BigQuery 或 Snowflake 原生讀取。

Databricks 的解法不是發明第四種格式，而是推出了 UniForm (Universal Format)。這是一場純粹在「元數據 (Metadata)」層級進行的降維打擊。

1. 檔案格式的本質解析

要理解 UniForm，必須先認清一個事實：無論是 Delta、Iceberg 還是 Hudi，它們底層存放實際資料的，全部都是 Parquet 檔案。

這三者的差異，僅僅在於它們如何記錄「哪一個 Parquet 檔案屬於這張表的最新版本」 — — 也就是 Metadata 的格式不同。Delta 用的是 JSON/Parquet 格式的 Transaction Log (_delta_log/)；Iceberg 用的是 Avro 格式的 Manifest 檔案。

2. 非同步的元數據翻譯 (Asynchronous Metadata Translation)

• UniForm 運作機制：當你在一張 Delta 表上開啟 UniForm 功能時，引擎會在每次資料寫入並產生 Delta Commit 後，觸發一個極度輕量的非同步任務 (Asynchronous Task)。
• 零資料複製 (Zero-Data Copy)：這個任務完全不會碰到那幾 TB 的 Parquet 實體檔案。它的時間複雜度接近 $O(1)$。它只做一件事：讀取 Delta Log 的更新，然後將這些變更「翻譯」成 Iceberg 標準的 metadata.json 與 Manifest 檔案，並寫入同一個 S3/ADLS 資料夾中。
• 架構結果：現在，同一個資料夾裡，同時存在著 Delta 的日誌與 Iceberg 的元數據。這張表，處於一種量子疊加態。

3. 跨引擎的原生讀取 (Native Cross-Engine Reads)

• 商業價值：當 Snowflake 或是 BigQuery 嘗試讀取這張表時，它們會循著 Iceberg 的標準，找到由 UniForm 自動生成的 metadata.json。這兩個引擎會以為自己正在讀取一張純粹的 Iceberg 表，並順利讀取底層的 Parquet 檔案。
• 零效能損耗：因為沒有透過任何外部的 API 轉接，也沒有啟動額外的運算叢集，這達成了真正的 Zero-Copy, Zero-Compute 跨平台資料共享。

結語：抽象化的最高境界

在這場硬核大師班中，我們穿透了華麗的介面，看到了 Lakehouse 最底層的齒輪。

Liquid Clustering 幫我們抽象化了「資料該如何物理排列」的難題；UniForm 幫我們抽象化了「資料該用什麼格式儲存」的政治角力。

當底層儲存引擎能夠透過高深的數學與元數據轉換，自行解決效能與相容性問題時，架構師才能真正從無止盡的 Tuning (調校) 中解脫，將每一分算力與心智，投資在商業價值的萃取上。這，才是 Data Intelligence 的硬核底氣。

關於作者：Leo Huang (黃鈺軒)

Databricks Champion | Data & AI Solution Architect

擁抱開源，敬畏數據。讓我們一起在深水區中穩健前行。

推薦主題標籤

Databricks #LiquidClustering #DeltaLake #ApacheIceberg #DataEngineering #DataArchitecture #BigData #DatabricksChampion #LeoHuang #硬核大師班