过去十年，湖仓领域的各类工程团队花了大把精力，试图教对象存储怎么像事务型数据库那样工作。在云原生架构体系中，厂商们默认使用大量文本文件和日志流来拼凑出系统一致性。2026 年 4 月发布的 DuckLake 1.0 给出了一种更直接的解法：把表的元数据从对象存储里的 JSON 清单文件，搬进真正的关系型数据库。
湖仓格式过去十年的复杂度，有相当一部分来自用对象存储去干数据库该干的事。DuckLake 把元数据平面交还给 ACID 事务数据库，换来快照、时间旅行和小批量写入不必再靠复杂合并操作硬扛。格式规范的 1.0 远不等于软件落地的 1.0，这套用旧技术栈解新问题的架构，真正的门槛卡在权限模型与实现成熟度上。
放弃对象存储管理元数据
过去的主流实践中，Iceberg 这类格式在每次写入数据时，都需要生成新的 snapshot JSON、manifest list 和 manifest 文件。这种静态管理机制在低频大批量写入时运转良好，但在遇到高频小规模写入的业务场景时，元数据目录下的对象数量往往会超过实际的数据文件数量。用静态文本文件在对象存储上模拟事务机制，在规模膨胀后直接导致文件列举操作变慢，API 调用成本也随之攀升。
DuckLake 放弃了这种叠床架屋的做法，将系统拆分为三层结构。底层的 storage 依然是对象存储或本地磁盘上的 Parquet 文件，顶层的 compute 保持可插拔状态。位于中间的关键 catalog 层变成了一个真正的 SQL 数据库，目前兼容 PostgreSQL、SQLite、MySQL 甚至是 DuckDB 自身。将 schema 演进、分区信息、列统计都存进关系表里，查询引擎不再需要遍历海量的小文件来获取当前数据快照的状态。
将元数据直接写成数据库里的事务，省去了部署 Polaris 或 Unity Catalog 等独立 REST 服务的开销。在 Iceberg 生态中，独立目录操作常常成为写入路径的物理瓶颈，处理不当会直接拖垮整条写入链路。DuckLake 的这种架构让系统性能的约束条件，从对象存储的 I/O 延迟，回退到了工程界更为熟悉的数据库并发事务处理能力上。
关系表吞下高频小规模写入
针对实时数仓中常见的数据频繁更新问题，DuckLake 引入了专门的 data inlining 机制。当系统遇到小批量的 insert、update 和 delete 操作时，这些数据不再立刻触发底层 Parquet 文件的重写，而是先直接写入 catalog 数据库中。这种设计将碎片化的 I/O 请求转换为高效的数据库内部更新事务，从源头上阻断了小文件问题的产生。
当数据库中的积压数据量达到设定的物理阈值后，后台的系统进程才启动任务，将这部分缓冲数据统一刷写并生成标准 Parquet 文件。这种延迟写入的策略，避免了为了清理小文件而高频触发消耗大量计算资源的物理合并任务。同时这也显著降低了与对象存储交互的网络传输和读取成本，系统可以在保持高并发读写状态的同时，维持底层数据块的物理连续性。
除了对小批量的缓冲，DuckLake 在底层数据扫描上支持指定排序键的特性。在进行后续的文件合并操作时，引擎会严格维持数据的预设物理顺序。底层数据文件的有序排列，使得查询引擎能够直接利用范围裁剪和过滤下推技术，在文件扫描环节就精准丢弃掉无关的存储块。
极简规范换取计算框架多路接入
DuckLake 将自身定位为一个开放的技术规范，目前在 GitHub 仓库上已经积累了超过 3.2k 的关注量。商业公司 MotherDuck 为其背书，提供了免费的电子书指南。官方团队发布的博客文章直言不讳地指出，这份规范的逻辑简单清晰，甚至代码模型都能根据文档快速为 DataFrames 写出一套兼容实现。将系统架构的复杂度降低到普通开发者可以单兵复现的程度，是新标准在早期争取生态开发者站位的高效策略。
图：规范足够简单，连 LLM 都能照着为 DataFrames 实现一份。来源：DuckLake 官方网站博客卡片图
规范与引擎的解绑机制，让这套标准不需要和 DuckDB 产生强行绑定。只要目标计算引擎能理解关系型元数据和底层 Parquet 文件格式，Trino、Spark 等常见的数据分析框架都能作为计算层接入网络。在 DataFusion 开源生态中，开发者已经使用 Rust 语言实现了专用的湖仓数据客户端。
图：DataFusion 生态里的 DuckLake 客户端架构示意。来源：DuckLake 官方网站博客卡片图
这套由社区开发的客户端使用 Postgres 作为后端的元数据存储。项目主导者表示，即使面对极高的并发请求压力，这套轻量级架构依然能做到亚秒级的查询响应时间，其表现并不逊色于团队以前为特定场景定制的元数据系统。这种表现展示了将复杂的目录管理逻辑下放给成熟的关系型数据库，在多路高并发读取场景中具备真实的工程价值。
规范版本掩盖不住权限模型短板
尽管规范 1.0 版本已经以 MIT 协议对外发布并承诺了向后兼容性，但社区实践情况表明，该标准在落地环节依然存在不少工程阻力。工程人员反馈在运行 v1.5.4 版本时，遇到过目录过滤后记录计数错误的系统故障。而在切换到主分支修复该问题后，DuckDB 的内置 SQL 解析器性能又出现了高达 10 倍的断崖式下滑。这种新旧版本之间起伏不定的稳定性表现，要求技术团队在将其接入核心业务线前必须进行严格的边界压力测试。
技术社区的讨论集中指出了这套系统的核心缺陷在于访问控制模型的短板。当前版本的权限控制颗粒度十分粗放，策略只能做到针对底层 bucket 级别的放行或阻断。系统层面整体缺乏企业级应用中必须的列级和行级访问控制机制，也同样不支持用于数据脱敏的列掩码功能。没有这些基础设施，系统就形同一个缺乏防御机制的蓄水池。
缺少细粒度的安全控制层，这套湖仓架构在实际的企业商业分析场景中往往寸步难行。在无法做到跨团队数据安全隔离的现阶段，这套规范更适合被部署在由单一团队掌控的内部研发沙盒中，难以直接接管要求严苛的多租户生产数据。
格式竞争回归事务与存算模型
在兼容性层面，系统支持多表 ACID 事务控制和历史时间旅行查询。其底层采用的删除向量机制在文件格式上选择了直接兼容 Iceberg 的实现方案。这允许引擎在处理行级数据删除请求时，不必立即对庞大的 Parquet 数据块执行重写操作。当程序发出删除指令时，系统只在向量表中记录标记状态，推迟了消耗大量资源的物理数据擦除流程，缓解了集群算力的峰值压力。
关于社区中为什么不使用流行编程语言重写核心代码的争论，开发团队的回答展示了其实用主义导向。由于 DuckDB 自身从 2018 年起就是基于 C++ 语言构建，其衍生的湖仓管理规范自然延续了这套底层技术栈。这种语言选择规避了大规模重构带来的代码断层，保证了底层执行引擎的时序一致性和系统的稳定性。
数据湖格式迭代的核心工程诉求不是引入新潮的词汇概念。把复杂的数据快照状态和事务机制交还给经过数十年行业验证的关系型数据库处理，是 DuckLake 团队做出的务实取舍。它用这种结构化置换获得了处理高并发元数据查询的能力，但也暂时让出了精细的文件权限粒度。当湖仓架构的竞争退去外围生态的包装，检验厂商功底的标准依然是底层一致性和安全防护颗粒度这些最基础的软件命题。
参考链接：
- DuckLake GitHub 仓库
- DuckLake 官方说明
- Hacker News 社区讨论
