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

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

2025 到 2026 年，实时数仓领域最显著的变化是 OLAP 引擎之间的竞争从"功能差异化"进入了"架构趋同、生态竞争"的新阶段。ClickHouse、Apache Doris 和 StarRocks 三大引擎在核心能力上不断互相追赶——ClickHouse 补齐了 JOIN 弱项，Doris 加速了向量化执行，StarRocks 强化了实时 Upsert。选型不再是一个"谁功能多"的问题，而是一个"谁的架构更匹配你的场景"的问题。

本文从架构设计、JOIN 能力、Upsert 支持、云原生弹性四个维度进行对比，并结合真实迁移案例说明决策过程。

架构设计：三套不同的哲学

ClickHouse：列存极致性能派。ClickHouse 采用 Share-Nothing 架构，每个节点独立存储和计算。数据按 MergeTree 引擎族组织，写入时追加数据片段（Data Part），后台持续合并。ClickHouse 的核心设计哲学是"用空间换时间、用并行换吞吐"——它通过大量数据冗余（副本）和激进的列式压缩来最大化查询性能。在单表聚合查询场景下，ClickHouse 的性能通常是同类引擎的 2–5 倍。

2025 年 ClickHouse 的重要变化包括：引入了共享存储（Shared Storage）架构，允许计算和存储分离；增强了 projections（预聚合物化视图），可以在写入时自动生成多种聚合粒度的数据副本，显著加速多维度查询。

Doris：MySQL 兼容的全能选手。Doris 采用 FE（Frontend）+ BE（Backend）的两层架构，FE 负责元数据管理和查询解析，BE 负责数据存储和计算。Doris 的架构设计追求"开箱即用"——它内嵌了向量化执行引擎，不需要像 ClickHouse 那样针对不同查询模式选择不同的表引擎。Doris 的 MPP 架构天然支持分布式 JOIN，不需要像 ClickHouse 那那样依赖特殊的 JOIN 算法。

Doris 在 2025–2026 年的重点发展包括：Lakehouse 能力（原生读取 Iceberg/Hudi 表）、Pipeline 执行引擎（替代原有的非向量化执行器）、以及自动分区和物化视图的增强。

StarRocks：性能与功能的均衡派。StarRocks 的架构与 Doris 同源（最初从 Apache Doris 分叉），但在发展路径上走向了不同的方向。StarRocks 强调"一个引擎解决所有问题"——既支持极速的 OLAP 查询，又支持实时数据更新和多表关联分析。

2026 年的 StarRocks 引入了存算分离架构（Shared-Data 模式），将数据持久化到对象存储（如 S3），计算节点变为无状态。这使得弹性扩缩容的粒度从"节点级"细化到"查询级"——空闲时可以完全释放计算资源，查询到达时按需拉起。

JOIN 能力：从"能用"到"好用"

JOIN 是 OLAP 引擎的分水岭。历史上 ClickHouse 的 JOIN 能力是其最大短板，但近两年已有显著改善。

ClickHouse 的 JOIN 进化。ClickHouse 20.8+ 引入了 Hash JOIN 和并行 Hash JOIN，2024 年后进一步支持了 partial merge join。但 ClickHouse 的 JOIN 仍然有隐性限制：右表需要能放入单节点内存（或使用 Grace Hash Join），跨节点 Shuffle 的效率不如原生 MPP 引擎。在三表以上的复杂 JOIN 场景下，ClickHouse 的查询规划器可能生成次优的执行计划。

最佳实践：在 ClickHouse 中，尽量通过预聚合（AggregatingMergeTree + 物化视图）将多表 JOIN 提前物化为单表查询。如果必须做实时 JOIN，控制右表大小在单节点内存的 50% 以内。

Doris 和 StarRocks 的原生 MPP JOIN。两者都支持 Shuffle Join、Broadcast Join、Colocate Join 等多种 JOIN 策略。Colocate Join 是一个值得特别说明的能力——它要求数据在写入时按 JOIN Key 做一致性哈希分布，使得 JOIN 操作可以在本地完成而不需要网络 Shuffle。Colocate Join 在维表关联场景下可以将 JOIN 性能提升 3–10 倍，但对数据分布有严格要求。

两者的主要差异在于：StarRocks 的 Optimizer 基于成本的优化器（CBO）在复杂查询上的表现略优于 Doris，尤其是多表 JOIN + 子查询的场景。Doris 在 2025 年引入了新的 CBO 后差距在缩小，但在涉及 5 表以上 JOIN 时 StarRocks 仍然更稳定。

Upsert 支持：实时更新的三种路径

