实时数仓 OLAP 引擎选型：ClickHouse Doris StarRocks 对比

ClickHouse、Doris、StarRocks 是当前实时数仓 OLAP 引擎的三驾马车。它们在 2025-2026 年已经高度趋同——都支持物化视图、湖仓融合、存算分离——但在各自"崩盘"的场景上差异巨大。选型的关键不是比谁的 Benchmark 跑分更高，而是搞清楚你的工作负载会让哪个引擎先撑不住。

架构设计哲学：单机极致 vs 分布式均衡

ClickHouse 的设计哲学是"单机做到极致"。它基于 Shared-Nothing 架构，每个节点独立管理自己的数据，MergeTree 存储引擎族是其性能根基。单表聚合查询（如高基数 GROUP BY）的性能是三者中最强的——这源于它对向量化执行、列式压缩和数据本地性的极致优化。但 ClickHouse 的分布式能力是后来补上的：分布式表需要额外配置，节点间的数据分布依赖 ZooKeeper 或 ClickHouse Keeper 做协调。当集群规模超过 50 节点时，运维复杂度会显著上升。

Doris 采用 FE（Frontend）+ BE（Backend）的分离架构。FE 负责元数据管理和查询规划，多个 FE 节点通过 Paxos 协议保证一致性；BE 负责数据存储和执行，支持自动均衡和故障恢复。这个架构的核心优势是简洁——不需要 ZooKeeper，MySQL 协议兼容使得客户端接入几乎零成本。100 节点规模下的集群管理比 ClickHouse 轻量得多。

StarRocks 脱胎于 Doris 的早期分支，但查询引擎已经完全重写。它采用了三进程架构：FE 负责元数据和规划，BE 负责存储和计算，可选的 CN（Compute Node）节点提供纯算力扩展。StarRocks 的 CBO（基于代价的优化器）在三者中最为成熟，对复杂多表 JOIN 的查询计划选择明显优于 ClickHouse。在星型模型和雪花模型的分析查询中，StarRocks 的 JOIN 性能比 ClickHouse 快 5-10 倍是常见的情况。

Upsert 能力：CDC 场景的分水岭

实时数仓的核心场景之一是 CDC（Change Data Capture）数据的摄入和更新。三个引擎对 Upsert 的支持差异极大，这是选型中最重要的分维度之一。

ClickHouse 最初设计为 append-only 的日志分析引擎，Upsert 是后来通过 ReplacingMergeTree、CollapsingMergeTree 等变体引擎实现的。这些引擎在后台 Compaction 时才真正去重和更新，查询时需要额外的 FINAL 关键字才能保证读到最新数据——这会显著降低查询性能。对于高频更新的场景（如订单状态变更），ClickHouse 的 Upsert 体验在三者中最弱。

Doris 提供三种数据模型：Unique Key（每次更新覆盖旧值）、Aggregate（增量聚合）、Duplicate（允许重复）。Unique Key 模型支持实时 Upsert，写入即可查询到最新数据，不需要等待 Compaction。但 Unique Key 模型在高频更新下的写放大问题需要关注——每次更新都会生成一个新的版本，版本过多时查询性能会下降。

StarRocks 的 Primary Key 模型在 Doris Unique Key 的基础上引入了 LSM-Tree 结构来管理多版本数据，兼顾了 Upsert 的实时性和查询性能。在百万级 QPS 的更新场景下，StarRocks 的 Primary Key 表的写入吞吐和查询延迟都优于 Doris 的 Unique Key。但这也意味着 StarRocks 的 BE 节点需要更多的内存来维护索引。

存算分离：弹性与成本的博弈

2025-2026 年，三个引擎都在推进存算分离架构，但成熟度不同。

ClickHouse 的 SharedMergeTree（ClickHouse Cloud）在云端实现了存算分离，将数据持久化到对象存储（S3），计算节点可以按需扩缩容。但开源版本的存算分离能力有限，主要依赖本地磁盘。

Doris 的存算分离模式（Decoupled Mode）在 2.x 版本中已经可用，支持将数据卸载到 S3/对象存储，计算节点无状态化。多集群工作负载隔离在生产中已有落地案例，但相比 StarRocks 还稍显年轻。

StarRocks 的 Shared-Data 模式（3.0+）配合 K8s Operator，提供了最接近 Snowflake 的弹性体验：计算节点可以按秒级扩缩容，数据统一存储在对象存储层。对于需要弹性应对业务高峰的场景（如电商大促），StarRocks 的存算分离架构是三者中最成熟的。

场景化推荐

日志和监控分析（高吞吐 append、单表聚合为主）：选 ClickHouse。它的单表扫描性能和压缩效率在三者中最强，Grafana、Kafka 的生态集成也最成熟。

自助分析和报表（多表 JOIN、SQL 标准性要求高）：选 Doris。MySQL 协议兼容意味着现有的 BI 工具和数据开发平台可以直接对接，CBO 对复杂查询的优化已经足够好，且运维门槛最低。

实时数仓 + CDC 更新 + 弹性扩缩容：选 StarRocks。Primary Key 模型的 Upsert 性能最好，存算分离架构的弹性能力最强，CBO 对多表 JOIN 的优化也是三者中最优的。

预算有限、团队规模小、对运维要求低：选 Doris。不需要 ZooKeeper、MySQL 协议兼容、社区文档中文友好——这些"非技术"因素在实际选型中的权重往往比性能 Benchmark 更高。

选型中的常见陷阱

只看单表 Benchmark 就下结论：ClickHouse 的单表扫描Benchmark 在三者中最优，但如果你的查询涉及 3-4 张表的 JOIN，结果可能完全反转。一定要用自己业务的真实查询做测试。

忽略 Upsert 的实际需求：很多团队初期以为自己的数据是 append-only，上线后才发现业务需要更新——这时候从 ClickHouse 迁移到 Doris/StarRocks 的成本很高。提前确认数据是否有更新需求。

高估团队的运维能力：ClickHouse 的性能上限最高，但运维复杂度也最高。一个 50 节点的 ClickHouse 集群的日常运维（副本同步、分区管理、Merge 策略调优）需要专人负责。如果团队没有这个人力，Doris 的"开箱即用"体验是更务实的选择。

在 EasyMR + StreamWorks 的实时数仓架构中，OLAP 引擎作为查询层与 Flink 实时层和离线层协同工作——引擎的选择直接影响上层 BI 报表和自助分析的查询体验。根据业务场景选对引擎，比选"最强"引擎重要得多。