Flink和Spark Streaming到底选哪个？
总结
Flink擅长低延迟、复杂状态、CEP。Spark擅长批流一体、大生态。选型的核心是看延迟要求和团队技术栈。面试时能说清楚核心对比点，再加一个“我在不同公司的不同选择”的实战，就很有说服力。
下一篇聊一个很实用的调优问题：TaskManager的Slot数设多少合适？并行度怎么定？
你们生产环境用的是Flink还是Spark Streaming？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
这是实时计算领域最经典的选型问题。我在两家公司分别用过这两个引擎，体会很深。简单说：对延迟要求高、有复杂状态逻辑选Flink；已经是Spark技术栈、延迟要求不高选Structured Streaming。今天把每个维度的对比和我的实战选型经验讲清楚。
核心对比
| 维度 | Flink | Spark Structured Streaming |
|---|---|---|
| 计算模型 | 真正的流处理（逐条） | 微批处理（Mini-batch） |
| 延迟 | 毫秒级 | 秒级到分钟级 |
| 状态管理 | 原生支持（State第一公民） | 有限支持（基于Checkpoint） |
| Event Time | 原生支持 + Watermark | Spark 2.1+支持 |
| Exactly-Once | 原生支持（Barrier对齐） | 支持（基于Checkpoint） |
| SQL支持 | Flink SQL（成熟） | Spark SQL（更成熟） |
| 批流一体 | DataStream + Table API | 同一套DataFrame API |
| 生态 | 独立生态，云原生支持好 | Spark大生态，Databricks支持好 |
| CEP | 原生支持 | 不支持 |
什么场景选Flink？
- 对延迟要求高（毫秒级）： 实时风控、实时推荐、实时广告出价。Spark的微批至少有几百毫秒延迟。
- 有复杂状态逻辑： 实时用户画像、会话分析、复杂事件模式检测（CEP）。Flink的State是第一公民，比Spark强很多。
- 需要双流Join： Flink的Interval Join、Window Join都比Spark成熟。
什么场景选Spark？
- 已经是Spark技术栈： 团队熟悉Spark，批处理也用Spark，不想引入新技术栈的运维成本。
- 批流一体场景： 想用同一套代码同时做实时和离线。Structured Streaming的AvailableNow触发器很实用。
- 用Databricks： Databricks生态里 Structured Streaming是原生支持的，体验比Flink好。
实战经验：我的选型路径
- 元宇宙社交App：选Flink —— 要做实时礼物流水统计、实时用户画像，有复杂状态逻辑，延迟要求毫秒级。而且批处理用Hive不用Spark，没有Spark技术栈。
- 出海硬件公司：选Structured Streaming —— 全用Databricks，批处理全是Spark，实时需求只是分钟级的埋点数据加工，没有复杂状态逻辑。
- 短剧出海公司：选Flink —— 用阿里云DataWorks提交Flink SQL作业，做广告归因和实时数据处理。