DuckDB、ClickHouse、Druid或Pinot如何选

目录

• 不是排行榜，是决策树
• 对比表
• DuckDB：当你不需要服务
• ClickHouse：生产的平衡点
• Druid 和 Pinot：当你真的需要大规模实时

  • Apache Druid：从广告技术分析到通用流式
  • Apache Pinot：生来是端出去的，不是拿来探索的
  • 实用的 Druid vs. Pinot 规则
• 真实案例对照
• 常见问题

  • DuckDB 还是 ClickHouse？
  • ClickHouse 还是 Druid，该选哪个？
  • Apache Pinot vs. Druid vs. ClickHouse，哪个更好？
  • ClickHouse 还是 Vertica？
  • 以后能从 Druid 或 Pinot 迁到 ClickHouse 吗，反过来呢？
• 结论

不是排行榜，是决策树

泛泛的「DuckDB vs ClickHouse vs Druid vs Pinot」对比往往越看越糊，是因为它们把两个不同的问题当成一个来混：

问题 1：你需要的是服务，还是一个库就够？ DuckDB 跑在你的进程里。另外三个是另起炉灶的服务，端口、用户和高可用都卷进来。

问题 2：如果需要服务，优先的是通用分析，还是极端并发下的延迟？ ClickHouse 为前者优化。Druid 和 Pinot 为后者而生。

这两个问题答完，树就是这样：

1. 查询是由单个进程发出的——你的后端、notebook、ETL 脚本——而且数据舒舒服服装得下一块盘？ → DuckDB。别的不需要。
2. 你需要共享服务，多源持续写入，负载是「对一张不断变大的事件表做聚合」？ → ClickHouse。从单打独斗的 maker 到中等团队，绝大多数项目的平衡点都在这里。
3. 你的优先不是探索性分析，而是把同一条预先定义的查询，以毫秒延迟端给成千上万同时在线的用户，并由 Kafka 流式喂入？ → Druid 或 Pinot。而且只有你有专人运维它们的时候。

我见过最多的错，是本能地跳过第 1 步——「咱们上点正经的」——而真实体量的 80% 本来装得下一台机器。第二个错没那么常见，但更贵：还没有能撑起第 3 步的负载就走到了那里，结果为 ClickHouse 一个二进制就能解决的问题，去运维一个六种进程的集群。

对比表

	DuckDB	ClickHouse	Apache Druid	Apache Pinot
架构	嵌入式、进程内、无服务器	分布式列存，每节点一个二进制	分布式列存，专用进程	分布式列存，专用进程
最小部署	一个库（pip install duckdb）	1 个二进制	6 种进程 + ZooKeeper + metadata store	Controller、Broker、Server + ZooKeeper
最佳用例	本地分析、notebook、ETL、查询自己的 Parquet/CSV 的应用后端	生产事件表、频繁聚合、自托管	流式摄入加即席探索，以及热/冷数据分层	以毫秒 SLA 把同一条预定义查询端给海量并发
运维复杂度	无：没有东西要运维	低–中：多维护一个服务	高：需要专职团队	高：需要专职团队
流式摄入	不适用	好（Kafka engine、物化视图）	极好，它存在的理由	极好，它存在的理由
并发	低（一个进程）	很好	好	极好，就是为此设计的
灵活的即席查询	极好	极好	好	有限：在事先已知的模式上发光
何时不要用	你需要多个读/写方实时共享数据，或扩到一台机器之外	你需要在数万并发 QPS 下保证亚秒延迟	你是没有专职 SRE 的小团队，或优先的是没有固定模式的自由探索	你是没有专职 SRE 的小团队，或查询形态一直在变

格子是简化；细节在后面各节。

DuckDB：当你不需要服务

DuckDB 由 Mark Raasveldt 和 Hannes Mühleisen 在阿姆斯特丹的 CWI（Centrum Wiskunde & Informatica）创建，第一个公开版本 2019 年在 SIGMOD 会议上宣布。起点动机很能说明问题：他们一直想把 MonetDB 嵌进 R 和 Python 包，结果发现现有的分析数据库没有一个是为活在另一个进程里面、还不假定自己说了算而设计的。DuckDB 就是来填这个空的。

实务上，它就是分析领域的 SQLite：一个库，不是服务。pip install duckdb，你就已经有一个向量化列存引擎跑在脚本里，SQL 方言兼容 PostgreSQL。直接从磁盘或 URL 查 Parquet 和 CSV，原生对接 pandas 和 Polars，没有端口要开，也没有进程要盯。

