2. 风控链路全景分析：典型链路与批流一体统一架构
风控系统本质上是一条对实时性与准确性要求极高的数据处理流水线。从用户行为发生到最终决策返回，数据依次经过采集、计算、规则匹配与输出四个核心阶段。传统架构下，离线与实时链路各自独立建设，导致特征口径不一致、规则验证滞后、运维成本高昂。批流一体正是为了解决这一核心矛盾而生。
2.1 风控系统典型链路：数据采集 → 特征计算 → 规则引擎 → 决策输出
一条完整的实时风控链路通常包含以下四个阶段，每个阶段都有其特定的技术挑战与优化空间。
| 阶段 | 核心职责 | 典型组件 | 延迟要求 |
|---|---|---|---|
| 数据采集 | 统一接入用户行为、设备指纹、交易流水、第三方黑名单等异构数据源 | Kafka、Flume、Logstash、SDK埋点 | 秒级 |
| 特征计算 | 对原始数据进行清洗、聚合、统计，生成用于规则判断的特征变量 | Flink、Spark Streaming、Redis、HBase | 毫秒～秒级 |
| 规则引擎 | 加载决策树、评分卡、规则集，对特征进行逻辑匹配与风险评分 | Drools、自研规则引擎、Groovy脚本 | 毫秒级 |
| 决策输出 | 输出通过/拒绝/人工审核等决策结果，并回写日志、触发告警或阻断 | Redis、MySQL、Elasticsearch、回调接口 | 毫秒级 |
实战要点： 在实时链路中，特征计算往往是性能瓶颈。例如一个需要滑动窗口统计“过去5分钟同一设备登录次数”的特征，若使用纯实时计算，状态后端压力巨大；而离线链路则天然适合此类窗口聚合。批流一体正是通过统一计算逻辑，让实时与离线共享同一套特征定义。
下图展示了典型风控链路的完整数据流向与各阶段之间的依赖关系。
2.2 批流一体如何统一离线与实时链路
传统风控架构中，离线链路（T+1 批量计算）与实时链路（毫秒级流计算）各自独立开发与维护。这导致两个严重问题：特征口径不一致（同一“近7天交易金额”在离线与实时中计算结果不同）和规则验证滞后（新规则需离线回测通过后才能上线，周期长达数天）。
批流一体架构的核心思想是：同一套计算逻辑，两种执行模式。具体通过以下三个层面实现统一：
- 计算逻辑统一：使用 Flink SQL 或 Beam 等批流一体框架，同一段 SQL 或 Pipeline 代码既可运行在 Batch 模式（离线），也可运行在 Streaming 模式（实时）。特征定义、窗口聚合、UDF 函数完全复用。
- 数据存储统一：实时特征与离线特征共享同一份元数据定义，底层存储（如 HBase、Redis、对象存储）通过统一的读写接口访问，避免数据孤岛。
- 规则验证统一：新规则在离线批处理环境中使用历史数据完成回测，验证通过后直接发布到实时规则引擎，无需重新开发特征逻辑。
批流一体核心收益：
- 特征口径 100% 对齐，消除离线与实时结果不一致的排查成本。
- 规则上线周期从 3～5 天缩短至 1 天以内。
- 计算资源统一调度，离线作业与实时作业共享集群，利用率提升 30% 以上。
下图展示了批流一体架构下，离线与实时链路如何共享同一套计算逻辑与数据层。
2.3 批流一体落地中的关键设计模式
在实际落地过程中，以下三种设计模式被证明最为有效：
| 模式名称 | 适用场景 | 实现方式 | 典型收益 |
|---|---|---|---|
| Lambda 架构简化版 | 已有离线+实时两套系统，需快速统一口径 | 离线与实时共用同一套 SQL 模板，通过配置切换执行模式 | 口径一致，开发成本低 |
| Kappa 架构 | 新建风控系统，无历史包袱 | 所有数据以流式方式处理，离线回测通过重放历史消息实现 | 架构简洁，运维成本低 |
| 混合架构 | 既有大量历史数据，又要求实时响应 | 实时流处理 + 离线批处理共享特征元数据，通过统一特征服务对外输出 | 兼顾历史与实时，灵活性最高 |
避坑指南： 批流一体并非“一套代码走天下”。在以下场景中仍需谨慎处理：
- 状态大小差异：离线作业可处理 TB 级状态，实时作业状态过大会导致 Checkpoint 超时。需为实时作业设置合理的状态 TTL 与 RocksDB 优化。
- 时间语义对齐：离线使用 Event Time 进行回溯，实时需处理乱序数据。建议统一使用 Event Time + Watermark 机制。
- 数据回溯能力：实时链路需保留足够长的 Kafka 日志或启用 CDC 方案，以支持离线回测时的数据重放。