4. 数据源接入设计：核心数据源与接入方式

贷后预警策略的实时化落地，首要任务是打通数据孤岛，将分散在多个业务系统中的核心数据源，以低延迟、高可靠的方式接入实时计算平台。本章节详细阐述四大核心数据源的内容特征，以及三种主流数据接入方式的技术选型与架构设计。

4.1 核心数据源全景

贷后预警依赖的数据可归纳为内部交易数据、内部行为数据、外部信用数据三大类，具体包含以下四个核心数据源：

4.2 数据接入方式技术选型

根据数据源的实时性要求、数据量级及下游消费模式，贷后预警系统通常采用以下三种接入方式：

• Kafka 消息队列： 适用于高吞吐、低延迟的实时事件流，如还款流水、催收记录。数据源通过 CDC（变更数据捕获）或业务系统直接推送至 Kafka Topic，预警引擎以消费者组方式订阅消费。
• API 接口： 适用于按需查询、低频但高价值的第三方数据，如征信报告、外部黑名单。预警引擎在规则触发时，通过 HTTP/RPC 调用外部服务获取数据，支持同步与异步两种模式。
• 数据库 CDC： 适用于存量业务系统的数据变更捕获，如核心账务系统、催收系统的数据库。通过 Debezium、Canal 等工具监听 Binlog/Redo Log，将变更事件实时推入 Kafka，实现无侵入式数据接入。

4.3 数据接入架构总览

下图展示了贷后预警系统的数据接入分层架构，清晰呈现了从数据源到实时计算引擎的完整链路：

4.4 核心数据源接入详细设计

4.4.1 还款流水接入（CDC + Kafka）

还款流水是贷后预警最核心的实时数据源，其接入设计需保证数据不丢、不重、顺序一致：

• 接入方式： 采用 Debezium 监听核心账务系统 MySQL/Oracle 的 Binlog，将 INSERT/UPDATE/DELETE 事件实时推送至 Kafka Topic repayment_flow。
• Topic 分区策略： 按 loan_id 哈希分区，保证同一笔贷款的流水事件顺序消费。
• 数据格式： 使用 Avro 序列化，Schema 包含 loan_id、due_date、actual_pay_date、amount_due、amount_paid、overdue_days、event_time 等字段。
• 容错机制： 开启 Kafka 幂等生产者，消费者端启用 checkpoint，确保 Exactly-Once 语义。

// 还款流水 Kafka 消息示例（Avro 格式）
{
  "loan_id": "LN202410010001",
  "due_date": "2024-10-15",
  "actual_pay_date": "2024-10-16",
  "amount_due": 5000.00,
  "amount_paid": 3000.00,
  "overdue_days": 1,
  "event_type": "PARTIAL_PAYMENT",
  "event_time": 1729036800000
}

4.4.2 催收记录接入（业务系统直推 Kafka）

催收记录由催收管理系统实时产生，采用业务系统主动推送的方式接入：

• 接入方式： 催收系统在每次催收动作完成后，通过 Kafka Producer API 将记录写入 Topic collection_record。
• 数据字段： 包含 case_id、collector_id、action_type（电话/短信/外访）、contact_result、promise_pay_date、remark。
• 实时性要求： 催收动作发生后 5 秒内必须到达预警引擎，用于触发“催收后复催”或“承诺还款到期提醒”等策略。

4.4.3 征信报告接入（API 异步查询 + 本地缓存）

征信报告查询成本高、频率低，不适合实时流式接入，采用 API 异步查询模式：

• 接入方式： 预警引擎在规则条件满足时（如逾期天数 > 30 天），通过 HTTP 请求调用征信服务接口，查询用户最新征信报告。
• 缓存策略： 征信报告结果在本地 Redis 缓存 7 天，避免同一用户短期内重复查询，降低外部接口调用成本。
• 异步处理： 采用 CompletableFuture 或消息队列实现异步回调，避免同步等待阻塞预警流程。

4.4.4 外部黑名单接入（API 实时查询 + 本地全量同步）

外部黑名单数据需要兼顾实时性与查询性能，采用“本地全量 + 远程增量”的双模接入：

• 全量同步： 每日凌晨通过批量 API 拉取全量黑名单数据，写入本地 HBase 或 Redis 集群，用于离线规则计算。
• 实时查询： 预警引擎在实时规则中，通过 Redis 缓存查询用户是否命中黑名单，缓存未命中时回源查询外部 API。
• 增量更新： 外部黑名单服务通过 Webhook 或 Kafka 推送增量变更事件，本地消费后实时更新缓存。

4.5 数据接入质量保障

数据接入的质量直接决定预警策略的准确性，必须建立以下保障机制：