我要投稿

DeepSeek Smallpond

发布日期：2025-03-04 05:31:23 浏览次数： 1660 作者：MLSys2024

你可能已经从Twitter/LinkedIn的热议中听说了smallpond。从这些热议中，你可能会得出结论：Databricks和Snowflake已经完蛋了。别急，事实并非如此。

尽管这项开源技术很有趣且功能强大，但它短期内不太可能在分析领域被广泛使用。以下是一个简明的解析，帮助你透过喧嚣看清本质。我们将涵盖以下内容：

1.smallpond及其配套系统3FS是什么

2.它们是否适合你的使用场景

3.如果适合，如何使用它们

什么是smallpond？

smallpond是DeepSeek最近推出的一款轻量级分布式数据处理框架。它扩展了DuckDB（通常是一个单节点分析数据库），使其能够跨多个节点处理更大的数据集。smallpond通过使用分布式存储和计算系统，让DuckDB能够管理分布式工作负载。主要特性：

1.分布式分析：通过数据分区和并行运行分析任务，使DuckDB能够处理超出单机内存容量的数据集。

2.开源部署：如果你能成功运行它，3FS将为你提供强大且高性能的存储，成本远低于其他替代方案。

3.手动分区：用户需要手动对数据进行分区，smallpond会将这些分区分布到多节点上进行并行处理。

什么是3FS？

3FS，全称为Fire-Flyer File System，是深度求索开发的一款高性能并行文件系统。它专门为AI和高性能计算（HPC）工作负载优化，通过使用SSD和RDMA网络技术，提供了极高的吞吐量和低延迟。

3FS是smallpond依赖的高速分布式存储后端，为其提供了惊人的性能。3FS在180个节点的集群上实现了6.6 TiB/s的读取吞吐量，远超许多传统分布式文件系统。

如何使用它？首先，和安装其他Python包一样，使用以下命令安装：pip install smallpond。但要真正发挥smallpond的优势，还需要更多的努力，具体取决于你的数据规模和基础设施：

1.小于10TB：除非你有非常特定的分布式计算求，否则smallpond可能并不必要。单节点的DuckDB实例或更简单的存储解决方案会更简单，甚至可能性能更好。坦白说，在小规模数据下使用smallpond（没有Ray或3FS）可能会比原版DuckDB更慢，也更复杂。

2.10TB到1PB：smallpond开始展现其优势。你需要设置一个集群，利用3FS或其他高速存储后端来实现快速并行处理。

3.超过1PB（PB级规模）：smallpond和3FS正是为处理海量数据集而设计的。在这个规模下，你需要部署一个更大的集群，并进行大量的基础设施投资。

部署通常包括以下步骤：

1.设置计算集群（例如AWS EC2、Google Compute Engine或本地服务器）。

2.在节点上部署3FS，这些节点需要配备高性能SSD和RDMA网络。

3.通过Python安装smallpond，以便在集群上运行分布式DuckDB任务。

其中，步骤1和步骤3非常简单，但步骤2非常困难。由于3FS是新技术，目前还没有关于如何在AWS或其他云平台上设置它的指南（也许深度求索未来会提供相关支持？）。你当然可以在裸金属服务器上部署它，但这会让你陷入更深层次的DevOps困境。

我尝试过用S3替换3FS来运行smallpond，但对于中等规模的数据，尚不清楚这样做是否能带来比单节点扩展更好的性能提升。

你是否需要使用smallpond，取决于以下几个因素：

1.数据规模：如果你的数据集小于10TB，smallpond会带来不必要的复杂性和开销。对于更大的数据集，它能提供显著的性能优势。

2.基础设施能力：smallpond和3FS需要强大的基础设施和DevOps专业知识。如果没有一支擅长集群管理的团队，部署和运维可能会非常具有挑战性。

3.分析复杂度：smallpond在分区级并行处理方面表现出色，但在复杂连接（join）操作上优化较少。如果你的工作负载需要跨分区进行复杂的连接操作，性能可能会受到限制。

核心概念

Session

作为 smallpond 的入口点

负责管理执行环境、配置和资源

提供创建 DataFrame 的方法

管理 Ray 集群和执行器

DataFrame

数据处理的主要抽象

提供数据转换和操作的接口

支持 SQL、map、flat_map 等操作

延迟执行,直到调用 compute() 才真正执行

Platform

抽象不同执行平台(如本地、MPI等)的差异

负责任务的启动和资源管理

提供平台特定的配置和默认值

LogicalPlan

表示整个计算的DAG(有向无环图)

由 Node 组成

可以被优化和转换为执行计划

Node (逻辑节点)

DataSourceNode: 数据源节点

SqlEngineNode: SQL 执行节点

ArrowComputeNode: Arrow 计算节点

DataSinkNode: 数据输出节点

ProjectionNode: 列选择节点

UnionNode: 数据合并节点

ConsolidateNode: 分区合并节点

ExecutionPlan

由 LogicalPlan 转换而来

包含具体的执行任务(Task)

管理任务的依赖关系和执行顺序

Task

具体的执行单元

包含输入、输出和执行逻辑

支持重试和错误处理

可以在不同的执行器上运行

Scheduler

负责任务的调度和分配

管理任务的生命周期

处理任务失败和重试

支持推测执行

DataSet

表示一组数据文件

支持不同的文件格式(Parquet、CSV、JSON等)

管理数据的分区和分布

提供数据读取和写入接口

WorkQueue

管理任务的执行队列

支持任务的优先级

处理任务的状态变化

Session

-> 创建 DataFrame

-> 构建 LogicalPlan

-> Optimizer 优化

-> Planner 生成 ExecutionPlan

-> Scheduler 调度执行

-> Platform 运行任务

Session 管理整个执行环境

DataFrame 提供用户接口

LogicalPlan 描述计算逻辑

ExecutionPlan 负责具体执行

Platform 提供运行时支持

DataSet 管理数据存储和访问

工作原理

惰性DAG执行：Smallpond对诸如`map()`、`filter()`和`partial_sql()`等操作使用惰性求值（lazy evaluation）。它不会立即执行这些操作，而是构建一个逻辑执行计划，表现为一个有向无环图（DAG），每个操作成为一个节点`SqlEngineNodeHashPartitionNode`、`DataSourceNode`。

直到你显式触发执行操作时，才会真正开始计算。这些触发操作包括：

write_parquet() — 将数据写入磁盘

to_pandas() — 将结果转换为pandas

DataFrame

compute() — 显式强制计算
count() — 统计行数
take() — 获取部分数据行

这种惰性求值机制非常高效，因为它避免了不必要的计算，并优化了工作流程。

从逻辑计划到执行计划：当你最终触发一个操作时，逻辑计划会转化为一个由具体任务（例如`SqlEngineTask`、`HashPartitionTask`）组成的执行计划。这些任务是实际的工作单元，由Ray进行分发和执行。

Ray核心与分布式处理：Smallpond的分布式能力依赖于Ray Core，在Python层面通过分区实现可扩展性。分区可以手动完成，Smallpond支持以下分区方式：

哈希分区（基于列值）
均匀分区（按文件或行数）
随机洗牌分区

每个分区在其自己的Ray任务中独立运行，使用DuckDB实例处理SQL查询。这种与Ray的紧密集成强调了水平扩展（增加更多节点）而非垂直扩展（使用更强大的单节点）。要在规模上使用它，你需要一个Ray集群。你可以选择在自己的基础设施或云提供商（如AWS）上运行Ray集群，但如果你只是想测试一下，使用Anyscale会更容易上手。