DuckDB 作为数据处理首选工具技术分析

一、概述

1. 背景介绍

随着硬件性能的不断提升，尤其是单机高性能处理器的普及，数据处理领域正在经历一个范式转变：大多数表格数据可以在单台大型机器上处理，集群时代即将结束，仅适用于超大规模数据集。

2. 核心观点

DuckDB 作为一款开源的进程内 SQL 分析引擎，因其简单安装、人体工学设计、卓越性能和丰富功能，已成为数据处理的首选工具。

3. 适用场景

  • 大型数据集的批处理（CSV、Parquet、JSON 格式）
  • 数据清洗、连接、聚合、派生列等操作
  • 命令行快速查看 CSV 文件
  • CI/CD 环境中的数据管道测试

二、DuckDB 架构与原理

1. 核心概念

A. 进程内引擎

DuckDB 类似 SQLite，在应用程序内部运行，无需启动独立服务（如 Postgres）。这种设计消除了服务管理的复杂性。

B. 分析优化

DuckDB 专为分析查询（OLAP）设计，针对涉及大量行的连接和聚合操作进行优化，而非原子事务（OLTP）。

2. 性能对比

分析优化引擎与事务优化引擎的性能差异不容忽视。在 DuckDB 中运行的查询可能比在 SQLite 或 Postgres 中运行的相同查询快 100 倍甚至 1000 倍。

graph LR
    A[查询引擎选择] --> B{查询类型}
    B -->|OLAP 分析| C[DuckDB]
    B -->|OLTP 事务| D[Postgres/SQLite]
    C --> E[100-1000x 性能提升]
    D --> F[标准事务性能]

DuckDB 性能对比

3. 系统架构

graph TB
    subgraph 应用层
        A[Python 应用]
        B[命令行工具]
        C[其他语言绑定]
    end

    subgraph DuckDB 引擎
        D[SQL 解析器]
        E[查询优化器]
        F[列式存储引擎]
        G[向量化执行]
    end

    subgraph 数据层
        H[CSV 文件]
        I[Parquet 文件]
        J[JSON 文件]
        K[S3 存储]
        L[HTTP 数据源]
    end

    A --> D
    B --> D
    C --> D
    D --> E
    E --> F
    F --> G
    G --> H
    G --> I
    G --> J
    G --> K
    G --> L

DuckDB 系统架构

三、核心功能特性

1. 速度优势

DuckDB 在基准测试中始终是最快的数据处理引擎之一。领先的开源引擎包括 Polars、DuckDB、DataFusion、Spark 和 Dask。在大型数据上 Spark 和 Dask 具有竞争力，但在小型数据上较慢。

2. 简单安装，零依赖

DuckDB 本身是单个预编译二进制文件。在 Python 中，可以通过 pip 安装，无需任何依赖。与 Spark 等重量级选项相比，安装非常简单。配合 uv 工具，可以在不到一秒内从零开始搭建全新的 DuckDB Python 环境。

3. CI 和测试支持

凭借其速度和几乎零启动时间，DuckDB 非常适合 CI 和数据管道测试。历史上这一直很棘手，在 Apache Spark 等引擎中运行大量测试套件既耗时又令人沮丧。现在设置测试环境更加简单，测试环境与生产管道之间的差异也更小。

4. 友好的 SQL 语法

DuckDB 团队在其 SQL 方言中实现了广泛创新，使其使用体验非常出色。

A. EXCLUDE 关键字

可以方便地排除特定列：

SELECT * EXCLUDE (sensitive_column)
FROM table_name;

B. COLUMNS 关键字

允许选择和正则替换列子集：

-- 选择所有以 emp_ 开头的列并重命名移除前缀
SELECT COLUMNS('emp_(.*)') AS '\1'
FROM employees;

C. QUALIFY 子句

用于过滤窗口函数的结果。

D. 函数链

支持类似 Python 的函数链调用：

SELECT first_name.lower().trim()
FROM customers;

5. 多格式文件支持

可以直接查询文件中的数据，包括 S3 上的文件或 Web 上的文件。

A. 查询 Parquet 文件夹

SELECT *
FROM read_parquet('path/to/*.parquet');

B. 直接查询网络数据

SELECT *
FROM read_parquet('https://raw.githubusercontent.com/plotly/datasets/master/2015_flights.parquet')
LIMIT 2;

C. CSV 类型严格性

DuckDB 提供丰富的选项来确保从无类型格式（如 CSV）导入数据时的类型安全，这是数据管道稳定性的关键。

6. Python API 集成

许多数据管道实际上是一长串 CTE（公用表表达式）。在 Python 中，可以分步编写：

input_data = duckdb.sql("SELECT * FROM read_parquet('...')")
step_1 = duckdb.sql("SELECT ... FROM input_data JOIN ...")
step_2 = duckdb.sql("SELECT ... FROM step_1")
final = duckdb.sql("SELECT ... FROM step_2;")

这种写法的优势：

  • 可以轻松检查每个步骤的数据状态
  • 没有性能损失，因为步骤会延迟执行
  • 便于在 CI 中独立测试每个 SQL 步骤

