数据采集与整合：多源数据合并、字段对齐、数据字典建立
做信用评分建模，最头疼的不是算法，而是数据从哪里来、怎么凑到一起。我见过太多团队在模型上线前才发现，某个关键变量的含义和当初理解的不一样——那感觉，就像跑完马拉松发现终点线画错了位置。
这一章，咱们就聊数据融合的实战套路。说白了，就是把多个渠道的数据「拧」成一根绳子。
数据源的多样性与协调
信用评分的数据源，通常来自这几个方面：
- 核心信贷系统：客户基本信息、账户余额、还款记录
- 外部征信数据：人行征信、百行征信、多头借贷记录
- 交易流水数据：银行流水、支付平台行为日志
- 反欺诈平台：设备指纹、IP归属、黑名单命中记录
- 第三方数据商：教育、就业、社保等政务数据
这些系统的数据格式、更新频率、标识字段各不相同。嗯，这里要注意：同一个客户在不同系统中的ID可能是完全不同的东西。我曾经在项目里遇到过，一家银行用身份证号作为唯一标识，而另一家合作的消费金融公司用的是自生成的客户编号——合并时直接按ID关联，结果两条完全不相关的人被强行绑定在了一起。
多源数据合并策略
合并方式无非这几种，我按实际场景排了个优先级：
| 合并方式 | 适用场景 | 我踩过的坑 |
|---|---|---|
| 硬关联（内连接） | 两套数据都有高准确率的共同ID | 丢失大量样本，有时损失率超过40% |
| 全关联（外连接） | 保数据完整性、后续做缺失处理 | 会产生大量空值列，模型前要谨慎处理 |
| 模糊匹配 | ID字段有误差（如名字少一个字母） | 需要设定相似度阈值，我习惯用0.85以上 |
| 逐层合并 | 数据源超过3个，且层级关系复杂 | 先按客户级合并，再按账户级追加 |
我个人习惯优先用硬关联。为什么？因为你想想看，如果你的客户ID都不可靠，后面做的所有特征工程都是空中楼阁。不过也别太死板——有时为了保证样本量，我会先用硬关联做一个核心集，再把模糊匹配的结果作为「候选池」单独存放，提供给模型组风险决策用。
字段对齐：统一语义与格式
不同数据源对同一个字段的定义，可能存在根本性的差异。举个最常见的例子：
- A系统把「逾期」定义为超过还款日1天
- B系统定义为超过3天
- C系统甚至只标记「催收中」状态，不直接说是否逾期
你看，这三个字段虽然都叫「逾期标志」，但语义完全不同。这时候必须做字段对齐。
1. 字段名统一：全部转为小写+下划线格式
2. 单位统一：金额统一为「分」还是「元」？我建议统一到「分」，避免浮点精度问题
3. 缺失值标识统一：用-99、-1还是NA？
4. 枚举值映射：比如性别字段，A系统用0/1，B系统用M/F，必须建立映射表
5. 时间格式标准化：全部转为'YYYY-MM-DD HH:MM:SS'格式，别用不同时区
这里有个小技巧——我每次做字段对齐时，会额外生成一个字段差异报告。记录每个字段在源系统和目标系统中的名字、类型、取值范围、缺失率差异。将来模型调优或者数据追责时，这个报告能救你命。
# 字段对齐示例：用一个简单的映射配置
field_mapping = {
'cust_id': {'source': ['customer_id', 'user_no', 'client_code'],
'type': 'string'},
'overdue_flag': {'source': ['overdue_status', 'is_overdue', '逾期标志'],
'type': 'int',
'value_map': {'Y': 1, 'N': 0, '是': 1, '否': 0}},
'loan_amount': {'source': ['amount', 'loan_amt', '放款金额'],
'type': 'float',
'unit': 'fen'}
}
你看，这个配置虽然简单，但能保证每次合并时都按同一套规则执行。我习惯把这类配置放在YAML文件里，方便版本管理。
数据字典：让变量可追溯
数据字典是数据仓库的说明书。没有它，半年后你回头看你建的宽表，很可能一头雾水——「这个字段到底是啥意思？」
每一行对应一个变量，至少包含：变量名、中文含义、数据类型、取值范围、缺失值处理方式、来源系统、创建日期、负责人。好记性不如烂笔头，这句话在数据工程里是铁律。
| 变量名 | 中文含义 | 数据类型 | 取值范围 | 来源系统 |
|---|---|---|---|---|
| cust_id | 客户唯一标识 | string | 16位数字 | 核心系统 |
| overdue_30d | 近30天逾期天数 | int | 0-30 | 征信系统 |
| mob | 账龄（月） | int | 1-120 | 账户系统 |
| target | 好坏样本标签 | int | 0/1 | 模型组定义 |
数据字典不能只是Excel文件。我习惯把它嵌入到建表脚本的注释中，同时保持一份在线文档，方便跨团队沟通。另外，每次迭代都要更新——字段改了但字典不更新，比没有字典更坑人。
整合后的质量检查
数据合并完了，别急着往下走。得先过一遍质量检查：
- 样本量检查：合并后的总记录数是否符合预期？少了还是多了？
- 关键字段完整性：ID、目标变量、建模必须字段的缺失率是否在阈值内？
- 分布偏移检查：合并前后的字段分布有没有「断层」？我常见的问题是金额字段小数点位置不对，导致分布图出现诡异的尖峰。
- 逻辑一致性：比如逾期天数不应该大于贷款期限，性别字段不应该出现「未知」以外的值。
最后，数据整合这件事，最考验的不是技术，而是耐心和细心。把每一步都做成可复用的脚本、可追溯的日志、可查阅的字典，你后续建模的效率会翻倍。相信我，这一点我深有体会。