ClickHouse 调研：49K stars 的 OLAP 王座，向量化执行 + MergeTree 引擎，跟 Doris / DuckDB 比起来到底香在哪里

ClickHouse® 是一款用于实时分析的列式数据库管理系统（DBMS），10 年间凭借向量化执行引擎和 MergeTree 表引擎家族，稳坐 OLAP 领域头把交椅。本文带你深入 ClickHouse 的核心能力、技术架构、生态系统，以及它与 Apache Doris / DuckDB / StarRocks 的对比选型。

OLAP 选型这两年越来越卷。

ClickHouse、Doris、StarRocks、DuckDB、Trino、Apache Druid、Apache Pinot……每一个名字背后都是一篇技术长文、一份 benchmark 报告、一场架构师之间的圣战。

但如果只看一个指标——GitHub stars 和生态密度——答案会清晰得多：

ClickHouse：49,269 stars · Apache-2.0 · 10 年老兵 · 2026.1 估值 150 亿美元
Apache Doris：~3 万 stars · Apache 顶级 · 百度出身
DuckDB：~24K stars · MIT · 嵌入式 OLAP 神兽
StarRocks：~9K stars · ELv2 ⚠️ · 国内黑马
Trino：~11K stars · Apache-2.0 · 联邦查询标准

ClickHouse 是 OLAP 领域的 ” 基础设施级 ” 项目：它不仅是工具，更是产业标准。绝大多数大数据组件（Kafka、Prometheus、Vector、Iceberg）都对 ClickHouse 协议有原生支持。

一句话 ：ClickHouse 让你在 TB 到 PB 级 数据上做 毫秒到秒级 的 SQL 聚合查询。

场景	例子	ClickHouse 表现
实时监控	服务日志、传感器时序数据	单机写入 100 万行 / 秒
用户行为分析	100 亿条点击流查留存、漏斗	92ms 处理 1 亿行（官方 demo）
业务 OLAP	销售、订单、广告数据多维分析	10 亿行 GROUP BY <1s
日志检索	Nginx、应用日志替代 ELK	比 ES 快 10-100 倍
AI 数据湖	向量检索、Embedding 检索	内置向量索引 + 距离函数

基本信息：

维度	数据
GitHub	ClickHouse/ClickHouse
Stars	49,269
Forks	8,801
Open Issues	6,912（量多但健康）
License	Apache-2.0（无任何商用风险）
首次 commit	2016-06-02（正好 10 周年）
最近 commit	2026-08-16（今天还在推代码）
仓库大小	10.2 GB（C++ 巨型单体）
主语言	C++ 90%+ + Rust + Python
最新版本	26.7.3.19（2026-08-06）/ LTS 26.3.17.110
商业实体	ClickHouse Inc.（2026.1 融资 4 亿美元，估值 150 亿美元）

ClickHouse 不是单一引擎，而是一整个 表引擎家族——这是它跟其他 OLAP 数据库最大的不同。官方把它分为 6 大类：

类别	代表引擎	用途
MergeTree 系列	MergeTree / ReplacingMergeTree / SummingMergeTree / AggregatingMergeTree / CollapsingMergeTree / VersionedCollapsingMergeTree / GraphiteMergeTree	生产主力——支持主键索引、分区、TTL、实时更新
日志系列	TinyLog / StripeLog / Log	小表调试用
外部存储	HDFS / S3 / URL / File / AzureBlobStorage	直接查外部数据
内存引擎	Memory / Set / Join / Buffer	临时数据 / 维度表
接口引擎	Kafka / RabbitMQ / MySQL / PostgreSQL / JDBC / ODBC / MongoDB / Redis / Hive / S3 / Hudi / DeltaLake	直接对接外部系统，不需要 ETL
特殊引擎	Distributed / MaterializedView / Dictionary / Merge / File	分布式 / 物化视图 / 数据字典

实战中最常用的 3 个：

