StarRocks vs ClickHouse vs Doris：三大 OLAP 引擎选型深度对比
构建数据特征、查询模式、运维能力三维选型矩阵，结合快手替换 ClickHouse 为 Doris 的实战案例给出场景化推荐
袋鼠云
三维选型矩阵
选型 OLAP 引擎不应只看性能跑分，而应从数据特征、查询模式、运维能力三个维度综合评估。以下是经过生产验证的决策框架：
维度一：数据特征
- 宽表扁平化场景（单表 100+ 列，少 JOIN）：ClickHouse 是首选。其 MergeTree 引擎在宽表上的列式压缩率和扫描性能行业领先，SSB 100G 基准测试中单表查询延迟多数在秒级以内。
- 星型/雪花模型（频繁多表 JOIN）：StarRocks 和 Doris 的 CBO 优化器表现更好。StarRocks 的 Broadcast Join、Shuffle Join、Colocation Join 三种策略可自动选择最优 JOIN 方式，在 TPC-H 测试中能完成 ClickHouse 无法跑通的多表关联查询。
- 数据更新频繁（订单状态、用户画像实时变更）：StarRocks 的主键模型支持 Delete-and-Insert，更新性能比传统 Merge-on-Read 模式提升约 3 倍。Doris 的 Unique Key 模型同样支持实时更新。ClickHouse 的 ReplacingMergeTree 需要后台合并才能去重，存在短暂的数据不一致窗口。
维度二：查询模式
- 高并发简单查询（QPS > 1000）：ClickHouse 在三副本集群下推荐 QPS 控制在 100 以内，单个查询即可能占满半个 CPU。StarRocks 支持数千用户并发分析，在互联网和金融场景中已验证万级并发能力。Doris 通过 Pipeline 执行引擎和资源隔离，同样具备高并发能力。
- Ad-hoc 探索式查询（临时维度组合）：三者均可支持，但 StarRocks 和 Doris 的物化视图和预聚合能力更适合动态维度变化，无需提前打平宽表。
- 实时数据导入 + 即时查询（秒级可见）：StarRocks 支持 Stream Load 和 Routine Load（对接 Kafka），数据导入后秒级可查。Doris 同样支持 Flink CDC 直写。ClickHouse 的 Kafka 表引擎支持实时消费，但写入后需要等待 part 合并才能被分布式表完全可见。
维度三：运维能力
- 集群扩缩容：StarRocks 和 Doris 在感知节点拓扑变化后可自动调度 Tablet 迁移，实现在线弹性扩缩容。ClickHouse 无法自动感知集群拓扑变化，扩节点后需手动重平衡数据（通过设置权重、临时表迁移或 TTL 自然淘汰），运维成本显著更高。
- 依赖组件：ClickHouse 依赖 ClickHouse Keeper（或 ZooKeeper）进行副本协调。Doris 的 FE + BE 架构自包含，不依赖外部协调服务。StarRocks 同样 FE/BE 自包含，支持 FE 共识协议。
- 生态兼容：三者均支持 MySQL 协议客户端连接。StarRocks 和 Doris 对 Hive 外表、Iceberg、Hudi、Delta Lake 等湖仓格式的支持更成熟，适合联邦查询场景。
数栈·多模态数据智能平台
袋鼠云面向 AI 时代打造的多模态数据智能平台，一站式覆盖数据存算、开发、治理、资产、服务与指标、分析、AI 应用，构建可见、可用、可管、可理解的私域数据底座。
快手替换 ClickHouse 为 Doris 的实战启示
快手曾是 ClickHouse 的重度用户，日增数据量达数十 TB 级别。随着业务发展，ClickHouse 暴露出几个关键痛点：
- 运维复杂度高：集群规模扩大后，数据重平衡和故障恢复耗时长，节点扩缩容需要人工介入。ClickHouse 集群无法自动感知节点变化，需自研 CMDB 联动脚本来实现数据迁移。
- JOIN 能力受限：随着分析需求从宽表转向星型模型，ClickHouse 在多表 JOIN 场景下频繁出现 OOM，迫使业务层不得不维护大量打平宽表，增加了 ETL 复杂度和存储冗余。
- 高并发瓶颈：当分析师规模增长到数百人时，ClickHouse 的查询并发能力成为瓶颈，不得不将查询结果写入 MySQL 再对外服务，架构链路过长。
快手最终选择 Apache Doris 作为替代方案，核心原因包括：Doris 的 Unique Key 模型支持实时 Upsert，FE/BE 架构无需外部依赖、扩缩容自动化程度高，且社区迭代速度快。迁移后，多表关联查询不再需要打平宽表，运维团队从专人维护 ClickHouse 集群缩减为兼职覆盖。
经营分析
围绕目标、预算、执行、异常与归因，构建经营分析、过程监控、问题定位与决策闭环。
场景化推荐速查
- 日志分析、监控看板、宽表聚合 → ClickHouse：压缩率高、单表查询极致、社区成熟
- 实时数仓、订单分析、高并发 BI → StarRocks：CBO 优化器强、主键更新快、万级并发
- 混合负载、渐进式替换 ClickHouse、湖仓联邦 → Doris：运维简单、生态兼容好、迁移成本低
需要注意的是，引擎选型不是零和博弈。越来越多的团队采用混合架构——ClickHouse 负责日志和宽表场景，StarRocks 或 Doris 负责交互式分析和多表关联，通过数据分层让各引擎发挥所长。关键在于建立统一的元数据管理层，让跨引擎的数据血缘和质量监控形成闭环。
无论选择哪款引擎，建议在 POC 阶段用真实业务数据和查询进行至少两周的压力测试，重点关注数据导入延迟、P99 查询延迟、并发承载能力和运维操作复杂度四个维度，避免仅凭官方基准测试结果做决策。
