[Rust] OpenDuck开源：自建DuckDB混合执行服务

MotherDuck 让 DuckDB 上云这件事看起来很简单——一行 ATTACH 'md:mydb'，远程表就像本地一样参与查询，还能自动把计算拆到你的笔记本和云端两边跑。问题是，这一切都跑在 MotherDuck 的商业服务上，协议私有，后端锁死。

OpenDuck 做的事情很直接：把 MotherDuck 证明过的架构全部用开放协议重新实现一遍。它不宣称 wire-compatible，不试图做 MotherDuck 的兼容替代品，而是用同一套设计理念从零搭出一个你能自己部署的版本。我翻完源码后的第一反应是——这东西的协议设计比我想象的简洁得多。

项目卡片

• 项目：OpenDuck[^1]
• 状态：v0.1.0 / 524 Stars / 2026-04-14 创建，活跃迭代中
• 一句话判断：如果你认可 MotherDuck 的架构思路但需要自托管，OpenDuck 是目前唯一的开源选择。

[^1]: OpenDuck: https://github.com/CITGuru/openduck

它做了什么

OpenDuck 的架构分三层：DuckDB 扩展（客户端）、Gateway（路由 + 计划拆分）、Worker（内嵌 DuckDB 的执行节点）。Gateway 使用 Rust 实现，承担 token 认证、Worker 注册、计划拆分与亲和路由；元数据存储在 PostgreSQL，对象存储存放 sealed layer。

差异存储（Differential Storage）。数据写成 append-only 的不可变 sealed layer，元数据存 PostgreSQL，支持快照隔离读取。DuckDB 看到的是一个普通文件，底层持久化逻辑对引擎透明。这意味着多个读取者可以并发读不同快照，写入走单一序列化路径。

混合执行（Hybrid Execution）。Gateway 会解析查询中的 openduck_run('REMOTE', ...) 提示或 compound hint，给每个算子打上 LOCAL/REMOTE 标签，然后在边界插入 Bridge 算子。同 compute context 下的远程表会被合并成单个 RemoteSql 节点推送到同一个 Worker，最大化远程计算下推。

[LOCAL]  HashJoin(l.id = r.id)
  [LOCAL]  Scan(products)          ← 本地
  [LOCAL]  Bridge(R→L)
    [REMOTE] Scan(sales)           ← 远程 Worker

只有中间结果跨网络传输。我通常会先看一个项目的失败处理再判断成熟度，OpenDuck 的 HybridError 设计了 is_fallback_eligible() 方法——远程 Worker 不可达时可以自动降级到本地执行，这个设计思路是对的。

DuckDB-native Catalog。这点我觉得拉开差距了。OpenDuck 直接实现了 DuckDB 的 StorageExtension、Catalog、SchemaCatalogEntry、TableCatalogEntry 接口，远程表对优化器来说就是本地表，正常参与 JOIN 重排、类型推导、CTE 优化。跟那种“发 SQL 收 Arrow”的通用客户端驱动完全不是一个层级。

4 个 RPC 定义的开放协议

OpenDuck 的协议定义在单个 execution.proto 文件里，总共 4 个 RPC：

• ExecuteFragment：发送 SQL，流式返回 Arrow IPC 批次
• CancelExecution：按 execution_id 取消运行中的查询
• RegisterWorker：Worker 注册自己的数据库亲和性和计算能力
• Heartbeat：Worker 发送心跳保活

2 个数据面 RPC + 2 个生命周期 RPC，对比 Arrow Flight SQL 的约 15 个 RPC，面窄但集成深。只要你的服务能接受 SQL 并返回 Arrow IPC，就是一个兼容后端——Gateway、Worker、甚至完全不同的执行引擎都行，客户端扩展不关心对面是谁。

上手体验

目前扩展还没发布到 DuckDB 官方扩展仓库，必须从源码编译。编译链路依赖不轻：vcpkg（或 macOS 用 Homebrew 装 protobuf/grpc/apache-arrow）、bison、C++17 编译器。Linux 相对直接，macOS 需要额外注意 vcpkg 和系统库的冲突。Worker 内嵌的 DuckDB 版本固定在 v1.5.0，diff-fuse（FUSE 适配层）仅支持 Linux。

# 编译后端
cargo build --workspace

# 编译 DuckDB 扩展
cd extensions/openduck && make

# 启动服务（单进程模式：Worker + Gateway）
export OPENDUCK_TOKEN=your-token
cargo run -p openduck -- -d mydb --token your-token

连接方式分两种。直接用 DuckDB SDK 需要手动 LOAD 扩展并启用 allow_unsigned_extensions：

import duckdb
con = duckdb.connect(config={"allow_unsigned_extensions": "true"})
con.execute("LOAD '/path/to/openduck.duckdb_extension';")
con.execute("ATTACH 'openduck:mydb?endpoint=http://localhost:7878&token=xxx' AS cloud;")

Python wrapper 更简单，自动检测编译产物路径：

import openduck
con = openduck.connect("mydb")
con.sql("SELECT * FROM users LIMIT 10").show()

Docker Compose 提供了 PostgreSQL 和 MinIO 的开发环境，分别作为元数据存储和对象存储。

安全修复记录值得关注

CHANGELOG 里记录了大量安全修复，涵盖 SQL 注入（Python 客户端 connect() 参数拼接、DuckLake ATTACH 语句）、路径遍历（storage_uri 和 db_name）、PostgreSQL URL 日志泄露、未认证的 Worker 注册等。部分修复参考了外部安全研究者的报告。

翻完 CHANGELOG 我数了一下，仅 Unreleased 版本就有 7 项安全修复，从 SQL 注入到路径遍历到 token 泄露全覆盖了。快速迭代期暴露安全短板很正常，修复的速度和覆盖面说明维护者态度认真。但如果是我自己部署，我会等到这些修复落地一个正式 release 之后再上生产。

和几个常见方案的对比

vs MotherDuck：架构思路一致，但 OpenDuck 是自托管、开放协议、开放后端。不兼容 MotherDuck 的私有 wire format，不能直接替代 MotherDuck 的云端服务。

vs Arrow Flight SQL：Flight SQL 是通用数据库协议（“Arrow 版的 JDBC”），OpenDuck 是 DuckDB 专属系统。区别在于 OpenDuck 实现了 DuckDB 内部的 Catalog 接口，远程表对优化器可见，还能做混合执行拆分。Flight SQL 的服务端不知道客户端的查询计划，无法参与算子下推。

vs DuckLake：两者不在同一层。DuckLake 管 lakehouse catalog（表 → Parquet + 元数据），OpenDuck 管 DuckDB 的存储和执行层。可以组合使用——远程 Worker 挂载 DuckLake catalog，OpenDuck 做查询传输。

值不值得试

OpenDuck 目前 v0.1.0，功能架构完整但工程成熟度还在早期。扩展需要源码编译、混合执行依赖手动 hint 而非全自动计划拆分、FUSE 适配只支持 Linux。需要一个开箱即用的 DuckDB 云方案，MotherDuck 仍然省心得多。

但如果你想要自己掌控后端、想插自定义执行引擎、不想被商业服务锁定，OpenDuck 的协议简单到任何人都能写一个兼容后端——4 个 RPC，一个 proto 文件。这种“面窄但集成深”的设计，比堆功能更值得长期关注。

---

更多技术深度解析欢迎访问 云栈社区。