MergeTree：默认引擎，支持主键索引 + 分区 + TTL + 实时数据更新
ReplacingMergeTree：MergeTree 增强版，去重场景（比如用户画像）
Distributed：逻辑上是一张表，物理上分散到 N 个分片——这是 ClickHouse 集群的核心

跟其他 OLAP 不同的是：ClickHouse 跟 Kafka / MySQL / S3 / HDFS / MongoDB 等 30+ 数据源有原生接口引擎，基本不需要额外的 ETL 工具。

ClickHouse 的查询引擎不是一次处理一行，而是 一次处理一批列数据（通常 1024-8192 行）：

传统逐行处理：for row in rows:  process(row)            # 每次 CPU 指令有 pipeline stall

ClickHouse 向量化：for batch in batches: process(batch)       # SIMD 指令一次算 1024 行

配合 SSE 4.2 / AVX2 / AVX-512 指令集，CPU 浮点和整数运算能跑到接近峰值的吞吐。

官方性能 demo（100M 行匿名 Web 分析数据）：

SELECT MobilePhoneModel, COUNT() AS c
FROM metrica.hits
WHERE RegionID = 229
  AND EventDate >= '2013-07-01'
  AND EventDate <= '2013-07-31'
GROUP BY MobilePhoneModel
ORDER BY c DESC LIMIT 8;

实测：92ms 处理 1 亿行，约 10 亿行 / 秒 或 7 GB/ 秒 的吞吐

MergeTree 是 ClickHouse 的灵魂。它的设计兼顾 写入吞吐 和 查询性能：

写入：数据先写到内存 buffer（buffered write），满了刷盘成 part 文件（类似 LSM tree 的 SSTable）
合并：后台线程定期把小的 part 合并成大的 part（compaction）
查询：基于 主键稀疏索引 （每 8192 行一个索引项）+ 分区裁剪 + 数据跳过

CREATE TABLE events (
    event_date Date,
    user_id UInt64,
    event_type LowCardinality(String),
    payload String
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_date)
ORDER BY (user_id, event_date)
TTL event_date + INTERVAL 90 DAY;

3 个关键参数：
–
PARTITION BY：分区键（一般按月 / 按周），查询时自动跳过无关分区
–
ORDER BY：排序键（也是主键），决定稀疏索引的粒度
–
TTL：自动过期删除（IoT 时序数据特别有用）

实战经验 ：MergeTree 的 ORDER BY 选择对查询性能影响最大，要按 最常过滤的列 排序。

ClickHouse 的物化视图是 实时增量更新 的——不像传统数据库要全量刷新：

CREATE MATERIALIZED VIEW events_hourly_mv
ENGINE = SummingMergeTree
PARTITION BY toYYYYMM(hour)
ORDER BY (event_type, hour)
AS SELECT
    toStartOfHour(event_date) AS hour,
    event_type,
    count() AS cnt,
    uniqState(user_id) AS uv
FROM events
GROUP BY hour, event_type;

新数据写入 events 表时，物化视图自动增量聚合——非常适合做 小时级 / 天级预聚合 加速查询。

ClickHouse 在 AI Builders Night、The Agentic Data Stack: Berlin 等活动里重点推 AI 方向：

内置向量索引（HNSW / 量化）
Embedding 距离函数（cosine / L2 / inner product）
直接对接大模型（ClickHouse Cloud 提供 OpenAI / Claude / Mistral 集成）
GitHub topics 里 ai、lakehouse、embedded、self-hosted 都在强化

这意味着 ClickHouse 不只是 OLAP，也是 AI 原生数据栈 的一部分。

由 ClickHouse Inc. 运营，官方团队直接维护
支持 AWS / GCP / Azure / Alibaba Cloud
跟开源版功能基本对齐，但多了 自动扩缩容 、 多副本备份、IAM 等
价格：~$0.0065/ 小时起（最小配置）

2026.1 融资 4 亿美元、估值 150 亿美元——资本市场认定它跟 Snowflake / Databricks 是同一级别的玩家。

Python 嵌入式 OLAP 引擎，直接 import 就能用
跟 DuckDB 的 Python 嵌入式 API 类似，但底层是 ClickHouse
适合 Jupyter notebook 数据分析

