📚 课程目录第2章催收数据基础

2. 催收数据基础：数据来源与ETL

催收模型的效果高度依赖底层数据的广度、深度与质量。本章系统梳理催收数据的三大来源体系，并介绍数据仓库与ETL的核心概念，为后续特征工程打下坚实基础。

2.1 催收数据来源全景

催收数据按来源可分为内部系统、外部征信与三方数据三大类。下表从数据内容、更新频率、获取成本三个维度进行对比：

数据来源	典型数据内容	更新频率	获取成本	核心用途
内部系统	客户基本信息、账户信息、还款记录、历史催收记录、通话录音	实时/每日	低（自有）	基础画像、行为特征、催收策略
外部征信	央行征信报告、百行征信、朴道征信等	每月/按需	中	信用评分、多头借贷、逾期历史
三方数据	运营商数据、电商数据、社保公积金、黑名单、设备指纹	实时/每日	高（按调用量计费）	失联修复、反欺诈、还款能力评估

2.2 内部系统数据详解

内部系统是催收建模最核心、最可控的数据源，通常包含以下关键模块：

核心账务系统： 合同金额、已还金额、剩余本金、逾期天数、逾期期数、罚息金额等。
客户关系管理（CRM）： 客户姓名、身份证号、手机号、家庭地址、工作单位、联系人信息。
催收作业系统： 催收员分配记录、催收动作（电话、短信、信函）、催收结果（承诺还款、无效、失联）、通话时长与频次。
行为日志： 客户登录APP频次、浏览页面、点击行为、还款操作时间戳。

实战要点： 内部数据虽然成本低，但常存在字段缺失、格式不统一、历史数据迁移错误等问题。建模前必须进行严格的数据质量探查（Data Profiling）。

2.3 外部征信与三方数据

外部数据主要用于补充内部数据无法覆盖的信息维度，尤其在失联修复和反欺诈场景中不可或缺。

2.3.1 外部征信数据

央行征信： 包含个人信贷记录、公共记录（欠税、民事判决）、查询记录。更新周期通常为T+1月。
百行/朴道征信： 覆盖互联网信贷、消费金融等新兴业态，数据维度更广，更新频率更高。

2.3.2 三方数据

运营商数据： 通话时长、通话频次、联系人数量、在网时长、流量使用情况。常用于失联修复和稳定性评估。
电商/支付数据： 消费金额、消费频次、消费类别、收货地址稳定性。用于评估还款能力和消费习惯。
黑名单/反欺诈数据： 法院失信被执行人、网贷黑名单、设备指纹关联风险。

合规风险提示： 外部数据采集必须遵循《个人信息保护法》和《征信业管理条例》。严禁非法获取、买卖个人敏感信息。三方数据调用需获得用户明确授权，并确保数据脱敏处理。

2.4 数据仓库与ETL基础

原始数据分散在多个异构系统中，无法直接用于建模。数据仓库（Data Warehouse）与ETL（Extract, Transform, Load）是解决这一问题的核心基础设施。

2.4.1 数据仓库分层架构

催收数据仓库通常采用分层设计，以提升数据复用性和管理效率：

ODS（操作数据存储层）： 从源系统直接抽取的原始数据，保持与源系统一致，不做任何清洗。
DWD（明细数据层）： 对ODS数据进行清洗、去重、格式标准化，形成统一的明细数据。
DWS（汇总数据层）： 按客户、账户、时间等维度进行轻度汇总，如客户月度还款汇总、催收员月度绩效。
ADS（应用数据层）： 面向具体业务场景（如催收模型训练）生成的特征宽表，直接供建模使用。

2.4.2 ETL核心流程

ETL是数据从源系统进入数据仓库的完整过程，每个环节都有特定的技术要点：

阶段	核心任务	常见技术/工具	催收场景典型问题
Extract（抽取）	从源系统读取数据，支持全量/增量抽取	Sqoop、DataX、Kafka Connect	源系统接口不稳定、增量字段缺失
Transform（转换）	数据清洗、字段映射、格式转换、衍生计算	Spark SQL、Hive、Python Pandas	手机号格式不统一、身份证号校验、逾期天数计算逻辑
Load（加载）	将转换后的数据写入目标数据仓库表	Hive、ClickHouse、MySQL	数据倾斜、分区策略不合理导致加载缓慢

2.4.3 催收ETL实战示例

以下是一个典型的催收ETL脚本片段（使用Spark SQL），用于将原始催收记录转换为建模可用的特征宽表：

-- 1. 从ODS层抽取原始催收记录
CREATE TEMP VIEW raw_collection AS
SELECT 
    account_id,
    collector_id,
    call_time,
    call_duration_sec,
    call_result,
    promise_amount,
    promise_date
FROM ods.collection_records
WHERE dt = '${biz_date}';

-- 2. 数据清洗与转换
CREATE TEMP VIEW cleaned_collection AS
SELECT 
    account_id,
    collector_id,
    call_time,
    -- 过滤异常通话时长（小于5秒视为无效）
    CASE WHEN call_duration_sec < 5 THEN 0 ELSE call_duration_sec END AS valid_duration,
    -- 标准化催收结果
    CASE 
        WHEN call_result IN ('承诺还款', '部分承诺') THEN 'promise'
        WHEN call_result IN ('无人接听', '关机', '停机') THEN 'unreachable'
        ELSE 'other'
    END AS result_category,
    -- 承诺金额空值填充为0
    NVL(promise_amount, 0) AS promise_amount,
    promise_date
FROM raw_collection;

-- 3. 按账户汇总生成特征
INSERT OVERWRITE TABLE ads.account_collection_features PARTITION(dt = '${biz_date}')
SELECT 
    account_id,
    COUNT(*) AS total_calls,
    SUM(valid_duration) AS total_valid_duration,
    AVG(valid_duration) AS avg_call_duration,
    SUM(CASE WHEN result_category = 'promise' THEN 1 ELSE 0 END) AS promise_count,
    SUM(promise_amount) AS total_promise_amount,
    MAX(promise_date) AS last_promise_date
FROM cleaned_collection
GROUP BY account_id;

  关键设计原则： 催收ETL脚本必须考虑数据回溯能力。当模型上线后发现特征计算逻辑有误时，需要能够重新跑历史日期的ETL任务，生成修正后的特征数据，避免模型重训时数据不一致。

2.5 数据质量与治理

数据质量是催收模型的生命线。以下是在数据接入阶段必须关注的几个核心维度：

完整性： 关键字段（如逾期天数、手机号）缺失率是否超过阈值？缺失值如何处理？
准确性： 数据是否与源系统一致？是否存在逻辑矛盾（如逾期天数大于0但还款金额也为0）？
一致性： 不同系统间的同一字段（如客户ID）是否能够关联？编码规则是否统一？
时效性： 数据从产生到进入数据仓库的延迟是否满足建模要求？实时场景需要秒级延迟，离线场景可接受T+1。

2.6 本章小结

催收数据来源的多样性和复杂性决定了数据基建的重要性。内部系统提供基础画像与行为数据，外部征信与三方数据补充信用与风险维度。数据仓库的分层架构（ODS→DWD→DWS→ADS）与ETL流程是数据从原始状态转化为可用特征的关键路径。在实际项目中，建议优先夯实内部数据质量，再逐步引入外部数据，并建立完善的数据质量监控体系，确保模型训练数据的可靠性与一致性。