DuckLake：用数据库管理元数据，重构Lakehouse的简洁之道

当Lakehouse变得越来越复杂时，DuckDB团队选择了一条回归本质的路

引言：我们为什么需要另一个表格式？

在数据工程领域，Lakehouse（湖仓一体）架构已成为现代数据平台的主流选择。Apache Iceberg、Delta Lake、Hudi等表格式通过"对象存储+元数据层"的方式，试图在数据湖的开放性与数据仓库的性能之间找到平衡点。然而，随着这些系统的演进，我们不得不面对一个现实：复杂性正在吞噬Lakehouse的初衷。 复杂的JSON/AVRO元数据文件、目录服务依赖、小文件问题、元数据查询性能瓶颈...这些痛点让许多团队开始反思：我们是否走错了方向？ 正是在这样的背景下，DuckDB团队推出了DuckLake——一个基于"用数据库管理元数据"这一朴素理念的全新表格式。它不追求功能上的大而全，而是选择回归本质，用最简单的方式解决最核心的问题。

一、现有方案的困境：绕了一圈又回到数据库

1.1 数据湖的"先天不足"

传统的Parquet + 对象存储（如S3）架构确实提供了极好的扩展性和开放性，但缺乏对数据修改、事务一致性、跨表操作等数据库能力的原生支持。这就像拥有一个巨大的文件柜，却没有目录索引——找东西全靠翻。

1.2 现有Lakehouse方案的"过度设计"

为了弥补数据湖的不足，Iceberg、Delta Lake等方案在文件层引入了复杂的元数据系统：

• 元数据文件爆炸：快照文件、manifest文件、统计信息文件...每次操作都会产生新的元数据文件
• 目录服务依赖：最终仍需要引入Hive Metastore、Glue Catalog等外部服务来保证一致性
• 性能瓶颈：元数据查询需要多次请求对象存储，小文件问题导致查询性能下降
• 运维复杂度：元数据文件需要定期清理，否则会拖慢整个系统

核心问题：这些方案试图用文件系统解决数据库的问题，但最终发现还是需要数据库来管理元数据。这就像用Excel管理公司财务，最终还是要用ERP系统一样。

二、DuckLake的核心设计：回归数据库本质

DuckLake的设计哲学可以用一句话概括：

既然最终还是要用数据库管理元数据，不如从一开始就将所有元数据放在SQL数据库中管理

2.1 架构设计：三层分离

DuckLake采用清晰的存储-元数据-计算三层架构：

层级	组件	说明
存储层​	对象存储（S3/GCS）	存储实际数据文件（Parquet格式），保持开放性
元数据层​	SQL数据库（PostgreSQL/DuckDB）	存储所有元数据：表结构、快照、文件统计等
计算层​	DuckDB引擎	通过标准SQL操作数据，支持多种计算引擎

这种设计的巧妙之处在于：将最复杂的元数据管理交给最擅长这件事的组件——数据库。

2.2 元数据管理：一切皆SQL表

在DuckLake中，所有元数据都以标准SQL表的形式存储在数据库中：

-- 表结构元数据
CREATE TABLE ducklake_tables (
    table_id BIGINT PRIMARY KEY,
    table_name VARCHAR,
    schema JSONB,
    current_snapshot_id BIGINT
);

-- 快照元数据
CREATE TABLE ducklake_snapshots (
    snapshot_id BIGINT PRIMARY KEY,
    table_id BIGINT,
    manifest_list TEXT,
    timestamp TIMESTAMP
);

-- 文件元数据
CREATE TABLE ducklake_files (
    file_id BIGINT PRIMARY KEY,
    snapshot_id BIGINT,
    file_path VARCHAR,
    row_count BIGINT,
    min_max_stats JSONB
);

这种设计带来的好处是显而易见的：

• 一致性保证：通过数据库的ACID事务保证元数据一致性
• 查询性能：元数据查询就是一条SQL语句，无需多次对象存储请求
• 运维简单：数据库的备份、恢复、监控等工具链可直接使用
• 可扩展性：元数据库可以独立扩展，不受存储层影响

三、DuckLake的核心优势

3.1 简单性：告别复杂元数据文件

DuckLake彻底摒弃了复杂的JSON/AVRO元数据文件。所有元数据操作都通过标准SQL完成：

-- 创建表
CREATE TABLE sales (
    id BIGINT,
    product VARCHAR,
    amount DECIMAL(10,2)
) USING ducklake;

-- 插入数据
INSERT INTO sales VALUES (1, 'product_a', 100.0);

-- 更新数据
UPDATE sales SET amount = 150.0 WHERE id = 1;

-- 查询数据
SELECT * FROM sales;