在需要支持实时数据更新的场景（如订单状态变更、维表同步），Upsert 能力至关重要。

ClickHouse 的 ReplacingMergeTree。ClickHouse 通过 ReplacingMergeTree 实现 Upsert——写入相同主键的新版本数据，后台 Compaction 时保留最新版本。但这不是严格的实时 Upsert：在 Compaction 完成之前，查询可能返回重复数据。通过 FINAL 修饰符可以在查询时强制去重，但会显著降低查询性能。

Doris 的 Unique Key 模型。Doris 的 Unique Key 模型在写入时立即对相同主键的数据做覆盖，实现了真正的实时 Upsert。2025 年后 Doris 引入了序列号（Sequence Column）机制，解决了并发更新时的乱序覆盖问题。Unique Key 模型的代价是写入放大——每次更新都需要重写整行数据。

StarRocks 的 Primary Key 模型。StarRocks 的 Primary Key 模型在 2024 年后引入了基于 LSM-Tree 的持久化主键索引，将主键索引从内存移到了磁盘，使得支持千万级以上主键规模的实时更新成为可能。在实测中，StarRocks 的 Primary Key 模型在高频更新（>10K rows/s）场景下的写入吞吐量约为 Doris Unique Key 的 1.5–2 倍。

云原生弹性：存算分离的实际效果

2025–2026 年，三大引擎都在向存算分离架构演进，但进度和成熟度不同。

StarRocks 最为激进，Shared-Data 模式已在生产环境大规模验证。计算节点可以秒级启动和释放，配合 Kubernetes HPA 实现查询驱动的自动弹性。实测场景中，一个日处理 5TB 数据的集群在非高峰时段可以缩减到 3 个节点，高峰时段自动扩展到 20 个节点，月度计算成本降低约 60%。

ClickHouse 的 Shared-Storage 架构在 2025 年 GA，但弹性扩缩容仍需手动操作或依赖编排工具。ClickHouse Cloud（商业版）提供了更好的弹性体验，但开源版本在这方面的成熟度不如 StarRocks。

Doris 的云原生架构在 2026 年处于快速追赶阶段。Doris 的弹性能力主要体现在 BE 节点的动态扩缩容上，但存储层的弹性还依赖外部的共享存储方案。

Demandbase 迁移案例：从 ClickHouse 到 StarRocks

Demandbase 是一家 B2B 营销技术公司，其广告投放决策系统原先运行在 ClickHouse 上。随着数据量从日增 500GB 增长到日增 2TB，遇到了三个核心痛点：

痛点一：Upsert 性能不足。广告点击和转化数据需要实时更新到分析表中，ClickHouse 的 ReplacingMergeTree 在高更新频率下产生了大量未合并的 Part，导致查询性能退化。

痛点二：复杂 JOIN 效率低。广告归因分析需要将曝光数据、点击数据、转化数据和维表做多维关联，ClickHouse 的 JOIN 在 4 表以上场景下查询时间不可控。

痛点三：运维复杂度高。ClickHouse 的集群扩缩容需要手动迁移数据，每次扩容耗时数小时。

迁移到 StarRocks 后，关键改善包括：Upsert 延迟从秒级降到毫秒级（Primary Key 模型 + LSM-Tree 索引）、多表 JOIN 查询时间缩短 40%–60%（MPP Shuffle Join）、集群扩缩容时间从小时级降到分钟级（存算分离架构）。整体查询 P99 延迟从 12 秒降到 3 秒以内。

选型建议

选 ClickHouse 的场景：单表聚合查询为主、数据更新频率低、团队有 ClickHouse 运维经验、对查询延迟有极致要求。ClickHouse 在日志分析、用户行为分析等"写多读少、单表大宽表"的场景下仍然是性能天花板。

选 Doris 的场景：需要 MySQL 兼容降低接入成本、需要统一的分析入口（OLAP + 数据湖查询）、对运维简便性有高要求。Doris 的"开箱即用"特性使其在中小企业和快速原型场景中有明显优势。

选 StarRocks 的场景：需要实时更新 + 复杂 JOIN + 云原生弹性的组合能力、数据量大且增长快、对成本敏感。StarRocks 的存算分离架构在数据量和查询复杂度同步增长的场景下最能发挥价值。

最后的忠告是：不要只看基准测试数据。TPC-DS 或 TPC-H 的跑分只能反映引擎的理论上限，实际业务中的数据分布、查询模式、并发模式、运维能力才是决定成败的关键因素。建议用你自己的数据和查询做 A/B 测试，而不是依赖公开的对比报告。