DuckDB：一个正在改变数据分析方式的数据库

提到数据库，MySQL、PostgreSQL 是业务开发中最常见的选择；提到数据分析，很多开发者首先想到的是 Pandas、Spark；而在数据仓库和数据湖场景中，又会接触到 Hive、ClickHouse、Trino 等技术。

但这几年，一个名字开始越来越频繁地出现在数据分析、数据工程和 AI 应用中：DuckDB。

DuckDB 的定位非常有意思。它不是传统意义上需要独立部署的数据库服务，而是一个 嵌入式分析型数据库。它可以直接运行在 Python、Node.js、Java、Go、R、Rust 等应用程序内部，不需要单独启动数据库服务器。

这意味着，一段简单的 Python 程序，就可以拥有一个完整的 SQL 分析能力。

DuckDB 到底是什么？

理解 DuckDB，首先需要区分两种数据库形态。

MySQL、PostgreSQL 这类数据库通常采用 Client-Server 架构：

复制代码

应用程序
   ↓
MySQL / PostgreSQL
   ↓
数据库服务器
   ↓
磁盘

应用程序通过网络连接数据库，再发送 SQL。

DuckDB 则可以直接嵌入应用程序：

javascript 复制代码

Python / Node.js / Java
        ↓
      DuckDB
        ↓
CSV / Parquet / JSON / DataFrame

甚至不需要启动数据库服务。

Python 中安装 DuckDB：

复制代码

pip install duckdb

然后就可以直接执行 SQL：

ini 复制代码

import duckdb

result = duckdb.sql("""
    SELECT 1 + 1 AS result
""")

print(result)

这就是 DuckDB 最核心的特点：把一个分析型 SQL 引擎直接放进应用程序里。

最有意思的能力：直接查询文件

传统数据库的数据处理流程通常是：

sql 复制代码

CSV
 ↓
导入数据库
 ↓
创建表
 ↓
INSERT
 ↓
SELECT

DuckDB 可以跳过中间这些步骤。

例如存在一个 orders.parquet 文件，可以直接执行：

sql 复制代码

SELECT *
FROM 'orders.parquet';

甚至可以直接进行复杂的数据分析：

vbnet 复制代码

SELECT
    product_id,
    SUM(amount) AS total_amount
FROM 'orders.parquet'
GROUP BY product_id
ORDER BY total_amount DESC;

不需要提前创建表，也不需要把数据导入 MySQL。

多个 Parquet 文件也可以直接查询：

sql 复制代码

SELECT *
FROM 'data/*.parquet';

这其实体现出了 DuckDB 一个非常重要的设计理念：

数据不一定要先进入数据库，数据库也可以直接计算数据。

为什么 DuckDB 特别适合 Parquet？

DuckDB 的流行和 Parquet 的普及有很大关系。

CSV 是非常常见的数据交换格式，但它本质上是行式文本格式。

Parquet 则是针对分析场景设计的列式存储格式。

例如数据中有：

bash 复制代码

id
name
age
address
salary

如果分析任务只需要：

sql 复制代码

SELECT age
FROM users;

传统的行式数据通常需要读取一整行，而列式存储可以更加高效地读取所需要的列。

DuckDB 对 Parquet 提供了非常完善的支持，并能够利用列裁剪、过滤下推等机制减少实际读取的数据量。

于是，一种非常自然的数据处理模式出现了：

sql 复制代码

业务数据
   ↓
Parquet
   ↓
DuckDB
   ↓
SQL 分析

进一步结合对象存储，还可以形成：

复制代码

对象存储
   ↓
Parquet
   ↓
DuckDB
   ↓
数据分析

这也是现代数据工程中越来越值得关注的一种架构模式。

DuckDB 和 Pandas 是什么关系？

Python 数据分析领域长期以来都离不开 Pandas。

传统的数据处理方式可能是：

ini 复制代码

import pandas as pd

df = pd.read_csv("orders.csv")

result = (
    df.groupby("product_id")["amount"]
      .sum()
      .sort_values(ascending=False)
)

这种方式非常灵活，但随着数据处理逻辑越来越复杂，代码也可能逐渐变得复杂：

ini 复制代码

df = df.merge(...)
df = df[df["amount"] > 100]
df = df.groupby(...)
df = df.sort_values(...)
df = df.reset_index(...)

