DuckDB 走向分布式？DeepSeek 的 smallpond 涉足大数据DuckDB！降维打击传统大数据领域，搅动中台数据工程风云！

DeepSeek 正在利用 smallpond（一种新的、简单的分布式计算方法）推动 DuckDB 超越其单节点根源。但它是否解决了可扩展性挑战——还是带来了新的权衡？

DeepSeek 最近搞了个大新闻。他们的 R1 模型在 2025 年 1 月发布时，就直接干翻了 OpenAI 的 O1 等竞争对手。但真正让它牛的是它的高效基础设施——在保持顶级性能的同时，成本还大幅降低。

现在，他们开始瞄准数据工程师了。DeepSeek 发布了一系列小型存储库，作为独立的代码模块。HuggingFace 的联合创始人兼产品总监 Thomas Wolf 分享了一些亮点，但我们要重点聊一个他没提到的项目——smallpond，一个基于 DuckDB 构建的分布式计算框架。DeepSeek 正在通过 smallpond 推动 DuckDB 突破单节点的限制，提供了一种全新的、简单的分布式计算方法。

首先，像 DeepSeek 这样的热门 AI 公司使用 DuckDB，本身就是个大事，我们会解释为什么。其次，我们会深入探讨这个存储库，看看他们如何巧妙地让 DuckDB 变成分布式系统，以及它的局限性和未解决的问题。

假设你已经熟悉 DuckDB 了。我围绕它做了很多内容。但以防万一，这里简单回顾一下。

为了透明起见，写这篇博客时，我是 MotherDuck 的数据工程师和 DevRel。MotherDuck 提供了一个基于云的 DuckDB 版本，功能更强大。它的方法和我们这里讨论的不一样，虽然我会尽量保持客观，但还是提醒一下！

**DuckDB 提醒**
DuckDB 是一个进程内分析数据库，意味着它在你应用程序内部运行，不需要单独的服务器。你可以通过添加库轻松地在多种编程语言中安装它——可以把它看作分析领域的 SQLite，但它是为高性能查询大型数据集而设计的。

它用 C++ 编写，包含了数据管道可能需要的所有集成（AWS S3/Google Cloud Storage、Parquet、Iceberg、空间数据等），而且速度超快。除了处理常见的文件格式，它还有自己的高效存储格式——一个符合 ACID 标准的文件，包含所有表和元数据，压缩效果很强。

在 Python 中，入门非常简单：

pip install duckdb

然后，只需几行代码就能加载并查询 Parquet 文件：

import duckdb
conn = duckdb.connect()
conn.sql("SELECT * FROM '/path/to/file.parquet'")

得益于 Arrow，它还支持以零拷贝的方式读取和写入 Pandas 和 Polars DataFrames。

import duckdb
import pandas

# 创建一个 Pandas DataFrame
my_df = pandas.DataFrame.from_dict({'a': [42]})

# 查询 Pandas DataFrame "my_df"
# 注意：duckdb.sql 连接到默认的内存数据库连接
results = duckdb.sql("SELECT * FROM my_df").df()

DuckDB 正在进入 AI 公司吗？
我们讨论了很多关于 LLM 框架、模型和代理的内容，但常常忘记 AI 项目的第一步其实是数据。

无论是训练、RAG 还是其他应用，最终都归结为向系统提供优质、干净的数据。但我们怎么做到这一点呢？通过数据工程。数据工程是 AI 工作流中的关键一步，但由于它不够“性感”也不够“新”，所以讨论得不多。

关于 DuckDB，我们已经看到其他 AI 公司（比如 HuggingFace）在幕后使用它，通过他们的数据集查看器快速服务和探索数据集库。

现在，DeepSeek 推出了轻量级开源框架 smallpond，利用 DuckDB 以分布式方式处理 TB 级数据集。他们的基准测试显示：“在 30 分 14 秒内对 110.5TiB 数据进行排序，平均吞吐量达到 3.66TiB/分钟。”
来源：https://github.com/deepseek-ai/smallpond

虽然我们已经看到 DuckDB 轻松地在单节点上处理 500GB（clickbench），但这进入了另一个数据量级。

