第3章数据源接入与数据采集

第一章：数据源接入与数据采集

大家好，我是老张。在风控数据仓库这个领域摸爬滚打了十来年，今天咱们聊聊最基础、也最容易被忽视的一环——数据源接入与采集。

说实话，很多团队一上来就急着建模型、搞算法，结果数据质量一塌糊涂，后面全白干。我见过太多这样的案例了。所以，咱们先把地基打牢。

1.1 风控数据源分类

风控数据源，说白了就是四类：征信、三方、埋点、内部业务。每一类都有它的脾气。

1.1.1 征信数据

征信数据是风控的「硬通货」。央行征信、百行征信、朴道征信，这些都是官方渠道。我个人习惯把征信数据分为两类：

个人征信报告：包含身份信息、信贷记录、公共记录等
企业征信报告：包含工商信息、司法风险、经营状况等

这里有个坑——征信数据更新频率低，一般按月更新。你想想看，如果用户上个月逾期了，这个月才查到，那风控模型就滞后了。嗯，要注意。

避坑指南：我曾经遇到过一个项目，征信数据延迟了45天，结果模型还在用旧数据做决策。后来我们加了实时查询接口，才解决了这个问题。

1.1.2 三方数据

三方数据，就是第三方数据服务商提供的。比如同盾、百融、集奥等。这类数据的特点是：

实时性强：API调用，秒级返回
覆盖面广：设备指纹、IP风险、手机号风险等
价格不菲：按调用次数收费，成本控制很重要

我建议，三方数据要按场景分级使用。比如，高风险场景用高精度数据，低风险场景用基础数据。别一上来就全量调用，成本扛不住。

1.1.3 埋点数据

埋点数据，就是用户在APP或网页上的行为轨迹。比如：

页面停留时间
点击次数
输入框聚焦/失焦
复制粘贴行为

这类数据量最大，也最脏。我记得有一次，埋点数据里出现了用户年龄为-1的记录，排查了半天，发现是前端埋点代码写错了。

小技巧：埋点数据建议用JSON格式传输，方便扩展字段。但要注意，JSON解析性能开销大，建议用列式存储（如Parquet）来存。

1.1.4 内部业务数据

内部业务数据，就是公司自己系统产生的数据。比如：

用户注册信息
交易流水
还款记录
客服工单

这类数据质量相对可控，但要注意数据孤岛问题。不同部门的数据格式、字段定义可能都不一样。我见过最夸张的，同一个「用户ID」在三个系统里叫法都不一样：user_id、uid、customer_no。

1.2 数据采集方式

数据采集方式，主流就三种：API、FTP、DB同步。每种方式都有适用场景。

1.2.1 API采集

API采集，适合实时性要求高的场景。比如：

征信查询
三方数据调用
实时风控决策

代码示例（Python）：

import requests
import json

def fetch_credit_report(user_id):
    url = "https://api.credit.com/v1/report"
    headers = {
        "Authorization": "Bearer your_token",
        "Content-Type": "application/json"
    }
    payload = {
        "user_id": user_id,
        "query_type": "personal"
    }
    
    try:
        response = requests.post(url, headers=headers, json=payload, timeout=5)
        response.raise_for_status()
        return response.json()
    except requests.exceptions.Timeout:
        # 超时处理
        return {"error": "timeout"}
    except requests.exceptions.RequestException as e:
        # 其他异常
        return {"error": str(e)}

这里要注意，API调用一定要加超时和重试机制。我曾经遇到过三方接口挂了，结果我们的服务也跟着挂了，因为没设超时。

1.2.2 FTP采集

FTP采集，适合批量数据交换。比如：

征信报告批量下载
三方数据日增量文件
内部系统对账文件

FTP采集的坑也不少：

文件命名不规范
文件格式不统一（CSV、Excel、TXT）
文件编码问题（GBK vs UTF-8）

避坑指南：我曾经遇到一个FTP文件，文件名里带了空格和中文，结果脚本解析失败。后来我们强制要求文件名用「yyyyMMdd_HHmmss_数据源_类型.csv」这种格式。

1.2.3 DB同步

DB同步，适合内部业务系统。常用工具：

Canal（MySQL binlog监听）
DataX（离线批量同步）
Kafka Connect（实时流同步）

我个人习惯用Canal做实时同步，DataX做离线全量。为什么？因为Canal能捕获增量变更，DataX适合做历史数据迁移。

DB同步要注意：

主键冲突
数据一致性（事务边界）
性能影响（别把源库拖垮了）

1.3 数据质量初检

数据采集进来，第一件事就是做质量初检。别急着入库，先看看数据能不能用。

我总结了一个「五步检查法」：

完整性检查：必填字段是否为空？
准确性检查：字段值是否在合理范围内？
一致性检查：同一字段在不同数据源是否一致？
时效性检查：数据是否在预期时间内到达？
唯一性检查：是否有重复记录？

代码示例（数据质量检查）：

def quality_check(df):
    issues = []
    
    # 完整性检查
    null_count = df['user_id'].isnull().sum()
    if null_count > 0:
        issues.append(f"user_id 缺失 {null_count} 条")
    
    # 准确性检查
    invalid_age = df[(df['age'] < 0) | (df['age'] > 120)]
    if len(invalid_age) > 0:
        issues.append(f"年龄异常 {len(invalid_age)} 条")
    
    # 唯一性检查
    dup_count = df.duplicated(subset=['user_id']).sum()
    if dup_count > 0:
        issues.append(f"重复记录 {dup_count} 条")
    
    return issues

核心要点：数据质量初检不是一次性的，要建立自动化监控。每天跑一遍，发现问题及时告警。我见过最惨的案例，数据质量出问题，模型跑了一周才发现，损失惨重。

1.4 知识体系总览

下面这张图，是我画的数据源接入与采集的整体架构。你一看就明白了。

这张图展示了从数据源到ODS层的完整链路。你想想看，每一层都有坑，每一层都要把关。数据源层要搞清楚数据来源和更新频率，采集方式层要选对工具和策略，质量初检层要建立自动化规则。

好了，第一章就聊到这儿。数据源接入是风控数据仓库的起点，也是最重要的环节。后面咱们会深入每个细节，比如API调用的限流策略、FTP文件的自动化解析、DB同步的断点续传等等。

记住一句话：数据质量，从源头抓起。

公众号:蓝海数据掘金营，微信deep3321

📚 课程目录

第一章：数据源接入与数据采集

1.1 风控数据源分类

1.1.1 征信数据

1.1.2 三方数据

1.1.3 埋点数据

1.1.4 内部业务数据

1.2 数据采集方式

1.2.1 API采集

1.2.2 FTP采集

1.2.3 DB同步

1.3 数据质量初检

1.4 知识体系总览