DuckDB 提供了另一种思路：

ini 复制代码

import duckdb

result = duckdb.sql("""
    SELECT
        product_id,
        SUM(amount) AS total_amount
    FROM 'orders.parquet'
    GROUP BY product_id
    ORDER BY total_amount DESC
""").df()

最终结果仍然可以转换成 Pandas DataFrame。

DuckDB 甚至可以直接查询 Pandas DataFrame：

python 复制代码

import duckdb
import pandas as pd

df = pd.DataFrame({
    "name": ["Tom", "Jack", "Jimmy"],
    "age": [18, 25, 30]
})

result = duckdb.sql("""
    SELECT *
    FROM df
    WHERE age >= 25
""").df()

因此，DuckDB 并不是为了替代 Pandas。

更准确的关系是：

Pandas 负责 Python 数据处理生态，DuckDB 负责 SQL 查询和分析计算。

两者可以组合起来使用。

DuckDB 和 Spark 有什么区别？

DuckDB 经常被拿来和 Spark 比较，因为两者都可以进行数据分析和数据处理。

但它们的设计目标并不完全相同。

Spark 更偏向于：

diff 复制代码

大规模数据
+
分布式计算
+
多节点集群
+
复杂数据工程

DuckDB 更偏向于：

diff 复制代码

单机分析
+
本地数据
+
数据探索
+
ETL
+
数据处理
+
嵌入式计算

例如一个数据团队需要处理 PB 级数据，并且需要多个节点进行分布式计算，Spark 这样的系统更加适合。

但如果只是需要分析一批 Parquet 文件：

yaml 复制代码

data/
├── 2026-01.parquet
├── 2026-02.parquet
├── 2026-03.parquet
└── ...

那么完全可以直接：

vbnet 复制代码

SELECT
    country,
    COUNT(*) AS users,
    AVG(age) AS avg_age
FROM 'data/*.parquet'
GROUP BY country;

没有集群，没有任务调度，也不需要额外部署一整套大数据系统。

所以 DuckDB 和 Spark 并不是简单的替代关系。

可以把 Spark 理解成分布式数据计算平台 ，而 DuckDB 更像是轻量级的分析计算引擎。

DuckDB 和 MySQL 有什么区别？

DuckDB 和 MySQL 的定位差异更加明显。

MySQL 更典型的使用场景是业务系统：

复制代码

用户注册
订单创建
商品查询
库存修改
支付
事务处理

这些属于典型的 OLTP 场景。

DuckDB 更关注：

复制代码

数据统计
数据聚合
报表分析
数据探索
ETL
数据处理

也就是 OLAP 场景。

例如：

ini 复制代码

SELECT *
FROM orders
WHERE user_id = 10001;

更接近业务查询。

而：

sql 复制代码

SELECT
    DATE(order_time) AS day,
    COUNT(*) AS orders,
    SUM(amount) AS revenue
FROM orders
GROUP BY day
ORDER BY day;

则属于典型的数据分析。

因此，DuckDB 并不是为了替代 MySQL。

两者解决的是不同的问题：

MySQL 更关注业务数据的读写和事务，DuckDB 更关注数据的分析和计算。

为什么 DuckDB 适合数据工程？

数据平台建设中经常会遇到一个问题：

是不是所有数据处理任务都需要大数据平台？

例如一个任务只是：

markdown 复制代码

每天几十 GB 数据
        ↓
数据清洗
        ↓
数据聚合
        ↓
生成 Parquet

如果为了这样的任务部署完整的大数据体系：

diff 复制代码

Kafka
+
Spark
+
Hive
+
YARN
+
HDFS

整个系统的复杂度可能远远超过任务本身。

DuckDB 提供了一种更加轻量的选择：

复制代码

原始数据
   ↓
DuckDB
   ↓
清洗
   ↓
聚合
   ↓
Parquet

尤其是在单机数据处理、数据探索、离线 ETL 等场景中，这种方式非常简洁。

这也是 DuckDB 在现代数据工程体系中越来越受到关注的原因之一。

DuckDB 为什么开始进入 AI 应用？

DuckDB 还有一个很值得关注的方向：AI 数据分析。

现在很多 AI 应用都开始支持这样的场景：

上传一个 Excel 或 CSV，让 AI 自动分析数据。

