3、技术选型：实时计算引擎对比（Flink vs Spark Streaming vs Kafka Streams），选型决策树

实时计算引擎选型，说白了就是一场「三选一」的博弈。Flink、Spark Streaming、Kafka Streams，这三个名字你肯定都听过。但真到了项目里，选哪个？

我见过太多团队，上来就拍脑袋选 Flink，结果业务场景其实用 Kafka Streams 就能搞定，白白增加了运维成本。也见过有人迷信 Spark Streaming 的生态，结果在毫秒级延迟上栽了跟头。

这一章，我就把这三个引擎的底裤扒干净。咱们从架构、延迟、状态管理、生态、运维五个维度硬碰硬对比，最后给出一棵可以直接抄作业的选型决策树。

3.1 三驾马车：核心架构差异

先看一张整体对比图，心里有个谱。

3.2 硬碰硬：五大维度对比

咱们直接上干货。我整理了一张对比表，每个维度都标出了我个人的「实战评分」。

对比维度	Flink	Spark Streaming	Kafka Streams
延迟	毫秒级（纯流）	秒级（微批次）	毫秒级（记录级）
状态管理	★★★★★ 原生强	★★★★☆ 依赖 RDD	★★★★☆ RocksDB
容错/一致性	Exactly-Once + 分布式快照	Exactly-Once + WAL	Exactly-Once + Kafka 事务
生态/集成	★★★★★ 丰富	★★★★★ 极丰富	★★★☆☆ 仅 Kafka
运维复杂度	高（独立集群）	高（依赖 YARN/K8s）	低（无集群）
适用场景	复杂 ETL、CEP、实时数仓	批流混合、机器学习	轻量管道、Kafka 原生

3.3 避坑指南：我踩过的三个坑

做技术选型，光看优点没用。我把自己在项目中踩过的坑分享出来，你遇到类似情况可以绕道走。

• 坑一：用 Spark Streaming 做毫秒级风控。 我曾经在一个金融风控项目里，硬要用 Spark Streaming 做毫秒级规则匹配。结果批次间隔调到 200ms，集群压力巨大，还经常背压。最后换 Flink，问题迎刃而解。记住：微批次不是真流，别跟物理规律较劲。
• 坑二：用 Kafka Streams 做跨 Topic 复杂 Join。 Kafka Streams 的 Join 依赖 co-partitioning，如果两个 Topic 分区数不一致，或者 key 分布不均匀，性能会急剧下降。我有个同事因为这个，排查了整整两天。后来改成 Flink 的 Interval Join，代码量少了一半。
• 坑三：迷信 Flink 的「批流一体」。 Flink 的批流一体确实牛，但如果你只是跑离线 ETL，Spark 的成熟度和稳定性更高。我见过有人为了「统一技术栈」，用 Flink 跑离线批处理，结果任务调优花了一个月。没必要，工具要选最趁手的。

3.4 选型决策树：直接抄作业

好了，理论讲完，坑也说了。下面这棵决策树，是我根据多年实战经验总结的。你拿着它，对着自己的业务场景走一遍，答案就出来了。

3.5 实战案例：一个选型复盘

最后，分享一个我去年做的项目选型复盘，你感受一下。

业务场景： 电商实时大屏 + 实时风控 + 离线报表。

需求拆解：

• 大屏：秒级刷新，数据量大。
• 风控：毫秒级规则匹配，状态复杂。
• 报表：T+1 离线，Hive 生态。

我的选型过程：

1. 风控需要毫秒级 + 复杂状态 → 排除 Spark Streaming。
2. 大屏和风控共用数据源，但延迟要求不同 → 不能只用 Kafka Streams。
3. 离线报表依赖 Hive → 需要批处理能力。
4. 最终方案： Flink 做实时层（风控 + 大屏），Spark 做离线层（报表）。中间用 Kafka 解耦。

这个方案运行了一年多，很稳。你看，选型不是「非此即彼」，而是「组合拳」。