Clickbench 基准测试
但等等，DuckDB 不是专注于单节点吗？这里面有什么问题？

让我们开始吧。

smallpond 的内部结构

1、基于 DAG 的执行模型*
smallpond 在对 DataFrames（如 `map()`、`filter()`、`partial_sql()` 等）执行操作时采用惰性求值，意味着它不会立即执行这些操作。相反，它会构建一个以有向无环图（DAG）表示的逻辑计划，其中每个操作对应图中的一个节点（如 `SqlEngineNode`、`HashPartitionNode`、`DataSourceNode`）。

只有当调用某个操作时才会触发执行，比如：

• - `write_parquet()`——将数据写入磁盘  
• - `to_pandas()`——转换为 pandas DataFrame  
• - `compute()`——明确请求计算  
• - `count()`——计数行  
• - `take()`——检索行  

这种方法通过推迟计算直到必要时才进行，减少冗余操作并提高效率，从而优化性能。

当触发执行时，逻辑计划会转换为执行计划。执行计划由与逻辑计划中的节点相对应的任务（如 `SqlEngineTask`、`HashPartitionTask`）组成。这些任务是通过 Ray 分发和执行的实际工作单元。

Ray 核心与分配机制
需要理解的重要一点是，smallpond 中的分发机制在 Ray（特别是 Ray Core）的帮助下通过分区在 Python 级别运行。

给定操作根据用户提供的手动分区进行分布。smallpond 支持多种分区策略：

• - 哈希分区（按列值）  
• - 均匀分区（按文件或行）  
• - 随机洗牌分区  

对于每个分区，Ray 任务中会创建一个单独的 DuckDB 实例。每个任务通过 DuckDB 使用 SQL 查询独立处理其分配的分区。

鉴于这种架构，你可能会注意到该框架与 Ray 紧密集成，但这需要权衡：它优先考虑扩展（使用标准硬件添加更多节点）而不是扩大（提高单个节点的性能）。

因此，你需要一个 Ray 集群。有多种选择，但如今你可以通过 AWS/GCP 计算或 Kubernetes 集群管理自己的集群。只有由 Ray 的创建者创立和领导的公司 Anyscale 提供完全托管的 Ray 服务。即便如此，你仍需要监控集群的开销。

这里最棒的一点是，开发者的体验非常好，因为你在工作时获得本地单节点，只在需要时才扩展。但问题是：考虑到当今 AWS 上最大的机器提供 24TB 内存，你真的需要扩展并增加集群开销吗？

存储选项
Ray Core 仅用于计算——存储在哪里？

虽然 smallpond 支持用于开发和较小工作负载的本地文件系统，但提到的 100TB 基准测试实际上使用了定制的 DeepSeek 3FS 框架：Fire-Flyer 文件系统是一种高性能分布式文件系统，旨在应对 AI 训练和推理工作负载的挑战。

简单来说，与 AWS S3 相比，3FS 注重速度，而不仅仅是存储。

• 虽然 S3 是一个可靠且可扩展的对象存储，但它具有更高的延迟和最终一致性，因此不太适合需要快速、实时数据访问的 AI 训练工作负载。

• 另一方面，3FS 是一个高性能分布式文件系统，利用 SSD 和 RDMA 网络提供低延迟、高吞吐量的存储。它支持随机访问训练数据、高效检查点和强一致性，无需额外的缓存层或变通方法。

对于需要快速迭代和分布式计算的 AI 密集型工作负载，3FS 提供了更优化的 AI 原生存储层——以一些成本和操作复杂性换取原始速度和性能。

因为这是 DeepSeek 的一个特定框架，所以如果你想达到相同的性能，你必须部署自己的 3FS 集群。那里没有完全托管的选项……或者这可能是 DeepSeek 衍生创业公司的想法？

一个有趣的实验是使用 AWS S3 测试相同规模的性能。但 smallpond 目前缺少此实现。对于需要 100TB 处理能力的普通公司来说，这种方法更为实用。

