考察点
这是架构选型类高频题，面试官不期待背参数，期待你有一套决策框架：先问数据形态（要不要更新），再问负载形态（并发多高、join 多不多），最后看团队运维能力。能讲出两边各自的短板比吹优点更加分。追问常落在「日志场景为什么选 CK」「实时报表为什么选 Doris」这类具体场景反推。
参考答案
先看本质差异：两个引擎的设计目标不同
ClickHouse 的设计目标是把「单机大宽表扫描」做到极致——列存、稀疏索引、向量化全都围着这个目标转，分布式能力反而是后来补的。Doris 从第一天就是 MPP 分布式数据库，目标是替代 Greenplum、Impala 这类传统 MPP，同时兼容 MySQL 协议吃下 BI 生态。设计目标不同，导致后续所有差异都有迹可循。
核心维度对比
| 维度 | ClickHouse | Doris |
|---|---|---|
| 单机扫描性能 | 极致，单核每秒数亿行 | 强，但单机能效略逊 |
| 高并发点查/小查询 | 弱，默认 100 并发就吃力 | 强，数千 QPS 级 |
| 行级更新 | 弱（mutation 重写 part） | 强（Unique Key + MoW 真 UPSERT） |
| 多表 Join | 弱，大表 join 容易爆内存 | 强，CBO + shuffle join 完整 |
| 写入吞吐 | 极高，攒批追加 | 高，但攒批要求略严 |
| SQL 兼容性 | 方言多，函数体系独特 | MySQL 协议兼容，BI 直连 |
| 运维复杂度 | 高（ZK/Keeper、手动分片、merge 调优） | 低（FE/BE 两种进程，自动均衡） |
| 生态 | 日志/监控场景成熟（Grafana 等） | 报表/实时数仓场景成熟 |
用决策框架而不是背结论
第一问：数据要更新吗？业务库 CDC 同步、维度表频繁修正、需要按主键 UPSERT——直接 Doris，ClickHouse 的 ReplacingMergeTree 只是「查询时去重」的妥协方案，mutation 更新在大表上是灾难。纯追加的日志、埋点、IoT 时序——两个都行，进入下一问。
第二问：并发和查询形态？给业务系统或大屏供数，几百上千 QPS 的小查询——Doris，它的 MPP 调度、短查询优化、MySQL 协议就是干这个的。内部分析师跑 Ad-hoc 大查询、一次扫几亿行但并发很低——ClickHouse 单机性价比无敌。
第三问：join 多不多？建模是大宽表（数仓 DWS 层打平后交付）——ClickHouse 很舒服。星型模型、查询带多个维度表关联——Doris，CK 的 join 在大数据量下要么字典预加载、要么人工半join，工程上很别扭。
第四问：团队能养几个人运维？CK 集群的分片设计、副本对齐、merge 参数、ZK 都要人盯；Doris 扩缩容基本自动，FE/BE 架构简单。小团队倾向 Doris，有专职 SRE 且场景匹配时 CK 的性能上限更高。
各自的典型场景画像
ClickHouse 的主场：日志检索分析（很多可观测性产品底层就是它）、用户行为漏斗/留存分析（它的事件序列函数和漏斗函数很强）、广告曝光点击明细、IoT 时序。共同点是数据只增不改、查询低并发重扫描。
Doris 的主场：实时数仓 DWS/ADS 层、经营报表和 BI 看板、用户画像点查、需要 CDC 实时同步业务库的分析场景。共同点是有更新、有 join、有并发。
不回避短板
面试里主动说短板显得真实。CK 的短板：并发一高 CPU 就打满、更新删除别扭、join 弱、集群运维门槛高。Doris 的短板：单机极限性能不如 CK（超大规模明细扫描成本更高）、版本迭代快踩坑概率高、生态工具链没 CK 在日志领域成熟。两者都不擅长的也要提一句：真正的高并发点查（上万 QPS）应该加缓存或用 KV，OLAP 引擎不是干这个的。
可能的追问
- 我们公司日志平台每天百亿行写入，选哪个？—— ClickHouse。纯追加、重扫描、低并发分析，正对它设计目标；配合 Kafka 引擎 + 物化视图预聚合是成熟方案。
- 实时经营看板 500 QPS，数据来自业务库 CDC，选哪个？—— Doris。CDC 需要 UPSERT（Unique Key 模型），500 QPS 超了 CK 舒适区，MySQL 协议还能让 BI 工具直连。
- 两个能混用吗？—— 常见架构：CK 存日志明细做行为分析，Doris 承载数仓汇总层和对外报表，各干各的主场，数据通过调度或外表互通。