在早期以 Hadoop / Hive 為核心的資料湖時代,資料以 Parquet 或 ORC 列式檔案直接存儲於 HDFS 或 AWS S3 物件儲存中。

然而,單純的物件儲存存在三大硬傷:

  1. 缺少 ACID 事務保證:多個任務同時寫入或更新時,讀取端極易讀取到寫到一半的「髒數據」;
  2. 目錄級元數據瓶頸:Hive 依賴目錄路徑進行分區查找,當資料量破千萬個檔案時,僅 S3 LIST 目錄就需耗費數十分鐘;
  3. 無法時間旅行(Time Travel)與更新刪除(UPSERT / DELETE):對於 GDPR 被遺忘權或資料修正極度痛苦。

為此,業界誕生了 現代開放表格格式(Open Table Formats),正式開啟了 湖倉一體(Lakehouse) 時代。

當前開源世界形成了「三國鼎立」格局:Apache Iceberg、Delta Lake 與 Apache Hudi。本文將為你深入剖析這三大表格格式的底層元數據結構與架構權衡。


1. 三大 Table Formats 核心架構矩陣

核心特性Apache Iceberg (Netflix / Apple 主推)Delta Lake (Databricks 主推)Apache Hudi (Uber 主推)
元數據組織方式樹狀快照結構 (Metadata Tree: Catalog ➔ Manifest List ➔ Manifests)單一交易日誌目錄 (_delta_log/*.json + Checkpoint Parquet)時間線 (Timeline) 與 Commit 狀態檔案
事務隔離級別快照隔離(Snapshot Isolation / OCC)串行化 / 寫入快照隔離快照隔離 / 樂觀鎖
寫入更新模式Copy-on-Write (Positional/Equality Delete)Copy-on-Write 與 Deletion VectorsCopy-on-Write (COW) 與 Merge-on-Read (MOR)
分區機制隱藏分區(Hidden Partitioning,無須在 SQL 顯式宣告)物理目錄分區 (date=2026-09-02/)物理目錄分區
主要優勢場景跨引擎通用性極佳(Trino, Spark, Flink, StarRocks)與 Spark / Databricks 生態深度整合高頻即時 Upsert / CDC 增量入湖

2. Apache Iceberg 底層結構:樹狀元數據體系

Iceberg 徹底拋棄了「目錄即分區」的傳統 Hive 思維,將表格狀態抽象為一個精密的樹狀層級:

Apache Iceberg 樹狀元數據體系(Metadata Tree)架構圖展示 Catalog 指針指向 Table Metadata,經 Manifest List、Manifest Files 最終定位底層 Parquet 資料檔。Iceberg Catalog (AWS Glue / REST / Nessie)Table Metadata (v3.metadata.json - Schema, 分區規格, 快照清單)Manifest List File (snap-101.avro - 記錄多個 Manifest 檔案)Manifest File 1 (記錄 Min/Max 統計)Manifest File 2 (記錄 Min/Max 統計)data1.parquet (資料列)data2.parquet (資料列)

為什麼 Iceberg 查詢速度極快?

  • 精確剪枝(Pruning):查詢引擎無需掃描任何 S3 目錄,只需在記憶體中讀取 Manifest 的 Min/Max 統計資訊,即可直接過濾掉 99% 無關的 Parquet 檔案!
  • 隱藏分區(Hidden Partitioning):工程師可以用 timestamp 分區,用戶查詢 WHERE event_time >= '2026-09-01' 時,Iceberg 自動在底層轉換為天級分區剪枝,防止因忘記指定分區欄位而引發全表全量掃描。

3. Delta Lake 底層結構:交易日誌與 Checkpoint

Delta Lake 以 _delta_log 目錄下的 JSON 事務日誌為核心:

_delta_log/
├── 00000000000000000000.json  (Commit 0: 建立表格,寫入 2 個 Parquet)
├── 00000000000000000001.json  (Commit 1: 刪除 1 個 Parquet,新增 1 個 Parquet)
├── ...
└── 00000000000000000010.checkpoint.parquet (每 10 次 Commit 壓縮為一個 Checkpoint)
  • 時間旅行(Time Travel):只需重放從 0 到指定 Commit 的交易日誌,即可精確重現歷史任意時間點的表格狀態(SELECT * FROM table VERSION AS OF 5)。

4. Apache Hudi 特化模式:Merge-on-Read (MOR)

Hudi 專為高頻即時寫入(CDC 入湖)打造了 MOR(讀時合併) 模式:

Apache Hudi Merge-on-Read (MOR) 即時讀寫架構圖展示即時寫入追加 Avro Delta 日誌,查詢端可選擇只讀 Parquet 或動態合併 Parquet+Avro,非同步 Worker 執行壓實。即時寫入流 (Flink / Spark)基礎列式檔案 + 增量行式日誌 (MOR 儲存層)• base_data.parquet (歷史歷史快照)• delta_log.avro (即時 Append 追加日誌,極速入湖!)Read Optimized 查詢只讀 Parquet 檔案毫秒級響應・微小延遲Snapshot Query (即時)動態合併 Parquet + Avro100% 嚴格最新資料Compaction Worker非同步背景壓縮壓實合併產出全新 Parquet

5. 架構選型指南

  • 選 Apache Iceberg:如果你的企業是多引擎架構(既用 Spark 跑 ETL,又用 Trino / Presto 做互動分析,還用 Flink / StarRocks 查即時報表),Iceberg 的生態相容性與元數據設計是目前業界公認的最佳選擇。
  • 選 Delta Lake:如果團隊深度依賴 Databricks 生態與 Apache Spark,Delta Lake 的開箱即用體驗與優化最為絲滑。
  • 選 Apache Hudi:如果業務有著極端頻繁的 MySQL / PostgreSQL CDC 逐行 Upsert / Delete 增量同步需求。