与 Spark/Daft 等其他框架的主要区别
与 Spark 或 Daft 等可以在查询执行级别分配工作的系统（将连接或聚合等单个操作分解）不同，smallpond 在更高级别运行。它将整个分区分配给工作器，每个工作器使用 DuckDB 处理其整个分区。

这使得架构更简单，但对于受益于操作级分布的复杂查询而言，其优化程度可能较低。

让我们回顾一下 smallpond 的特点：

• - 基于 DAG 执行的惰性求值——操作被推迟，直到明确触发。  

• - 灵活的分区策略——支持哈希、基于列和基于行的分区。  

• - Ray 驱动的分布——每个任务都在自己的 DuckDB 实例中运行，以实现并行执行。  

• - 多存储层选项——基准测试主要使用 3FS 进行。  

• - 集群管理权衡——需要维护计算集群，但像 Anyscale 这样的完全托管服务可以缓解这种情况。  

• - 潜在的 3FS 开销——自我管理 3FS 集群会带来显著的额外复杂性。  

使用 DuckDB 进行分布式计算的其他方式
使用 DuckDB 进行分布式计算的另一种方法是通过无服务器函数（如 AWS Lambda）。在这里，逻辑通常比分区更简单，通常按文件处理。或者你可以决定使用一些包装器按分区进行处理，但你无法比逐个文件处理做得更好。

Okta 实现了这种方法，你可以阅读更多内容在 Julien Hurault 的博客：[Okta 的多引擎数据堆栈](https://www.julienhurault.com/blog/2023/10/okta-multi-engine-data-stack/)

摘自 Julien Hurault 的博客 Okta 的多引擎数据堆栈

最后，MotherDuck 正在进行双重执行，在本地和远程计算之间取得平衡，以优化资源使用。

扩展 DuckDB
总而言之，令人兴奋的是看到 DuckDB 被用于 AI 密集型工作负载，并且人们在需要时如何分割计算方面发挥创造力。

smallpond 虽然被限制在用于分配计算的特定技术堆栈中，但它的目标是简单，这与 DuckDB 的理念一致

这也提醒我们，有多种方式可以扩展 DuckDB。扩展始终是更简单的方法，但有了 smallpond 和此处提到的其他示例，我们就有了更多的选择。

如今，这种方法很有意义，而不必默认依赖复杂而繁重的分布式框架“以防万一”。这不仅会在从中小型数据开始时损害你的云成本，而且还会对开发者的体验产生影响（仍然爱你，Apache Spark ❤️）。

虽然我们拥有强大的单节点解决方案，足以满足大多数用例的需求，特别是根据 Redshift 的数据，如果你的用例中有 94% 的用例容量低于 10TB，那么我们现在有更多的选择来让 Duck 飞起来。

网友：
1、DuckDB 本身就很酷，尤其是与 SQLite 和/或 PostgreSQL 结合使用时，现在还有这个。感谢 DeepSeek！

2、这篇文章回答了与 DuckDB、Polers 等相比的好处

3、如果您想试用 duckdb，请尝试 QStudio。这是一款集成了 duckdb 的免费 SQL 客户端：https://www.timestored.com/qstudio/help/duckdb-sql-editor。

4、期待未来几年我们最终能够抽象出所有的后端技术

5、单节点的 DuckDB 性能简直强到离谱（速度超快），尤其是跟 Spark 这些东西比。这个项目里有很多工作都专注于提升速度，我不知道还有什么更快的数据处理工具（传统 SQL 不算，因为它的速度优势主要来自索引之类的，本质上是在提前做额外的工作）。

我猜这得看分布式工作流程写得好不好，虽然有很多地方可能出问题，但理论上它应该能实现非常惊人的性能。

我这么说的原因是 Dask 用了 Pandas，所以能比 Spark跑出更好的基准测试，我觉得这部分是因为一些很好的优化，但也因为 Pandas比 Spark 的基于行的模型更快。DuckDB 在某些测试中比 Pandas 快 10 倍以上，你可以想象一下这有多厉害……

https://www.jdon.com/77945.html

DeepSeek开源smallpond和3FS指南