Structured Streaming vs Spark Streaming，新项目该用哪个？
总结
新项目100%选Structured Streaming，Spark Streaming已经弃用。选Structured Streaming还是Flink，看延迟要求和团队技术栈。面试时能说清楚两者的核心区别（尤其是Event Time和Catalyst优化），再加一个“我为什么这么选”的实战，就很完整。
下一篇聊一个很实用的调优场景：Executor频繁被杀——Spark内存模型和调优思路。
你们生产环境用的是Structured Streaming还是Flink？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
这个问题很多人分不清楚。两个名字很像，但架构完全不同。简单说：Spark Streaming是老的微批处理，Structured Streaming是新的基于DataFrame的流引擎。新项目100%选Structured Streaming。
核心区别
| 维度 | Spark Streaming（DStream） | Structured Streaming |
|---|---|---|
| 数据抽象 | RDD的微批（DStream） | DataFrame/Dataset |
| 优化器 | 无（手动优化） | Catalyst自动优化 |
| Exactly-Once | 需要手动管理Offset | Checkpoint自动保证 |
| Event Time | 不支持（只有Processing Time） | 原生支持 + Watermark |
| 编程模型 | RDD操作 | 和批处理相同的DataFrame API |
| 状态 | 已弃用（Spark 3.4标记为deprecated） | 活跃开发，推荐使用 |
为什么Structured Streaming更好？
① 和批处理统一的API： 同样的DataFrame代码，改一下读写方式就能从批变流。团队不需要学两套API。
② Event Time支持： 原生支持Event Time窗口和Watermark，可以处理乱序数据。DStream只支持Processing Time，没法处理乱序。
③ Catalyst优化： 流处理也能享受谓词下推、列裁剪、代码生成等优化。
Structured Streaming的三种触发模式
// 1. 微批处理（默认，固定间隔触发）
.trigger(Trigger.ProcessingTime("30 seconds"))
// 2. 连续处理（真正的低延迟，毫秒级）
.trigger(Trigger.Continuous("1 second")) // 实验性功能
// 3. 一次性触发（用于增量处理，像Spark的批处理）
.trigger(Trigger.AvailableNow()) // Spark 3.3+，处理完当前数据即停止AvailableNow触发器特别实用——可以用流处理的代码做增量批处理，一套代码同时支持实时和离线。我在出海硬件公司就是这么用的。
实战经验：Spark Streaming vs Flink的选择
很多面试官会追问“为什么不用Flink”。我的经验：
选Flink： 对延迟要求高（毫秒级）、复杂的流处理逻辑（多流Join、CEP）、团队有Flink经验。我在元宇宙社交App用Flink做实时数据平台。
选Structured Streaming： 已经是Spark技术栈、延迟要求不高（秒级到分钟级）、想用同一套代码做批流一体。我在出海硬件公司用Databricks的Structured Streaming。