实时特征计算引擎选型：Flink vs Spark Streaming vs Kafka Streams
做实时特征工程，选计算引擎是第一个绕不开的坎。我见过不少团队，代码写了大半才发现引擎不合适，回头重搞，那叫一个痛苦。今天咱们就把这三个主流选手——Flink、Spark Streaming、Kafka Streams——掰开揉碎聊清楚。
说白了，没有银弹。每个引擎都有自己的脾气，选对了事半功倍，选错了天天加班修坑。
先看一张全景图
下面这张图是我自己整理的选型框架，帮你快速建立全局认知。建议保存下来，以后做技术方案时直接对照。
Apache Flink：真正的流处理王者
Flink 是我个人最偏爱的实时计算引擎。为什么？因为它从设计之初就是为流处理而生的，不是批处理的改版。
我记得第一次用 Flink 做实时特征工程，是在一个广告点击率预估项目里。我们需要在用户点击后 200 毫秒内完成特征拼接，包括过去 5 分钟的点击序列、滑动窗口内的统计量、以及用户画像的实时更新。Flink 的事件时间语义和精确一次语义，让这件事变得异常干净。
Flink 的核心优势：
- 真正的流处理：每条数据到达即处理，延迟可以做到毫秒级
- 事件时间语义：支持乱序事件处理，watermark 机制成熟
- 状态管理：内置 RocksDB 状态后端，支持 TB 级状态
- 精确一次语义：端到端一致性保证，特征不会重复计算
- CEP 库：复杂事件处理，适合做行为序列特征
但 Flink 也有它的短板。部署运维成本不低，需要独立的集群。如果你团队里没人懂 Flink 的 checkpoint 和 savepoint 机制，出问题时会很头疼。
我的经验：如果你需要做滑动窗口聚合、会话窗口、或者复杂的多流 join，Flink 是首选。我在一个风控项目里用 Flink 做实时特征，窗口精度到了秒级，状态量到了 500GB，RocksDB 扛住了。
Spark Streaming：生态为王
Spark Streaming 走的是微批次路线。它把实时流切成一个个小批次，每个批次用 Spark 引擎处理。说白了，就是用批处理的方式模拟流处理。
你可能会问：那延迟能保证吗？嗯，这要看你的批次间隔。我见过有人设 100 毫秒的批次间隔，结果集群资源吃紧，反而比 500 毫秒的延迟还高。Spark Streaming 的延迟通常在秒级，做不到 Flink 那样的毫秒级。
但 Spark Streaming 有一个巨大的优势——生态。如果你团队已经在用 Spark 做离线特征，那 Spark Streaming 可以无缝衔接。MLlib、GraphX、Spark SQL，这些库直接拿来用。
Spark Streaming 的核心优势：
- 批流一体：同一套代码跑批处理和流处理
- 生态丰富：MLlib、Spark SQL、DataFrame API 直接可用
- 社区成熟：文档多，踩坑经验多，招人容易
- 结构化流：Structured Streaming 改进了 API，更接近 Flink 的体验
注意：Spark Streaming 的微批次本质决定了它不适合对延迟敏感的场景。如果你需要 100 毫秒内的特征产出，别选它。我曾经在一个实时推荐项目里硬上 Spark Streaming，批次间隔压到 200 毫秒，结果集群 CPU 飙到 90%，还经常背压。后来换 Flink，问题解决了。
Kafka Streams：轻量级选手
Kafka Streams 是个异类。它不是一个独立的计算框架，而是一个 Java 库。你把它打成 jar 包，嵌在你的微服务里就能跑。
我第一次接触 Kafka Streams 是在一个创业公司。那时候团队小，没人力运维 Flink 集群。我们用 Kafka Streams 做实时特征，直接把特征计算逻辑写在推荐服务里，部署简单到令人发指。
Kafka Streams 的延迟可以做到毫秒级，因为它不需要网络传输数据——数据直接从 Kafka 消费，在本地处理。但它也有硬伤：状态管理能力有限，不支持跨任务的状态共享，也不支持复杂的多流 join。
Kafka Streams 的核心优势：
- 零外部依赖：不需要独立集群，嵌入应用即可
- 毫秒级延迟：数据本地处理，没有网络开销
- 与 Kafka 深度集成：Exactly-once 语义、分区机制天然支持
- 运维简单：没有集群要管，跟着应用一起部署
我的建议：如果你的特征计算逻辑比较简单——比如简单的过滤、映射、聚合，或者只需要维护一个不大的状态——Kafka Streams 是性价比最高的选择。我在一个用户画像实时更新项目里，用 Kafka Streams 处理每天 10 亿条事件，单机就扛住了。
选型对比：一张表说清楚
下面这张表是我做选型时必看的。每次有新项目，我都会对照这张表过一遍需求。
| 对比维度 | Flink | Spark Streaming | Kafka Streams |
|---|---|---|---|
| 处理模型 | 真正的流处理 | 微批次 | 流处理（记录级） |
| 延迟 | 毫秒级 | 秒级 | 毫秒级 |
| 状态管理 | 强（RocksDB + 堆内存） | 中（基于 checkpoint） | 弱（本地状态存储） |
| 精确一次语义 | 支持 | 支持 | 支持（需 Kafka 配合） |
| 事件时间 | 原生支持 | Structured Streaming 支持 | 有限支持 |
| 部署运维 | 需要独立集群 | 需要独立集群 | 嵌入应用，无需集群 |
| 生态集成 | 中等 | 丰富（MLlib、SQL） | 仅限 Kafka 生态 |
| 学习曲线 | 陡峭 | 中等 | 平缓 |
| 适用场景 | 复杂事件处理、窗口聚合、状态密集型特征 | 批流一体、离线+实时混合、已有 Spark 技术栈 | 轻量特征计算、微服务内嵌、Kafka 原生生态 |
选型决策流程
我一般按下面这个流程来做选型决策，你可以参考一下：
- 先看延迟要求：如果特征产出需要毫秒级，排除 Spark Streaming
- 再看状态复杂度：如果需要 TB 级状态、复杂窗口、多流 join，选 Flink
- 然后看团队现状：如果团队已有 Spark 技术栈，且延迟要求不高，选 Spark Streaming
- 最后看运维能力：如果团队小、不想维护集群，选 Kafka Streams
避坑指南：我曾经见过一个团队，因为听说 Kafka Streams 部署简单，就硬用它做复杂的多流 join。结果状态管理搞不定，数据对不上，最后不得不重写。记住：Kafka Streams 适合简单场景，别贪心。
小结
选实时特征计算引擎，没有标准答案。Flink 适合复杂状态场景，Spark Streaming 适合批流一体，Kafka Streams 适合轻量内嵌。关键是想清楚你的需求：延迟要求、状态规模、团队能力、运维成本。
我个人习惯是：新项目优先考虑 Flink，除非有明确的理由不选它。但如果你团队已经在用 Spark，也别硬换，Spark Streaming 在大多数场景下够用了。