4. 数据采集与清洗：催收系统日志、通话记录、短信回执、APP推送点击数据的ETL流程
在催收低延迟触达与Score评分体系中，数据是驱动决策的燃料。本章聚焦于如何从催收系统的多个数据源（系统日志、通话记录、短信回执、APP推送点击）中，构建一套高效、可靠的ETL（Extract, Transform, Load）流程。该流程不仅需要处理海量异构数据，还必须满足低延迟触达场景下的实时性要求。
4.1 数据源特征与采集策略
不同数据源具有截然不同的格式、时效性和可靠性特征。采集策略必须针对每个源的特点进行设计，以确保数据的完整性和及时性。
| 数据源 | 数据格式 | 时效性要求 | 主要挑战 | 推荐采集方式 |
|---|---|---|---|---|
| 催收系统日志 | 半结构化文本（JSON/Log4j） | 准实时（秒级） | 高吞吐、格式不统一 | Filebeat + Kafka |
| 通话记录（CDR） | 结构化（CSV/数据库表） | T+1 / 准实时 | 数据量大、字段多 | JDBC Connector / 文件批量导入 |
| 短信回执 | 结构化（JSON/HTTP回调） | 实时（毫秒级） | 状态码复杂、延迟波动 | HTTP API + Kafka |
| APP推送点击 | 半结构化（JSON/埋点） | 实时（秒级） | 设备标识映射、数据稀疏 | SDK埋点 + Kafka |
架构提示： 所有实时数据流建议统一汇聚到Kafka消息队列，作为ETL流程的“缓冲层”和“解耦层”。这能有效应对上游数据源的突发流量，并为下游的实时计算和离线批处理提供统一的数据入口。
4.2 ETL核心流程设计
ETL流程分为三个主要阶段：数据抽取（Extract）、数据清洗与转换（Transform）、数据加载（Load）。针对催收场景，我们设计了以下标准化流程。
- 数据抽取（Extract）：
- 全量抽取： 用于初始化历史数据，通常在系统上线或数据迁移时执行。
- 增量抽取： 日常运行模式，通过时间戳、自增ID或CDC（Change Data Capture）技术捕获新增或变更的数据。
- 实时流式抽取： 针对短信回执和APP推送，通过监听Kafka Topic实现毫秒级数据接入。
- 数据清洗与转换（Transform）：
- 格式标准化： 将不同源的JSON、CSV、Log等格式统一转换为Parquet或Avro列式存储格式，便于后续分析。
- 数据脱敏： 对手机号、身份证号等敏感信息进行MD5或AES加密，确保合规。
- 字段映射与衍生： 将原始字段映射到统一的数据模型，并计算衍生指标（如：通话时长区间、短信送达耗时、推送点击率）。
- 异常值处理： 过滤空值、重复数据、格式错误的数据行，并记录到异常数据表。
- 数据加载（Load）：
- 实时层： 加载到Redis或Druid，用于Score评分模型的实时特征计算。
- 离线层： 加载到Hive或ClickHouse，用于历史分析和模型训练。
- 服务层： 加载到MySQL或Elasticsearch，供催收员工作台和报表系统查询。
实战案例： 某头部消金公司通过将短信回执的ETL延迟从分钟级降低到秒级，使得“已读回执”信号能立即触发下一轮催收策略，整体回款率提升了约3.2%。
4.3 数据清洗规则详解
数据清洗是ETL流程中最耗时、最关键的环节。以下是针对催收数据源的典型清洗规则。
| 数据源 | 常见脏数据 | 清洗规则 | 处理动作 |
|---|---|---|---|
| 系统日志 | 堆栈异常信息、调试日志 | 正则匹配过滤非业务日志 | 丢弃或归档至异常日志库 |
| 通话记录 | 通话时长=0、空号码 | 过滤无效记录 | 丢弃并记录日志 |
| 短信回执 | 状态码为“未知”或“过期” | 映射为标准状态（送达/失败/未知） | 保留并标记状态 |
| APP推送点击 | 重复点击、设备ID为空 | 去重（按设备+时间窗口） | 保留首次点击，丢弃后续 |
4.4 数据质量监控与告警
ETL流程必须内置数据质量监控机制，确保进入Score评分模型的数据是可信的。
- 数据量监控： 对比实时流入量与历史基线，若波动超过±20%则触发告警。
- 延迟监控： 记录每条数据从产生到进入目标存储的时间戳，超过阈值（如短信回执>5秒）则告警。
- 数据完整性监控： 检查关键字段（如案件ID、客户ID）的空值率，超过1%则告警。
- 数据一致性监控： 定期对账，确保Kafka中的消息数与Hive中的记录数一致。
避坑指南： 不要忽视“数据倾斜”问题。在催收场景中，某些高逾期案件可能产生大量通话记录和短信回执，导致单个分区数据量过大，引发ETL任务OOM或处理延迟。建议按案件ID哈希或客户ID进行更细粒度的分区。
4.5 整体ETL架构图
下图展示了从四个数据源到最终数据存储的完整ETL架构，体现了实时流与离线批处理的融合（Lambda架构）。
4.6 数据血缘与回溯
在复杂的ETL流程中，数据血缘（Data Lineage）是保障数据可追溯性的关键。当Score评分出现异常时，能够快速定位是哪个数据源、哪个清洗环节出了问题。
- 记录元数据： 在ETL的每个环节，记录输入数据源、处理时间、处理逻辑版本、输出目标。
- 数据回溯： 当发现历史数据错误时，支持基于时间戳或版本号的“回滚”与“重跑”机制。
- 字段级血缘： 对于Score模型的关键特征（如“最近7天通话次数”），能够追溯到原始通话记录表的特定字段。
最佳实践： 使用Apache Atlas或自研的元数据管理平台，自动采集ETL任务的执行计划，生成可视化的数据血缘图谱。这能大幅降低排查问题的MTTR（平均修复时间）。
4.7 性能优化与低延迟保障
为了满足催收低延迟触达的要求，ETL流程必须进行针对性优化。
| 优化维度 | 具体措施 | 预期效果 |
|---|---|---|
| 数据序列化 | 使用Avro或Protobuf替代JSON | 减少网络传输和CPU开销，提升吞吐量30%+ |
| 并行度调优 | 根据Kafka分区数设置Flink/Spark的并行度 | 避免数据倾斜，充分利用集群资源 |
| 状态后端 | 使用RocksDB作为Flink的状态后端 | 支持大规模状态管理，避免OOM |
| 数据过滤下推 | 在Kafka Consumer端提前过滤无效数据 | 减少下游处理压力，降低延迟 |
| 批量写入 | 对Redis/MySQL采用批量写入（Batch Insert） | 减少网络IO，提升写入吞吐量 |
通过以上ETL流程的设计与优化，我们能够为催收Score评分模型提供高质量、低延迟的数据基础，确保每一次触达决策都建立在实时、准确的数据之上。