考察点
这道题出自字节跳动大数据工程师一面，属于流计算选型的必考题。面试官想看的不是"Flink 延迟低、Spark 吞吐高"这种一句话结论，而是你能从计算模型出发，把延迟、状态管理、时间语义、容错机制的差异串成一条逻辑链——差异都是模型不同推导出来的，不是孤立的知识点。追问常往"Structured Streaming 的连续模式了解吗"、"微批模型为什么状态管理天然简单"、"你们项目为什么选 Flink"走。
参考答案
计算模型：一切差异的根源
Flink 是事件驱动（event-driven）的真流处理：数据来一条处理一条，算子之间通过网络流式传输，没有批次概念。Spark Streaming（DStream）是微批（micro-batch）：把流切成一个个小批次（比如 1 秒一批），每个批次本质上是一个微型的 Spark 批处理 job，复用 RDD 和 DAG 调度那套体系。这个根本差异决定了后面所有的不同。
可以类比快递配送：Flink 是外卖骑手，来一单送一单；Spark Streaming 是驿站集包，攒一班车统一发。
延迟与吞吐
延迟上，Flink 的流水线处理能把端到端延迟压到毫秒级，事件从 source 进来到 sink 出去只经过算子链，没有批次边界等待。Spark Streaming 的延迟下限就是批间隔，加上批次内调度开销，生产上一般在秒级。对延迟敏感的场景（实时风控、实时推荐特征）这个差距是决定性的。
吞吐上不能简单说谁高。微批模型单批次内可以做批式优化，吞吐可观；Flink 高吞吐靠 pipeline 和背压机制，大规模生产同样能跑百万级 TPS。真实差异在于延迟-吞吐的权衡曲线：Spark Streaming 想压延迟就要缩批间隔，调度开销占比上升，吞吐掉得很快；Flink 在低延迟区间吞吐保持得更好。
状态管理
Flink 的状态是一等公民：keyed state（ValueState、ListState、MapState 等）内嵌在算子里，state backend 可选内存或 RocksDB，超大规模状态（TB 级）放 RocksDB 增量快照。状态查询、savepoint 迁移、扩缩容重分布都有原生支持。
DStream 的状态靠 updateStateByKey / mapWithState，本质是全量或增量的 RDD 维护，状态量大时性能差很多，也缺少 savepoint 这种运维原语。Structured Streaming 改进了这块，提供带 TTL 的状态 store 和 RocksDB backend，但生态成熟度仍晚于 Flink。
时间语义与乱序处理
Flink 原生支持事件时间（event time）+ watermark 机制，处理乱序、迟到数据是框架内置能力，窗口按事件时间触发，还能定义 allowedLateness 和侧输出流兜住极端迟到数据。DStream 只有处理时间语义——批次切分基于系统时钟，事件晚到几分钟就被算进错误的窗口，做跨夜订单统计这类需求基本没法用。Structured Streaming 后来补上了 event time 和 watermark，算是追平了这一项。
容错语义
DStream 的容错来自 RDD 血统（lineage）：批次失败就重放源数据重算，天然 exactly-once（对内部状态而言），这是微批模型少有的优势——一致性边界就是批次边界，简单清晰。Flink 靠 checkpoint（Chandy-Lamport 分布式快照）保证内部状态 exactly-once，端到端还要 sink 配合两阶段提交，机制更重但换来了不停机的增量快照。
| 维度 | Flink | Spark Streaming (DStream) |
|---|---|---|
| 计算模型 | 事件驱动真流 | 微批 |
| 延迟 | 毫秒级 | 秒级（批间隔决定） |
| 时间语义 | 事件时间+watermark | 处理时间 |
| 状态 | 原生 keyed state，RocksDB 支持 TB 级 | updateStateByKey，能力弱 |
| 内部容错 | checkpoint | RDD lineage |
| 批流统一 | DataStream/Table 一套 API | 批流 API 分离 |
选型结论怎么答
面试收尾给一个带场景的判断：延迟敏感（亚秒级）、需要事件时间、复杂状态计算选 Flink；团队已有 Spark 栈、秒级延迟够用、希望和离线批处理共用代码和资源的场景选 Structured Streaming。补一句 DStream 在新项目里基本已被 Structured Streaming 取代，说明你知道技术演进方向。
可能的追问
- Structured Streaming 和 Flink 还差在哪？模型上 SS 默认仍是微批（连续处理模式试验多年未成主流），状态生态、CEP、细粒度控制上 Flink 更成熟；但 SS 和 Spark SQL/ML 无缝打通是优势。
- 微批为什么 lineage 容错简单？每个批次的输出只依赖该批次的输入 RDD，重放该批次源数据即可重建，没有跨批次的中间状态要恢复（状态算子除外）。
- 背压两个框架怎么处理？Flink 有基于 credit 的流控和原生背压监控；Spark Streaming 靠动态限流（backpressure PID 控制器）调消费速率，本质是调批次大小和速率。