4、流处理引擎选型：Flink核心概念、Spark Streaming对比、Storm的适用场景
聊到实时特征计算，选哪个流处理引擎，几乎是每个团队都要吵一轮的话题。
我这些年三个引擎都用过，踩过不少坑。今天就把我的真实感受摊开来讲。
4.1 先看一张全景图
下面这张图，是我自己梳理的选型逻辑。你一看就明白三个引擎的定位差异。
4.2 Flink：真正的流处理王者
Flink 的核心思想，说白了就是「数据一来就处理，绝不攒批」。
它原生支持事件时间语义，能处理乱序数据。这一点，我在做实时风控特征计算时深有体会。
Flink 三大核心概念：
- 事件时间（Event Time）： 数据产生的时间，不是到达时间。做特征计算时，这个太重要了。
- 状态管理（State）： 算子可以保存中间结果。比如统计过去5分钟的用户点击量，状态帮你记住。
- Checkpoint： 定期保存状态快照。机器挂了，从最近一次Checkpoint恢复，保证精确一次语义。
我个人习惯用 Flink 做实时特征计算。为什么？因为它能保证「精确一次」。
举个例子：你在计算用户实时信用分，每条数据都不能丢，也不能重复算。Flink 的 Checkpoint + 两阶段提交，完美解决。
我的经验： 刚开始用 Flink 时，我忽略了 Watermark 的设置。结果窗口一直不触发，数据积压。后来调了 Watermark 延迟时间，问题解决。记住：Watermark 是事件时间的「闹钟」。
4.3 Spark Streaming：微批次的妥协与优势
Spark Streaming 本质上是「微批次」——把流切成一个个小批次，然后用 Spark 引擎去跑。
你想想看，这样做的好处是什么？
- 和 Spark 批处理共用一套代码，流批一体。
- 生态丰富，SQL、MLlib 都能用。
- 吞吐量高，适合大流量场景。
但代价也很明显：延迟是批次间隔决定的。你设 1 秒，那延迟至少 1 秒。设 100 毫秒？小批次太多，调度开销反而变大。
避坑指南： 我曾经在一个项目里用 Spark Streaming 做毫秒级特征计算。结果发现，批次间隔设到 500ms 以下，性能反而下降。后来换成 Flink，延迟降到 100ms 以内。所以，如果你的业务要求「秒级以下延迟」，别犹豫，选 Flink。
Spark Streaming 适合什么场景？
- 准实时 ETL，延迟容忍度在秒级。
- 团队已经深度使用 Spark，不想引入新引擎。
- 需要流批一体，同一套代码跑历史和实时。
4.4 Storm：老兵不死，只是凋零
Storm 是最早的流处理引擎之一。它的模型很简单：Spout 读数据，Bolt 处理，组成一个拓扑。
延迟极低，毫秒级。但问题也很突出：
- 不保证精确一次，只保证至少一次。
- 状态管理弱，需要自己维护外部存储。
- 社区活跃度下降，新功能少。
我记得 2018 年接手过一个老项目，用的就是 Storm。拓扑写得很复杂，状态全靠 Redis 存。每次重启，数据对账都让人头疼。
Storm 的适用场景（现在）：
- 存量系统维护，已经跑了好几年，没必要重写。
- 超低延迟、无状态的简单处理，比如日志过滤。
- 对数据一致性要求不高的场景。
新项目？我个人建议别选 Storm 了。Flink 已经能覆盖它的所有场景，还做得更好。
4.5 三引擎对比表
| 维度 | Flink | Spark Streaming | Storm |
|---|---|---|---|
| 处理模型 | 真正的流处理 | 微批次 | 纯流 |
| 延迟 | 毫秒级 | 秒级（取决于批次间隔） | 毫秒级 |
| 语义保证 | 精确一次 | 精确一次 | 至少一次 |
| 状态管理 | 内置，强大 | 有限（需配合外部存储） | 弱，需自己实现 |
| 事件时间 | 原生支持 | 支持（但延迟较高） | 不支持 |
| 生态 | 丰富，持续增长 | 非常丰富 | 萎缩 |
| 学习曲线 | 中等 | 低（熟悉Spark的话） | 低 |
| 推荐场景 | 实时特征、CEP、实时数仓 | 准实时ETL、流批一体 | 存量维护、超低延迟简单处理 |
4.6 我的选型建议
说了这么多，到底怎么选？
- 新项目，做实时特征计算： 无脑 Flink。状态管理、事件时间、精确一次，都是为这个场景量身定做的。
- 团队 Spark 技术栈深厚，延迟容忍秒级： Spark Streaming 可以，但别硬上毫秒级场景。
- 维护老系统： Storm 还能用，但别扩展了。慢慢迁移到 Flink 吧。
最后说一句： 选引擎不是选「最好的」，是选「最适合你团队和业务」的。我见过用 Flink 做简单日志过滤的，也见过用 Spark Streaming 做实时风控的。关键是你对它的理解深度。