3. 数据标准与规范：让数据说同一种语言

做风控这么多年，我见过最头疼的事，不是模型不准，而是数据对不上。

同一个客户，在A系统叫「张三」，在B系统叫「Zhang San」。同一个字段，这边叫「loan_amt」，那边叫「apply_amount」。你想想看，这数据怎么用？

所以，数据标准与规范，说白了就是让所有系统、所有团队，用同一套规则说话。今天我们就聊聊这个。

3.1 字段命名规范：起个好名字，省一半功夫

字段命名这事，看着简单，坑却不少。我刚开始做风控时，接过一个项目，数据库里字段名五花八门——有驼峰的、有下划线的、还有拼音首字母的。查个数据，得先猜半天字段含义。

我个人习惯的命名原则：

  • 全小写 + 下划线：比如 customer_id，而不是 customerID 或 CustomerId
  • 业务含义优先：字段名要能看出业务场景，比如 loan_apply_date 比 date1 强一百倍
  • 避免缩写歧义：比如 cust 是客户，那 cst 是什么？别猜，直接写全
  • 统一前缀/后缀：时间字段统一加 _dt，金额字段统一加 _amt

我建议的命名模板：

# 客户相关
customer_id          # 客户ID
customer_name        # 客户姓名
customer_phone       # 客户手机号

# 贷款相关
loan_id              # 贷款编号
loan_apply_amt       # 申请金额
loan_approve_amt     # 审批金额
loan_issue_dt        # 放款日期

# 风控相关
risk_score           # 风险评分
risk_level           # 风险等级
overdue_days         # 逾期天数

小技巧： 我习惯在项目启动时，就拉上开发、业务、数据三方，一起定一份《字段命名规范文档》。后面谁改谁难受，但一开始定好，后面就爽了。

3.2 数据字典建设：给数据做「身份证」

数据字典是什么？说白了，就是给每个字段做一张「身份证」。上面写清楚：这个字段叫什么、什么类型、多长、什么意思、从哪来的。

我在项目中遇到过最离谱的事——一个字段叫 flag，文档里写「0-正常，1-异常」。结果查代码发现，有的系统用0表示正常，有的用1表示正常。你猜怎么着？数据对不上，模型全废了。

数据字典应该包含的内容：

字段名 数据类型 长度 业务含义 取值范围 来源系统
customer_id varchar 32 客户唯一标识 UUID格式 CRM系统
loan_apply_amt decimal 18,2 客户申请贷款金额 0 - 99999999.99 贷款系统
risk_score int 3 风控模型评分 300 - 850 风控引擎

注意： 数据字典不是写一次就完事的。我见过太多项目，字典建完就吃灰。一定要有专人维护，每次字段变更，字典必须同步更新。

3.3 代码表标准化：别让「1」和「01」打架

代码表这事，看着小，但坑最深。比如性别，有的系统用「0-男，1-女」，有的用「1-男，2-女」，还有的用「M-男，F-女」。数据一合并，直接乱套。

我曾经踩过的坑： 一个风控项目，需要对接三个外部数据源。A源用「Y-是，N-否」，B源用「1-是，0-否」，C源用「true-是，false-否」。我写映射逻辑写了整整两天，还漏了一个字段，导致模型跑出来全是错的。

代码表标准化的核心原则：

  • 统一编码规则：所有代码表用同一套编码体系，比如都用数字，或者都用字母
  • 集中管理：建一个统一的代码表管理平台，所有系统都从这里取
  • 版本控制：代码表变更要有记录，谁改的、什么时候改的、为什么改

我建议的代码表示例：

-- 性别代码表
code_type: 'GENDER'
code_value: '0'  -> 含义: '未知'
code_value: '1'  -> 含义: '男'
code_value: '2'  -> 含义: '女'

-- 婚姻状况代码表
code_type: 'MARITAL_STATUS'
code_value: '0'  -> 含义: '未知'
code_value: '1'  -> 含义: '未婚'
code_value: '2'  -> 含义: '已婚'
code_value: '3'  -> 含义: '离异'
code_value: '4'  -> 含义: '丧偶'

-- 逾期状态代码表
code_type: 'OVERDUE_STATUS'
code_value: '0'  -> 含义: '正常'
code_value: '1'  -> 含义: '逾期1-30天'
code_value: '2'  -> 含义: '逾期31-60天'
code_value: '3'  -> 含义: '逾期61-90天'
code_value: '4'  -> 含义: '逾期90天以上'

3.4 数据一致性：从源头到终端的「对齐」

数据一致性，说白了就是同一个数据，在A系统和B系统里，值是一样的。但现实往往是——A系统说客户逾期了，B系统说没有。为什么？因为两个系统对「逾期」的定义不同。

我总结的三个关键点：

  • 定义一致：同一个业务概念，所有系统用同一个定义。比如「逾期」是超过还款日1天还是3天？必须统一
  • 口径一致：计算逻辑要统一。比如「逾期率」，分子分母怎么算？不同算法结果差很多
  • 时效一致：数据更新时间要同步。A系统每天凌晨更新，B系统实时更新，那对不上很正常

避坑指南： 我曾经在做一个风控报表时，发现逾期率忽高忽低。查了半天，原来是数据仓库和业务系统的更新时间差了2小时。后来统一了调度时间，问题就解决了。

3.5 知识体系总览

下面这张图，是我对数据标准与规范的整体理解。你可以把它当成一张「地图」，知道每个模块在做什么、怎么配合。

数据标准与规范知识体系 数据标准与规范 字段命名规范 数据字典建设 代码表标准化 数据一致性 全小写+下划线 业务含义优先 统一前缀后缀 字段定义 数据类型 取值范围 统一编码规则 集中管理 版本控制 定义一致 口径一致 时效一致 目标：确保数据一致性，让数据说同一种语言

嗯，数据标准与规范这块，说难不难，说简单也不简单。关键是要有人推动、有工具支撑、有制度保障。我见过太多项目，一开始觉得「差不多就行」，结果后面数据对不上，返工成本高得吓人。

所以，我的建议是：从一开始就把标准定好，后面会省很多事。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →