实时 OLAP 引擎选型：ClickHouse 与 Doris、StarRocks

实时 OLAP 引擎选型，最先要纠正的误区是"看基准测试分数选引擎"。ClickHouse、Doris、StarRocks 在各自的典型场景下都能跑出漂亮数字，真正决定成败的是你的写入模型、查询形态、并发压力和运维资源四个变量。一句话结论：如果以高并发单表聚合和点查为主、写入是追加型，ClickHouse 最省心；如果需要高频 upsert、复杂多表 Join 和完整数仓建模，优先考虑 Doris 或 StarRocks；两者的选择再落到你对运维复杂度和生态的偏好上。

实时 OLAP 的核心诉求与评估维度

选型前先列出四个必答问题：

• 写入形态：数据是只追加，还是需要按主键更新删除？这决定引擎的数据模型能否支撑。
• 查询形态：是"大宽表单表聚合/明细点查"为主，还是"多表 Join + 复杂分析"为主？
• 并发与延迟：服务的是报表看板（亚秒响应）还是接口服务（数千 QPS）？
• 运维能力：团队能维护几个组件、几类集群？存算分离是否是刚需？

这四个问题的答案组合，比任何 benchmark 排行都更能决定选型结果。

三引擎架构与特性差异

三个引擎都是列式存储 + 向量化执行的共享无共享（shared-nothing）架构，但设计取舍不同。

• ClickHouse：以 MergeTree 家族为核心，数据按分区和排序键组织，写入先落内存再异步合并，读取时列裁剪和向量化极强；多副本由 ReplicatedMergeTree + ClickHouse Keeper 管理，跨节点查询靠 Distributed 表。它的强项是单表超大数据的聚合和点查，弱项是 Join 与事务。
• Doris：MPP 架构，FE 负责元数据与查询规划、BE 负责存储与计算，2022 年毕业为 Apache 顶级项目。提供 Duplicate/Unique/Aggregate 三种数据模型，2.0 起 Unique 模型支持 Merge-on-Write，upsert 效率明显提升；3.0 引入计算存储分离的多集群架构。
• StarRocks：源自早期 Doris 代码库的分叉，独立演进后主打 C++ 向量化执行与 Primary Key 表，同样采用 FE/BE 的 MPP 架构，3.0 起提供 Shared-Data 存算分离模式。它在 CBO、Runtime Filter、Colocate Join 上投入较多，并且把外部数据源的 Catalog 查询作为一等能力。

实时写入能力对比

• ClickHouse：为高吞吐追加写入而生，批量写入效率高；但高频小批量写入会产生大量 parts，需要频繁合并；UPDATE/DELETE 靠异步 mutation，不适合高频按主键更新。CDC 实时数仓直接套在它上面通常很别扭。
• Doris：Stream Load / Routine Load 配合 Flink Connector 是标准姿势，Unique 模型的 Merge-on-Write 让高频 upsert 成为常规操作，适合"明细层 + CDC 同步"的实时数仓链路。
• StarRocks：同样提供 Stream Load 与 Flink Connector，Primary Key 表支持高频 upsert，写入吞吐和 Doris 同属一个量级，差异主要体现在实现细节与调优习惯上。

如果业务需要"实时写入 + 主键更新删除"，基本可以先把 ClickHouse 排除，在 Doris 与 StarRocks 之间选。

高并发查询与多表 Join 对比

• 单表大宽表聚合：三者都能做好；ClickHouse 的向量化与排序键设计在超大表单表聚合上最激进，但并发能力依赖副本数和集群规模。
• 多表 Join：这是分水岭。ClickHouse 的 Join 依赖内存哈希表，驱动表受限、大表 Join 大表容易内存溢出，复杂多表 Join 场景维护成本高；Doris 和 StarRocks 是原生 MPP，有完整的 CBO、Join 重排、Runtime Filter，还提供 Colocate Join / Bucket Join 让同分布数据本地关联，多表 Join 的稳定性和可预测性明显更好。
• 高并发：报表场景三者都能支撑；接口服务化查询（数千 QPS）通常需要配合缓存或多副本扩容，Doris/StarRocks 的 FE 路由 + BE 横向扩展相对简单。

