银行欺诈交易每年造成的直接损失以百亿计，而欺诈手段正从盗刷银行卡演进到 AI换脸远程开户和 AI语音模拟客服诈骗。传统的规则引擎和事后批处理模型已经难以应对，基于 Apache Flink 的实时流式计算成为新一代反欺诈系统的技术底座。
反欺诈系统的核心挑战
银行反欺诈面临的矛盾是：
- 延迟必须极低：一笔转账从客户点击确认到资金划出，风控决策窗口通常只有 100-300 毫秒
- 特征维度极广：需要关联客户近30天的交易行为、设备指纹、IP地址、社交关系、GPS位置
- 规则与模型并存：90%的欺诈可以通过规则拦截，但新型欺诈需要机器学习模型补充
Flink 的流式计算能力满足这三个要求：毫秒级 Watermark、大状态存储、灵活的 CEP 和 ML 推理支持。
架构演进：Lambda 到 Kappa
Lambda 架构的痛点是两套代码（实时和离线），特征口径不一致。现代银行采用 Kappa 架构：
[交易流水] --Kafka--> [Flink流处理] --> [实时特征计算]
|
+--> [历史回溯 + 模型训练]
所有数据都经过 Kafka，Flink 既做实时计算也做批处理回放，保证特征口径完全一致。
Flink 在反欺诈中的典型作业
1. 滑动窗口特征计算
实时风控依赖大量滑动窗口特征，如近1小时同卡交易金额总和、近24小时同商户交易笔数等。
2. CEP 复杂事件模式识别
团伙欺诈通常遵循特定模式：短时间内多卡在同一商户连续小额试探，然后大额盗刷。Flink CEP 将这种攻击模式编码为规则。
3. 实时模型推理
Flink 集成了 TensorFlow Serving / ONNX Runtime，支持流式特征直接喂给模型做实时评分。某银行将轻量级的 XGBoost 模型以 PMML 格式内嵌到 Flink，推理延迟从50ms降到5ms。
风控规则引擎
银行反欺诈规则成百上千条，且业务人员需要在线调整阈值。Flink 通过 Broadcast Stream 将变更的规则动态广播到所有 TaskManager，实现不重启作业的在线规则更新。
状态管理与 Exactly-Once
反欺诈系统的状态通常极大（数百GB的客户历史行为状态）。Flink 的 RocksDBStateBackend + 增量 Checkpoint 是关键。
在生产环境中，Kafka Producer 开启幂等性和事务，Flink 的 TwoPhaseCommitSinkFunction 确保消费 offset 和风控结果写入要么同时成功，要么同时回滚。每日对 Flink 计算的实时特征与 Hive 离线特征做一次交叉稽核，保证口径差异在0.1%以内。
总结
基于 Flink 的实时反欺诈系统将银行从事后追溯推向事前拦截。技术团队建设时最核心的三个原则： 1. 延迟是命：特征计算必须在 100ms 内完成 2. 状态是根：RocksDBStateBackend 的配置直接决定作业稳定性 3. 口径一致：实时特征和离线特征必须用同一套计算逻辑