它赢在哪： 任何由一个人或一个进程发起查询的流程。探索性数据科学、notebook、只需要读自己数据的小应用分析后端、转换文件的 ETL 管道。对这种负载画像，简洁上很难找到认真的对手。

它输在哪，以及为什么那是设计而不是缺陷： DuckDB 本质上是单个进程。它不把数据端给来自不同机器的几十个并发读者，不水平扩展，也不是为同时接收多源不断写入而设计的。需要共享时有 MotherDuck 这层云，但那一刻你已经换了工具类别。

它已经不够用的信号： 当你需要多个服务同时写、多个客户端同时读，彼此还不互相堵住。这时你跨到 ClickHouse。

ClickHouse：生产的平衡点

如果 DuckDB 解决的是「一个进程，我的数据」，ClickHouse 解决的是「一个服务，大家的数据」。当你需要分析不再是你自己跑的脚本，而变成 24/7 接收应用写入、回答团队或客户查询的东西，就是它。

我不在这里重复整套列存架构和稀疏索引——细节在 ClickHouse 是什么以及如何安装——但对这个决定的摘要是：一个二进制，没有 JVM，没有强制 ZooKeeper，同一套引擎从笔记本扩到几百个节点。

相对 Druid 和 Pinot 赢在哪： 除了毫秒 SLA 的海量并发这个极端以外的一切。探索性即席查询、像样的 JOIN、没有专职 SRE 的小团队、低运维成本。绝大多数「我需要实时」其实是「我需要数据在几秒内可用，而不是几分钟」，那里 ClickHouse 绰绰有余。

相对 Druid 和 Pinot 输在哪： 如果你真正的 SLA 是毫秒级、数万条相同查询并发——想象一个成百上千最终用户同时查的产品功能——ClickHouse 不花相当调优功夫就可能不够，而 Druid 和 Pinot 从零就是为这个画像设计的。

在这个语境下何时不要用 ClickHouse： 数据装得下一台机器、查询只来自一个进程，相对 DuckDB 就是过度工程。SLA 是 Kafka 流式喂入下的极端并发毫秒，相对 Druid 或 Pinot 就是选错工具。

Druid 和 Pinot：当你真的需要大规模实时

Druid 和 Pinot 是一家：都跑在 JVM 上，都把系统拆成几种专用进程，都靠 ZooKeeper 协调，都等着一条 Kafka 式摄入管道持续喂数据。它们运维起来也明显比 ClickHouse 复杂：这不是看法，是直接后果——不是一个二进制，而是六种（Druid）或三种（Pinot）进程要分别部署、监控、扩缩。

但它们彼此不可互换，因为生来要解的问题不同。

Apache Druid：从广告技术分析到通用流式

Druid 2011 年生于 Metamarkets，一家程序化广告公司，需要对几十亿事件做实时下钻和上卷，发现 MySQL 和 HBase 都给不出需要的速度。2012 年开源，2015 年转到 Apache 许可。

那个出身——事件流上的探索性分析，维度会变，用户想用事先没想到的方式切数据——至今还规定着它的设计。Druid 明确分开「热」数据（近期、在内存）和「冷」数据（历史、在深层存储），这对需要长期保留、并对完整历史而不只是最新数据做探索查询的人很强。

相对 Pinot 赢在哪： 未预料的即席查询的灵活度，以及按新旧管理数据。如果你的分析团队想对历史问新问题、又不想重做索引，Druid 余地更大。

Apache Pinot：生来是端出去的，不是拿来探索的

Pinot 生于 LinkedIn，目标窄得多、具体得多：把「谁看过你的主页」这类功能，以毫秒延迟端给几亿用户。它的架构——星树索引、倒排索引、为已知访问模式设计的分区——为一遍又一遍跑同一种查询形态、很快、同时给很多人，而优化，这不是巧合。

相对 Druid 赢在哪： 预定义查询上的硬并发。如果你事先知道要端出去的查询形态——固定筛选的产品仪表盘、按用户的指标计数——优先的是扛住数万同时查询且延迟最低，Pinot 就是为这一点打磨的。

相对 Druid 输在哪： 形态全新的探索查询。Pinot 在你了解访问模式并按它们建索引时发光；有人想问谁也没料到的问题时就别扭。

