数据获取与数据源探索

构建信用评分模型，第一件正经事就是搞数据。我见过不少新人，模型理论背得滚瓜烂熟，结果一上手发现数据根本拿不到，或者拿到了也没法用。说白了，数据才是真正的「原材料」，没料你怎么炒菜？

这一章我们就来聊聊：数据从哪来，拿的时候要注意什么，以及拿到手之后怎么快速摸清它的底细。

3.1 数据来源：别只盯着一个池子

信用评分模型的数据源，常见的有三类。我建议你一开始就把渠道铺开，别只盯着一家。

来源类型	典型数据	获取难度
银行/持牌机构内部	贷款申请、还款记录、账户流水	低（自家系统嘛）
第三方征信机构	央行征信、百行征信、同盾、芝麻	中（要渠道授权）
外部替代数据	电商消费、运营商、社保、公积金	高（合规要求多）

我在项目中遇到过一家消费金融公司，只用了内部还款记录，结果模型在用户早期就失效了——因为新客户根本没有历史。后来补了征信和运营商数据，模型才真正「活」过来。

3.2 数据获取方式：API、数据库、还是文件搬砖？

拿数据的方法就那么几种，选对了省大事。

• API 实时调用：适合征信、黑名单等需要秒级响应的场景。注意限流和超时重试。
• 数据库直连：适合内部系统批量取数。写个 SQL 就行，但别在生产库上跑大型 join。
• 文件导入：CSV、Excel、Parquet 最常见。适合离线建模，但注意编码和分表。

举个例子。我早期做模型时，图省事直接拉了生产库的全量数据，结果把线上库搞崩了一次……嗯，从那以后我再也不敢在生产环境「select *」了。建议用只读副本或离线快照。

3.3 数据探索：看懂「食材」再下锅

数据拿到手，别急着建模。先做一轮快速探索，搞清楚每一列是什么、长什么样。我习惯用这套流程：

1. 看形状：行数、列数、数据类型。发现 object 列里混了数字？常见坑。
2. 看缺失：每列缺失率。超过 70% 的我基本直接砍掉。
3. 看分布：统计量（均值、中位数、标准差）。画个箱线图，异常值一目了然。
4. 看相关性：特征之间是否强相关。两个变量相关系数超过 0.9，考虑合并或删除一个。
5. 看时间连贯性：信用数据天然带时间戳，检查跨度是否合理。

你想想看，如果欠款金额列里混了身份证号，你不检查就直接建模，结果能好吗？我碰到过一回，缺失值用 -999 填充，但模型把 -999 当成了有效特征……后来查了好久才发现。

3.4 数据清洗：从原始到可用

清洗是体力活，但也是技术活。我通常做这几步：

• 格式统一：日期转成统一格式，金额单位统一（元/万元），分类变量编码。
• 异常值处理：年龄 200 岁？收入负数？直接当错误处理，或按业务逻辑截断。
• 重复记录去重：同一个客户多条申请记录，只保留时间最近或状态最新的。

举个例子，央行征信拉回来的数据经常有「多头借贷」标识，但字段名各家叫法不同：有的叫‘multi_loan_cnt’，有的叫‘recent_loan_num’。需要手动映射。我曾经手动对过 40 个字段的映射表，累归累，但后来模型效果提升就是靠这些细节。

好，现在我们把整个数据获取与探索的流程串起来。下面这张图是我自己常用的框架，你一看就明白。

图中框的颜色代表不同阶段：蓝/红/紫是数据源，绿色是获取方式，橙色是探索，青色是清洗。你跟着这个流程走一遍，基本不会漏掉关键步骤。

3.5 数据质量评估：一眼看出「食材」好坏

数据拿到手，我习惯先跑一个「数据质量报告」。核心看三样：

• 完整度：每列缺失率，按字段重要度加权打分。
• 准确度：看值域是否合理。比如收入字段，0 和 999999 都是可疑值。
• 一致性：不同来源的同字段是否冲突。比如身份证号在 A 库和 B 库里对不上。

我遇到过最奇葩的事：某个客户在征信报告里是「已婚」，在内部系统里是「未婚」，年龄还差了 5 岁。后来发现是录入时用了不同的校验规则。这种矛盾数据，要么取最新来源，要么标记异常。

3.6 数据集成：把不同源的数据「粘」起来

信用评分模型通常需要融合多个来源的数据。常用的合并方式：

• 主键合并：用身份证号、手机号等唯一标识，关联不同表。注意一对多和多对一关系。
• 时间窗口聚合：比如近 3 个月逾期次数、近 6 个月平均负债。窗口长度要合理，太短看不出趋势，太长又淹没信号。
• 属性拼接：把不同来源的同一特征（比如收入）拼接成「最低收入」「最高收入」「来源数」等新特征。

有一次我需要对征信、电商、运营商三个来源做拼接。每个来源都有「用户 ID」但格式不同，征信是 15 位、电商是 32 位、运营商是手机号。光做 ID 映射就折腾了大半天——但后面模型跑起来，多源的泛化能力明显比单源好。

从数据获取到探索再到清洗集成，每一步都直接影响模型效果。别想着跳过，也别想着一步到位。慢慢来，把地基打牢，后面盖楼才稳。