import chdb
result = chdb.query("SELECT version()")
print(result)  # 26.7.3.19

sql.clickhouse.com 提供免费在线 ClickHouse 实例
可以直接跑上面的 100M 行 demo 查询
适合 初次接触 ClickHouse 的技术选型评估

ClickHouse 几乎支持所有主流数据源：

类型	支持
消息队列	Kafka / RabbitMQ / NATS（接口引擎直连，不需要 ETL）
关系数据库	MySQL / PostgreSQL / SQLite / JDBC / ODBC
NoSQL	MongoDB / Redis / S3 / HDFS
表格式	Iceberg / Delta Lake / Hudi
时序	Prometheus remote storage / InfluxDB line protocol
向量	内置 HNSW / 量化索引

维度	ClickHouse	Apache Doris	DuckDB	StarRocks
Stars	49,269	~30K	~24K	~9K
协议	Apache-2.0 ✅	Apache-2.0 ✅	MIT ✅	ELv2 ⚠️
出身	Yandex（俄罗斯）	百度（中国）	CWI（荷兰）	Doris 团队分家
架构	Shared-Nothing + ZK	FE/BE + Raft	单进程嵌入式	Shared-Nothing + Controller
列存	✅	✅	✅	✅
向量化执行	✅	✅	✅	✅
主键索引	✅ 稀疏索引	✅	✅	✅
物化视图	✅ 实时增量	✅	❌	✅
实时更新	✅ ReplacingMergeTree	✅ Unique Key	✅	✅ Primary Key
分布式扩展	✅ Distributed 表	✅ 原生 MPP	❌ 单机	✅ 原生 MPP
高并发点查	⚠️ 中等	✅ 强	❌ 单机	✅ 强
多表 JOIN	⚠️ 较弱	✅ 强	✅ 强	✅ 强
ASOF JOIN	❌（不支持）	✅ 4.0+ 领先	⚠️ 实验	✅
嵌入式运行	❌	❌	✅ Python/R/JS	❌
运维复杂度	⚠️ 中等（ZK 依赖）	✅ 低	✅ 零	⚠️ 中等
SQL 方言	接近 ANSI SQL + 扩展	接近 MySQL	PostgreSQL	MySQL
商业版	ClickHouse Cloud	SelectDB	MotherDuck	StarRocks Inc.
估值 / 融资	$15B（2026.1）	SelectDB 估值未披露	MotherDuck A 轮	$200M+（2024）

结论怎么选：

你的场景	选谁
宽表 + 单表聚合查询 + 时序数据（IoT / 监控 / 日志）	ClickHouse ✅
多表关联查询 + 高并发点查（实时数仓 / 业务 OLAP）	Doris / StarRocks
本地 Python / 数据科学 / 单机分析	DuckDB
PB 级联邦查询（Hive / Iceberg / S3）	Trino（不是 ClickHouse 主战场）
AI 原生 + 向量检索 + 自然语言	ClickHouse / WrenAI / DB-GPT（8/15 已调研）
必须 Apache 协议 + 国产可控	Doris / ClickHouse

对比已调研的飞熊 8 月 BI 栈：

已调研项目	跟 ClickHouse 的关系
DuckDB (294)	同位竞争——嵌入式 vs 分布式，ClickHouse 更强在集群规模，DuckDB 更强在单机易用
Apache Doris (296)	直接对标——Doris 强在 JOIN 和高并发，ClickHouse 强在单表聚合和生态广度
Rill (320)	ClickHouse 是 Rill 的默认底层 OLAP——Rill 把 ClickHouse 包成了 ” 快 BI”
Evidence.dev (314)	对接关系——Evidence 支持 ClickHouse 作为数据源
WrenAI (316)	替代关系 + 互补——WrenAI 是 GenBI 前端，ClickHouse 是底层 OLAP
dbt-core (290)	互补——dbt 做转换，ClickHouse 做存储和查询
Apache Superset (270) / Metabase (274) / Lightdash (272)	可视化层——ClickHouse 是它们支持的高性能数据源之一