传统实现可能是：

markdown 复制代码

Excel / CSV
    ↓
Pandas
    ↓
Python
    ↓
LLM

而 DuckDB 可以让架构变成：

markdown 复制代码

Excel / CSV / Parquet
        ↓
      DuckDB
        ↓
        SQL
        ↓
      查询结果
        ↓
        LLM

例如用户提出：

哪个城市的销售额最高？

AI 可以将问题转换成 SQL：

vbnet 复制代码

SELECT
    city,
    SUM(amount) AS total_amount
FROM sales
GROUP BY city
ORDER BY total_amount DESC
LIMIT 1;

DuckDB 负责真正执行计算，然后把结果交给 LLM 进行解释。

这时候，AI 的职责并不是自己处理几十万行数据，而是：

理解自然语言 → 生成 SQL → 执行查询 → 解释结果。

这和现在越来越流行的 Text-to-SQL、数据分析 Agent 非常契合。

因此，对于 AI 数据分析类产品来说，DuckDB 是一个非常值得关注的基础组件。

DuckDB 真正有意思的地方，不只是"快"

介绍 DuckDB 时，经常会看到一个关键词：

快。

但 DuckDB 真正值得关注的地方并不只是性能。

它改变了传统的数据处理方式。

过去的数据处理思路通常是：

sql 复制代码

数据
 ↓
数据库
 ↓
SQL

而 DuckDB 可以变成：

复制代码

数据在哪里
 ↓
直接查询哪里

数据可以来自：

javascript 复制代码

CSV
JSON
Parquet
Pandas
Polars
Arrow
数据库
对象存储

DuckDB 可以把这些不同的数据源统一到 SQL 查询体系中。

这让 SQL 不再只是"查询数据库里的表"，而可以成为一种更加通用的数据处理语言。

DuckDB 背后的趋势是什么？

DuckDB 本身可能只是这个变化中的一个代表。

过去的数据架构经常强调：

复制代码

数据库
 ↓
数据仓库
 ↓
数据湖
 ↓
数据湖仓

数据存储和数据计算往往绑定在一起。

而现在的数据基础设施正在出现一些新的变化。

Parquet 负责数据存储，Arrow 负责数据交换，Iceberg 等技术负责数据湖表管理，而 DuckDB、Trino、Spark 等计算引擎负责处理数据。

存储和计算正在进一步解耦。

数据不一定必须先进入一个庞大的数据库系统，计算引擎可以直接访问开放的数据格式。

从这个角度来看，DuckDB 的意义就不只是"一个轻量数据库"。

它代表的是一种更加轻量的数据计算方式。

DuckDB 适合哪些场景？

从实际应用来看，DuckDB 比较适合以下几类场景。

本地数据分析。

大量 CSV、Parquet、JSON 文件需要快速分析，不希望为了临时任务部署数据库。

Python 数据处理。

Pandas 负责数据操作，DuckDB 负责复杂 SQL 查询，两者结合可以形成非常舒服的数据分析工作流。

轻量级 ETL。

数据清洗、Join、聚合、转换、生成 Parquet，都可以交给 DuckDB 完成。

数据探索。

拿到一批陌生数据后，不需要先设计数据库表结构，可以直接通过 SQL 进行探索。

AI 数据分析 Agent。

让 LLM 负责理解用户问题和生成 SQL，让 DuckDB 负责执行数据计算。

这个方向尤其值得关注。

最后

DuckDB 看起来只是一个数据库，但它真正有意思的地方并不是"又出现了一个数据库"。

它把 SQL、Python、Pandas、Parquet、数据湖和 AI 数据分析连接了起来。

传统数据库强调的是：

把数据存进去，再从数据库里查询。

DuckDB 更强调：

数据已经在那里，直接对数据进行计算。

这也是为什么 DuckDB 在数据分析、数据工程以及 AI 应用中越来越受到关注。

未来的数据处理系统未必都需要一个庞大的数据库服务。

一个文件、一套 Parquet 数据、一个计算引擎，再加上 AI，就可能完成过去需要数据库、数据仓库甚至大数据平台才能完成的一部分工作。

DuckDB 的价值，也许不在于替代 MySQL 或 Spark，而在于提供了一种更加轻量、更加贴近数据本身的计算方式。