【列存引擎内核】ClickHouse 和 DuckDB 怎么选

前两篇 DuckDB 专题（架构（第 11 篇）、Pipeline（第 12 篇））与 ClickHouse 主系列（MergeTree、Distributed、运维）放在一起，读者自然问：同一 OLAP 问题该用谁？

本文给 决策树与组合架构，不做「谁快 10 倍」类结论——WRITING_GUIDE 要求性能判断须实测或引用；此处两者工作负载差异太大，虚构数字无意义。

一、先别把它们当成同一类产品

flowchart TB
  Q[分析需求]
  Q -->|远程多用户 PB 级| CH[ClickHouse 集群]
  Q -->|进程内 TB 级| DUCK[DuckDB]
  Q -->|PG 库内加速| PGD[pg_duckdb]
  Q -->|湖仓 Parquet 探查| DUCK
  CH --> PG[(PostgreSQL CDC)]
  DUCK --> PG

二、五维对比矩阵

2.1 部署与接入

2.2 数据规模与持久化

Refer Merge（第 06 篇） vs DuckDB checkpoint。

2.3 并发与 QPS

不列 QPS 数字——须用业务 query mix 压测。

2.4 SQL 与生态

2.5 运维与故障域

三、决策树（文字版）

START
├─ 是否需要独立 SQL 服务供多团队/BI 远程访问？
│   ├─ 是 → 倾向 ClickHouse（或 Trino/StarRocks 等，本文边界外）
│   └─ 否 → 继续
├─ 数据是否已在 Parquet/CSV 文件 / S3，仅偶尔分析？
│   ├─ 是 → 倾向 DuckDB（read_parquet/httpfs）
│   └─ 否 → 继续
├─ 持续 ingest > 单机磁盘 IO 或需副本 HA？
│   ├─ 是 → ClickHouse ReplicatedMergeTree + Distributed
│   └─ 否 → 继续
├─ 是否必须嵌在 Python/R 进程且无运维？
│   ├─ 是 → DuckDB
│   └─ 否 → 继续
├─ 是否已有 PostgreSQL 且只想加速 ANALYTICAL 查询？
│   ├─ 是 → 评估 pg_duckdb vs CH 外表副本
│   └─ 否 → 按团队技能 CH/DuckDB 二选一
END

四、组合架构模式

4.1 PG + ClickHouse 分析副本

• OLTP 在 PG（postgresql-kernel）；
• CDC / 批量导出到 CH MergeTree；
• 复杂聚合、日志级 scan 走 CH。

DuckDB 不承担中心仓，除非规模小。

4.2 PG + pg_duckdb

• 同一实例，分析查询路由 DuckDB 执行；
• 适合 数据量中小、不想运维第二套集群；
• 与 CH 副本相比：少网络 hop，多 PG 资源争用。

4.3 DuckDB 边缘 + ClickHouse 中心

• 边缘设备 DuckDB 预聚合；
• 周期性 upload 汇总行到 CH Distributed；
• IoT / 门店场景。

4.4 数据科学 DuckDB + 生产 CH

• 分析师本地 DuckDB 拉 Parquet sample；
• 生产 truth 在 CH——避免直连生产大 scan。

五、与 PostgreSQL 生态位

PG B-Tree 索引语义 与 CH 排序键（第 07 篇） 不同——迁 schema 时勿照搬 PRIMARY KEY 含义。

六、与 LSM / 行存边界

LSM 系列 写优化 ingest（Kafka → CH 也常并存）；DuckDB 不取代 Kafka consumer 集群。行存 InnoDB/PG 做源库，列存做 读优化副本——铁三角见 系列 index。

七、成本维度（非 benchmark）

八、何时两者都用

合法且常见：

1. CH 生产仓 + DuckDB 本地复现 bug（拉 sample Parquet）；
2. CH 存全量 + DuckDB 做 ML feature export；
3. 不同团队技能栈——数据平台 CH，研究 DuckDB。

避免：双写全量 无同步机制——必不一致。

九、反模式

十、评估清单（POC 设计）

POC 应 固定 query mix 与数据规模，记录：

1. 环境：CPU、RAM、磁盘、版本号；
2. 负载：并发、insert batch size、SELECT 比例；
3. 指标：p50/p95 延迟、吞吐、磁盘、失败率；
4. 运维：备份、升级、故障注入（杀进程、断网）；
5. 结论：业务 SLA 是否满足——不输出跨团队通用排名。

十一、学术坐标：选型旁的论文地图（非排名）

