2. Batch预警体系概述：传统T+1批处理架构、数据流程与典型痛点

在贷后风控领域，Batch（批处理）预警是最早被广泛采用的模式。其核心逻辑是：在每日固定时间点（通常是凌晨），将前一日（T日）的全量业务数据统一加工、跑批，生成预警名单，并在次日（T+1）早晨推送给贷后管理人员。这种架构在业务规模较小、数据时效性要求不高的阶段，曾是行业标准。

2.1 传统T+1批处理架构

典型的Batch预警架构采用分层离线计算模型，数据从生产库经过ETL进入数据仓库，再通过调度系统触发预警脚本。整体架构如下图所示：

2.2 数据流程详解

Batch预警的数据流程遵循严格的时间窗口和线性依赖关系。一个典型的T+1预警数据流包含以下步骤：

2.3 典型痛点分析

随着业务规模增长和风险形态演变，传统Batch预警的架构缺陷逐渐暴露。以下是行业普遍面临的五大核心痛点：

痛点一：时效性滞后，错过最佳干预窗口

在欺诈交易、多头共债、资金链断裂等场景中，风险信号往往在数小时内急剧恶化。T+1的预警模式意味着：

• 欺诈交易：欺诈分子在T日完成盗刷，T+1日预警生成时资金已转移。
• 多头借贷：借款人在T日密集申请多家平台，T+1日预警时已形成实质逾期。
• 还款逾期：客户T日未还款，T+1日预警触发，但催收黄金期（逾期后24小时）已过半。

痛点二：全量跑批，计算资源浪费严重

Batch模式每天对全量存量客户进行扫描，即使其中90%以上的客户风险状态无变化。这种“地毯式”计算导致：

• 计算集群在凌晨出现明显的资源尖峰，白天则大量闲置。
• 单次跑批耗时随客户量线性增长，当客户量突破千万级时，跑批窗口可能延长至4~6小时。
• 无效计算占比高，单位预警成本（每产生一条有效预警的计算开销）居高不下。

痛点三：数据一致性难以保证

由于数据采集、清洗、加工、跑批各环节存在时间差，且依赖复杂的调度依赖，经常出现：

• 数据漂移：T+1日跑批时，部分数据源尚未完成日切，导致预警数据与真实业务状态不一致。
• 依赖断裂：上游ETL任务失败或延迟，导致下游预警任务空跑或产出脏数据。
• 重复预警：同一风险事件在连续两天的跑批中都被命中，贷后管理员收到重复工单。

痛点四：规则僵化，难以快速迭代

Batch预警的规则通常以静态配置文件或数据库存储过程的形式存在：

• 新增或修改一条预警规则，需要经历“需求评审 → 代码开发 → 联调测试 → 上线部署”的完整周期，通常耗时1~2周。
• 规则之间耦合度高，修改一条规则可能影响其他规则的执行结果，回归测试成本高。
• 无法支持“灰度发布”或“A/B测试”，新规则上线即全量生效，风险不可控。

痛点五：缺乏事件驱动能力，无法感知突发风险

Batch预警只能感知“日终快照”，无法感知“日内事件”。例如：

• 某头部企业突发负面舆情，相关借款人的还款意愿可能在数小时内骤降，但Batch预警要等到次日才能反映。
• 客户在T日14:00发生大额异常交易，系统无法在交易发生后立即触发预警，只能等待次日跑批。
• 贷后管理员无法主动订阅特定客户或特定风险事件，所有预警都是“推”模式，缺乏“拉”的能力。

2.4 Batch与实时架构的对比

为了更直观地理解Batch架构的局限性，下表从多个维度对比了传统Batch预警与实时预警的差异：