2. 实时风控系统架构演进：从批处理到流处理

这一章我想跟你聊聊架构的事。很多人一上来就问我，Flink 在风控里到底怎么落地的？

其实要回答这个问题，得先搞清楚一件事：我们为什么需要流处理？

说白了，风控的敌人是“快”。欺诈分子可不按小时按天干活，他们眨眼间就刷单、薅羊毛、搞盗刷。你如果还是每天凌晨跑个离线报表，等发现骗子时，钱早就跑了。

2.1 离线批处理的困境

我刚开始做风控时，用的就是纯批处理方式。每天 T+1 跑 Hive 任务，算交易特征、搞黑名单匹配。结果有一次，一个团伙在凌晨 2 点集中攻击，到早上 8 点我们才发现异常——那 6 个小时的损失，到现在还记得。

你想想看，批处理有几个硬伤：

• 延迟太高：分钟级甚至小时级，根本防不住实时攻击
• 数据新鲜度差：特征都是昨天的，骗子早就变了招式
• 难以增量计算：每次都得全量跑，资源浪费严重

2.2 Lambda 架构：又爱又恨的过渡方案

后来大家开始用 Lambda 架构。这个架构分三层：批处理层、流处理层、服务层。批处理层负责历史数据全量计算，流处理层负责实时增量计算，最后合并出结果。

听起来挺完美，对吧？

但我在实际项目里发现，Lambda 架构有个大问题：维护两套代码。批处理用 Hadoop/Spark，流处理用 Storm/Flink，逻辑虽然一样，但代码完全不同。一旦改个规则，两边都得改，还容易对不齐。

2.3 Kappa 架构：化繁为简

所以后来出现了 Kappa 架构。它的思路很简单：所有数据都当作流来处理。历史数据重新跑，就把数据从 Kafka 里重放一遍，用同一个流处理引擎搞定。

我曾经在一个项目中尝试把 Lambda 架构迁移到 Kappa 架构。当时最大的阻力是：历史数据重放时，消息队列的压力很大。但优化了分区策略后，效果反而比原来好——只维护一套代码，逻辑统一，bug 少了一半。

对比维度	Lambda 架构	Kappa 架构
代码维护	两套代码（批+流）	一套代码（全是流）
数据重算	批处理层重算	消息队列重放
架构复杂度	高（需协调批流结果）	低（处理逻辑统一）
实时性	依赖流处理层	天然实时
典型场景	有强历史回溯需求的系统	以实时决策为主的系统

2.4 Flink 在风控中的定位

好了，那 Flink 在实时风控里到底扮演什么角色？

我用一句话概括：Flink 是实时风控的“计算引擎”和“决策核心”。

• 全链路实时性：事件从 Kafka 进来，Flink 毫秒级处理，马上出结果
• 状态管理：用户画像、历史行为、滑动窗口统计，Flink 的状态后端帮你搞定
• CEP 引擎：复杂事件匹配，比如“1 分钟内同一设备更换 3 个账号”，Flink CEP 原生支持
• Exactly-Once 语义：风控决策不能重复也不能丢，Flink 的 checkpoint 机制保证数据一致性

我个人习惯把 Flink 放在风控架构的 “规则引擎层” 和 “特征计算层” 之间。它既负责实时的特征衍生（比如近 5 分钟交易次数、IP 变更频率等），也负责把这些特征喂给规则引擎或模型做决策。你想想看，如果每个特征都要自己去写窗口逻辑，那得多崩溃？Flink 的窗口 API 和 ProcessFunction 让这件事变得很优雅。

// 一个简化的实时特征计算示例
DataStream<Transaction> transactions = ...;

// 按用户ID分组，统计近5分钟的交易次数
DataStream<Feature> features = transactions
    .keyBy(tx -> tx.getUserId())
    .window(SlidingProcessingTimeWindows.of(
        Time.minutes(5), Time.minutes(1)))
    .aggregate(new CountAggregator(), new FeatureWindowFunction());

2.5 架构演进全景图

下面这张图，展示了从离线批处理到 Flink 流处理的核心演进路线。你重点关注“批处理 vs 流处理”的差异，以及 Flink 在其中的位置。

2.6 选型建议

最后给点实在的建议：

• 如果业务刚刚起步：直接上 Flink + Kafka 的 Kappa 架构。别走 Lambda 的老路，省得后面重构。
• 如果已有大量批处理资产：先用 Lambda 架构，逐步把能实时化的特征迁移到 Flink 上。
• 如果对实时性要求不高（分钟级即可）：可以考虑 Spark Streaming，但别指望它做毫秒级决策。