去年5月，DuckDB團(tuán)隊(duì)扔出一份宣言，核心觀點(diǎn)讓不少人愣了一下——把lakehouse的所有元數(shù)據(jù)存進(jìn)數(shù)據(jù)庫(kù)，而不是散落在對(duì)象存儲(chǔ)的文件堆里。當(dāng)時(shí)業(yè)內(nèi)主流做法是把元數(shù)據(jù)寫(xiě)成JSON、manifest文件，像Delta Lake、Apache Iceberg都是這個(gè)路數(shù)。DuckDB團(tuán)隊(duì)偏說(shuō)：這不對(duì)。

將近一年過(guò)去，他們交卷了。DuckLake v1.0正式發(fā)布，帶著生產(chǎn)級(jí)承諾和向后兼容保證。參考實(shí)現(xiàn)——ducklake擴(kuò)展——已經(jīng)隨DuckDB v1.5.2上線。

元數(shù)據(jù)進(jìn)數(shù)據(jù)庫(kù)，到底解決什么

先搞清楚lakehouse格式的基本功課。它讓你在對(duì)象存儲(chǔ)（S3、GCS、Azure Blob這些）上存數(shù)據(jù)，卻能像查數(shù)據(jù)庫(kù)一樣訪問(wèn)。Delta Lake配Unity Catalog、Iceberg配Lakekeeper，都是這個(gè)玩法。

DuckLake的岔路口在于：元數(shù)據(jù)去哪。

傳統(tǒng)做法是把表結(jié)構(gòu)、分區(qū)信息、事務(wù)日志寫(xiě)成文件，跟數(shù)據(jù)文件放一起。查詢時(shí)先讀這些文件，再?zèng)Q定讀哪些數(shù)據(jù)。DuckLake說(shuō)，這些元數(shù)據(jù)應(yīng)該住在真正的數(shù)據(jù)庫(kù)里——SQLite、PostgreSQL、甚至DuckDB自己都能當(dāng)這個(gè)"目錄"（catalog）。

好處是顯性的。SQL原生支持的事務(wù)、索引、主鍵約束，現(xiàn)在能直接用在元數(shù)據(jù)層。多個(gè)DuckDB實(shí)例可以共享同一個(gè)PostgreSQL目錄，實(shí)現(xiàn)所謂的"multiplayer"模式——各查各的，但看到的表狀態(tài)是一致的。

更隱蔽的好處是部署成本。只要有個(gè)存儲(chǔ)桶和一個(gè)HTTPS端點(diǎn)，就能搭一個(gè)免認(rèn)證的只讀lakehouse。不需要額外跑元數(shù)據(jù)服務(wù)，目錄就是數(shù)據(jù)庫(kù)。

一年迭代：從草圖到生產(chǎn)

v1.0的規(guī)格書(shū)（specification）定了幾個(gè)硬指標(biāo)：元數(shù)據(jù)表的Schema、支持的數(shù)據(jù)類型、以及如何根據(jù)目錄信息定位實(shí)際數(shù)據(jù)。參考實(shí)現(xiàn)必須全部覆蓋。

過(guò)去12個(gè)月的更新清單里，有幾項(xiàng)值得單獨(dú)拎出來(lái)。

零拷貝掛載Parquet。已有的Parquet文件不用deep copy，直接注冊(cè)進(jìn)DuckLake就能查。這對(duì)存量數(shù)據(jù)遷移是剛需。

Iceberg兼容層。不是重新發(fā)明輪子，而是讓Iceberg表能被DuckLake讀取。生態(tài)位上留了后門(mén)。

Geometry和Variant類型。地理空間數(shù)據(jù)和半結(jié)構(gòu)化數(shù)據(jù)的支持補(bǔ)上了，覆蓋場(chǎng)景更廣。

社區(qū)反饋的速度超出預(yù)期。ducklake擴(kuò)展目前在DuckDB核心擴(kuò)展的下載量排名里進(jìn)了前十——對(duì)于一個(gè)誕生不到一年的項(xiàng)目，這個(gè)滲透率不常見(jiàn)。

三個(gè)被驗(yàn)證的用法

團(tuán)隊(duì)自己總結(jié)了幾個(gè)跑得通的場(chǎng)景。

流式入湖。利用目錄數(shù)據(jù)庫(kù)的"inlining"能力，小批量更新先寫(xiě)進(jìn)目錄，再異步刷到對(duì)象存儲(chǔ)。 latency從分鐘級(jí)降到秒級(jí)。

極簡(jiǎn)只讀服務(wù)。存儲(chǔ)+HTTPS端點(diǎn)，無(wú)認(rèn)證、無(wú)狀態(tài)、無(wú)額外服務(wù)。適合公開(kāi)數(shù)據(jù)集分發(fā)。

多實(shí)例協(xié)作。多個(gè)DuckDB進(jìn)程連同一個(gè)PostgreSQL目錄，各跑各的分析，但元數(shù)據(jù)變更全局可見(jiàn)。數(shù)據(jù)倉(cāng)庫(kù)的并發(fā)查詢難題，用數(shù)據(jù)庫(kù)解決數(shù)據(jù)庫(kù)的問(wèn)題。

路線圖里還藏著野心。規(guī)格書(shū)留了版本擴(kuò)展的口子，未來(lái)新增元數(shù)據(jù)表不會(huì)破壞舊客戶端。參考實(shí)現(xiàn)也會(huì)跟進(jìn)更多目錄后端——現(xiàn)在只有SQLite、PostgreSQL、DuckDB三種，顯然不夠。

一個(gè)懸而未決的問(wèn)題是：DuckLake會(huì)不會(huì)成為第四種主流lakehouse格式？Delta Lake有Databricks背書(shū)，Iceberg有Netflix起源和Apache基金會(huì)，Hudi有Uber場(chǎng)景打磨。DuckLake的籌碼是DuckDB的裝機(jī)量，以及"元數(shù)據(jù)即數(shù)據(jù)庫(kù)"這個(gè)足夠簡(jiǎn)潔的抽象。

生產(chǎn)就緒的聲明已經(jīng)發(fā)出。接下來(lái)要看的是，有多少團(tuán)隊(duì)愿意把現(xiàn)有l(wèi)akehouse遷過(guò)來(lái)——或者更現(xiàn)實(shí)地說(shuō)，新項(xiàng)目會(huì)不會(huì)默認(rèn)選它。