决策树回答「部署形态」；下表回答「文献里各自优化什么」——不能用来宣称谁更快。

11.1 争论：统一引擎 vs 双栈

• 统一引擎：一个系统扛 OLTP+OLAP 或「一个 OLAP 打天下」——HTAP / 湖仓路线见 db-frontier/12、lakehouse。
• 双栈（本系列默认工程判断）：PG/行存 OLTP + CH 服务分析 + DuckDB 本地探查——与 C-Store「读写存储分离」精神一致，但是 产品边界分离，不是单进程 WS/RS。

无顶会结论要求所有组织选同一栈；POC 须固定 query mix（第十节）。

11.2 开放问题

1. pg_duckdb 是否侵蚀「独立 CH 集群」的中小规模市场？ 可检验：同一报表在 PG 扩展 vs CH 副本的运维人天与 SLA（入口：pg_duckdb 文档；本篇决策树）。
2. 湖上 DuckDB / CH 谁更适合作为 Iceberg 交互层？ 见 query-engine / lakehouse；本篇不展开。
3. 向量化引擎是否应统一 morsel API？ 研究侧开放；生产以各项目 release 为准。

十二、小结

• 服务化、大规模、高 ingest、副本 HA → ClickHouse 主系列能力栈；
• 嵌入、文件分析、联邦探查、轻运维 → DuckDB；
• PG 内分析 → pg_duckdb vs CH 副本按规模与组织分工。

无银弹；组合架构多于单选。论文坐标（C-Store / X100 / morsel / Kersten）解释 为何分工，不替代 POC。

附录 A、场景叙事（无性能数字）

A.1 中心化日志平台

特征：PB 级、数千 QPS ingest、多团队 SQL、副本 HA。
选型：ClickHouse ReplicatedMergeTree + Distributed + Kafka MV（第 10 篇）。
DuckDB 位置：分析师本地 sample Parquet，不扛生产 ingest。

A.2 电商 PG 库内报表

特征：单 PG 实例、<1TB 分析表、无专职 CH 运维。
选型：pg_duckdb 或 periodic export + DuckDB notebook。
何时升级到 CH：PG CPU/IO 被分析打满、需独立 SLA。

A.3 数据科学笔记本

特征：S3 Parquet、单用户、交互探索。
选型：DuckDB read_parquet / httpfs。
CH 仅在需共享 dashboard 服务时叠加。

A.4 边缘门店汇总

特征：断网、本地聚合、周期性 upload。
选型：门店 DuckDB 预聚合；中心 ClickHouse 收汇总行。
注意 upload batch 避免中心 too many parts。

A.5 合规数据不出 VPC

特征：敏感数据、禁止第三方 SaaS 分析。
两者均可自建；CH 集群运维更重，DuckDB 嵌入应用更轻——按 运维编制 而非技术绝对优劣。

A.6 HTAP 幻想警示

特征：期望一套系统 OLTP+实时大屏。
现实：PG/Citus OLTP + CH 副本仍主流；DuckDB 不替代 PG 事务；CH 不做行级事务。

附录 B、团队技能矩阵

附录 C、迁移路径

PG → CH：CDC（Debezium）或批量 COPY → MergeTree；排序键 redesign（第 07 篇）。
CH → DuckDB：FORMAT Parquet 导出 → read_parquet；丢失 Distributed/副本，仅便携分析。
DuckDB → CH：EXPORT DATABASE / Parquet 中间格式 → CH INSERT；须重设 PARTITION/ORDER BY。

附录 D、合规与驻留

两者均可 on-prem。DuckDB 数据在单文件易拷贝——权限与磁盘加密由宿主应用负责。CH 集群需 RBAC、network isolation、backup 策略（监控 第 14 篇）。

上一篇：DuckDB Pipeline

下一篇：监控与系统表

参考资料

核心论文

1. Stonebraker et al., C-Store, VLDB 2005（列存架构坐标；A 级）。
2. Boncz et al., MonetDB/X100, CIDR 2005（向量化坐标；A 级）。
3. Leis et al., Morsel-Driven Parallelism, SIGMOD 2014（DuckDB 并行坐标；A 级）。
4. Kersten et al., Compiled and Vectorized Queries, PVLDB 2018（执行争论；A 级）。

规范 / 源码 / 文档

5. ClickHouse Documentation, 24.x — 部署与用例（A 级）。
6. DuckDB Documentation, 1.x — 嵌入与扩展（A 级）。
7. pg_duckdb 项目文档 — 联邦边界（B 级）。
8. 本系列 PLAN 研究台账；第 01、04、12 篇。