开发在线OLAP数据库DuckDB的团队提出了一种解决方案，旨在解决他们所称的困扰基于Databricks、Snowflake、Google等技术实现的湖仓(Lakehouse)架构的“微小变更”问题。

　　这家开源RDBMS背后的咨询与支持公司，继去年发布宣言后，刚刚推出了其DuckLake湖仓格式的首个生产就绪版本。2025年5月发布的DuckLake宣言承诺将重新构想在单一系统上整合数据仓库与数据湖的概念。

　　本质上，该宣言提议利用关系型数据库管理系统(RDBMS)来管理基于Apache Iceberg和Delta Lake(由Databricks推出，Linux基金会管理)等通用开放表格式的湖仓系统中的元数据，并向工程师展示了如何使用PostgreSQL、SQLite或DuckDB作为该任务的目录数据库。

　　随着本周发布的DuckLake v1.0(一种已准备就绪的湖仓格式规范)，这些数据库专家正展示如何利用该数据库解决基于开放表格式的湖仓系统中常见的所谓“微小变更”问题——这类系统通常依赖Parquet文件格式。

　　DuckDB Labs联合创始人兼首席执行官Hannes Mühleisen向The Register表示：“当你对表进行微小修改(例如添加单行数据)时，这会影响数据湖的性能。因为基于其工作原理，系统必须生成一个仅包含一行数据的新文件，随后还需写入大量元数据……最后目录系统还需进行更新。这非常低效，因为像Parquet这样的格式其实并不适合存储单行数据，它们更适合存储数百万行数据;而从对象存储中检索所有这些微小文件极其低效，因为你需要进行大量数据传输。”

　　Mühleisen表示，DuckLake的方法是利用元数据关系型数据库管理系统(RDBMS)将这些微小变更批量处理，然后以相对较大的数据块传输到Parquet中。Mühleisen同时也是阿姆斯特丹数学与信息学中心(Centrum Wiskunde & Informatica)的教授。

　　“其他数据湖格式与 DuckLake 之间的核心设计差异在于，我们直接采用了数据库架构，并且敢于充分利用它。我们将数据湖的所有元数据都存放在 DuckLake 数据库的目录中，清晰掌握有哪些表、哪些文件、它们之间的关联关系，以及随时间发生的所有变更。现在，当你新增一行数据时，我们不会往对象存储里再写入新文件，而是直接将这行数据添加到数据库的表里。这里的核心理念是：像 PostgreSQL、DuckDB 这类数据库系统，在处理小规模数据变更方面，远比对象存储高效得多。”他表示。

　　他解释道：“元数据数据库会存储诸如行级增删等微小变更，直到最终将这些变更‘刷新’回Parquet并生成一个相对较大的文件，而在此过程中‘对用户完全透明’。”

　　在伴随1.0版本发布的博客文章中，DuckDB Labs首席工程师 Pedro Holanda表示，公司的基准测试显示，与开源表格式Iceberg相比，其查询速度提升了926倍，数据摄取速度提升了105倍。

　　“当初我写博文说我们实现了上千倍的性能提升时，还心想‘这下肯定有人要不满了’，结果根本没人生气。大家的反应都是：‘这确实是个实实在在的问题。’甚至还有人说，我这是在用架构‘耍小聪明’。而这恰恰就是核心所在 —— 用更优秀的设计，实现这种‘取巧式’的突破。”他向The Register透露。

　　尽管如此，工程师们仍在围绕现有的湖仓架构进行开发，并试图解决相同的问题。在去年DuckLake发布之际，AWS资深人士、AI数据库公司LanceDB的软件工程师Jake Ye在博客中指出，业界正“日益围绕基于JSON的协议作为互操作性的基础而趋于统一”。他同时指出，由于缺乏良好的结构化可扩展性、版本控制和传输层分离，DuckLake在推广过程中面临诸多挑战。

　　Snowflake首席工程师Russell Spitzer当时向我们透露，许多项目在Iceberg的采用上“已取得相当大的进展，且Iceberg社区正在着手解决元数据目录问题。DuckDB仍处于起步阶段，而现有厂商已在市场上站稳脚跟。DuckLake这一理念能否成功落地，恐怕还需要一段时间才能见分晓。”