# Linux 一行安装（官方脚本）curl https://clickhouse.com/ | sh

# 或者 apt 源（推荐生产环境）sudo apt-get install -y apt-transport-https ca-certificates curl gnupg
curl -fsSL 'https://packages.clickhouse.com/rpm/lts/repodata/repomd.xml.key' | sudo gpg --dearmor -o /usr/share/keyrings/clickhouse-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/clickhouse-keyring.gpg] https://packages.clickhouse.com/deb stable main" | sudo tee /etc/apt/sources.list.d/clickhouse.list
sudo apt-get update && sudo apt-get install -y clickhouse-server clickhouse-client

# 启动
sudo /etc/init.d/clickhouse-server start

# 验证
clickhouse-client --query "SELECT version()"
# 26.7.3.19

-- 创建数据库和表
CREATE DATABASE IF NOT EXISTS iot;

CREATE TABLE iot.sensor_readings (
    event_date Date,
    sensor_id UInt32,
    temperature Float32,
    humidity Float32,
    location LowCardinality(String)
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_date)
ORDER BY (sensor_id, event_date)
TTL event_date + INTERVAL 90 DAY;

-- 导入 CSV
clickhouse-client --query "INSERT INTO iot.sensor_readings FORMAT CSVWithNames" < sensor_data.csv

-- 或者从 Kafka 直连
CREATE TABLE iot.sensor_kafka (
    event_date Date,
    sensor_id UInt32,
    temperature Float32
) ENGINE = Kafka('kafka-host:9092', 'sensor-topic', 'CSV')
  SETTINGS kafka_format = 'CSV';

-- 创建物化视图（实时聚合）CREATE MATERIALIZED VIEW iot.sensor_hourly_mv
ENGINE = SummingMergeTree
PARTITION BY toYYYYMM(hour)
ORDER BY (sensor_id, hour)
AS SELECT
    sensor_id,
    toStartOfHour(event_date) AS hour,
    avg(temperature) AS avg_temp,
    max(temperature) AS max_temp,
    count() AS cnt
FROM iot.sensor_readings
GROUP BY sensor_id, hour;

-- 单传感器过去 24 小时最高温度
SELECT max(temperature)
FROM iot.sensor_readings
WHERE sensor_id = 42
  AND event_date >= now() - INTERVAL 1 DAY;

-- 所有传感器每天平均温度（用物化视图加速）SELECT sensor_id, hour, avg_temp, max_temp
FROM iot.sensor_hourly_mv
WHERE hour >= now() - INTERVAL 7 DAY
ORDER BY hour DESC, avg_temp DESC
LIMIT 100;

-- 时序 ASOF JOIN（ClickHouse 25.x+ 支持，跟 Doris 对标）SELECT
    readings.sensor_id,
    readings.event_date,
    readings.temperature,
    alarms.threshold
FROM iot.sensor_readings AS readings
ASOF LEFT JOIN iot.sensor_alarms AS alarms
    ON readings.sensor_id = alarms.sensor_id
   AND readings.event_date >= alarms.effective_from
   AND readings.event_date < alarms.effective_to
WHERE readings.event_date >= today() - 7;

-- 向量检索（AI 场景）SELECT id, cosineDistance(embedding, [0.1, 0.2, ...]) AS distance
FROM documents
ORDER BY distance ASC
LIMIT 10;

ClickHouse 的 SQL 不是严格 ANSI，不支持事务 、 不支持单行 UPDATE/DELETE（要用 ReplacingMergeTree / CollapsingMergeTree 变通）。从 MySQL / PostgreSQL 迁移需要适配。

ClickHouse 集群模式用 ZK 协调分片副本，运维门槛较高——单机模式没这问题。

26.x 引入了 Keeper（ClickHouse 内置 ZK 替代），但生态还没完全迁移。

ClickHouse 在 单表宽表查询 上是王者，但在 多表复杂 JOIN上不如 Doris / StarRocks（这是 StarRocks 3.0 SSB benchmark 普遍领先 ClickHouse 的原因）。