这些操作在底层通过数据库事务保证原子性，无需担心元数据文件不一致的问题。

3.2 可扩展性：各层独立扩展

由于存储、元数据、计算三层分离，每层都可以独立扩展：

• 存储层：对象存储天然支持无限扩展
• 元数据层：数据库可以垂直或水平扩展（如PostgreSQL集群）
• 计算层：DuckDB可以部署在任意计算节点

这种架构特别适合云原生环境，可以根据业务需求灵活调整资源。

3.3 高性能：亚毫秒级更新与高并发

传统Lakehouse方案在处理小数据更新时性能较差，因为需要重写整个文件或产生大量小文件。DuckLake通过数据库管理元数据，可以实现：

• 亚毫秒级小数据更新：更新操作只修改元数据，不重写数据文件
• 高并发写入：数据库的事务机制支持高并发
• 快速元数据查询：元数据查询就是SQL查询，无需扫描文件系统

四、实战：快速上手DuckLake

4.1 安装与配置

首先安装DuckLake扩展：

-- 在DuckDB中安装扩展
INSTALL ducklake;
LOAD ducklake;

-- 配置元数据存储（使用本地DuckDB文件）
SET ducklake_catalog = 'local.db';

也可以使用PostgreSQL作为元数据存储：

SET ducklake_catalog = 'postgresql://user:pass@host:port/dbname';

4.2 创建表与数据操作

-- 创建DuckLake表
CREATE TABLE user_events (
    user_id BIGINT,
    event_type VARCHAR,
    event_time TIMESTAMP,
    properties JSON
) USING ducklake;

-- 插入数据
INSERT INTO user_events VALUES 
(1, 'login', '2024-01-01 10:00:00', '{"device": "mobile"}'),
(2, 'purchase', '2024-01-01 11:00:00', '{"amount": 100}');

-- 更新数据
UPDATE user_events SET properties = '{"amount": 150}' 
WHERE user_id = 2 AND event_type = 'purchase';

-- 删除数据
DELETE FROM user_events WHERE user_id = 1;

-- 查询数据
SELECT * FROM user_events;

4.3 高级特性演示

时间旅行：

-- 查看历史快照
SELECT * FROM ducklake_snapshots WHERE table_name = 'user_events';

-- 查询历史数据
SELECT * FROM user_events FOR SYSTEM_TIME AS OF '2024-01-01 10:30:00';

事务支持：

-- 跨表事务
BEGIN TRANSACTION;
INSERT INTO table1 VALUES (1);
INSERT INTO table2 VALUES (1);
COMMIT;

Schema演进：

-- 添加列
ALTER TABLE user_events ADD COLUMN new_column VARCHAR;

-- 修改列类型
ALTER TABLE user_events ALTER COLUMN properties TYPE JSONB;

五、适用场景与局限性

5.1 适用场景

• 中小规模数据平台：数据量在TB级别，需要完整的ACID支持
• 需要频繁更新的场景：如用户行为数据、实时日志等
• 对运维复杂度敏感：希望用简单方案解决复杂问题
• 云原生环境：希望各层独立扩展

5.2 当前局限性

• 元数据库可能成为瓶颈：如果元数据量非常大（如PB级数据），元数据库需要足够强大
• 生态成熟度：相比Iceberg/Delta Lake，生态工具链还在发展中
• 多引擎支持：目前主要与DuckDB深度集成，其他计算引擎支持有限

六、总结：回归本质的力量

DuckLake最值得称道的不是技术上的颠覆性创新，而是设计哲学上的回归。它承认了一个简单的事实：数据库最擅长管理元数据，那就让数据库做它最擅长的事。这种"回归本质"的设计带来了多重好处：

1. 简单性：元数据用SQL表管理，运维复杂度大幅降低
2. 性能：元数据查询就是SQL查询，无需多次IO
3. 一致性：数据库的ACID事务保证数据一致性
4. 开放性：数据仍以Parquet格式存储，保持开放性

当然，DuckLake并非万能药。对于超大规模数据平台，元数据库可能成为瓶颈；对于需要与Spark、Flink等生态深度集成的场景，还需要更多时间发展。但它的出现，为Lakehouse领域提供了一个全新的思路：有时候，最简单的方案就是最好的方案。如果你正在为现有Lakehouse方案的复杂性而苦恼，不妨试试DuckLake。它可能不是最强大的方案，但很可能是最简洁、最易用的方案。

---

相关资源：

• DuckLake GitHub仓库：https://github.com/duckdb/ducklake
• DuckDB官方文档：https://duckdb.org/docs/stable/
• DuckLake设计文档：https://ducklake.select/

注：本文基于DuckLake 0.1.0版本撰写，具体实现可能随版本更新而变化，请以官方文档为准