對於剛接觸大數據架構的工程師來說，理解 Data Lakehouse（湖倉一體）的核心挑戰之一，就是如何管理元數據 Metadata。元數據簡單來說就是關於數據的數據，例如一張表包含哪些欄位、數據存放在哪個路徑、目前的版本號是多少。
在傳統的 Data Lake 格式如 Apache Iceberg 或 Delta Lake 中，元數據通常是以文件的形式存放在物件儲存（Object Storage，例如 AWS S3）中。雖然這種做法能讓儲存幾乎無限擴展，但會帶來一個棘手的問題：當你頻繁地進行小規模更新、刪除或插入時，系統會產生大量的小元數據文件。這會導致查詢時需要掃描大量文件才能找到實際數據，造成嚴重的性能下降，這在業界被稱為小檔案問題 Small File Problem。
DuckLake 1.0 的出現就是為了挑戰這個傳統設計。它的核心觀點非常明確：元數據不應該散落在文件系統中，而應該存放在一個真正的 SQL 資料庫中。
將元數據移至 SQL Catalog 的影響
當我們把元數據從文件轉移到 SQL Catalog（即一個專門管理目錄的資料庫）時，最大的改變在於協調成本的降低。在文件導向的格式中，更新元數據往往需要複雜的文件鎖定或原子性替換操作。而使用 SQL 資料庫後，我們可以利用資料庫原生的事務特性來確保一致性，大幅提升元數據操作的速度。
針對小檔案問題的解決方案：數據內聯 Data Inlining
DuckLake 1.0 引入了一個關鍵功能叫做數據內聯 Data Inlining。在傳統 Lakehouse 中，即使你只更新一行數據，系統可能也得創建一個新的數據文件來記錄這個變更。
數據內聯允許系統將少量的插入、更新或刪除操作直接記錄在 SQL Catalog 資料庫中，而不是立即寫入 S3 的物理文件。當這些變更累積到一定程度（預設閾值為 10 行）後，才會將其合併到主數據文件中。這有效地阻止了小文件的瘋狂增長，讓寫入性能大幅提升。
性能優化與兼容性
除了元數據管理，DuckLake 還針對查詢效率做了幾項優化。首先是排序表 Sorted Tables，讓過濾查詢能更快定位數據。其次是桶分區 Bucket Partitioning，這對於高基數列（High-Cardinality Columns，指重複率低、唯一值極多的欄位，如用戶 ID）非常有用，能避免產生過多的小分區目錄。
為了讓工程師能快速上手，DuckLake 保持了與 Iceberg 類似的特性，並支持刪除向量 Deletion Vectors。刪除向量是一種記錄哪些行已被刪除的輕量化機制，不需要重寫整個數據文件即可實現邏輯刪除。
生態系與未來發展
目前 DuckLake 已經提供 DuckDB 擴展插件，並支持 Apache Spark、Trino、Pandas 和 Apache DataFusion 等主流數據處理框架。對於不想自行維運資料庫的團隊，MotherDuck 則提供了託管服務。
從開發路線圖來看，DuckLake 2.0 將會引入類似 Git 的分支管理功能 Dataset Branching，讓數據工程師可以像管理程式碼一樣對數據集進行分支開發與版本控制，並加入基於角色的權限管理 RBAC。
總結來說，DuckLake 的核心價值在於將元數據的管理權從文件系統移交回資料庫，透過 SQL 的高效能與事務能力，解決了長期困擾 Data Lake 的元數據碎片化問題。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。