3、技术选型：主流实时计算框架对比
做实时风控，选对计算框架，项目就成功了一半。
我见过不少团队，一上来就追新潮，选了最火的框架，结果跑起来发现根本不适合自己的场景。最后要么重写，要么硬撑着用，苦不堪言。
今天咱们就聊聊三个主流选手：Flink、Spark Streaming 和 Kafka Streams。我会结合自己的踩坑经验，帮你理清选型思路。
3.1 三大框架的核心差异
先看一张对比表，心里有个底：
| 维度 | Flink | Spark Streaming | Kafka Streams |
|---|---|---|---|
| 计算模型 | 真正的流式计算（逐条处理） | 微批次（Micro-batch） | 流式计算（基于Kafka分区） |
| 延迟 | 毫秒级 | 秒级（取决于批次间隔） | 毫秒级 |
| 状态管理 | 内置强状态管理（RocksDB） | 基于Checkpoint的状态 | 本地状态存储（RocksDB） |
| 精确一次语义 | 支持 | 支持 | 支持（需配合Kafka事务） |
| 部署方式 | 独立集群 / YARN / K8s | 独立集群 / YARN / K8s | 嵌入应用（无需集群） |
| 学习曲线 | 中等偏难 | 中等 | 较易 |
| 生态集成 | 丰富（Hive、HBase、ES等） | 非常丰富（Spark生态） | 依赖Kafka生态 |
说白了，这三个框架的哲学完全不同。
Flink 是「天生流式」的，每条数据来了就处理，不攒批。我习惯叫它「真·流处理」。
Spark Streaming 是「假装流式」的，它把数据切成小段，每段当批处理来跑。嗯，这里要注意：微批次带来的延迟是硬伤，但吞吐量确实高。
Kafka Streams 是「轻量流式」的，它不是一个集群，而是一个库。你写个Java应用，引入依赖，就能做流处理。
3.2 选型考量因素
选框架不是选美，得看你的实际场景。我总结了五个核心考量点：
3.2.1 延迟要求
实时风控对延迟极其敏感。一笔交易进来，你必须在几百毫秒内给出决策。
我在项目中遇到过：用Spark Streaming做反欺诈，批次间隔设到500ms，结果高峰期延迟飙到3秒。用户都付款成功了，风控结果才出来——这还有什么意义？
所以，如果你的延迟要求是秒级以内，直接选Flink或Kafka Streams。Spark Streaming更适合延迟容忍度在5秒以上的场景。
3.2.2 状态复杂度
风控场景里，状态管理是核心。比如：
- 统计用户过去5分钟的交易次数
- 维护IP地址的黑白名单
- 计算滑动窗口内的累计金额
Flink的状态管理是最成熟的。它支持多种状态后端（内存、RocksDB），还能做增量Checkpoint。我做过一个项目，状态量达到几百GB，Flink跑得很稳。
Kafka Streams的状态管理也不错，但它是本地存储，如果应用挂了，状态恢复需要从Kafka重放数据——这个过程可能很慢。
Spark Streaming的状态管理相对弱一些，尤其是复杂窗口操作，写起来比较别扭。
3.2.3 运维成本
这一点很多人会忽略。你想想看，一个实时风控系统，运维复杂度直接决定了你的幸福感。
Kafka Streams 的运维成本最低。它不需要独立集群，你的应用就是处理节点。扩缩容？改个分区数，重启应用就行。
Flink 需要维护一个集群，但好在它支持多种资源管理器（YARN、K8s），部署起来还算方便。不过，调优是个技术活——并行度、Checkpoint间隔、状态后端选择，每个参数都可能影响性能。
Spark Streaming 依赖Spark集群，如果你已经有Spark做离线计算，那复用集群是个不错的选择。但要注意，流处理和批处理混跑，资源隔离要做好，否则互相影响。
3.2.4 数据源与下游
你的数据从哪里来？处理完往哪里去？
如果数据源就是Kafka，下游也是Kafka，那Kafka Streams是天然的选择。它和Kafka深度集成，连序列化、分区分配都不用你操心。
如果数据源多样（Kafka、文件、数据库CDC），或者下游需要写入HBase、Elasticsearch、MySQL等，那Flink和Spark Streaming的生态优势就体现出来了。它们有丰富的Connector，开箱即用。
3.2.5 团队技术栈
这一点很现实。你团队里都是Java开发，那Kafka Streams上手最快。如果团队熟悉Spark，那Spark Streaming更合适。
我个人建议：不要为了技术而技术。选一个团队能驾驭的框架，比选一个「最牛」的框架重要得多。
3.3 我的选型建议
场景一：高实时、低延迟、状态复杂
选 Flink。比如金融交易反欺诈、实时风控规则引擎。
场景二：中等延迟、高吞吐、已有Spark生态
选 Spark Streaming。比如日志分析、用户行为统计。
场景三：轻量级、Kafka原生、不想维护集群
选 Kafka Streams。比如简单的规则过滤、数据清洗、实时ETL。
💡 我曾经在一个项目中，用Kafka Streams做前置过滤，把明显正常的数据放行，只把可疑数据交给Flink做深度分析。这样既降低了Flink集群的压力，又保证了核心场景的低延迟。这种「分层处理」的思路，你可以参考。
3.4 一张图看懂选型逻辑
下面这张SVG图，是我梳理的选型决策流程。你可以把它贴在墙上，每次选型时对照着看：
⚠️ 注意：选型不是一锤子买卖。我见过一个团队，一开始用Spark Streaming，后来延迟要求变高，硬生生迁移到Flink，花了三个月。所以，选型时要考虑未来1-2年的业务发展，留点余量。
3.5 我的个人经验总结
做了这么多年风控架构，我自己的「黄金组合」是这样的：
- 核心风控引擎：用 Flink。因为它状态管理强，延迟低，适合做复杂的规则计算和模型推理。
- 前置过滤层：用 Kafka Streams。把明显正常或明显异常的数据先处理掉，减轻Flink压力。
- 离线分析：用 Spark。做历史数据回溯、模型训练、报表统计。
当然，这只是我的习惯。你的场景可能不同，灵活变通就好。
最后说一句：没有最好的框架，只有最合适的框架。选型之前，先想清楚你的核心诉求是什么，然后拿着这张决策树去对号入座。
公众号:蓝海资料掘金营，微信deep3321