考察点
这是开放型架构题，面试官想看决策框架而不是结论背诵。高分答案的特征是：先问清楚约束再推引擎、每个约束能映射到具体引擎特性、敢承认「没有银弹」。追问通常是给一个具体业务场景让你现场推演，或者问「你们当时为什么选了 X」。
参考答案
第一步：明确三个硬指标
选型不是从引擎名单开始，而是从业务约束开始。三个指标必须先量化：
数据量级与增速。每天百万行和每天百亿行是两个世界。日增百亿行的日志场景，写入吞吐和压缩率是生死线；总量几千万行的经营报表，任何主流引擎都能跑，选型权重应该让给别的因素。
查询并发与延迟。给分析师用的内部平台，并发个位数、秒级可接受；给 C 端产品或大看板供数，几百到几千 QPS、P99 亚秒——这一条直接淘汰一批引擎。
更新频率与模式。纯追加、T+1 修正、实时 CDC UPSERT，三种模式对应完全不同的存储结构要求。这是 OLAP 选型里区分度最高的一个问题。
硬指标到引擎特性的映射
| 约束 | 指向的特性 | 受益者 |
|---|---|---|
| 百亿级追加写 | 顺序写 + 高压缩 + 后台合并 | ClickHouse、Doris |
| 高并发小查询 | MPP 短查询调度、点查索引 | Doris、StarRocks |
| 行级实时更新 | 主键模型 / MoW | Doris、StarRocks |
| 极低并发大扫描 | 单机向量化极限 | ClickHouse |
| 稳定亚秒 + 固定指标 | 预计算 Cube | Kylin、Doris MV |
第二步：叠加软约束
硬指标收敛到 2-3 个候选后，用软约束拍板：
Join 与建模方式。能接受数仓侧先打成大宽表，CK 就好用；业务要求星型模型即席关联，选 CBO 成熟的 MPP 引擎（Doris/StarRocks）。这一条经常被忽视，上线后才发现 join 性能不达标，返工成本极高。
生态与接入成本。BI 工具用什么协议（MySQL 协议兼容性 Doris 最好）、团队熟悉什么、上游是 Kafka 还是 Hive、要不要联邦查询外表。引入一个引擎同时要引入它的监控、备份、扩缩容运维体系，隐性成本要算。
团队与社区。引擎的版本迭代速度、生产案例、出问题能不能找到人问。小众引擎的纸面参数再漂亮，团队 hold 不住也是负资产。
第三步：用排除法走一个完整例子
演示一下框架怎么用。场景：电商实时经营看板，业务库 MySQL 通过 Canal 同步，看板 300 QPS，要求分钟级新鲜度，查询带店铺、类目、地区多维下钻。
- CDC 有更新 → 排除 ClickHouse（mutation 和 Replacing 都不舒服）；
- 300 QPS → 排除 Kylin（建模固定，下钻组合多变）；
- 多维下钻 → 明细 + Rollup/MV 可解；
- MySQL 协议 BI 直连 → Doris 或 StarRocks；
- 最终 Doris：Unique Key 模型接 CDC，Rollup 加速高频下钻组合，MySQL 协议接看板。
常见的选型错误
最后总结几个反面教材，面试里很加分。一是 benchmark 迷信：拿 TPC-DS 分数拍板，忽略了自己业务是 80% 点查还是 80% 大扫描，分布完全不同。二是忽视写入模式：上线才发现业务有 20% 更新，CK 架构下补丁越打越多。三是功能贪心：一个平台想同时服务 C 端高并发和分析师 Ad-hoc，结果两边都不满意——正确做法是分层，明细层 + 服务层用不同引擎。四是低估运维：集群扩缩容、版本升级、数据均衡都要人力，小团队选运维最省的那个。
一句话框架
数据形态（追加还是更新）决定存储模型，负载形态（并发与扫描比例）决定执行架构，团队形态（运维与生态）决定落地成本——三层问完，候选名单基本自己浮出来。
可能的追问
- 数据量不大时选型还有意义吗？—— 有，权重转移而已。小数据量下性能都过剩，决策权重移到查询并发、更新支持、接入成本和团队熟悉度上。
- StarRocks 和 Doris 怎么再细分？—— 两者能力高度重叠，差异在细节：StarRocks 向量化做得早、存算分离版本推进快；Doris 生态中文资料多、社区活跃。实测自己业务的典型查询压测，比看文档靠谱。
- 选了之后怎么验证没选错？—— 上线前用真实数据分布和查询 SQL 做 POC 压测，覆盖写入峰值、并发高峰、最大单查询三种极端场景，别用官方 demo 数据。