ClickHouse、Doris 与 StarRocks：OLAP 引擎选型与适用场景解析

为什么 OLAP 引擎选型越来越难

最近几年，ClickHouse、Apache Doris 和 StarRocks 几乎成了 OLAP 领域出镜率最高的三个开源项目。很多数据团队在做技术选型时，第一反应就是在这三者之间挑一个。但真正麻烦的地方在于：它们表面上都能做列式存储、都能跑 SQL、都能出报表，实际架构和适用场景却差得很远。

拿我接触过的不少项目来说，有些团队因为 ClickHouse 查询快就把它当成万能数仓，结果业务方要做一个多表关联的宽表汇总，ClickHouse 跑得又慢又费内存。也有些团队听说 Doris 和 StarRocks 同源，就认为选谁都一样，直到上线后才发现两者在高并发和实时更新上的行为完全不同。这类问题其实不是引擎不行，而是选型时没有理解它们各自的设计取舍。

三个引擎，三种不同的设计取舍

ClickHouse：极致的单表分析加速器

ClickHouse 从一开始就定位于大规模日志和事件数据的快速查询。它的核心优势是列式存储加上向量化执行，在单表聚合、过滤、排序这些场景下，性能确实非常亮眼。但它的架构是 MPP 加上分布式共享无状态节点，Coordinator 的作用比较弱，所以它更擅长让每个节点独立处理局部数据，然后在最终阶段做结果合并。

这种设计带来的一个直接后果是：多表 Join 的支持很弱。虽然新版本在持续改进 Join 能力，但相比专门优化过的查询引擎，它仍然不适合复杂关联查询。如果业务里需要频繁做星型模型或雪花模型的宽表构建，ClickHouse 会要求你先用物化视图或者应用层把数据拼好，这个维护成本并不低。

另外，ClickHouse 的更新和删除能力也是出了名的别扭。它用 MergeTree 家族的引擎来模拟更新，比如 ReplacingMergeTree、CollapsingMergeTree，需要依赖合并策略来消除旧数据。这也意味着它的“实时更新”不是传统意义上的行级 upsert，而是一种异步合并后的最终一致性。

Apache Doris：更完整的分析型 SQL 数据库

Doris 的基因来自百度内部的大规模报表场景，所以它一开始就把“标准 SQL 和良好的多表 Join 能力”作为核心目标。Doris 采用 FE（Frontend）和 BE（Backend）的架构，FE 负责解析 SQL、生成执行计划、管理元数据，BE 负责数据存储和查询计算，这比 ClickHouse 的架构更接近一个完整的数据库系统。

Doris 在模型设计上也很适合真实业务，比如 Aggregation Model、Unique Model、Duplicate Model 分别对应预聚合、主键更新和明细存储。它还提供 Rollup 和物化视图，能根据查询自动匹配最优的预聚合数据。对大多数报表型场景来说，Doris 的 SQL 兼容性和查询优化能力比 ClickHouse 要友好得多。

但 Doris 也有自己的问题。早期版本在并发处理和高吞吐写入方面相对保守，如果遇到非常极端的点查场景，比如每秒几千上万的 key-value 式查询，它的性能可能不如专门的 KV 存储。此外，Doris 的节点角色和表结构设计比 ClickHouse 复杂，运维门槛会高一些。

StarRocks：面向实时数仓的演进版

StarRocks 是从 Doris 分叉出来的，早期两者共享大量代码，但后来走的路线明显不同。StarRocks 在查询优化器上花了很大力气，引入了 CBO（基于成本的优化），同时强化了主键模型，支持真正的实时 upsert 和部分列更新。它还提供了比较完善的主键表物化视图，让实时数仓的链路可以做得更短。

相比 Doris，StarRocks 在高并发点查和实时写入上表现更激进。它的主键表利用持久化索引来标记删除和更新位置，避免了大范围的合并操作，所以写入后数据立刻可查。这一点对实时风控、实时推荐这类需要低延迟更新的场景很关键。

但 StarRocks 也不是没有代价。它的主键表对内存占用更敏感，持久化索引需要合理配置磁盘和内存。而且因为社区和商业化的推进节奏比较快，版本升级时容易遇到一些兼容性问题。如果团队希望用最稳定的社区版，可能需要更加关注版本选择。