最佳实践：把数据 ETL 打平成宽表，避免 JOIN。

ClickHouse 25.x 才开始支持 ASOF JOIN，比 Doris 4.0+ 晚很多。如果你的场景是 时序对齐（IoT、行情、交易补全），Doris 在这个维度更强。

量多但健康——绝大多数是 feature request 或边缘场景 bug，不是 P0 阻塞。但生态文档分散，新手上手要花点时间。

源码编译需要较新版本的 GCC（11+），ARM 平台支持还在完善（已经支持但部分第三方库可能有问题）。

高基数（high cardinality）列（如 user_id 直接做 ORDER BY）容易 OOM。建议 ORDER BY 用低基数维度 + 单独存明细。

ClickHouse 不是一个简单的数据库——它是 OLAP 领域的事实标准之一。

3 个最值得用的理由：

极致单表查询性能：92ms 处理 1 亿行，10 亿行 / 秒吞吐——宽表聚合场景下没有对手
生态完整：从 Kafka / MySQL 到 Iceberg / Prometheus，从 chDB 嵌入式到 Cloud SaaS，一个项目覆盖 OLAP 全场景
AI 原生方向：内置向量索引 + 距离函数 + AI 集成，跟 WrenAI / DB-GPT / Rill 等 GenBI 工具天然适配

1 句建议：

先跑 ClickHouse SQL Playground 的 100M 行 demo（sql.clickhouse.com），如果你的查询秒级返回，再决定是否上生产。

如果你的场景是 多表 JOIN / 高并发点查 ，看 Apache Doris (296)；如果你是 单机 Python 数据分析，看 DuckDB (294)；如果你的场景是 AI 原生 + 自然语言查询，看 8/15 已发的 WrenAI / DB-GPT / Evidence / Rill——它们底层很多就是 ClickHouse。

ClickHouse GitHub · 49K stars / Apache-2.0
ClickHouse 官方文档 · 10 年积累最全的 OLAP 文档
ClickHouse SQL Playground · 在线免费试用
ClickHouse 26.7 Release Call · 7/23/2026 最新功能
MergeTree 引擎详解 · 表引擎家族核心
The Agentic Data Stack · 2026 ClickHouse AI 方向
ClickHouse Inc. 150 亿美元估值 · 2026.1 融资新闻
Apache Doris vs ClickHouse 对比 · 国内主流 OLAP 选型参考
DuckDB vs ClickHouse · 嵌入式 vs 分布式 OLAP
ClickBench Benchmark · 业界公认 OLAP 性能榜

ClickHouse 调研：49K stars 的 OLAP 王座，向量化执行 + MergeTree 引擎，跟 Doris / DuckDB 比起来到底香在哪里

写在前面

一、它解决什么问题

二、核心能力全景：6 大类表引擎家族

三、差异化能力：向量化执行 + MergeTree + 物化视图

1. 向量化执行（Vectorized Query Execution）

2. MergeTree 表引擎：列存 + LSM 思想的混合

3. 物化视图（Materialized Views）

4. 向量检索 + AI 原生能力（2026 新方向）

四、生态系统：ClickHouse Cloud + chDB + Playground + 集成

1. ClickHouse Cloud（商业 SaaS）

2. chDB（嵌入式 ClickHouse）

3. ClickHouse SQL Playground（在线体验）

4. 数据集成生态

五、对比 Apache Doris / DuckDB / StarRocks

六、实战：3 步跑通 ClickHouse

Step 1：一行命令安装

Step 2：创建 MergeTree 表 + 导入数据

Step 3：跑查询（聚合 / 时序 / 向量）

七、风险与坑

1. SQL 方言跟 ANSI 有差异

2. ZooKeeper 依赖（集群模式）

3. 多表 JOIN 性能弱

4. ASOF JOIN 支持晚

5. 6,912 open issues

6. C++ 编译门槛

7. 单机内存吃紧

八、总结

参考

近期文章

近期评论