2026 年資料庫湖倉一體（Lakehouse）實踐：Delta Lake 與 Apache Iceberg 比對
二、Delta Lake 深度解析：從事務日誌到 Liquid Clustering
Delta Lake 的設計哲學可以用一句話概括：用一個簡單、可自我實作的日誌，把物件儲存上的一堆 Parquet 檔案變成可靠的表。理解這一點，就能理解它所有的優點與限制。
核心架構：事務日誌（_delta_log）與檔案層級的取捨
一張 Delta 表的目錄結構大致是這樣：資料檔案以 Parquet 形式散落在表目錄下，旁邊有一個 _delta_log 子目錄，裡面存放兩種檔案——JSON 格式的提交日誌（例如 00000000000000000010.json），以及每隔若干次提交產生的 Parquet 檢查點（checkpoint）。此外還有一個 _last_checkpoint 檔案，指出最新的檢查點位置。
每一次寫入交易，本質上就是產生一個新的 JSON 提交檔案，內容包含 add（新增哪些資料檔案）、remove（移除哪些）、metadata（Schema、分區設定變更）、protocol（讀寫協議版本）、txn（冪等交易識別碼）等動作。引擎讀表時，先讀檢查點，再依序套用之後的 JSON 日誌，就能還原出「這張表目前由哪些檔案組成」。
這個設計的優點非常明顯：概念單純、實作門檻低、除錯直觀。任何一個工程師打開 _delta_log，用肉眼就能看懂哪一筆交易做了什麼，這對事故排查的價值極高。Delta Kernel（以 Rust 實作的讀寫核心）正是靠這個簡單模型，讓 Trino、Flink 等引擎不必依賴 Spark 就能原生讀寫 Delta。
但它的限制也源自同一個設計。第一，日誌是「線性」的。要規劃一次查詢，引擎需要知道所有相關資料檔案的位置與統計資訊，而這些資訊散落在多個 JSON 與檢查點裡，讀取效率不如 Iceberg 的分層 manifest。當表累積了數十萬次提交，即使有檢查點，載入中繼資料仍可能有可觀延遲。第二，並發寫入採樂觀鎖。兩個 writer 同時提交時，其中一方可能因為版本衝突而失敗，需要重試；在物件儲存上，這個衝突偵測依賴的是「建立同名檔案時的原子性」，理論上可行，但在高頻寫入場景需要仔細調校。第三，列出檔案（list）操作的壓力。若沒有啟用 Delta 的檔案清單模式，部分操作需要列舉目錄，在雲端會轉換成 API 呼叫成本。
Delta 的殺手級功能：Deletion Vectors、Liquid Clustering 與 UniForm
如果說日誌架構是 Delta 的骨架，那以下幾項功能就是它在 2026 年仍具競爭力的肌肉。
Deletion Vectors（刪除向量）。傳統的 DELETE 或 UPDATE 需要把整個 Parquet 檔案重寫一遍，代價高昂。刪除向量讓引擎只記錄「這個檔案裡第幾個 row 被刪掉了」，用一個位元圖（bitmap）表示，實際重寫延後到壓實（compaction）時再處理。對於高頻小量更新的維度表，這能帶來數量級的成本下降。
Liquid Clustering。過去我們用靜態分區加 Z-Order 來加速查詢，但分區一旦定錯就難以回頭，Z-Order 又需要定期重跑。Liquid Clustering 改成「宣告要按哪些欄位聚簇」，由系統在寫入與背景維護時自動調整資料分佈，並且支援欄位組合的演化。對那些一開始不確定查詢模式的團隊來說，這大幅降低了「選錯分區策略」的風險。
UniForm。這是 Databricks 最聰明的一步棋：在寫入 Delta 的同時，自動產生對應的 Iceberg 中繼資料。結果是同一份 Parquet 檔案，Delta 引擎與 Iceberg 引擎都能讀。這讓「選 Delta 還是 Iceberg」在某些場景下不再是非此即彼，而是可以「以 Delta 為主寫入、以 Iceberg 為對外介面」。
其他值得注意的還包括 Change Data Feed（行級變更追蹤，是 CDC 場景的基礎）、Type Widening（數值型別放寬不必重寫資料）、Variant 型別（半結構化資料的原生支援），以及在特定地理區域與欄位上的 Collation 支援（對多語言排序很重要）。
Delta 在 2026 年的生態現況
客觀地說，Delta 在 2026 年仍然是由 Databricks 主導的專案，即使它已完全開源、且透過 Delta Kernel 降低了整合門檻。它的主場非常清楚：Databricks 平台本身，以及深度使用 Spark 生態的組織。在這些環境裡，Delta 的效能調校（配合 Photon 引擎、預測式 I/O、自動壓實）與功能迭代速度，通常領先其他組合同步。
在 Databricks 之外，Trino、Flink、Spark、Athena（透過 Lake Formation 或外部整合）、Snowflake（透過外部表）都能讀 Delta，但「深度寫入支援」與「治理整合」的成熟度，普遍落後於它們對 Iceberg 的支援。這是選型時必須誠實面對的事實：Delta 的跨引擎體驗，在 2026 年已經及格，但還不是它的強項。
三、Apache Iceberg 深度解析：分層中繼資料與目錄之戰
Iceberg 的設計哲學與 Delta 幾乎相反：用更複雜、但更具擴展性的多層中繼資料結構，換取大規模、高併發、跨引擎場景下的效率與彈性。
核心架構：中繼資料樹與快照隔離
Iceberg 的中繼資料是一棵樹。最上層是 Catalog，它指向「當前表的最新 metadata 檔案」（通常叫 metadata.json，檔名帶有版本號）。這個 metadata 檔案記錄了 Schema、分區規格、排序規則、屬性，以及一份「快照（snapshot）清單」。每個快照指向一個 manifest list，manifest list 再指向多個 manifest 檔案，每個 manifest 檔案裡記載著一批資料檔案的路徑、大小與欄級統計資訊（min/max、null 數量等）。
這套結構帶來幾個關鍵好處。查詢規劃不必列出物件儲存，只要讀中繼資料樹就能完成分區裁剪與檔案裁剪，這在雲端的成本效益極高。分區可以演進，因為分區規格是記錄在 metadata 裡的，改分區不需要重寫歷史資料，舊資料仍用舊規格解讀，Iceberg 的「隱藏分區」讓使用者查詢時不必知道實體分區欄位。快照天然支援時間旅行與回滾，每個快照就是一個一致的表格狀態，這對資料回溯、稽核、以及「出錯時快速回滾」非常實用。
缺點同樣來自這套結構。中繼資料本身需要維護：快照會不斷累積，必須定期執行 expire snapshots、rewrite manifests、清除孤兒檔案，否則會拖慢規劃速度、也浪費儲存成本。寫入路徑較複雜，一個提交要寫 manifest、manifest list、metadata，步驟多、對 Catalog 的原子性操作依賴高。並發控制依賴 Catalog 的 compare-and-swap，這也是為什麼 Catalog 的選擇對 Iceberg 如此關鍵——它是整個一致性模型的地基。
Iceberg v3 規格與 2026 年的新特性
Iceberg 的規格演進一直是社群治理的典範，v3 規格在 2025 年前後陸續被主流引擎實作，2026 年已成為新建表的常見選擇。幾個值得注意的方向：
目錄之戰：REST Catalog 成為 2026 年的共識
如果說 Iceberg 的資料檔案格式是它的身體，那 Catalog 就是它的神經中樞。過去最常見的組合是 Hive Metastore，但 HMS 在雲端時代暴露出明顯限制：它不是為物件儲存設計的、並發能力有限、跨雲部署困難、權限模型老舊。
這催生了 2024 至 2026 年的目錄百花齊放：Snowflake 的 Polaris（已開源）、Databricks 的 Unity Catalog（開源版本 OSS Unity Catalog）、AWS 的 S3 Tables（託管式 Iceberg 目錄）、Apache Gravitino、Lakekeeper、Nessie 等。它們的共同交會點是 Iceberg REST Catalog 規範——只要實作這個規範，任何支援它的引擎（Spark、Trino、Flink、Doris、StarRocks、PyIceberg）就能連上，不必為每個目錄寫專屬連接器。
這件事的實際意義是：2026 年選 Iceberg，你其實是在做「雙重選型」——選表格式，同時選目錄供應商。目錄決定了你的治理邊界、跨引擎可見性、以及未來換引擎的遷移成本。這也是為什麼很多團隊在 2026 年的實務結論是：「表格式選 Iceberg，目錄選一個有商業支援的 REST Catalog。」
四、正面對決：Delta Lake 與 Apache Iceberg 的八個維度比對
前面兩章分別拆解了各自的架構，接下來我們把它們放在同一張桌子上比較。以下先給一張總覽表，再逐項展開。
維度
Delta Lake
Apache Iceberg
中繼資料結構
線性 JSON 日誌 + 定期檢查點
分層樹狀結構（metadata → manifest list → manifest）
查詢規劃效率
需載入日誌，大表時延遲較明顯
讀中繼資料樹即可，欄級統計裁剪效率高
並發寫入
樂觀鎖，衝突時重試
依賴目錄的 CAS，跨引擎並發較成熟
分區演化
支援，搭配 Liquid Clustering 更彈性
隱藏分區、規格演化為原生設計
串流與 CDC
Change Data Feed 成熟，Spark 串流體驗佳
增量讀取需靠引擎或附加元件，社群方案多元
跨引擎支援廣度
及格，Databricks 外以讀取為主
極廣，幾乎所有主流引擎皆第一級支援
治理與權限
與 Unity Catalog 整合最完整
依目錄而定，REST Catalog 生態多元
維運負擔
壓實與檢查點維護相對單純
需主動管理快照過期與 manifest 重寫
表格格式與中繼資料管理
兩者都把資料存在 Parquet 檔案裡，差異在於「如何描述這些檔案」。Delta 的答案是一條線性的日誌，優點是可讀性極高、除錯容易、實作簡單；缺點是當表非常大且提交次數極多時，載入中繼資料的成本會逐漸浮現，必須靠檢查點與日誌清理來控制。Iceberg 的答案是一棵分層的樹，優點是查詢規劃可以只看必要的 manifest、欄級統計資訊完整、分區演化自然；缺點是中繼資料檔案數量會隨快照累積而膨脹，需要主動維運。
如果用一句話總結：Delta 的中繼資料是「好懂但會長大」，Iceberg 的中繼資料是「高效但要好養」。小型團隊或表數量不多的場景，Delta 的維護負擔明顯較輕；資料規模到 PB 級、表數量上千、且需要頻繁做檔案裁剪的場景，Iceberg 的分層設計優勢會愈來愈明顯。
寫入效能與並發控制
在單一 writer 或低衝突的批次寫入場景，兩者效能差距通常在可接受範圍內，真正的差異出現在高並發寫入。Delta 採樂觀鎖，多個 writer 同時提交時，後到者發現版本已被推進就得重試；在 Spark 這種以批次為單位的寫入模式下問題不大，但在數十個串流作業同時寫同一張表的場景，重試風暴是需要設計的。
Iceberg 把並發控制的責任交給 Catalog，透過 compare-and-swap 保證「只有一個人能推進 metadata 指標」。這在多引擎、多團隊共用一張表的情境下更穩健，代價是你必須有一個可靠且支援 CAS 的 Catalog——如果 Catalog 本身是效能瓶頸或不可靠，整個寫入路徑都會受影響。2026 年的實務建議是：如果預期有大量並發寫入或跨引擎同時寫入，Iceberg 搭配成熟的 REST Catalog 是較穩的選擇；如果寫入集中在單一平台（例如 Databricks）且以 Spark 為主，Delta 的體驗更順。
讀取效能與查詢引擎支援
讀取路徑上，Iceberg 的優勢來自兩點：一是查詢規劃不必列舉目錄，二是 manifest 裡的欄級統計可以做更細緻的檔案裁剪。對於掃描大量小檔案、或查詢條件集中在少數欄位的分析型工作負載，這些優勢會直接反映在延遲與雲端 API 成本上。
Delta 在讀取上並非劣勢方，尤其搭配 Databricks 的 Photon 引擎與預測式 I/O 時，端到端效能常常領先；但這種領先很大程度來自在單一平台內的深度整合，一旦跨到 Trino 或 BigQuery 等外部引擎，Iceberg 的通用性就體現出來。對 2026 年多數組織而言，「哪個引擎讀得最快」往往不是決策關鍵，「哪個引擎讀得動」才是。
串流與增量處理
Delta 在這方面有先天優勢，因為它就誕生於 Spark 生態，Change Data Feed 提供行級的變更查詢，配合 Structured Streaming 的 readStream 可以很自然地做增量 ETL。對以 Spark 為核心的團隊，這是實打實的生產力優勢。
Iceberg 的增量讀取過去需要靠引擎實作或額外工具，近年在 v3 規格與各引擎的推進下已明顯改善，社群也有多種開源方案處理 CDC 落地。整體而言，Iceberg 的串流體驗在 2026 年已可用，但 Delta 在 Spark 世界裡仍然是「原生順手」的那一個。
治理、安全與多模態資料
治理是選型中最容易被低估、卻最常導致專案失敗的一環。Delta 與 Unity Catalog 的整合是教科書級的緊密：欄級遮罩、列級過濾、血緣追蹤、跨工作區共享都在同一個治理層內完成。這對需要合規稽核的金融、醫療產業是很大的加分。
Iceberg 的治理則取決於你選的目錄。REST Catalog 生態的優點是選擇多、可替換，缺點是治理能力參差不齊，需要仔細評估每個目錄對欄級權限、稽核日誌、跨雲一致性的支援程度。2026 年的一個明顯趨勢是：主流目錄供應商都在往 REST 規範靠攏，同時把治理能力當成差異化重點，這對買方是好事，但也意味著選型時要花更多力氣做 PoC。
生態系與廠商中立性
這是 Iceberg 最明顯的優勢。它由 Apache 基金會治理，貢獻者來自 Netflix、Apple、AWS、Google、Snowflake、Databricks 等眾多公司，沒有單一廠商能主導規格走向。對擔心被單一供應商鎖定的組織，這是強而有力的理由。
Delta 雖然同樣開源，但社群結構與發展節奏仍以 Databricks 為核心。這不是缺點，只是不同——如果你本來就是 Databricks 客戶，這個「集中」帶來的是更快的新功能與更好的支援；如果你是多雲、多引擎的環境，這個「集中」就可能是風險。
維運成本與人才供給
維運成本要分兩塊看。Delta 的日常維運相對單純：設定自動壓實、監控日誌成長、定期清理舊版本即可。Iceberg 需要更主動的維護：排程 expire snapshots、rewrite manifests、清理孤兒檔案，否則查詢規劃會逐漸變慢。這些工作大多有現成工具，但需要有人負責。
人才方面，2026 年的市場狀況是：懂 Spark 與 Delta 的工程師數量龐大，幾乎是資料工程師的基本技能；懂 Iceberg 的工程師數量正在快速成長，但深度理解 Catalog 並發模型、能處理 manifest 調優的人仍然稀缺。如果你的團隊從未接觸 Iceberg，導入時要預留學習曲線，尤其是維運層面。
AI／向量檢索的支援
這是 2026 年最具體的新戰場。兩種格式都在往「湖倉原生支援 AI 工作負載」的方向走，但路徑不同。
Delta 陣營的策略是把向量索引與特徵儲存整合進 Unity Catalog 生態，讓 RAG 管線可以直接對 Delta 表做向量檢索，並沿用既有的權限與血緣。對已經在 Databricks 上做 ML 的團隊，這條路徑最短。
Iceberg 陣營的策略則是「讓所有引擎都能用同一份 AI 資料」。由於主流向量資料庫與查詢引擎陸續支援 Iceberg，你可以把嵌入向量直接存進湖倉表，讓不同 AI 應用各自用最適合的引擎讀取。這種開放性是 Iceberg 在 AI 時代的核心敘事。
實務上的建議是：如果你的 AI 管線已經被某個平台鎖定，選那個平台最順的格式；如果 AI 應用會由多個團隊、多種框架開發，Iceberg 的通用性會在未來兩年省下大量重複工。
五、選型決策框架：什麼情況該選誰
看完八個維度，你可能還是想問：「所以到底選哪個？」以下提供一套可操作的判斷方式。
四種典型場景的選型建議
場景一：深度使用 Databricks，團隊以 Spark 為主。直接選 Delta。你會在效能調校、功能迭代、治理整合上獲得最大紅利，UniForm 還能讓外部 Iceberg 讀者存取同一份資料，兼顧開放性。
場景二：多雲、多引擎並存，需要單一資料副本被所有系統讀取。選 Iceberg。這是它的主場：查詢規劃效率、跨引擎支援廣度、廠商中立性都是決定性優勢。記得同步把 Catalog 選型當成專案的一部分。
場景三：AWS 生態為主，想降低自建維運負擔。選 Iceberg，並優先評估 AWS S3 Tables 或 Lake Formation 這類託管目錄。這能同時解決表格式與目錄兩個問題，讓團隊把精力放在資料本身。
場景四：既有 Hive 資料倉儲要現代化，但不想一次全搬。可以先用 Iceberg 的隱藏分區與規格演化逐步遷移，因為它對既有 Hive 表的共存與逐步轉換最友善；也可以考慮以 XTable 產生雙格式中繼資料，讓舊路徑與新路徑並行。
混合策略：UniForm 與 XTable 的互通之道
2026 年最被低估的一招，是「不選，但要選對主從」。UniForm 讓 Delta 表自動產生 Iceberg 中繼資料，XTable（Apache 專案）則提供更通用的雙向轉換，讓 Delta、Iceberg、Hudi 之間可以產生對應中繼資料。實務上常見的做法是：
這種混合策略的關鍵前提是：資料檔案本身只有一份。UniForm 與 XTable 都是「中繼資料轉換」，不是資料複製，這也是它們相對於「雙寫兩份資料」的核心價值。唯一的代價是，某些進階功能（例如某種格式獨有的刪除向量或聚簇策略）在跨格式讀取時可能無法完整呈現，需要在設計時就避開。
六、實戰落地建議與常見陷阱
選型只是開始，真正的坑在落地之後。以下三個環節是最常見的翻車點。
小檔案與壓實策略
湖倉最常見的效能殺手就是小檔案。串流寫入、高頻微批次、以及頻繁的 MERGE，都會產生大量小檔案，導致查詢規劃變慢、物件儲存請求成本上升。兩種格式都提供了壓實工具（Delta 的 OPTIMIZE、Iceberg 的 rewrite_data_files），但關鍵是要有自動化排程與監控，而不是等人發現查詢變慢才手動處理。
實務建議：監控「每個分區或聚簇鍵的檔案平均大小」，設定閾值自動觸發壓實；對跨越延遲敏感度不同的表，套用不同的壓實頻率。Delta 的 Liquid Clustering 與 Iceberg 的分區演化都能降低「一開始選錯結構」的風險，但都不能取代壓實。
Catalog 治理與權限設計
無論選哪種格式，Catalog 都是治理的樞紐。常見錯誤包括：把 Catalog 當成純技術元件，忽略它的權限模型；沒有區分「生產目錄」與「實驗目錄」，導致沙盒表與正式表混在一起；以及沒有為跨團隊共用表設計命名空間與所有者制度。
如果選 Iceberg，建議在專案初期就明確回答三個問題：用哪個 Catalog（自建、雲廠商託管、或第三方）、它支援哪些權限粒度、以及未來若要更換 Catalog，遷移路徑是什麼。這三個問題的答案會直接影響你未來三年的維運成本。
成本控制的五個觀察點
湖倉的成本不像傳統倉儲那樣直觀，因為它分散在儲存、API 請求、運算與中繼資料維護四個地方。建議持續監控以下指標：
小檔案比例：直接影響查詢掃描效率。
時間旅行保留策略：保留 90 天版本很浪漫，但成本也是真的。
跨區與跨雲的資料傳輸：多雲策略下最容易失控的一項。
七、結語：2026 年之後，選型的本質是選治理與生態
回到最初的問題：Delta Lake 還是 Apache Iceberg？如果你只讀到這裡，請記住三句話。
第一，兩者的技術差距正在縮小，生態差距仍在。刪除向量、聚簇、增量讀取這些曾經的差異點，雙方都在補齊；但跨引擎支援廣度、目錄生態的多元性、以及廠商中立性，Iceberg 仍明顯領先，而 Databricks 平台內的深度整合，Delta 仍明顯領先。
第二，真正的決策變數不是格式，而是你的資料要服務誰。如果資料主要服務單一平台內的團隊，選那個平台最順的格式；如果資料要服務多雲、多引擎、多團隊，選通用性最高的那個。
第三，混合策略是 2026 年最務實的答案。UniForm 與 XTable 讓「資料只存一份、中繼資料多種呈現」成為現實。你可以在寫入端選效率最高的格式，在讀取端給所有消費者他們最熟悉的介面。
湖倉一體發展到 2026 年，已經過了「哪個格式會贏」的階段，進入「哪個治理與生態組合最適合我」的階段。表格式是手段，不是目的。真正決定成敗的，是你怎麼管理目錄、怎麼控制成本、怎麼讓資料在正確的時間被正確的人與系統讀到。把這三件事做好，選 Delta 或 Iceberg，其實都不會太差。