运维复杂度与生态

• 组件与扩缩容：ClickHouse 需要自己规划分片和副本，扩容往往伴随 rebalance 的思考；Doris/StarRocks 都是 FE/BE 两个角色，加 BE 即可扩容，运维模型更接近"开箱即用"的数仓。
• 生态：三者都有 Flink/Kafka 接入和主流 BI 工具支持；Doris 与 StarRocks 在国内实时数仓链路（Flink CDC 到引擎）的集成和资料更密集；ClickHouse 的国际化生态和第三方工具更丰富。
• 湖仓能力：如果要用 SQL 直接查 Hive/Iceberg/Paimon 上的数据，StarRocks 的外部 Catalog 与 Doris 的多 Catalog 都比 ClickHouse 顺手。

四象限选型决策树

按优先级给决策分支：

• 写入是纯追加 + 查询以单表单聚合/点查为主 + 并发通过副本解决 → ClickHouse。
• 需要主键 upsert 或删除 + 多表 Join 占比高 → Doris 或 StarRocks，进入下一层。
• 在 Doris 与 StarRocks 之间：更看重开源社区与国内生态的成熟度选 Doris；更看重向量化执行、湖仓外部 Catalog 与存算分离选 StarRocks。
• 查询以"直接查湖上数据"为主、不想把数据搬进引擎 → StarRocks 或 Doris 的外部 Catalog。
• 团队运维能力有限、希望最少组件 → Doris/StarRocks（两个角色），而不是 ClickHouse（分片/副本/Keeper 都要自己管）。

选型前的验证实验

纸上决策之后，用真实数据做一轮 PoC，每个引擎跑同样的四组实验：

• 写入压测：用生产峰值流量的数据量和主键形态写入，观察吞吐、延迟和副本同步情况；ClickHouse 重点看小批量写入后的 parts 数量，Doris/StarRocks 重点看 upsert 与 compaction 的稳定性。
• 查询压测：挑 3 到 5 个线上典型查询（含一个大宽表单表聚合和两个多表 Join），在目标并发下跑，记录 P50/P95 延迟，不要只比单查询最快耗时。
• 倾斜与稳定性：用带热点 Key 的真实分布跑 Join，观察是否有长尾和内存溢出；这比 benchmark 更能暴露引擎短板。
• 运维演练：在测试集群做一次扩缩容、一次节点故障恢复、一次版本升级，记录耗时和人工介入程度。

PoC 的验收标准应该是"目标并发下的 P95 延迟 + 写入追平能力 + 运维可承受度"三个指标同时达标，而不是某个引擎在某个查询上快几倍。

常见失败模式

• 只用追加型业务验证 ClickHouse，上线后引入 upsert 需求，才发现 mutation 成本高、只能重建表。
• 高并发点查直接把 ClickHouse 当作服务层，忽略了并发受副本数限制，压测时 QPS 上不去。
• Doris/StarRocks 的 Unique/Primary Key 表不做分桶和排序键设计，compaction 压力大、查询变慢。
• 迁移时直接在应用层双写两个引擎，双写事务不一致导致对账天天出差异；正确做法是单一 CDC 链路 + 目标端追平验证后再切流量。

迁移与组合建议

迁移不建议"一把梭"：先用全量导入工具把历史数据同步到目标引擎，再挂增量同步（Flink CDC / Stream Load）追平，双跑一段时间对比口径和延迟，确认一致后再切换读流量。迁移中最容易被低估的是数据模型差异：ClickHouse 的排序键、Doris 的 Unique Key 分桶、StarRocks 的 Primary Key 分桶各自决定了查询能走多快的路径，直接照搬建表语句往往性能腰斩，建表前要用目标引擎的典型查询重新设计排序键与分桶，而不是只搬数据。更常见的做法是组合使用：用 Doris/StarRocks 承接实时数仓的明细与宽表建模、多表 Join 与 BI 查询，把 ClickHouse 保留给对延迟和并发要求最高的单表服务查询；两套引擎之间的数据流转用同一套 CDC 链路维护，避免应用层双写带来的一致性问题。