面试官问'为什么选Spark不选Flink'——技术选型怎么讲不像背课文？

面试时怎么讲技术选型：完整的回答模板

我用在某知名出海硬件品牌选Spark+Databricks的例子演示完整的讲法：

// 面试时的完整回答结构
 
// 第1步：说清业务需求
"我们的业务是消费电子出海，核心数据需求是T+1的设备激活报表、
  用户复购分析、渠道ROI报表。对实时性要求不高，
  但对数据准确性和批处理性能要求很高。"
 
// 第2步：说清候选方案
"当时对比了三个方案：
  A. 继续用AWS EMR跑开源Spark；
  B. 迁移到Databricks；
  C. 用Flink做统一的流批一体。"
 
// 第3步：说清对比维度和排除理由
"排除A是因为EMR运维成本高、集群不稳定。
  排除C是因为我们主要是离线场景，Flink的批处理生态
  不如Spark成熟，而且团队更熟悉Spark SQL。"
 
// 第4步：说清最终决策理由
"最终选了Databricks，三个原因：
  1. Spark SQL生态最成熟，团队上手快；
  2. Delta Lake解决了数据湖的ACID和MERGE INTO需求；
  3. 自带AQE+Z-Ordering，性能优化开箱即用。"
 
// 第5步：用数字说效果
"迁移后ETL执行时间减少40%，查询延迟降低70%，
  存储成本降低35%。"

选型时容易忽略的'软因素'

很多候选人讲技术选型只讲技术维度，但实际工作中，软因素往往更影响最终决策：

// 面试时提到这些'软因素'会大加分
 
// ① 团队熟悉度
"我们团队3个人都熟悉Spark SQL，如果选Flink需要至少1个月的学习成本。
  在项目deadline很紧的情况下，选团队最熟悉的技术是最务实的。"
 
// ② 运维成本
"Databricks是托管服务，不需要我们自己运维集群。
  我们是小团队，没有专职运维，这个因素很重要。"
 
// ③ 招人难度
"Spark的人才池比Flink大得多。
  如果后面要扩团队，招Spark开发比招Flink开发容易。"
 
// ④ 社区和文档
"遇到问题时，Spark/Databricks的文档和社区比较完善，
  能更快地找到解决方案。"
 
// ⑤ 成本
"Databricks的费用比自建EMR高20%左右，
  但省掉了运维人力，综合算下来反而更便宜。"

面试高频追问

追问一：如果现在让你重新选，还会选Spark吗？

这是考你对技术发展趋势的了解。我的回答是：'离线批处理场景仍然会选Spark，这个没变。但如果有新的实时需求，我会引入Flink做实时层，而不是用Spark Structured Streaming。因为现在Flink SQL的成熟度比两年前好了很多，阿里云的Flink托管服务也很稳定。实际上我现在在某短剧出海公司就是Flink+MaxCompute的组合——实时用Flink，离线用MaxCompute（底层也是类Spark的引擎）。'

追问二：你们有没有考虑过流批一体？

这是考你对架构趋势的思考。回答时不要一味追捧新概念：'流批一体是趋势，但目前落地还有挑战。Flink在做流批一体，Databricks也在做。但实际上完全的流批一体意味着一套代码处理流和批，对SQL的要求很高，而且调试复杂度也高。我的观点是：如果团队有能力且业务确实需要，可以尝试。但大多数中小团队，流和批分开处理反而更清晰可控。不要为了架构先进性牺牲工程可维护性。'

追问三：你怎么评估一个新技术要不要引入？

这考的是你的技术决策框架。我会说：'我有一个三问原则：第一，这个技术解决了我们现在的什么痛点？如果没有明确痛点，不引入。第二，引入成本是多少？包括学习成本、迁移成本、运维成本。第三，有没有更简单的方案？能用参数调优解决的不换引擎，能用SQL解决的不写代码。我在某出海硬件品牌决定从EMR迁移到Databricks就是这个思路——痛点是运维成本和性能，引入成本可控（还是Spark生态），没有更简单的替代方案。'

实战踩坑

我在某元宇宙社交应用踩过一个技术选型的大坑。当时公司要搭建实时数据平台，我调研了Spark Streaming和Flink。因为团队更熟悉Spark，一开始选了Spark Structured Streaming。

结果上线后发现，虚拟礼物交易的看板延迟在5-8秒，业务方要求3秒以内。Spark Structured Streaming的微批模式，即使把trigger interval调到最小，加上数据序列化和微批调度的开销，也很难稳定做到3秒以内。

// 踩坑过程
 
// 第1阶段：选了Spark Structured Streaming
// 理由：团队熟悉Spark，觉得Structured Streaming够用
// 结果：延迟5-8秒，不满足业务的3秒要求
 
// 第2阶段：尝试优化Spark Streaming
// 调小trigger interval、优化序列化、减少Shuffle
// 结果：延迟降到4-5秒，还是不够
 
// 第3阶段：切换到Flink
// Flink事件驱动模式，延迟稳定在1-2秒
// 代价：团队花了3周学习Flink，迁移花了2周
 
// 教训：选型时应该先做POC验证核心指标
// 而不是基于'团队熟悉'就做决定
// 尤其是对延迟有硬性要求的场景

教训：技术选型的第一步应该是做POC（概念验证），用真实数据和真实场景验证核心指标。当时如果花一天时间分别用Spark Streaming和Flink跑个Demo测延迟，就不会走弯路了。'团队熟悉度'是重要因素，但不能凌驾于'能不能满足业务需求'之上。

总结

讲技术选型用五步法：业务需求→候选方案→对比维度→决策理由→实际效果。不要只说功能对比，要说为什么在你的场景下选了这个。记得提'软因素'——团队熟悉度、运维成本、招人难度。面试时能讲清楚'为什么不选'比'为什么选'更有说服力，因为它证明了你做过真正的技术决策，不是随波逐流。

下一篇聊一个高级面试题：面试官问你'数据架构是怎么设计的'——怎么讲才能展示全局视野？

你在项目中做过什么技术选型？最纠结的一次选择是什么？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长