去年5月，DuckDB团队扔出一份宣言，核心观点让不少人愣了一下——把lakehouse的所有元数据存进数据库，而不是散落在对象存储的文件堆里。当时业内主流做法是把元数据写成JSON、manifest文件，像Delta Lake、Apache Iceberg都是这个路数。DuckDB团队偏说：这不对。
将近一年过去，他们交卷了。DuckLake v1.0正式发布，带着生产级承诺和向后兼容保证。参考实现——ducklake扩展——已经随DuckDB v1.5.2上线。
元数据进数据库，到底解决什么
先搞清楚lakehouse格式的基本功课。它让你在对象存储（S3、GCS、Azure Blob这些）上存数据，却能像查数据库一样访问。Delta Lake配Unity Catalog、Iceberg配Lakekeeper，都是这个玩法。
DuckLake的岔路口在于：元数据去哪。
传统做法是把表结构、分区信息、事务日志写成文件，跟数据文件放一起。查询时先读这些文件，再决定读哪些数据。DuckLake说，这些元数据应该住在真正的数据库里——SQLite、PostgreSQL、甚至DuckDB自己都能当这个"目录"（catalog）。
好处是显性的。SQL原生支持的事务、索引、主键约束，现在能直接用在元数据层。多个DuckDB实例可以共享同一个PostgreSQL目录，实现所谓的"multiplayer"模式——各查各的，但看到的表状态是一致的。
更隐蔽的好处是部署成本。只要有个存储桶和一个HTTPS端点，就能搭一个免认证的只读lakehouse。不需要额外跑元数据服务，目录就是数据库。
一年迭代：从草图到生产
v1.0的规格书（specification）定了几个硬指标：元数据表的Schema、支持的数据类型、以及如何根据目录信息定位实际数据。参考实现必须全部覆盖。
过去12个月的更新清单里，有几项值得单独拎出来。
零拷贝挂载Parquet。已有的Parquet文件不用deep copy，直接注册进DuckLake就能查。这对存量数据迁移是刚需。
Iceberg兼容层。不是重新发明轮子，而是让Iceberg表能被DuckLake读取。生态位上留了后门。
Geometry和Variant类型。地理空间数据和半结构化数据的支持补上了，覆盖场景更广。
社区反馈的速度超出预期。ducklake扩展目前在DuckDB核心扩展的下载量排名里进了前十——对于一个诞生不到一年的项目，这个渗透率不常见。
三个被验证的用法
团队自己总结了几个跑得通的场景。
流式入湖。利用目录数据库的"inlining"能力，小批量更新先写进目录，再异步刷到对象存储。 latency从分钟级降到秒级。
极简只读服务。存储+HTTPS端点，无认证、无状态、无额外服务。适合公开数据集分发。
多实例协作。多个DuckDB进程连同一个PostgreSQL目录，各跑各的分析，但元数据变更全局可见。数据仓库的并发查询难题，用数据库解决数据库的问题。
路线图里还藏着野心。规格书留了版本扩展的口子，未来新增元数据表不会破坏旧客户端。参考实现也会跟进更多目录后端——现在只有SQLite、PostgreSQL、DuckDB三种，显然不够。
一个悬而未决的问题是：DuckLake会不会成为第四种主流lakehouse格式？Delta Lake有Databricks背书，Iceberg有Netflix起源和Apache基金会，Hudi有Uber场景打磨。DuckLake的筹码是DuckDB的装机量，以及"元数据即数据库"这个足够简洁的抽象。
生产就绪的声明已经发出。接下来要看的是，有多少团队愿意把现有lakehouse迁过来——或者更现实地说，新项目会不会默认选它。
热门跟贴