一张表看懂核心差异

对比维度	ClickHouse	Apache Doris	StarRocks
核心定位	大规模单表分析加速	统一的多维分析型数据库	实时数仓与高并发分析
多表 Join	较弱，需应用层拼接	较强，支持标准 SQL	强，CBO 优化
数据更新	异步合并，最终一致	Unique 模型支持 upsert	主键模型实时 upsert
高并发点查	一般，适合批量分析	中等，可支撑一定并发	较好，适合高并发查询
运维复杂度	低，单组件部署	中，需管理 FE/BE	中高，依赖组件多
典型场景	日志分析、监控数据	BI 报表、用户行为分析	实时数仓、实时大屏

用一段建表语句看设计差异

同样是存一份用户事件数据，ClickHouse 和 StarRocks 的建表方式能直观反映它们对更新的处理逻辑不同。

-- ClickHouse：用 ReplacingMergeTree 按 version 去重
CREATE TABLE events (
    user_id UInt64,
    event_time DateTime,
    event_type String,
    version UInt64
) ENGINE = ReplacingMergeTree(version)
PARTITION BY toYYYYMM(event_time)
ORDER BY (user_id, event_time);

-- StarRocks：主键模型直接声明主键
CREATE TABLE events (
    user_id BIGINT,
    event_time DATETIME,
    event_type STRING
) PRIMARY KEY (user_id, event_time)
DISTRIBUTED BY HASH(user_id) BUCKETS 10;

ClickHouse 的 ReplacingMergeTree 会在后台合并时丢弃 version 较小的重复行，查询时不能保证立即看到最新版本。而 StarRocks 的主键模型在写入时就会更新主键索引，查询能直接读到最新状态。这也就解释了为什么实时数仓场景里 StarRocks 用起来更顺手，而 ClickHouse 更偏向“写多改少”的日志流。

真实工程场景里的选择依据

选型不能只看性能指标，还要结合团队已有的技术栈、数据规模和运维能力。我建议从三个维度去思考。

场景一：日志和监控系统

如果主要数据是服务器日志、网络设备指标、用户行为埋点，这些数据的特点是写入量大、很少更新、查询以时间范围加维度过滤为主。这种情况下，ClickHouse 几乎是首选。它的写入吞吐非常高，单表扫描性能也足够好，而且部署简单，一个集群就能处理每天数百亿条记录。

场景二：BI 报表和交互式分析

如果业务需要支持复杂的多表关联、数据下钻、自定义报表，团队里有很多熟悉 SQL 的分析师，那么 Apache Doris 会更合适。它的标准 SQL 和优化器能减少很多“为了让查询跑得快而改表结构”的额外工作。Doris 的 Rollup 和物化视图也能很好地支撑固定报表与即席查询混合的负载。

场景三：实时数仓与实时大屏

如果业务希望从 Kafka 直接写入数据，并且要求在秒级甚至毫秒级看到最新数据，同时还需要做实时汇总和趋势分析，StarRocks 的主键模型和物化视图会让链路更简单。它的高并发查询能力也适合支撑面向外部用户的数据产品。

选型时最容易踩的三个坑

很多团队不是不知道这些引擎的差异，而是在落地时被一些表面现象带偏。这里说几个常见的误区。

误区一：ClickHouse 快，所以适合所有 OLAP 场景。它的快是建立在单表查询和极简模型上的。一旦遇到复杂 join 和并发写入，性能会明显下降，而且资源隔离做不好时还会影响其他任务。
误区二：Doris 和 StarRocks 同源，可以任意替换。两者在查询优化器、主键实现、物化视图机制上已经非常不同。比如 Doris 的 Unique Key 更新依赖合并，而 StarRocks 主键表是实时标记，这种差异在高并发更新场景下会被放大。
误区三：用 OLAP 引擎替代业务数据库。OLAP 引擎的目标是分析查询，即使 StarRocks 支持高并发，它也不适合承载事务型业务。把它当成在线交易库用，最后一定会在数据一致性或写入延迟上出问题。