7. ACID 合规性

DuckDB 为批量数据操作提供完整的 ACID 合规性，这使其区别于其他分析数据系统。这是一个非常有趣的新发展，使 DuckDB 有可能成为中型数据的湖屋格式（如 Iceberg 或 Delta Lake）的合适替代品。

8. 高性能 UDF 和社区扩展

A. 高性能 UDF

在 DuckDB 中，高性能自定义 UDF 可以用 C++ 编写。虽然编写这些函数并不简单，但 DuckDB 社区扩展提供了低摩擦的代码分发方式。

B. 社区扩展示例

INSTALL h3 FROM community;

这条命令可以立即安装用于地理空间数据的分层六边形索引。

9. 文档支持

团队将文档作为单个 Markdown 文件提供，可以轻松提供给 LLM。最佳实践：在代码编辑器中加载此文件，并使用代码折叠，可以轻松复制所需的文档部分到上下文中。

四、数据处理流程

1. 典型工作流

sequenceDiagram
    participant U as 用户
    participant P as Python 应用
    participant D as DuckDB 引擎
    participant F as 文件系统

    U->>P: 编写数据处理代码
    P->>D: duckdb.sql() 调用
    D->>F: read_parquet/read_csv
    F-->>D: 返回数据
    D->>D: SQL 优化与执行
    D-->>P: 返回 Relation 对象
    P->>P: 检查中间结果
    P->>D: 继续下一步处理
    D-->>U: 最终结果

DuckDB 数据处理流程

2. 开发与生产环境对比

特性传统 Spark 方案DuckDB 方案
安装复杂度高（需要 Java、Spark 环境）低（单条 pip 命令）
启动时间数秒到数十秒几乎零启动
测试难度高（需要模拟 Spark 环境）低（直接在 CI 中运行）
开发迭代慢（每次修改需重启 Spark）快（即时执行）
学习曲线陡峭（需要理解分布式概念）平缓（标准 SQL）

五、实际应用建议

1. 开发实践

A. 增量开发

使用 Python API 分步构建查询，每个步骤可以独立检查和测试。

B. 错误处理

利用 DuckDB 的友好 SQL 语法，减少样板代码。

C. 性能优化

对于大型数据集，优先使用 Parquet 格式而非 CSV。

2. 测试策略

A. 单元测试

每个数据处理步骤都可以作为独立函数进行单元测试。

B. 集成测试

利用 DuckDB 的快速启动特性，在 CI 中运行完整的集成测试。

C. 数据验证

使用 DuckDB 的类型严格性确保数据质量。

3. 部署考虑

A. 环境隔离

使用 uv 等工具快速创建隔离的 Python 环境。

B. 依赖管理

DuckDB 的零依赖特性大大简化了依赖管理。

C. 资源规划

对于大多数数据集，单机高性能配置（如 192 核处理器）足以替代分布式集群。

六、未来发展方向

1. PostgreSQL 扩展

A. DuckDB PostgreSQL 扩展

允许附加 Postgres 数据库并直接从 DuckDB 查询。

B. pg_duckdb

允许将 DuckDB 计算引擎嵌入 Postgres 中。

后者似乎特别强大，能够使 Postgres 同时针对分析和事务处理进行优化。预计将看到广泛采用，尤其是在解决当前关于启用和优化 Postgres 索引使用以及将过滤器上推到 Postgres 的一些不足之处之后。

graph TB
    subgraph pg_duckdb 集成架构
        PG[PostgreSQL]
        DD[DuckDB 计算引擎]

        PG -->|OLTP 事务| PG_Transaction[(事务处理)]
        DD -->|OLAP 分析| DD_Analytics[(分析查询)]

        PG -.智能路由.-> DD
        DD -.结果返回.-> PG
    end

    Client[客户端应用] --> PG
    PG --> Client

pg_duckdb 集成架构

2. 分布式 DuckDB

虽然单机 DuckDB 已能满足大多数需求，但分布式版本正在开发中，为真正超大规模数据集提供支持。

七、技术选型建议

1. 何时选择 DuckDB

  • 数据量适合单机处理（通常数百 GB 以内）
  • 需要 SQL 接口而非编程 API
  • 重视开发迭代速度
  • 需要在 CI 中进行快速测试
  • 希望简化部署和运维

2. 何时考虑其他方案

  • 数据量达到 PB 级别
  • 需要实时流处理
  • 已有成熟的 Spark 集群投资
  • 需要特定于其他引擎的功能

八、学习资源

1. 官方文档

  • DuckDB 官方文档（单文件 Markdown 版本）
  • DuckDB 友好 SQL 系列博客
  • DuckDB 技巧系列文章

2. 社区资源

  • DuckDB Web Shell（在线试用）
  • 社区扩展库
  • GitHub 讨论区

3. 实践建议

  • 使用代码编辑器折叠功能浏览完整文档
  • 在 Web Shell 中快速测试查询
  • 关注官方博客了解最新特性

参考资料

  1. Why DuckDB is my first choice for data processing
最后修改：2026 年 01 月 17 日
© 允许规范转载
如果觉得我的文章对你有用，请随意赞赏