实用的 Druid vs. Pinot 规则

如果你的问题是「面向内部团队自由探索的实时分析」，偏向 Druid。如果你的问题是「面向最终用户、查询可预期、并发海量的实时分析」，偏向 Pinot。如果这两个场景哪个描述你的情况你都说不清，这本身就是相当强的信号：你暂时两个都不需要。真正的问题大概是树上的第 2 步，不是第 3 步。

何时两个都不要用： 如果团队就几个人、没有在 JVM 上运维分布式系统的经验，维持 ZooKeeper 协调的六种进程，成本只有在非常大的规模上才摊得回来。好几家知名公司把负载从 Druid 迁到 ClickHouse，理由是降成本和变简单，这很能说明问题——正因为真实体量并不要求他们当时在付的那份复杂。

真实案例对照

把理论落到地上，四个具体场景，以及它们指向哪把工具：

数据分析师在 notebook 里从 Parquet 探索历史销售。 DuckDB。没得争：一个进程，数据装得下笔记本，零需要和任何人共享状态。

B2B SaaS，产品事件表每天在长，内部仪表盘好几个人在查。 ClickHouse。共享服务、持续写入、中等并发，不需要保证毫秒延迟。

广告技术平台从 Kafka 摄入曝光，分析团队需要按任意维度近实时切这些数据，并保留几个月。 Druid。流式摄入、灵活探索、热/冷分层。

社交网络或大众消费产品，把一条个性化指标——「你这周的统计」——以严格延迟 SLA 展示给数百万同时在线的用户。 Pinot。预定义查询、极端并发、事先已知的访问模式。

如果你的场景对不上这四个里的任何一个，回到开头的决策树：正确答案几乎总是能解决今天这个问题的最简单选项，不是最唬人的那个。

常见问题

DuckDB 还是 ClickHouse？

单个进程发查询、数据装得下一台机器，用 DuckDB：notebook、ETL、小应用后端。需要带多源持续写入和多个并发读者的共享服务，用 ClickHouse。分界是「库」对「服务」，不是性能。

ClickHouse 还是 Druid，该选哪个？

绝大多数情况选 ClickHouse：运维更简单，一个二进制对六种进程，通用分析性能绰绰有余。只有真实负载是大规模流式摄入、还要对热数据和冷数据做即席探索，并且有专职团队运维时，才上 Druid。

Apache Pinot vs. Druid vs. ClickHouse，哪个更好？

没有放之四海的「最好」。生产上的通用分析、运维要低，用 ClickHouse。带灵活探索和按新旧管数据的流式，用 Druid。以毫秒延迟把预定义查询端给海量并发，用 Pinot。按负载形态选，别按跑分选。

ClickHouse 还是 Vertica？

它们比看起来更像不同类别。Vertica 是专有列存 MPP（有功能受限的社区版），面向有许可证预算和 DBA 团队的大企业。ClickHouse 开源、没有许可费，按一个二进制部署，更适合想自托管、又不想谈合同的小团队。

以后能从 Druid 或 Pinot 迁到 ClickHouse 吗，反过来呢？

两个方向都可以，但并不轻松：各自的摄入模型和最地道的查询不是直接对拷。常见路径是先用 ClickHouse，因为它运维更便宜，只有并发或真实 SLA 以可测量的方式要求时，再迁到 Druid 或 Pinot，而不是提前迁。

结论

这篇文章里的四个工具，各自擅长的事都出色，正因为如此，「哪个更好？」这个问题本身就问歪了。DuckDB 在活由一个进程干的时候赢。ClickHouse 在你需要运维合理的通用服务时赢。Druid 和 Pinot 只在海量流式加毫秒 SLA 的极端上赢，而且只有你有人运维它们。

对今天起步的大多数项目，自然路径是：数据还装得下一台机器时从 DuckDB 开始，等分析需要变成共享服务时再跳到 ClickHouse。如果你真的走到 Druid 或 Pinot 那一档，你会知道——痛是具体、可测的，不是「这玩意儿该更大」的直觉。

如果下一步是 ClickHouse，最短路径是 ClickHouse 是什么以及如何安装；想把市场上其余选项看得更细，ClickHouse 替代方案对比 会进入 StarRocks、TimescaleDB 和云数仓——这篇刻意把它们留在树外，因为它们套不进实时引擎这棵决策树。