[toc]
Spark vs Flink 技术选型（面试满分版 + 业务场景怎么选）
一、核心本质区别（先记这句）
- Spark：微批处理，离线计算之王，批量吞吐强、成本低
- Flink：原生流处理，实时计算之王，低延迟、事件时间、Exactly-Once、水位线窗口完善
二、关键维度对比表（直接背）
表格
| 对比维度 | Spark | Flink |
|---|---|---|
| 计算模型 | 微批、离线为主 | 纯流式、事件驱动 |
| 延迟 | 分钟级、小时级 | 毫秒 / 秒级低延迟 |
| 时间语义 | 处理时间为主，事件时间弱 | 事件时间完善，水位线、乱序处理强 |
| 一致性 | 勉强支持 Exactly-Once | 原生支持 Exactly-Once |
| 窗口能力 | 简单窗口，迟到处理弱 | 滚动 / 滑动 / 会话 / 迟到数据全套支持 |
| 吞吐能力 | 超高吞吐，适合海量批量 | 吞吐不错，略低于 Spark 批处理 |
| 容错机制 | 血统依赖、重算整个分区 | Checkpoint + 状态增量快照，细粒度容错 |
| 状态管理 | 弱，依赖外部存储 | 原生状态后端（RocksDB）、TTL、增量 CK |
| 开发成本 | SQL 友好，上手简单 | API 稍复杂，实时场景功能更全 |
| 资源开销 | 批量调度资源利用率高 | 常驻任务，资源长期占用 |
| 小文件 | 容易产生，需手动合并 | 可窗口攒批 + 文件滚动策略控制 |
三、坚决选 Spark 的场景
- 离线数仓全链路（Hive 数仓分层、日 / 小时级调度）
- 海量数据批量清洗、迁移、大表全量计算
- 离线报表、离线指标、用户画像离线标签
- 数据量大、不要求低延迟、追求低成本高吞吐
- 历史数据回溯、批量重跑、大规模离线 ETL
- 团队以 SQL 开发为主、追求简单易维护
四、坚决选 Flink 的场景
- 实时数仓、实时大屏、实时指标
- 实时特征计算、推荐 / 广告实时数据流
- Kafka 实时消费、乱序日志、需要事件时间精准窗口
- 要求低延迟（秒级甚至毫秒级）
- 需要严格 Exactly-Once、不丢不重
- 状态长期存储、窗口计算、迟到数据兜底
- 实时风控、实时告警、行为实时分析
五、折中场景怎么选
-
准实时（5~10 分钟延迟）
可用 Spark Streaming，但现在业界更倾向直接上 Flink，统一流批引擎。
-
流批一体架构
直接用 Flink 流批统一，一套代码跑实时 + 离线，不用维护两套引擎。
-
数据湖 Hudi/Iceberg
写入、增量消费 Flink 更适配；离线分析 Spark 更强。
六、面试标准口述回答（直接背）
技术选型主要看延迟要求、业务场景、数据量级、一致性诉求：
离线批量、海量 ETL、日级小时级数仓、高吞吐低成本场景选 Spark；
低延迟实时计算、实时大屏、实时特征、乱序日志、事件时间窗口、要求精确一次语义的场景选 Flink；
现在主流架构采用Flink 流批一体，实时离线一套引擎统一开发，离线分析依然用 Spark 做大规模批量查询和报表。
七、最简选型口诀
离线批量、数仓报表 → 选 Spark
实时低延迟、窗口乱序、精准一次 → 选 Flink
流批一体统一架构 → 全站 Flink，离线分析保留 Spark
Spark vs Flink 面试必问 10 道（标准满分答案 直接背）
1. 底层计算模型有什么本质区别？
答：Spark 是微批计算，把流拆成小批量离线任务跑；
Flink 是原生流式计算，一条一条事件持续处理，是真正的流引擎。
2. 延迟对比？
答：Spark 分钟级、小时级，适合离线；
Flink 毫秒 / 秒级低延迟，适合实时大屏、实时指标。
3. 时间语义谁更强？
答：Flink 强很多，原生支持 EventTime 事件时间、Watermark 水位线、迟到数据处理；
Spark 偏向处理时间，事件时间、乱序支持较弱。
4. 窗口功能对比？
答：Flink 窗口完备：滚动、滑动、会话、全局窗口，支持水位线 + 允许迟到 + 侧输出兜底；
Spark 窗口简单，对乱序、晚到数据处理能力差。
5. 数据一致性 Exactly-Once 谁更好？
答：Flink 原生 Checkpoint + 状态后端，天然支持 Exactly-Once；
Spark 只能靠业务幂等、事务兜底，引擎层面支持不彻底。
6. 状态管理能力对比？
答：Flink 内置 RocksDB 状态后端、TTL 过期、增量 Checkpoint，适合长期驻留任务；
Spark 无原生状态，状态只能存在内存或外部存储，不适合复杂实时聚合。
7. 容错机制区别？
答：Spark 基于 RDD 宽窄依赖血统重算，失败重算整个分区；
Flink 基于 Checkpoint 快照，只恢复失败节点最近状态，粒度更细、开销更小。
8. 吞吐和资源开销对比？
答：Spark 批量调度，吞吐更高、资源利用率好、成本低，适合海量离线；
Flink 任务常驻集群，资源长期占用，吞吐略低于 Spark 批处理。
9. 处理乱序、迟到数据谁更强？
答：Flink 靠水位线推进时间，三层处理：水位线等待 + 允许迟到 + 侧输出兜底；
Spark 对乱序不友好，很难保证时间窗口精度。
10. 实际项目怎么技术选型？
答：
离线数仓、批量 ETL、历史回溯、日 / 小时级报表、海量高吞吐低成本 → 选 Spark；
实时大屏、实时特征、实时风控、乱序日志、要求低延迟 + 精确一次 → 选 Flink；
流批一体架构统一用 Flink 做实时 + 离线，复杂离线分析保留 Spark。
Spark Streaming / Structured Streaming / Flink 三者终极对比（面试直接背）
一、核心模型一句话
- Spark Streaming：纯微批，固定时间切分批次，老旧 API，已淘汰。
- Spark Structured Streaming：默认微批，API 封装成流，底层还是批次触发；仅 Continuous 模式是真流但生产不用。
- Flink：原生事件驱动流，来一条处理一条，不是微批。
二、三者对比总表
表格
| 框架 | 计算模型 | 延迟 | 时间语义 | 窗口 / 乱序 | 状态管理 | 生产常用 |
|---|---|---|---|---|---|---|
| Spark Streaming | 固定间隔微批 | 秒～分钟级 | 处理时间 | 弱、不支持乱序 | 无原生状态 | 已淘汰 |
| Spark Structured Streaming | 默认微批；Continuous 真流 | 百 ms~ 秒级 | 一般支持事件时间 | 一般，水位线偏弱 | 有状态但偏弱 | 准实时、简单实时 |
| Flink | 原生流式事件驱动 | 毫秒～秒级 | 完善 EventTime | 水位线 + 迟到 + 侧输出全套 | 原生 RocksDB+TTL + 增量 CK | 高可用复杂实时首选 |
三、关键细节区别（面试必问）
1. Spark Streaming
- 基于 DStream
- 按批次间隔（如 1s、5s）切分数据
- 没有完善事件时间、水位线
- 不推荐新项目，已过时
2. Spark Structured Streaming
- 基于 DataFrame/Dataset，统一 SQL 编程
- 底层Trigger 触发微批，轮询 Kafka
- 也支持 EventTime、窗口，但乱序、水位线能力远不如 Flink
- 有状态，但无 RocksDB、TTL 能力弱
- 适合简单准实时，不适合复杂乱序、长期状态任务
3. Flink
- 真正事件驱动，不是轮询微批
- 完美支持 Watermark+EventTime + 迟到数据三层处理
- 原生状态后端、RocksDB、增量 CK、状态 TTL
- 低延迟、Exactly-Once、复杂窗口、实时特征首选
四、延迟层级排序
Flink (毫秒级 10ms) < Structured Streaming (百毫秒 100ms) < Spark Streaming (秒级 1000ms+)
五、面试标准口述版
Spark Streaming 是老旧固定微批已淘汰；
Structured Streaming 虽然 API 是流式，默认底层依旧微批轮询触发，延迟和乱序处理能力有限；
Flink 是原生事件驱动流式，支持完善的事件时间、水位线、迟到数据和原生状态管理，低延迟、一致性更好，复杂实时业务优先选 Flink。
六、选型口诀
简单准实时、熟悉 Spark 生态 → 用 Structured Streaming
低延迟、乱序严重、窗口精准、长期状态 → 必选 Flink
老项目 Spark Streaming 直接废弃重构
Spark Structured Streaming是微批处理吗
一句话结论
Spark Structured Streaming 默认还是微批，但从架构设计上伪装成了 “流式”，不是真正的事件逐条处理；只有开启 Continuous 模式才是真正低延迟流。
1. 普通默认模式 —— 依然是微批
Spark Structured Streaming 底层依旧是按固定间隔生成 Batch，
每隔一段时间触发一次 Job，批量处理这段时间的数据。
- 本质：微批调度
- 延迟：百毫秒～秒级
- 缺点：没法做到毫秒级超低延迟，没有真正的事件驱动
2. 和 Flink 本质区别
- Flink：事件驱动，来一条处理一条，原生流式
- Spark Structured Streaming：架构包装成流，底层还是微批轮询触发
3. Spark 有没有真正流式？
有，但极少用：
Continuous 连续处理模式
1 | spark.sql.streaming.continuous.execution.enabled=true |
- 不再走微批
- 长驻线程持续拉取数据
- 延迟可到 毫秒级
- 缺点：稳定性差、功能阉割、生产基本不用
4. 面试标准口述（直接背）
Spark Structured Streaming 默认底层仍是微批处理，按照固定时间间隔生成批次任务执行，并不是像 Flink 那样事件驱动的原生流式；
虽然 API 设计成流式编程模型，但调度引擎还是微批。只有开启 Continuous 连续模式才是真正低延迟流，但生产稳定性不足，一般不用。
5. 最简总结
- 默认 SSS = 微批
- Flink = 原生流
- SSS Continuous 模式 = 真流，但生产不用