汤不热吧在数据分析领域，SQLite 几乎成为了嵌入式 OLTP 数据库的代名词，但当你需要对几十 GB 甚至上百 GB 的数据执行复杂的聚合分析时，传统行式存储的瓶颈便暴露无遗。DuckDB 正是在这样的背景下诞生的——它被称为「分析领域的 SQLite」，一个进程内、零依赖、面向 OLAP 场景优化的列式数据库引擎。本文将从底层存储原理、向量化执行模型、SQL 扩展生态到生产环境性能调优，系统性地拆解 DuckDB 的工程实践。
一、DuckDB 是什么：重新定义嵌入式分析数据库
DuckDB 由荷兰 CWI 数据库组的核心成员（也是 MonetDB 的作者）Mark Raasveldt 和 Hannes Mühleisen 主导开发，项目于 2019 年开源，采用 MIT 协议。它的设计哲学可以用一句话概括：把一个完整的列式 OLAP 引擎塞进一个进程里，无需启动服务，无需配置连接池，直接以库的形式嵌入应用程序。
与 PostgreSQL、ClickHouse 这类需要独立部署的服务端数据库不同，DuckDB 的整个引擎编译后只是一个约 30MB 的共享库，Python 包体积不到 20MB。你可以在本地脚本、Jupyter Notebook、甚至浏览器（通过 WASM 编译版本）中直接运行复杂的分析查询，而无需搭建任何基础设施。
1.1 DuckDB 与 SQLite、ClickHouse 的定位对比
| 维度 | SQLite | DuckDB | ClickHouse |
|---|---|---|---|
| 存储模型 | 行式（B-Tree） | 列式（PAX） | 列式（MergeTree） |
| 工作负载 | OLTP（点查、写入） | OLAP（聚合、扫描） | OLAP（海量聚合） |
| 部署形态 | 嵌入式 | 嵌入式 | 服务端 |
| 并发模型 | 文件锁，单写多读 | 单进程多线程 | 分布式多节点 |
| 数据规模 | GB 级 | GB～TB 级 | PB 级 |
| 扩展生态 | 有限 | 丰富的 Scanner 扩展 | 集群化生态 |
关键区别在于：SQLite 为高频小事务和点查询优化，单行写入快但全表扫描慢；DuckDB 恰好相反，它牺牲了高频点写的吞吐，换取了在大规模数据扫描和聚合上的极致性能。这并非替代关系，而是互补——很多团队在生产中同时使用 SQLite 做业务事务存储、DuckDB 做离线分析计算。
二、列式存储与 PAX 模型：为什么扫描快 10 倍
DuckDB 采用 PAX（Partition Attributes Across） 存储模型，这是一种混合行列格式。数据被划分为固定大小的数据块（block，默认 256KB），每个块内部按列存储。这种设计既保留了列式存储在扫描时只读取所需列的优势，又保证了同一行数据在物理上相近，降低了随机 I/O。
2.1 列式存储的扫描优势
假设你有一张 1 亿行的订单表，包含 20 列，但你只需要查询
1 | SELECT SUM(amount) FROM orders WHERE region = 'CN' |
。在行式存储中，即使只需要 2 列，引擎也必须把整行数据从磁盘读入内存，导致大量无效 I/O。而列式存储只读取
1 | amount |
和
1 | region |
两列的数据，I/O 量可能减少 90% 以上。
更重要的是，DuckDB 对每一列都内置了轻量级压缩与区段统计信息（Zone Map）。Zone Map 记录每个数据块内该列的 min/max 值，查询时引擎先检查 Zone Map，如果块的范围与谓词不匹配，直接跳过该块——这就是常说的数据跳过（Data Skipping）机制。
2
3
4
5
6
7
8
9
10
11
SELECT
table_name,
column_name,
column_id,
compression,
stats_min,
stats_max,
stats_null_count
FROM duckdb_columns()
WHERE table_name = 'orders';
DuckDB 支持多种编码方式，包括 Run-Length Encoding（RLE）、Bit-Packing、Dictionary Encoding、FSST（Fast Static Symbol Table）等。引擎会根据列的数据分布自动选择最优编码。例如，低基数的枚举列适合 Dictionary Encoding，递增的时间戳列适合 RLE，而高基数字符串列则采用 FSST 这种轻量级字典压缩。
2.2 数据加载与持久化
DuckDB 的持久化数据库是一个单独的
1 | .duckdb |
文件，整个数据库的状态、数据、索引都存储在这一个文件中，这与 SQLite 的设计一脉相承。写入时使用 WAL（Write-Ahead Log）保证 ACID 特性，崩溃后通过 checkpoint 恢复。
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 持久化模式：写入磁盘
con = duckdb.connect('analytics.duckdb')
# 从 CSV 创建表并导入（自动类型推断）
con.execute('''
CREATE TABLE orders AS
SELECT * FROM read_csv_auto('orders_2024.csv')
''')
# 从 Parquet 导入
con.execute('''
INSERT INTO orders
SELECT * FROM read_parquet('orders_2025_*.parquet')
''')
# 强制 checkpoint 将 WAL 刷入主文件
con.execute('CHECKPOINT')
值得一提的是，DuckDB 的
1 | read_parquet |
、
1 | read_csv |
、
1 | read_json |
这些 Scanner 函数不仅是导入工具，它们本身就是可查询的虚拟表。你可以直接对一个 50GB 的 Parquet 文件执行 SQL 查询而不导入，引擎会利用 Parquet 的 Row Group 统计信息和 DuckDB 的向量化引擎实时扫描，性能仅比导入后略低，但省去了存储空间和导入时间。
三、向量化执行引擎：CPU 缓存友好的查询处理
DuckDB 性能的核心来源是向量化执行模型（Vectorized Execution）。传统的 Volcano 模型每次处理一行数据就要在算子之间传递一次控制流，对于现代 CPU 来说意味着大量的函数调用开销和缓存失效。向量化模型则每次处理一个向量（默认 2048 行），同一算子内的计算在 CPU 寄存器和 L1 缓存中密集执行，极大提升了 CPU 利用率。
具体来说，DuckDB 的每个算子（Scan、Filter、Hash Join、Aggregate 等）都实现了向量化接口，数据以 Arrow 兼容的列式向量在算子间流动。对于
1 | SUM(amount) |
这样的聚合，引擎会把 2048 个 amount 值一次性加载进 SIMD 寄存器，利用 AVX2/AVX-512 指令并行计算。
3.1 与 JIT 的协同
除了向量化，DuckDB 还在运行时对查询计划进行表达式 JIT 编译。它使用一个自研的轻量级编译框架，将 SQL 表达式编译为紧凑的字节码，再在向量化引擎中解释执行。与 PostgreSQL 的 LLVM JIT 不同，DuckDB 选择字节码而非机器码，避免了 LLVM 编译的高延迟，在短查询场景下表现更优。
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
EXPLAIN
SELECT
region,
COUNT(*) AS order_cnt,
SUM(amount) AS total,
AVG(amount) AS avg_amount
FROM orders
WHERE order_date >= '2024-01-01'
GROUP BY region
ORDER BY total DESC;
-- 查看实际执行统计（profile）
PRAGMA enable_profiling='json';
PRAGMA profiling_output='/tmp/plan.json';
-- 执行查询后查看 /tmp/plan.json
在 EXPLAIN 输出中你会看到
1 | HASH_GROUP_BY |
、
1 | PROJECTION |
、
1 | FILTER |
等算子，每个算子旁边标注了向量化批处理的行数。如果某个算子的 cardinality 远低于预期，通常意味着统计信息偏差或谓词无法下推。
四、SQL 扩展生态：直接查询 Parquet、JSON 与远程数据源
DuckDB 的另一个杀手锏是其Scanner 扩展体系。你不需要先把数据导入数据库再查询，几乎所有常见的数据格式和存储系统都可以直接用 SQL 查询。这让 DuckDB 成为数据管道中理想的「中间计算层」。
4.1 直接查询 Parquet 文件
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
SELECT count(*), min(ts), max(ts)
FROM read_parquet('logs/*.parquet');
-- 合并多个文件并指定模式
SELECT user_id, event, ts
FROM read_parquet(
['2024-01.parquet', '2024-02.parquet'],
union_by_name=true
);
-- 结合 Hive 分区路径
SELECT event, count(*)
FROM read_parquet('events/year=2024/month=*/day=*/*.parquet',
hive_partitioning=true)
GROUP BY event;
Hive 分区路径的自动识别非常实用：DuckDB 会解析路径中的
1 | key=value |
段，将其作为虚拟列加入查询。这样你就可以用
1 | WHERE year=2024 AND month=1 |
进行分区裁剪，引擎只会读取匹配的文件。
4.2 扩展安装与 HTTPFS
DuckDB 内置了一个扩展管理器，可以通过一条命令安装社区扩展。其中
1 | httpfs |
扩展尤为重要——它让 DuckDB 能直接读取 S3、GCS、Azure Blob 上的远程文件，无需先下载到本地。
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
INSTALL httpfs;
LOAD httpfs;
-- 配置 S3 凭证
SET s3_region='us-east-1';
SET s3_access_key_id='AKIAXXXXX';
SET s3_secret_access_key='xxxxxxxxxxxx';
-- 直接查询 S3 上的 Parquet
SELECT count(*)
FROM read_parquet('s3://my-bucket/data/2024/*.parquet');
-- 查询公网数据集（无需凭证）
SELECT count(*)
FROM read_parquet('s3://ursa-labs-taxi-data/2018/*.parquet');
httpfs 使用了智能预取和并发请求策略，对于 S3 上分片良好的 Parquet 文件，查询性能可以接近本地磁盘。配合分区裁剪，常常能在几秒内完成对 TB 级数据集的聚合查询。
4.3 其他常用扩展
- postgres_scanner：直接查询 PostgreSQL 表，常用于将 PG 中的业务数据拉入 DuckDB 做重计算
- sqlite_scanner：读取 SQLite 数据库，用于离线分析 SQLite 应用数据
- spatial：提供 GIS 函数（PostGIS 风格），支持 GeoParquet
- json：增强 JSON 解析能力，支持 JSON 查询语法
- full_text_search：基于 Tantivy 的全文检索扩展
五、Python 集成实战：Pandas 互操作与 UDF
DuckDB 的 Python 绑定是其使用最广泛的形式。它有一个让数据科学家极为兴奋的特性：零拷贝互操作 Pandas DataFrame / Polars / Arrow Table。你可以直接在 SQL 中引用一个 Python 进程内的 DataFrame，无需先注册或导入。
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
import duckdb
# 准备数据
df = pd.read_csv('sales.csv', parse_dates=['date'])
# 直接在 SQL 中查询 DataFrame
con = duckdb.default_connection()
result = con.execute('''
SELECT
date_trunc('month', date) AS month,
product_category,
SUM(revenue) AS total,
AVG(revenue) AS avg_rev
FROM df
WHERE date >= '2024-01-01'
GROUP BY 1, 2
ORDER BY 1, 3 DESC
''').df() # 结果直接转回 DataFrame
print(result.head())
这段代码背后发生的事情值得了解：DuckDB 没有把 DataFrame 复制一份再写入存储，而是通过 Arrow 的零拷贝接口直接读取 DataFrame 的内存缓冲区。对于内存中已有的 DataFrame，查询延迟往往在毫秒级。这使得 DuckDB 在数据探索阶段比 Spark SQL 快几个数量级。
5.1 注册 Python UDF
当 SQL 内置函数不够用时，可以注册 Python UDF。DuckDB 会将数据按批次传递给 Python 函数，虽然比原生函数慢，但胜在灵活。
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
def extract_domain(url: str) -> str:
# 简化示例
return url.split('/')[2].split(':')[0] if '://' in url else url
con = duckdb.connect()
con.create_function(
name='extract_domain',
function=extract_domain,
parameters=['url'],
return_type='VARCHAR',
)
# 在 SQL 中调用
print(con.execute('''
SELECT extract_domain(url), count(*)
FROM read_json('clicks.json')
GROUP BY 1 ORDER BY 2 DESC LIMIT 10
''').fetchall())
需要注意，Python UDF 因为涉及跨语言调用，性能远不如 SQL 内置函数。对于大批量数据，应优先尝试用 SQL 表达式或 DuckDB 的字符串/日期函数替代。只有在逻辑确实无法用 SQL 表达时才使用 UDF。
六、生产环境性能调优实战
虽然 DuckDB 默认配置在大多数场景下已经足够好，但在生产环境处理大表时，合理的调优可以带来数倍性能提升。以下是几个关键调优点。
6.1 内存管理
DuckDB 是内存敏感的引擎，默认会使用可用内存的 80%。如果机器内存有限或与其它进程共享，应显式限制。
2
3
4
5
6
7
8
PRAGMA memory_limit='4GB';
-- 限制线程数（默认 = CPU 核数）
PRAGMA threads=4;
-- 查看当前内存使用
SELECT * FROM duckdb_memory();
当内存不足时，DuckDB 会自动将中间结果溢写到磁盘（spill to disk）。这是它相比纯内存引擎（如 Polars）的优势之一——不会因为数据量略超内存就 OOM 失败。但溢写会带来性能下降，所以应尽量保证工作集能放入内存。
6.2 利用分区与采样加速查询
对于时间序列数据，建议在导入时按时间分区存储为多个 Parquet 文件，配合 Hive 分区路径，可以实现高效的分区裁剪。
2
3
4
5
6
7
8
9
10
11
12
COPY (SELECT * FROM events)
TO 'events/'
(FORMAT PARQUET,
PARTITION_BY (year, month),
OVERWRITE_OR_IGNORE);
-- 之后查询时自动裁剪
SELECT count(*)
FROM read_parquet('events/year=2024/month=*/day=*/*.parquet',
hive_partitioning=true)
WHERE month IN (1, 2, 3);
对于探索性分析，DuckDB 提供
1 | TABLE_SAMPLE |
和
1 | USING SAMPLE |
子句，让你在大表上快速预览数据分布。
2
3
4
5
6
7
8
9
SELECT region, avg(amount)
FROM orders USING SAMPLE 1 PERCENT
GROUP BY region;
-- 伯努利采样，可重复
SELECT region, avg(amount)
FROM orders USING SAMPLE 1 PERCENT (bernoulli, 42)
GROUP BY region;
6.3 索引与 Zone Map 优化
DuckDB 不像 PostgreSQL 那样依赖 B-Tree 索引来加速点查询，它的核心加速手段是 Zone Map（区段统计）。Zone Map 在数据写入时自动构建，但对数据物理顺序敏感——如果某列在物理上是近似有序的，Zone Map 的过滤效果会非常好；如果完全随机，Zone Map 几乎失效。
因此，在导入数据时按高频过滤列排序，是 DuckDB 中最有效的「索引优化」技巧：
2
3
4
5
6
7
CREATE TABLE orders_sorted AS
SELECT * FROM staging_orders
ORDER BY region, order_date;
-- 这样之后 WHERE region='CN' 能跳过大量数据块
SELECT count(*) FROM orders_sorted WHERE region='CN';
对于需要点查的场景，DuckDB 也支持 ART（Adaptive Radix Tree）索引，主要用于主键约束和 JOIN 加速。但 OLAP 场景下，绝大多数查询是范围扫描，Zone Map + 向量化扫描往往比索引查找更快。
6.4 处理超大数据集的策略
当数据量超过单机内存时，DuckDB 的策略是「溢写 + 流式处理」。你可以通过以下手段让查询更稳：
- 优先选择
1GROUP BY
列基数较小的查询，避免哈希表膨胀
- 对大表 JOIN 使用
1Hash Join
时，确保小表在内侧（build side），DuckDB 会自动选择但可手动干预
- 用
1CREATE VIEW
替代
1CREATE TABLE延迟物化，减少中间存储
- 对超大数据集考虑分批处理，每次查询一个分区
七、典型应用场景与最佳实践
7.1 替代 Pandas 做重型数据分析
当 Pandas DataFrame 超过内存容量时，传统做法是切换到 Spark 或 Dask。但 DuckDB 提供了更轻量的选择——它能直接扫描大于内存的 Parquet 文件集，自动溢写，无需分布式集群。一个常见模式是：用 Pandas 处理小数据，用 DuckDB SQL 处理大数据，二者通过
1 | .df() |
接口无缝衔接。
7.2 数据管道中的转换层
在 ETL 管道中，DuckDB 常被用作「轻量级转换引擎」：从 S3 读取原始 Parquet，执行清洗和聚合 SQL，再写出为优化后的 Parquet。相比 Spark，它的启动开销几乎为零，单机吞吐却毫不逊色。
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
con = duckdb.connect()
con.execute('INSTALL httpfs; LOAD httpfs;')
con.execute("SET s3_region='us-east-1';")
# 读取 S3 原始数据，聚合后写出
con.execute('''
COPY (
SELECT
date_trunc('day', event_time) AS dt,
event_name,
count(*) AS cnt,
count(DISTINCT user_id) AS uniq_users
FROM read_parquet('s3://prod-events/2024/*.parquet')
GROUP BY 1, 2
) TO 's3://aggregated/daily_events.parquet'
(FORMAT PARQUET);
''')
7.3 嵌入式 BI 与本地语义层
DuckDB 的进程内特性非常适合做嵌入式 BI：把 DuckDB 编译进桌面应用或 Electron 应用，让用户在本地对导出的数据集执行 SQL 查询，无需连接远程数据库。配合 dbt 等语义层工具，DuckDB 还能作为本地分析语义层的执行引擎，实现「SQL 仓库离线版」的体验。
八、常见陷阱与排雷
最后总结几个实战中容易踩的坑：
- 不要把 DuckDB 当 OLTP 用：高频单行 INSERT 性能很差，批量写入才符合它的设计假设。如果必须写入流数据，建议先用内存 buffer 累积，再批量 flush。
- 连接是进程级的，不是线程安全的写：同一个
1.duckdb
文件同时只能被一个写连接打开。读连接可以并发，但写连接需要串行。多进程场景下推荐用主从架构或外部协调。
- Checkpoint 时机影响写入吞吐：默认自动 checkpoint 在 WAL 超过一定大小时触发，可能导致写入延迟抖动。可以手动
1CHECKPOINT
控制时机，或调整
1PRAGMA auto_checkpoint阈值。
- Parquet 文件的 Row Group 大小：太大不利于并行，太小带来元数据开销。DuckDB 默认 122880 行/Row Group，写出自定义 Parquet 时可参考。
- 慎用 SELECT *：列式存储下，
1SELECT *
会强制读取所有列，丧失列裁剪优势。永远只选需要的列。
掌握以上原理与技巧后，DuckDB 可以成为你工具箱中一把趁手的「分析瑞士军刀」。它不会替代分布式数据仓库，但在单机分析、数据管道转换、嵌入式 BI 这几个场景中，它提供的开发体验与性能平衡是当前同类产品中最优秀的之一。如果你还在为 Pandas 内存不足而切到 Spark 的重负载烦恼，不妨先用 DuckDB 试一次——很多时候，你需要的不是分布式，而是一个足够好的单机列式引擎。