类型 0 是什么
类型 0 指属性在首次入库后永不变化，源端后续给出的新值一律忽略：身份证号、开户日期、合同签署日、档案编号、出生日期属于这类。它本质上是主动放弃追踪，因此必须配数据质量规则监控稳定性。一旦源端出现不同值，只可能是两种原因——源数据本身错了，或当初把它归类为类型 0 的判断错了，两种都需要人工裁定，而不是让新值静默覆盖。
基本信息
| 适用 | 天然不变或业务上不允许变更的属性 |
|---|---|
| 变更处理 | 忽略，或走人工校正流程 |
| 存储成本 | 无额外版本行与历史列 |
| 必备配套 | 稳定性校验规则与告警 |
| 判定标准 | 该属性变化是否意味着某个业务事实本身出错了 |
典型使用场景
- 身份类属性：证件号、出生日期、开户日期
- 制度性日期：合同签署日、入职日、建档日
- 序号类编码：档案编号、开户序号，重新编号即错误
- 人工核验优先：变更必须走线下核验后再订正，不能自动覆盖
- 上游质量兜底：源端字段被误改时靠稳定性规则及时发现
- 审计要求：监管要求某属性一旦登记不得变更
特征判断与稳定性校验
特征判断与稳定性校验
-- 判断标准：该属性变化是否意味着业务事实出错？
-- 是 -> 用类型 0，并在数据质量规则里告警
-- 否 -> 考虑类型 1 / 2 / 3
-- 稳定性校验：源端值与已入库值不一致的成员
SELECT s.user_id, d.id_card, s.id_card AS src_id_card
FROM stg_user s
JOIN dim_user d ON s.user_id = d.user_id AND d.is_current = 1
WHERE s.id_card IS NOT NULL
AND d.id_card IS NOT NULL
AND s.id_card <> d.id_card; -- 有结果就该人工介入，不要自动覆盖适合类型 0 的属性
| 属性 | 能否变 | 处理方式 |
|---|---|---|
| 证件号 | 极少变，变即异常 | 类型 0 + 稳定性告警 |
| 开户日期 | 业务上不可变 | 类型 0，禁止覆盖 |
| 合同签署日 | 不可变 | 类型 0 |
| 注册渠道 | 理论不变但常被修正 | 类型 1 更合适 |
| 客户等级 | 会变且影响分析 | 类型 2 或类型 3 |
| 联系电话 | 会变且无历史价值 | 类型 1 |
类型 0 与「字段留空不管」完全不同：前者是有明确规则的忽略，后者是无人负责。类型 0 的属性必须在模型文档中写明判定依据，并挂上校验规则，否则一旦源端大范围改写这类字段，问题会长期无人发现。