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 和雲端數倉——這篇刻意把它們留在樹外，因為它們套不進即時引擎這棵決策樹。