面试官问'为什么选Doris不选ClickHouse'——技术选型怎么讲才有说服力？
本文目录
先说结论
技术选型的四维度模型：业务需求匹配度 → 团队能力适配度 → 生态兼容性 → 运维成本。不是'哪个技术更好'，而是'哪个最适合当前场景'。
面试回答的公式：'我们选了A而不是B，因为在我们的场景下（具体业务需求），A在XX维度上更匹配。虽然B在YY方面更强，但对我们来说ZZ更重要。'
最忌讳的回答：'因为A性能更好'——片面。'因为领导说用A'——没有思考。'因为网上都说A好'——人云亦云。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
技术选型是面试必问题，但大多数人的回答毫无说服力——要么说'公司用的这个我就用了'（显得没有思考），要么说'XXX性能最好所以选它'（太片面）。面试官问选型，考的不是你知道多少技术，而是你有没有系统化的决策能力。我在三家公司经历过多次技术选型——Doris vs ClickHouse、Flink vs Spark Streaming、Delta Lake vs Iceberg、Canal vs Debezium——今天把选型的方法论和实战案例全讲出来。
选型四维度模型
| 维度 | 考察什么 | 关键问题 | 权重 |
|---|---|---|---|
| 业务需求匹配 | 技术能力是否满足业务场景 | 延迟要求？并发要求？数据量级？查询模式？ | 最高 |
| 团队能力适配 | 团队是否有能力驾驭这个技术 | 学习成本？招聘难度？现有经验？ | 高 |
| 生态兼容性 | 跟现有技术栈是否集成良好 | 能否跟现有数据链路打通？SDK/Connector完善？ | 中 |
| 运维成本 | 部署、监控、升级、故障处理 | 是否需要专人运维？社区是否活跃？云服务可用？ | 中 |
实战案例一：Doris vs ClickHouse
这是我在某元宇宙社交应用做实时数仓OLAP引擎选型时的决策过程。两个都做了POC测试，最终选了Doris：
// 选型背景
// 业务需求：实时大屏 + 运营自助查询 + 秒级响应
// 数据量级：日增20GB，历史数据3TB
// 团队能力：3个数据开发，无DBA
// 现有技术栈：Flink + Kafka + Hive| 维度 | Apache Doris | ClickHouse | 我的评估 |
|---|---|---|---|
| 查询性能 | 优秀（MPP架构） | 极优秀（列存+向量化） | CH略快，但Doris够用 |
| 并发能力 | 高（支持100+ QPS） | 低（单查询吃满资源） | Doris胜（运营自助查询需要高并发） |
| 实时写入 | 原生支持Stream Load | 支持但写入时影响查询 | Doris胜（实时+查询互不影响） |
| 运维复杂度 | 低（FE+BE架构简单） | 高（需要ZooKeeper/Keeper） | Doris胜（团队没有DBA） |
| Flink集成 | Flink Doris Connector成熟 | 需要JDBC Sink或ClickHouse Sink | Doris略胜 |
| JOIN能力 | 支持多表JOIN | 单表性能极强但JOIN较弱 | Doris胜（需要多维分析JOIN） |
最终决策：选Doris，核心原因是我们需要'高并发自助查询'——运营团队20多人要同时在BI工具上做自助分析，ClickHouse的并发能力扛不住。虽然ClickHouse单表查询性能更强，但在我们的场景下，并发能力和运维简单性比单表性能更重要。
实战案例二：Hologres vs Doris
到了某短剧出海公司，技术栈换成了阿里云全家桶（MaxCompute + Flink + DataWorks）。这次OLAP引擎选型在Hologres和Doris之间做选择，最终选了Hologres：
// 选Hologres的核心理由：生态兼容性
// 1. 跟MaxCompute无缝打通
// MaxCompute的表可以直接在Hologres中查询（外部表）
// 不需要额外的数据同步链路
// 2. 跟DataWorks原生集成
// DataWorks可以直接调度Hologres SQL
// 不需要额外的调度配置
// 3. 跟Flink on 阿里云原生集成
// Flink Hologres Connector官方维护
// 支持实时Upsert写入
// 4. 运维零成本
// Hologres是全托管服务（Serverless）
// 不需要自己运维集群
// 虽然Doris开源免费，但部署在阿里云ECS上
// 需要自己运维集群、升级补丁、处理故障
// 团队只有5人，没有精力自运维OLAP集群实战案例三：Flink vs Spark Structured Streaming
在某出海硬件品牌做实时链路时，在Flink和Spark Structured Streaming之间做选择：
| 维度 | Flink | Spark Structured Streaming | 我的评估 |
|---|---|---|---|
| 延迟 | 真正的流处理（毫秒级） | 微批处理（秒级） | Flink胜 |
| Exactly-Once | 原生支持（Checkpoint+2PC） | 支持（微批天然幂等） | 平手 |
| State管理 | 丰富的State API + RocksDB | 依赖Checkpoint和Delta Lake | Flink胜 |
| 与Databricks集成 | 需要独立部署 | 原生集成（同一个平台） | Spark胜 |
| 团队经验 | 之前用过Flink | 团队Spark经验丰富 | Spark略胜 |
| 运维成本 | 独立Flink集群 | 复用Databricks平台 | Spark胜 |
最终决策：选了Spark Structured Streaming——虽然Flink在流处理能力上更强，但我们的实时需求延迟要求不高（分钟级就行），而且整个平台已经跑在Databricks上，用Spark可以复用同一套基础设施，不需要额外运维一套Flink集群。这个决策的核心逻辑是：当业务需求不需要毫秒级延迟时，生态兼容性和运维成本比技术性能更重要。
面试高频追问
追问一：如果让你重新选，会不会改变决策？
这个问题面试官经常问，考的是你的反思能力。我的回答是：Doris vs ClickHouse的决策不会变——并发和运维成本的优势在实际使用中得到了验证。Hologres的决策也不会变——全托管带来的运维零成本确实让小团队受益巨大。Spark Streaming的决策有一点反思——后来我们的一些需求确实需要更低延迟（比如实时风控），不得不额外部署了两个Flink作业。如果重来，我会在初期就用Flink做核心实时链路，而不是后来再加。
追问二：你怎么做POC测试的？
POC测试三步走：① 准备真实数据集（从生产环境采样1亿行数据）；② 设计测试场景（单表查询、多表JOIN、高并发、实时写入+同时查询、故障恢复）；③ 每个场景记录延迟、吞吐、资源消耗三个指标。POC一般做1-2周，不需要太长——关键是测试场景要覆盖真实的业务需求，不是跑TPC-H标准测试。
追问三：你选的技术后来遇到过什么限制吗？
一定会遇到。坦诚说出来反而加分——因为这证明你真的用过。比如Doris的限制：早期版本JOIN性能不够好（后来Doris 2.0改善了很多）、不支持UPDATE/DELETE（后来用Unique Key模型+MERGE解决）。Hologres的限制：成本比开源Doris高（但省了运维人力）、SQL方言跟标准SQL有差异（需要适配）。每次遇到限制时，我们都是先评估能否绕过，绕不过就加一层中间方案。
实战踩坑
选型过程中最大的教训是：不要被技术社区的声音左右决策。我在选Doris vs ClickHouse时，网上大量文章说'ClickHouse性能碾压Doris'，团队里也有人坚持要用ClickHouse。但我坚持先做POC测试，用我们自己的数据和场景测。结果在高并发场景下（模拟20个用户同时查询），ClickHouse的P99延迟从200ms飙到了3秒，而Doris稳定在500ms以内。这跟网上'ClickHouse性能更好'的结论完全相反——因为网上的测试大多是单用户单查询场景。
// POC测试结果（高并发场景）
// 测试条件：20个并发查询，3TB数据量，混合查询（简单+复杂）
// ClickHouse：
// 并发=1时 P99=180ms（确实很快）
// 并发=5时 P99=800ms
// 并发=10时 P99=1.8s
// 并发=20时 P99=3.2s（不可接受）
// Doris：
// 并发=1时 P99=350ms（略慢于CH）
// 并发=5时 P99=420ms
// 并发=10时 P99=480ms
// 并发=20时 P99=520ms（稳定！）
// 结论：单查询ClickHouse快，但高并发下Doris更稳教训：技术选型必须基于自己的场景做POC，不能依赖网上的评测文章。每个业务的数据特征、查询模式、并发需求都不同，别人的结论不能直接套用。
总结
技术选型的核心是四维度模型：业务需求、团队能力、生态兼容、运维成本。面试时回答选型问题，要用'我们选A因为在我们的场景下XX更重要'的公式，不要只说'A性能更好'。能说出POC测试过程、遇到过的限制、以及对决策的反思，说明你有完整的选型方法论和实战经验。
技术选型讲清楚了，最后一篇聊面试的收官之作——面试官问'你这个项目最大的难点和亮点是什么'，怎么回答才能给面试官留下深刻印象？
你在项目中做过哪些技术选型？有没有选错过的经历？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长