从 DeepSeek 到 Quack：分布式 DuckDB 的梦想何时开始变得真实
作者: amir
发布日期: 2026年5月19日
来源: dev.to
2025 年初，DeepSeek 改变了围绕 AI 基础设施的讨论。
大多数人关注的是模型质量、训练成本，以及一个新出现的中国 AI 实验室突然与业界巨头竞争背后的地缘政治故事。当然，那部分很有趣。但作为一名工程师，引起我注意的部分不仅仅是模型。
而是其背后的数据管道。
DeepSeek 发布了 Smallpond，一个基于 DuckDB 和 3FS 构建的轻量级数据处理框架。其想法出奇地简单：不是将所有东西都构建在像 Spark 这样的传统大数据引擎之上，而是在数据附近运行许多独立的、基于 DuckDB 的处理作业，仔细划分工作负载，让每个本地引擎做它最擅长的事情。
这听起来简直太简单了。
但这正是它有趣的原因。
令人不安的问题：我们真的总是需要 Spark 吗？
作为一名资深工程师，我曾在一些系统中工作，在这些系统中，Spark 是默认的答案，甚至在对问题有充分理解之前。
需要处理文件？使用 Spark。
需要聚合日志？使用 Spark。
需要转换 Parquet？使用 Spark。
需要连接中等规模的数据集？仍然使用 Spark。
Spark 很强大，我并不是在反对它。但在许多实际项目中，运营成本成为了隐性的税收：集群配置、内存调优、shuffle 行为、执行器大小调整、依赖打包、作业重试、监控，以及调试一个在长 DAG 中间某个位置失败的分布式作业的持续痛苦。
DuckDB 则位于这个光谱的另一端。
它是嵌入式的。它在你的进程内部运行。它读取 Parquet 文件非常出色。它支持 SQL。对于分析工作负载来说，它很快。而且最重要的是，它让本地数据处理再次变得平凡（boring）。
这里的"平凡"是一种赞美。
当我第一次认真使用 DuckDB 时，它取代了我工作流程中的许多小型 Python 脚本。我不再需要将 CSV 或 Parquet 文件加载到 Pandas 中、与内存限制作斗争、然后再次导出结果，而是可以直接在文件上编写 SQL：
sql
SELECT customer_id, sum(amount) AS total_spent
FROM read_parquet('orders/*.parquet')
GROUP BY customer_id
ORDER BY total_spent DESC
LIMIT 20;对于一次性分析来说，这已经很棒了。但 Smallpond 暗示了更大的可能性：如果 DuckDB 不仅仅是一个本地辅助工具，而是一个分布式数据系统的执行单元呢？
Smallpond 的启示：分发计划，而不是数据库
Smallpond 之所以有趣，是因为它并没有试图将 DuckDB 本身变成一个分布式数据库。相反，它将 DuckDB 视为一个快速的本地执行引擎。
其模式如下：
- 将数据集分割成分区。
- 将分区发送到不同的工作节点。
- 让每个工作节点在本地运行 DuckDB。
- 将中间结果写回共享存储。
- 在需要时合并或重新分区。
这在分布式系统中并不是一个新想法，但使用 DuckDB 作为本地分析核心使其感觉轻量级。
在 Smallpond 的仓库中，基本示例很简单：读取 Parquet，按键重新分区，运行 SQL，并再次写入 Parquet 输出。README 中还提到了一个 GraySort 基准测试，Smallpond 在一个集群上处理了超过 100 TiB 的数据。这有力地提醒我们，并非每个可扩展系统都需要看起来像传统的 Hadoop/Spark 技术栈。
对我来说，更深的教训是：
有时，最好的分布式架构不是一个巨大的分布式数据库。有时，它是数千个小型的、可预测的、协调良好的本地引擎。
这个想法很好地映射到了现代的 AI 管道上。
训练一个模型不仅仅涉及 GPU。在 GPU 看到任何数据之前，有一长串的数据清洗、去重、过滤、标记化、特征提取、元数据连接、质量检查和批生成工作。其中大部分工作是分析性的。大部分是基于文件的。而且大部分可以被推送到靠近存储的地方。
DuckDB 非常擅长这种风格的工作。
DuckDB 过去受限于何处
DuckDB 的优势一直是它的简单性：它是一个进程内分析数据库。
但这种简单性也带来了局限性。
如果你有一个 Python 进程、一个 CLI 会话或一个应用程序与 DuckDB 数据库文件交互，一切都感觉很干净。但是，一旦多个进程想要写入同一个数据库文件，你很快就会遇到锁定和并发限制。
这不是一个 bug。这是设计的一部分。
DuckDB 最初是为嵌入式 OLAP 工作负载优化的，而不是像 PostgreSQL 那样作为一个共享的多客户端服务器。
在我自己的项目中，我通常通过完全避免共享写入来解决这个问题：
- 写入分区的 Parquet，而不是写入一个共享的数据库文件
- 让每个工作节点产生不可变的输出
- 使用对象存储作为协调层
- 稍后运行一个最终的压缩或合并步骤
- 将 DuckDB 保留为查询引擎，而不是事实的来源
这很有效，但也有权衡。你开始构建自己的小型协调层。你需要命名约定、幂等写入、重试逻辑、清理作业，有时还需要一个元数据库来跟踪发生了什么。
这就是为什么 Quack 如此有趣。
Quack：DuckDB 开始通过网络通信
2026 年，Hannes Mühleisen 介绍了 Quack，这是一个将 DuckDB 转变为客户端-服务器数据库的远程协议。
其想法很优雅：客户端和服务器都是 DuckDB 实例，但它们通过 quack: 协议进行通信。服务器拥有数据。客户端发送查询。繁重的工作在数据附近完成，结果返回给客户端。
一个简化的例子如下所示：
sql
INSTALL quack FROM core_nightly;
LOAD quack;
CREATE SECRET (
TYPE quack,
TOKEN 'super_secret'
);
ATTACH 'quack:bigserver:9494' AS remote;
SELECT customer_id, sum(amount) AS total_amount
FROM remote.transactions
GROUP BY customer_id
ORDER BY total_amount DESC
LIMIT 10;这不仅仅是一种更优雅的语法。它改变了部署模型。
在 Quack 出现之前，DuckDB 主要是本地优先的。有了 Quack，DuckDB 可以在需要时变成远程优先的。
这意味着：
- 数据可以保留在强大的服务器上
- 笔记本电脑客户端无需下载庞大数据集即可查询
- 多个客户端可以连接到同一个 DuckDB 服务器
- DuckDB 可以在更传统的应用架构中使用
- DuckDB-Wasm 和基于浏览器的分析工具变得更有趣
官方 DuckDB 文档将 Quack 描述为 DuckDB 的 RPC 协议，并提到了其用例，如并发读写访问、将计算移动到靠近数据的位置，以及从本地客户端查询强大的服务器。
对我来说，关键短语是：数据附近的计算。
这是数据工程中最重要的思想之一。
将 500 GB 的数据移动到笔记本电脑是一个糟糕的计划。将 SQL 查询发送到已经拥有数据的机器是一个更好的计划。
我真正想要构建的原型
我想用这种架构尝试的第一件事，不是建立一个巨大的 AI 训练管道。而是一些更现实的东西：一个用于事件数据的轻量级分析服务。
想象一下这个设置：
- 应用程序事件作为 Parquet 文件写入对象存储
- 一个小型摄取服务批量处理新事件
- DuckDB 在本地读取和验证这些文件
- 为选定的文本字段生成嵌入向量
- 分析元数据存储在 DuckDB 或 DuckLake 中
- 向量搜索由专用的向量数据库处理
- Quack 将中央 DuckDB 实例暴露给内部工具
这种架构之所以有吸引力，是因为每个工具都专注于做好一项工作。
- DuckDB 擅长分析型 SQL。
- 对象存储擅长提供廉价、持久化的文件。
- 向量数据库擅长相似性搜索。
- Quack 成为了一座桥梁，允许多个客户端查询分析层，而无需将所有数据复制到本地。
向量数据库在这个故事中的位置
向量数据库存储嵌入，而不仅仅是行和列。
嵌入是文本、图像、音频、代码或其他对象的数字表示。例如，一个支持工单，如：
"我在更改账单地址后付款失败了。"
可以被转换为一个向量，例如：
[0.012, -0.441, 0.087, ...]
这些数字本身对人类没有意义，但它们在向量空间中的位置捕捉了语义含义。相似的文本会产生彼此接近的向量。
这支持了如下查询：
找到与此新投诉语义相似的工单。
传统 SQL 不是为这种相似性搜索设计的。当你确切知道字段和谓词时，SQL 非常出色：
WHERE status = 'failed' AND country = 'AM'
向量搜索则不同：
找到接近此嵌入的文档。
这就是为什么像 Qdrant、Milvus、Weaviate、Pinecone、pgvector 等系统变得流行的原因。它们使用诸如 HNSW 或 IVF 之类的索引来使最近邻搜索快速进行。
但这里有一个重要的部分：仅靠向量搜索通常是不够的。
在生产环境中，你通常需要混合检索：
- 向量相似性用于语义含义
- SQL 过滤器用于结构化约束
- 全文搜索用于精确关键词
- 元数据连接用于权限、客户、时间范围或产品类别
- 分析查询用于评估质量和漂移
这就是 DuckDB 再次变得有价值的地方。
我不希望我的向量数据库成为我整个的分析平台。我希望它检索候选结果。然后我希望使用 SQL 来检查、过滤、聚合、评估和调试系统。
例如：
sql
SELECT source, count(*) AS total, avg(score) AS avg_score
FROM retrieval_logs
WHERE created_at >= now() - INTERVAL '7 days'
GROUP BY source
ORDER BY avg_score DESC;这类查询自然属于 DuckDB 或数据湖仓层，而不是向量数据库内部。
为什么 Quack 使这个架构更清晰
如果没有 Quack，我通常会在每个服务内部本地运行 DuckDB，并将文件写回对象存储。这仍然是一个好模式。但它使交互式查询变得更加困难。
有了 Quack，我可以想象一个更清晰的工作流：
- ETL 工作节点在本地使用 DuckDB 处理原始数据。
- 处理后的文件写入对象存储。
- 一个中央的 DuckDB/DuckLake 服务器公开经过清洗的表。
- 内部工具通过 Quack 连接。
- BI 仪表板查询相同的分析层。
- 向量搜索服务将检索日志写回数据湖。
- 工程师使用 SQL 调试所有内容。
这不是要取代每一个数据仓库。它不是要取代 Kafka、Spark、PostgreSQL 或向量数据库。
但它是一个强大的中间层。
它适合许多团队实际所处的空间：数据量太大，无法用一个 Pandas 脚本处理，但又没有足够的操作复杂性来证明一个完整大数据平台的合理性。
作为一名工程师，我最喜欢的部分
我喜欢这个方向的原因是它尊重机械共鸣。
DuckDB 速度快，因为它理解分析执行：向量化处理、列式存储、高效扫描、智能 Parquet 读取以及无网络开销的本地执行。
Smallpond 说：保留那个本地执行模型，但并行运行它很多次。
Quack 说：保留 DuckDB 的引擎，但允许它在共享服务器模型有用时进行通信。
这是一个健康的发展。
它没有抛弃原始设计。它扩展了它。
作为一个曾花费过多时间调试过度设计管道的人，我欣赏那些通过组合而非魔法来扩展的系统。
我会谨慎对待的地方
在今天将 Quack 用作生产系统的核心之前，我仍然会保持谨慎。
官方页面将其描述为测试版。这很重要。
在依赖它之前，我会测试：
- 实际工作负载下的写入并发性
- 身份验证和网络暴露
- 备份和恢复策略
- 长时间运行写入期间的故障行为
- 与现有 DuckDB 扩展的兼容性
- 可观测性和查询日志记录
- 在负载均衡器或代理后面的行为
- 许多小写入与大批量写入的性能
我还会避免假装 DuckDB 突然变成了 PostgreSQL。
DuckDB 本质上仍然是一个分析引擎。即使 Quack 使多客户端访问成为可能，我也不会立即将其用于高容量的 OLTP 工作负载，如支付、订单或用户会话。
对于这些，PostgreSQL 仍然是那个平凡且正确的答案。
但对于分析工作负载、内部仪表板、数据管道、AI 预处理、评估数据集、批量转换和湖仓风格的元数据，Quack 打开了一扇非常有趣的门。
最后的思考
从 DeepSeek 的 Smallpond 到 DuckDB 的 Quack 的故事，不仅仅是关于一个工具变得分布式。
它关乎我们思考数据系统方式的转变。
多年来，应对规模的默认答案往往是：使用一个更大的分布式框架。
现在我们看到了另一种模式：
- 保持计算简单
- 保持数据采用开放格式
- 在数据附近运行快速的本地引擎
- 通过轻量级协议进行协调
- 在真正有意义的地方使用专用系统
这就是为什么这个领域令人兴奋。
DuckDB 让本地分析感觉简单。
Smallpond 表明，许多本地 DuckDB 作业可以成为一个严肃的分布式处理模式。
Quack 现在让 DuckDB 实例能够相互通信。
当你将它与对象存储、DuckLake、Parquet 和向量数据库结合起来时，你会得到一个非常务实的架构，适用于现代 AI 和数据工程。
不是因为这是一种趋势。
而是因为它消除了不必要的复杂性。