4. 数据标准与数据建模面试题
数据标准与数据建模是金融数据治理面试中的高频深水区。面试官真正想确认的不是你背过多少规范条文，而是你能否把命名规范、码值管理、主数据、参考数据串成一条可落地的治理链路，并用结构化表达讲清楚“为什么做、怎么做、做完有什么效果”。本章给出一套可直接复用的回答框架，并配以追问路径与常见误区复盘。
一、核心原理：四类概念的本质区别
面试中最容易失分的地方，是把主数据、参考数据、码值、数据标准混在一起讲。建议先用一句话定义边界，再展开治理动作。
- 数据标准：对数据项的业务定义、数据类型、长度、取值规则、责任部门的统一约定，是“规则层”。
- 命名规范：表名、字段名、指标名、接口名的统一命名规则，是标准在物理模型上的投影。
- 码值管理：对枚举值、状态码、行业代码的集中注册、版本控制与映射管理，解决“同义不同码”。
- 主数据：客户、产品、机构、员工等跨系统共享的核心实体，强调唯一可信源与生命周期管理。
- 参考数据：国家、币种、行业分类、汇率等相对稳定的外部或内部标准值，强调同步与版本。
回答时先给定义，再给“如果不治理会怎样”的反例，最后给治理动作，逻辑最稳。
二、方法流程：从标准制定到建模落地
金融场景下，数据标准必须嵌入需求、建模、开发、测试、发布五个环节，否则就是“墙上标准”。推荐用以下流程回答：
- 盘点与归集：梳理现有表、字段、码值、主数据分布，识别冲突与冗余。
- 制定标准：由数据治理委员会牵头，业务、科技、合规共同评审，输出命名规范、码值字典、主数据模型。
- 嵌入建模：在逻辑模型与物理模型评审中设置检查点，命名不合规不通过。
- 系统落地：通过元数据平台、码值服务、主数据管理平台（MDM）实现集中管控。
- 监控与迭代：用标准覆盖率、码值一致率、主数据重复率等指标持续度量。
命名规范示例（金融常见）：
表名：ODS_CUST_INFO、DWD_TRANS_DETAIL
字段：cust_id、prod_code、trans_amt、stat_date
指标：mth_avg_bal、npl_ratio
码值：CUST_TYPE 01-个人 02-对公 03-同业
主数据：客户主数据、产品主数据、机构主数据
参考数据：币种、国家、行业分类、汇率三、案例/场景：跨系统码值冲突如何治理
面试官常问：“如果两个系统对客户状态码定义不一致，你怎么处理？”建议按以下结构回答：
- 现状：核心系统用 A 码，信贷系统用 B 码，报表口径不一致，监管报送频繁出错。
- 动作：先建立码值映射表，再推动主数据平台统一发码，最后改造下游接口。
- 结果：码值一致率从 72% 提升到 98%，监管报送差错率下降 60%。
- 复盘：标准必须前置到需求阶段，否则后期改造成本极高。
| 治理对象 | 核心问题 | 治理动作 | 度量指标 |
|---|---|---|---|
| 命名规范 | 同义不同名、缩写混乱 | 发布命名规范并嵌入建模评审 | 命名合规率 |
| 码值管理 | 同码不同义、版本失控 | 集中注册、映射表、版本管理 | 码值一致率 |
| 主数据 | 多源重复、归属不清 | MDM 平台、唯一可信源、生命周期 | 主数据重复率 |
| 参考数据 | 同步滞后、口径不一 | 统一同步服务、版本发布 | 参考数据同步及时率 |
四、误区/复盘：面试中常见的失分点
误区一：把主数据和参考数据混为一谈。主数据是核心实体，参考数据是标准值，二者治理方式不同。
误区二：只讲规范不讲落地。面试官更关心你如何把标准嵌入建模、开发和发布流程。
误区三：忽略组织与责任。数据标准必须有 owner、有评审机制、有考核指标。
误区四：没有量化结果。用覆盖率、一致率、差错率等指标收尾，可信度更高。
建议在面试中用“定义—机制—场景—度量”四段式回答，每段控制在 30 秒以内，并主动抛出一个你亲历的码值或主数据治理案例。这样既能展示专业深度，也能体现落地能力。