3. 流式决策概念：流式处理与批处理的区别、流式决策在实时风控中的优势
3.1 批处理 vs 流式处理：核心差异
在风控系统中，数据处理模式决定了决策的时效性与架构复杂度。批处理（Batch Processing）与流式处理（Stream Processing）是两种截然不同的范式，理解其差异是掌握流式决策的基础。
| 对比维度 | 批处理（Batch） | 流式处理（Stream） |
|---|---|---|
| 数据范围 | 处理“过去”一段时间内的静态数据集（如 T+1 日全量数据） | 处理“现在”实时到达的每条或微批次数据 |
| 触发方式 | 定时调度（如每小时、每天凌晨） | 事件驱动（数据到达即触发计算） |
| 延迟 | 分钟级 ~ 小时级甚至天级 | 毫秒级 ~ 秒级 |
| 计算模型 | 全量扫描、聚合、离线训练 | 增量计算、状态维护、滑动窗口 |
| 典型场景 | 贷后监控报表、模型月度重训练 | 交易反欺诈、实时授信、登录风险判断 |
| 存储依赖 | HDFS、Hive、离线数仓 | Kafka、Redis、Flink 状态后端 |
关键认知：批处理追求“全量准确”，流式处理追求“低延迟可用”。在实时风控中，流式处理并非完全替代批处理，而是两者形成“流批一体”的互补架构——流式负责在线决策，批处理负责离线校准与模型迭代。
3.2 流式决策在实时风控中的核心优势
流式决策将传统风控的“事后分析”升级为“事中拦截”，其优势体现在以下四个层面：
- 毫秒级响应，拦截黄金窗口
欺诈交易、盗刷等风险行为通常在数秒内完成。流式决策可在数据到达后 50~200ms 内输出评分与决策，在资金转出前完成拦截。 - 事件驱动，无需等待调度
批处理依赖定时任务，若调度周期为 1 小时，则风险事件发生后最长需等待 60 分钟才能被识别。流式处理以事件为最小单元，数据产生即处理。 - 状态化计算，支持时序特征
流式引擎（如 Flink）可维护用户会话状态、滑动窗口内的交易频次、金额累计等时序特征，这些特征在批处理中难以高效实现。 - 弹性扩缩，应对流量洪峰
大促、秒杀等场景下流量可瞬间暴涨 10 倍以上。流式架构支持水平扩展，通过增加并行度保持决策吞吐量稳定。
实战经验：某头部消费金融平台将核心授信决策从批处理（T+1 评分卡）迁移至流式决策后，首笔交易欺诈损失降低 67%，同时通过率提升 4.2%。关键在于流式决策保留了“实时特征工程 + 动态阈值”的能力。
3.3 流式决策架构总览
下图展示了实时风控中流式决策的典型数据流转与组件关系：
3.4 流式决策 vs 批处理决策：决策链路对比
以下对比表从决策链路视角，清晰展示两种模式在实时风控场景下的差异：
| 决策链路环节 | 批处理决策 | 流式决策 |
|---|---|---|
| 数据采集 | 批量拉取（Sqoop / DataX） | 实时订阅（Kafka Consumer） |
| 特征计算 | Hive SQL 离线跑批 | Flink 滑动窗口 + 状态变量 |
| 模型推理 | 离线评分（Python / Spark MLlib） | 在线推理（模型服务 API） |
| 策略匹配 | 离线规则引擎（事后标记） | 实时规则引擎（事中拦截） |
| 决策输出 | 写入结果表，次日生效 | 同步返回决策结果，即时生效 |
| 端到端延迟 | 30 分钟 ~ 24 小时 | 100ms ~ 3 秒 |
架构陷阱：部分团队在迁移初期将批处理代码直接“包装”成流式任务，导致状态膨胀、延迟飙升。正确的做法是重新设计增量特征计算逻辑，并利用 Flink 的
KeyedProcessFunction 维护每个用户的实时画像状态，而非全量扫描。
3.5 流式决策的典型应用场景
- 交易反欺诈：实时判断当前交易是否与用户历史行为模式偏离（如异地登录后大额转账），延迟需控制在 200ms 以内。
- 实时授信：用户在申请额度时，流式引擎实时聚合近 30 天收入流水、多头借贷次数等特征，调用评分卡模型输出授信额度。
- 动态额度管理：监测用户消费频次、还款行为，当风险评分超过阈值时，自动触发额度冻结或降额。
- 设备指纹关联：将同一设备 ID 在 5 分钟内的所有事件进行关联分析，识别设备农场或模拟器攻击。
流式决策并非银弹，它更适合对延迟敏感、事件特征可增量计算、且需要状态维护的场景。对于离线报表、模型训练、长周期回溯分析等场景，批处理仍然是更优选择。成熟的实时风控体系通常采用“流批一体”架构，让两种模式各司其职。