DuckDB 1.5 深度实战：当分析型数据库压缩进一个文件，我们为什么还需要 Spark？
0. 引子：一个被过度设计的世界
如果你在 2026 年还在做数据分析，大概率经历过下面三种尴尬之一：
- 用 Pandas 读一个 3GB 的 CSV，
read_csv还没跑完，你的 16G 内存条已经先一步举手投降，Jupyter 内核默默重启； - 为了跑一个"其实并不大"的聚合查询，运维同学给你拉起一个三节点的 Spark 集群，光等 YARN 分配资源就花了八分钟，而真正的计算只用了十一秒；
- 或者，你把数据塞进 MySQL 跑
GROUP BY，然后眼睁睁看着它在几百万行上做全表扫描，索引在COUNT(DISTINCT)面前形同虚设。
这背后是一个被过度设计的世界：我们手里拿的是一把瑞士军刀（Pandas）、一台推土机（Spark）和一把螺丝刀（MySQL），却总是在用错的那把去拧眼前这颗螺丝。
2024 年底到 2026 年，一个叫 DuckDB 的项目悄悄爬上了 GitHub Trending 的常驻榜单，社区里甚至出现了"数据分析界的 SQLite"这种说法。到 2026 年 7 月，它已经迭代到 1.4.2 LTS / 1.5.x 系列，新增了 Quack 远程协议、DuckLake 湖仓格式、完整的 Iceberg 读写能力。它做的事情极其朴素：把一台分析型数据库（OLAP）塞进一个几百 KB 的进程内库，让你用一句 SQL 直接查 CSV、Parquet、JSON，甚至直接 JOIN 你线上正在跑的 MySQL 和 PostgreSQL。
这篇文章不打算给你念一遍官方文档，而是从一个写过 Pandas、踩过 Spark 坑、被 OLAP 性能折磨过的工程师视角，把 DuckDB 的架构原理、实战代码、性能边界和选型决策彻底拆开讲清楚。读完你应该能回答一个问题：在你的下一个数据分析需求里，DuckDB 到底能替掉多少"重武器"？
1. 背景介绍：数据分析的三重困境
1.1 Pandas 的"内存墙"
Pandas 是数据科学的国民工具，但它的设计哲学是把所有数据一次性搬进内存，再在行上循环。这带来两个致命问题：
第一，内存占用是数据本身的数倍。DataFrame 为了支持随机访问和 dtype 对齐，会有大量指针、对象头和副本开销。一个 2GB 的 CSV，在内存里常常膨胀到 6~10GB。
第二，执行是单线程的解释型循环。Pandas 的很多操作底层是 Python 层的 for-loop 或 CPython 调用，无法利用现代 CPU 的 SIMD 向量指令，也无法自动并行到多核。你买了 16 核的 M 系列芯片，Pandas 却只用其中 1 个核在苦哈哈地跑。
1.2 Spark 的"运维墙"
Spark 解决了规模和并行的问题，但代价是运维复杂度。一个最小的可用集群需要 Driver + 至少一个 Worker + 一个资源管理器（YARN/K8s）。它的执行模型是为 TB~PB 级数据设计的，当你只有几十 GB 数据时，调度开销、shuffle 网络和 JVM GC 会吃掉大量时间。更别提调参（executor 内存、并行度、分区数）本身就是一门玄学。
很多团队用 Spark 不是因为数据真的大到了必须分布式的程度，而是因为"以前就是这么干的"。
1.3 传统数据库的"OLAP 墙"
MySQL、PostgreSQL 擅长 OLTP（事务、点查、小范围更新），但在分析型查询（大表聚合、COUNT(DISTINCT)、多表宽 JOIN、窗口函数）上，它们是被设计用来做别的事的。行式存储让列扫描极其昂贵，查询优化器也不是为分析负载调校的。于是催生了"把数据从业务库 ETL 到 ClickHouse/数据仓库再做分析"的漫长链路。
1.4 DuckDB 的定位：SQLite 的分析型孪生兄弟
DuckDB 团队自己给的定位非常清晰：它是 SQLite 的分析型兄弟。
| 维度 | SQLite | DuckDB |
|---|---|---|
| 存储模型 | 行式（OLTP） | 列式（OLAP） |
| 典型负载 | 事务、点查 | 聚合、扫描、分析 |
| 嵌入方式 | 进程内库 | 进程内库 |
| 设计目标 | "永远在线的小型数据库" | "数据分析师的本地引擎" |
它和 SQLite 一样不需要服务器进程，一个 .duckdb 文件就是全部；但它把内部引擎整个换成了为分析优化的列式 + 向量化执行。这意味着你在笔记本上就能获得接近专业数仓的查询速度，而部署成本和 SQLite 一样接近于零。
2. 核心概念：DuckDB 到底是什么
在动手写代码前，先把几个核心概念钉死，否则后面会越看越糊涂。
2.1 嵌入式（Embedded）：它不是服务，是库
DuckDB 不是一个你要 systemctl start 的服务。它是被 import 进你进程的库。你写的 Python 脚本、R 脚本、甚至 Node.js 进程里，DuckDB 就运行在那里。没有网络协议、没有连接池、没有鉴权中间件——查询直接在你进程的地址空间里跑。
这带来一个被很多人忽略的巨大优势：零序列化开销。Pandas 读 MySQL 要经过网络 → 协议解析 → 反序列化 → 拷贝进 DataFrame；DuckDB ATTACH 一个 MySQL 后，查询计划可以直接把谓词下推到远端，只把需要的列和行拉回来。
2.2 OLAP 优化：为"扫很多行、碰很少列"而生
分析负载的典型特征是：一次扫描几百万行，但只关心其中 3 个列，做聚合。行式存储（MySQL）要把每行所有列都读出来再丢弃，I/O 浪费严重；列式存储（DuckDB）只读取那 3 个列的数据块，I/O 直接砍掉 90%。
2.3 列式存储 vs 行式存储（一眼看懂）
假设有一张 users(id, name, age, city) 表：
行式（MySQL 磁盘排布）：
[1,Alice,30,Beijing][2,Bob,25,Shanghai][3,Carol,28,Shenzhen]...
列式（DuckDB 磁盘排布）：
id: [1,2,3,...]
name: [Alice,Bob,Carol,...]
age: [30,25,28,...]
city: [Beijing,Shanghai,Shenzhen,...]
当你执行 SELECT AVG(age) FROM users，DuckDB 只读取 age 这一列连续的内存块，用向量化指令一次性算出平均值；MySQL 则要逐行把整条记录从磁盘读上来，再挑出 age。数据越大，差距越夸张。
2.4 向量化执行引擎（Vectorized Execution）
这是 DuckDB 快的真正秘密，下一章会展开。一句话预告：它不一次处理一行，而是一次处理一批（batch，通常 2048 行）的列式数据，配合 SIMD 指令，让 CPU 的吞吐量发挥到极致。
2.5 进程内零拷贝与 Arrow 互操作
DuckDB 内部用 Apache Arrow 的内存格式表示列数据块。这意味着它可以和 Pandas、PyArrow、Polars 之间做几乎零拷贝的转换——不发生逐行 Python 对象转换，而是直接把 Arrow 缓冲区的指针交出去。这是它和 Python 生态能无缝协作的底层原因。
3. 架构分析：它凭什么这么快
这一章是全文的技术心脏。理解了执行模型，你才会明白为什么"同样的 SQL，DuckDB 比 Pandas 快 10~100 倍"。
3.1 执行模型：从 Volcano 到向量化批处理
传统数据库（以及早期的很多引擎）用 Volcano 模型（迭代器/pull 模型）：每个算子实现一个 next() 方法，每次返回一行，上层算子不断调用 next() 拉取。问题在哪？每一次 next() 都是一次函数调用，每行数据都要走一遍虚函数分发，CPU 的分支预测和流水线被频繁打断，而且一行只有一条记录，SIMD 完全用不上。
DuckDB 用的是向量化批处理模型：每个算子一次产出/消费一个列向量（Vector，一批连续同类型的值，默认 2048 行）。算子内部是对整块数据做紧凑循环，编译器能很好地优化，CPU 能发射 SIMD 指令（比如一条指令同时比较 8/16/32 个整数）。
3.2 向量化到底怎么工作（示意）
假设我们要算 SELECT SUM(amount) FROM orders WHERE amount > 100：
行式解释型（Pandas 风格的慢路径）：
# 伪代码：单行循环，每行一次函数调用，无法 SIMD
total = 0
for row in orders: # 每行一次 Python 层迭代
if row.amount > 100: # 分支、对象属性访问
total += row.amount
向量化（DuckDB 的真实路径）：
1. Scan 算子：从磁盘读入 2048 行的 amount 列 → 一个连续的 float64 数组
2. Filter 算子：对整个数组做 SIMD 比较 amount > 100，产出一个"有效位图"
3. Aggregate 算子：对位图为 1 的元素做 SIMD 求和累加
一次处理 2048 行，比较和求和都是 CPU 级的批量操作。当数据量到百万、千万级，这种模型对行式循环的优势是数量级的。
3.3 为什么 Pandas 慢、DuckDB 快（直说）
- Pandas 的
df[df.amount > 100].amount.sum()虽然底层用了 NumPy 向量化（这一句其实不慢），但多步链式操作会产生大量中间 DataFrame 副本，每个副本都要分配内存、拷贝数据；而 DuckDB 的查询是一个完整编译后的流水线（pipeline），数据在算子间以列块流动，几乎不产生中间物化。 - Pandas 默认单线程；DuckDB 会自动把 Scan、Aggregate、Join 并行到所有 CPU 核。
- Pandas 读 Parquet/CSV 后是"死"的 Python 对象；DuckDB 直接以列式块在分析，且能边读边下推过滤（读 Parquet 时只看满足条件的 row group）。
3.4 存储层：直接"吃" Parquet / CSV / JSON
DuckDB 最让人上瘾的特性之一：你不需要导入数据，直接查文件。
-- 一行 SQL 查一个 10GB 的 Parquet 文件，DuckDB 自己处理分块、谓词下推
SELECT city, COUNT(*) AS n
FROM 's3://my-bucket/events/*.parquet'
WHERE event_date >= DATE '2026-07-01'
GROUP BY city
ORDER BY n DESC;
这里的关键能力是 Parquet 的谓词下推（predicate pushdown）和数据跳过（data skipping）：
- Parquet 文件按 row group 分块存储，每个 row group 在文件 footer 里记录了每列的最小值/最大值（min/max statistics）。
- DuckDB 读取时，先扫 footer 的统计数据，如果某个 row group 的
event_date范围完全不在[2026-07-01, ∞)内，整个 row group 直接跳过，连解压都不用做。 - 同样，它只读取
city和event_date两列对应的 column chunk，其他几十列碰都不碰。
这就是为什么"查一个大文件里两列"在 DuckDB 里几乎是瞬时的，而在 Pandas 里你得先 read_parquet(columns=[...]) 且仍要解析整个文件结构。
3.5 扩展机制与 ATTACH 联邦查询
DuckDB 的核心二进制刻意保持轻量，高级能力通过**扩展（extension）**动态加载。MySQL、PostgreSQL、Iceberg、Delta、HTTP、JSON、Spatial 等都是扩展，首次使用自动下载安装（autoload）。
它的 ATTACH 机制是联邦查询的灵魂：你可以把不同数据源"挂载"成当前连接里的若干个 catalog/schema，然后用一条 SQL 跨源 JOIN。这正是后面代码实战的重点。
3.6 1.5 系列新引擎：Quack 与 DuckLake
2026 年的 1.5.x 系列把 DuckDB 从"单机嵌入式"推向了"可协作、可湖仓"：
- Quack（1.5.3 起作为核心扩展）：一个远程查询协议，让 DuckDB 能作为客户端-服务器数据库运行。一个进程
CALL quack_serve()起服务，其他机器上的 DuckDB 通过ATTACH 'quack:host'连上来，把本地嵌入式库变成一个小集群。官方计划 2026 年秋季随 v2.0 发布生产就绪版本。 - DuckLake：DuckDB 自己的开放式湖仓格式（类似 Iceberg，但更轻），把元数据管理和数据存储解耦，支持 ACID、时间旅行、Schema 演进，且元数据可以存在 DuckDB 本身里。
- Iceberg 完整读写（1.5.3）：支持 MERGE INTO、ALTER TABLE、分区转换（partition transforms）、Iceberg v3 规范（二进制删除向量、VARIANT 类型等）。这意味着 DuckDB 能直接读写数据湖里的 Iceberg 表，成为 Lakehouse 查询引擎。
这些信号说明 DuckDB 的野心已经不只是"本地分析库"，而是想吃掉"轻量数仓/湖仓查询"这一整层。
4. 代码实战
光讲原理没用，下面全部是可运行的真实代码（以 DuckDB 1.5.x 为准）。
4.1 五分钟上手：Python 直接查文件
pip install duckdb pyarrow
import duckdb
# 连一个内存库（不落盘）；也可 duckdb.connect('analytics.duckdb') 持久化
con = duckdb.connect()
# 直接查一个 Parquet 文件，无需先"导入"
con.sql("""
SELECT language, COUNT(*) AS repo_count
FROM 'https://github.com/deriv-dev/awesome/*.parquet' -- 也支持通配与 http(s)
GROUP BY language
ORDER BY repo_count DESC
LIMIT 5
""").show()
# 直接查 CSV，自动类型推断
res = con.sql("SELECT * FROM 'sales_2026.csv' WHERE amount > 1000")
print(res.fetchall())
注意：上面用 con.sql(...) 返回的是 DuckDB 的 Relation 对象（惰性），调用 .show() / .fetchall() / .df() 才真正物化。这种惰性让你可以在物化前继续链式变换，DuckDB 会整体优化。
4.2 与 pandas / Arrow 零拷贝互操作
这是它能无缝替换 Pandas 工作流的关键：
import duckdb, pandas as pd, pyarrow as pa
# Pandas → DuckDB（零拷贝，DuckDB 直接引用 Arrow 缓冲区）
df = pd.read_csv('events.csv') # 假设已经有个 DataFrame
rel = duckdb.relation_from_df(df) # 不拷贝数据
duckdb.sql("SELECT event, COUNT(*) c FROM rel GROUP BY event").show()
# DuckDB → Pandas（仍是 Arrow 零拷贝转 DataFrame）
pdf = con.sql("SELECT * FROM 'big.parquet' LIMIT 100000").df()
# DuckDB → Arrow Table（最推荐，零拷贝，给 Polars/训练框架用）
arrow_tbl: pa.Table = con.sql(
"SELECT * FROM 'features.parquet'"
).fetch_arrow_table()
# 直接喂给 PyTorch（Arrow → numpy 再 → tensor）
import torch
tensor = torch.from_numpy(arrow_tbl.to_pandas().to_numpy())
经验法则：在 DuckDB 里做完所有聚合/过滤，最后只把需要的那一小撮结果 .df() 给 Pandas 画图，避免把大表搬进 Pandas。
4.3 替代 ETL：CSV → Parquet → 分析
很多"脏活"其实不需要 Spark：
# 把一大批 CSV 转成按日期分区的 Parquet（DuckDB 直接读目录通配）
con.sql("""
COPY (
SELECT *,
CAST(event_date AS DATE) AS dt
FROM 'raw_logs/*.csv'
WHERE event_date IS NOT NULL
) TO 'clean_logs/' (FORMAT PARQUET, PARTITION_BY (dt), COMPRESSION ZSTD)
""")
# 之后分析直接扫分区目录，谓词下推自动只碰对应日期的分区
con.sql("""
SELECT dt, COUNT(*) FROM 'clean_logs/' WHERE dt >= DATE '2026-07-01'
GROUP BY dt
""").show()
COPY ... TO ... (PARTITION_BY) 是 DuckDB 的隐藏利器：一行 SQL 完成"读 CSV → 清洗 → 按列分区写出 Parquet"，性能比 Python 逐文件处理高一个量级，且输出就是 Hive 风格分区目录，下游 Spark / Trino / 任何支持 Parquet 的工具都能直接读。
4.4 联邦查询：ATTACH MySQL，跨源 JOIN
这是最能体现"工程师爽点"的场景——线上 MySQL 跑着业务数据，你想分析，但不想写 ETL 把数据导出来：
import duckdb
con = duckdb.connect()
# 1. 加载 MySQL 扩展
con.sql("INSTALL mysql; LOAD mysql;")
# 2. 挂载线上库（只读是默认，注意权限与网络）
con.sql("""
ATTACH 'host=mysql-prod port=3306 user=analyst password=*** database=shop'
AS myshop (TYPE mysql, READ_ONLY)
""")
# 3. 本地 Parquet 的订单事实表 JOIN 远端 MySQL 的用户维表
con.sql("""
SELECT u.country,
SUM(o.amount) AS gmv,
COUNT(DISTINCT o.user_id) AS buyers
FROM 'orders_2026.parquet' AS o
JOIN myshop.shop.users AS u
ON o.user_id = u.id
WHERE o.created_at >= TIMESTAMP '2026-07-01'
GROUP BY u.country
ORDER BY gmv DESC
""").show()
这里 DuckDB 会把 u.country、u.id 的过滤和投影下推到 MySQL 执行，只把必要数据拉回本地再做 JOIN 和聚合。对分析师来说，MySQL 和 Parquet 在一个 SQL 里平等对待，心智负担骤降。
PostgreSQL 同理（用 postgres 扩展 / postgres_scanner），甚至还有把 DuckDB 引擎反向嵌入 PostgreSQL 的 pg_duckdb 扩展——在 PG 里直接 SELECT 云上的 Parquet 数据，无需 CDC 搬运。
4.5 数据湖实战：DuckLake + Iceberg
想用开放表格式但不想养一套重量级 catalog？DuckDB 1.5.3 直接读写 Iceberg，且自带 DuckLake：
con = duckdb.connect()
# 方式 A：DuckLake（元数据存 DuckDB 自身，数据可放本地/S3）
con.sql("INSTALL ducklake; LOAD ducklake;")
con.sql("""
ATTACH 'ducklake:my_lake' AS lake
(TYPE DUCKLAKE, DATA_PATH 's3://my-bucket/lake-data/')
""")
con.sql("""
CREATE TABLE lake.main.sales AS
SELECT * FROM 's3://my-bucket/raw/sales_2026.parquet'
""")
# 时间旅行 + Schema 演进都是 DuckLake 原生支持
# 方式 B：直接读写已有 Iceberg 表（1.5.3 支持 MERGE/ALTER/V3）
con.sql("INSTALL iceberg; LOAD iceberg;")
con.sql("""
ATTACH 's3://warehouse/' AS ice (TYPE ICEBERG)
""")
con.sql("""
MERGE INTO ice.db.orders t
USING 'new_orders.parquet' s
ON t.order_id = s.order_id
WHEN MATCHED THEN UPDATE SET t.amount = s.amount
WHEN NOT MATCHED THEN INSERT *
""").show()
这意味着"湖仓一体"不再必须是 Spark + 独立 catalog 服务（如 AWS Glue / Unity Catalog）的专属。一个进程、几条 SQL，你就能对 Iceberg 表做 MERGE 增量更新。
4.6 CLI 1.5：带配色和分页器的终端
1.5.0 把命令行客户端彻底翻新了，对喜欢在终端里鼓捣数据的人非常友好：
duckdb analytics.duckdb
-- 全新配色（暗/亮色，可自定义高亮）
.highlight_colors column_name darkgreen bold_underline
.highlight_colors numeric_value red bold
-- 动态提示：实时显示当前库/schema
memory D ATTACH 'shop.duckdb' AS shop;
shop D USE main;
-- 内置分页器、自动补全、便捷点命令，体验接近 psql 但更顺手
4.7 Quack：把 DuckDB 变成 C/S（1.5.3）
多人协作、或想让 DuckDB 跨进程共享一个库时：
-- 服务端（某台机器）
CALL quack_serve('quack:0.0.0.0:6543', token='super_secret');
CREATE TABLE shared AS FROM VALUES ('hello') v(msg);
-- 客户端（另一台机器上的任意 DuckDB）
CREATE SECRET (TYPE quack, TOKEN 'super_secret');
ATTACH 'quack:server-host:6543' AS remote;
FROM remote.shared;
注意 Quack 仍是 beta，协议/函数名可能变动，生产就绪预计随 v2.0（2026 秋）。但它清晰地展示了 DuckDB 不想只做"单机玩具"。
5. 性能优化：从"能用"到"飞起"
会写 DuckDB 和把 DuckDB 跑满是两回事。下面是来自实战的优化清单。
5.1 与 Pandas 的基准对比（可自己跑）
import duckdb, pandas as pd, time, pyarrow.parquet as pq
# 造一个 1 亿行的 Parquet
N = 100_000_000
# （用 DuckDB 自己造最快，见下）
con = duckdb.connect()
con.sql(f"""
CREATE TABLE t AS
SELECT i AS id,
(i * 2654435761 % 1000000) AS user_id,
(i % 50) AS category,
(random() * 1000)::DOUBLE AS amount
FROM range({N}) tbl(i)
""")
con.sql("COPY t TO 'bench.parquet' (FORMAT PARQUET)")
# ---- Pandas 路径 ----
df = pd.read_parquet('bench.parquet')
t0 = time.time()
r_pandas = df[df.amount > 500].groupby('category').amount.sum()
print("pandas:", time.time() - t0)
# ---- DuckDB 路径 ----
t0 = time.time()
r_duck = con.sql("""
SELECT category, SUM(amount)
FROM 'bench.parquet'
WHERE amount > 500
GROUP BY category
""").fetchall()
print("duckdb:", time.time() - t0)
在典型笔记本上，DuckDB 通常是 Pandas 的 5~50 倍（取决于列数、过滤选择性、是否命中并行），且 DuckDB 的内存占用远低于 Pandas 先 read_parquet 再过滤的峰值。
5.2 内存与并行：把硬件吃满
DuckDB 默认会用所有 CPU 核，并尽可能用内存。你可以用配置显式控制：
con = duckdb.connect(config={
'threads': 8, # 并行度，默认 = 核数
'memory_limit': '8GB', # 内存上限，超出则溢出到磁盘
'perfect_arrow_string': True,
})
- 数据超出内存怎么办：DuckDB 支持溢出到磁盘（spilling），设置
memory_limit后，超出部分自动落盘，不会像 Pandas 那样直接 OOM。这对"单机处理比内存大"的数据集是救命特性。 - 并行不是免费的：如果查询本身很小（几 MB），并行调度反而有开销，别为小查询硬开多线程。
5.3 Parquet 分区与投影下推
两个让大数据查询起飞的习惯：
- 用分区目录存数据：
COPY ... TO 'dir/' (PARTITION_BY (dt, country))，查询时WHERE dt = '2026-07-11'会自动只扫对应子目录。 - 只 SELECT 需要的列：DuckDB 的投影下推意味着
SELECT a, b只读这两列的物理块，列越少越快。
-- 好：只碰两列 + 分区裁剪
SELECT country, SUM(amount)
FROM 'clean_logs/dt=2026-07-11/' -- 分区已被 WHERE 锁定
GROUP BY country;
-- 差：SELECT * 强制读所有列
SELECT * FROM 'clean_logs/';
5.4 常见反模式（踩坑预警）
con.sql(...).df()全量拉进 Pandas 再处理：等于把 DuckDB 的优势全扔了。尽量在 SQL 里把聚合/过滤做完。- 逐行
for row in con.fetchall()然后 Python 循环：DuckDB 返回后就是 Python 对象，循环又变慢路径。需要行级处理时，考虑用 SQL 的UNNEST、窗口函数或写成 UDF 在引擎内跑。 - 隐式类型转换：
'2026-07-01'字符串和DATE列比较时若没显式CAST，可能失去谓词下推。养成用DATE '2026-07-01'字面量的习惯。 - 在事务库上跑重分析阻塞业务：
ATTACH mysql默认只读，但仍会占用源库连接和资源，生产上务必用只读副本，别直接打主库。 - 小文件过多：成千上万个几 KB 的 Parquet 会让元数据开销爆炸，先用
COPY合并成合理大小（如每个 128MB~1GB）。
5.5 与 Spark 的取舍：什么时候该上 Spark
DuckDB 不是银弹。一张决策表：
| 场景 | 选 DuckDB | 选 Spark |
|---|---|---|
| 单机、数据 ≤ 内存的数十倍 | ✅ | ❌ 过度设计 |
| 分析师本地探查 / notebook | ✅ | ❌ |
| 需要多机横向扩展、PB 级 | ❌ | ✅ |
| 高并发、多租户服务端查询 | ❌ | ✅ |
| 复杂流式（streaming）管道 | ❌ | ✅ |
| 一次性 ETL、CSV→Parquet 清洗 | ✅ | ⚠️ 杀鸡用牛刀 |
经验：数据能在单台机器（哪怕是 1TB 内存的云主机）上跑完的 80% 分析需求，DuckDB 都够用。超出这个边界再考虑 Spark。
6. 总结与展望
6.1 选型决策树
你有一个数据分析需求
│
├─ 需要多机分布式 / PB 级 / 高并发服务？
│ └─ 是 → Spark / Trino / ClickHouse
│
├─ 需要实时流式管道？
│ └─ 是 → Flink / Kafka Streams
│
└─ 否（单机、探索性、批处理、本地分析）→ DuckDB
├─ 文件分析（CSV/Parquet/JSON）→ 直接查
├─ 跨源分析（MySQL/PG/对象存储）→ ATTACH 联邦
├─ 湖仓表 → DuckLake / Iceberg 扩展
└─ 多人共享 → Quack（beta）/ MotherDuck 云
6.2 DuckDB 的边界（诚实地说）
- 写并发：DuckDB 是单写者模型，不支持像 PostgreSQL 那样的高并发多写。它适合"分析/读多写少"，不适合做高并发事务后端。
- 超大规模：单机能吃的数据量有物理上限（内存 + 磁盘），真到 PB 级还是要分布式。
- 服务端多租户：没有内置的权限/配额/连接治理，直接当多租户查询服务用有风险（Quack 在补这块，但还没 GA）。
6.3 生态演进：它要去向哪里
- MotherDuck：DuckDB 的商业云版本，把本地库和云端实例无缝同步，形成"本地快、云端协作"的混合模式，已经在不少团队替代轻量数仓。
- DuckLake：自己下场定义开放湖仓格式，和 Iceberg / Delta 正面竞争，但更轻、元数据用 DuckDB 自身管理。
- v2.0（预计 2026 秋）：Quack 远程协议计划随 v2.0 进入生产就绪，意味着 DuckDB 会正式拥有"嵌入式 + 客户端-服务器"双形态。
写在最后
DuckDB 最迷人的地方，是它把"分析型数据库"这件过去需要一整个团队、一堆服务器才能做的事，重新收敛回一个进程、一个文件、一句 SQL。它不试图取代 Spark，而是取代"为了一个小分析需求不得不请出 Spark"的那些过度设计。
对于一个每天和数据打交道的工程师来说，工具箱里多一个"快、轻、能直接查一切"的嵌入式引擎，意味着你可以用十分之一的成本，回答过去要花一上午才能回答的问题。下次当你又准备 kubectl apply 一个 Spark 作业时，先问一句：这事儿，DuckDB 在你的笔记本上能不能三十秒跑完？
如果答案是能——那就别把推土机开进花园了。