3. 数据质量核心概念

在金融数据治理中，“数据质量”不是一句口号，而是一组可以被定义、被度量、被验收的约束集合。很多团队在验收时只检查“有没有数据”，结果上线后才发现金额算错、客户重复、账实不符。要避免这类问题，必须先把质量维度拆开，理解每个维度在金融场景中的具体含义、检查对象和典型失败模式。

一、六个核心维度的专业定义与金融场景

下面这张表把六个维度放在一起对比，便于在规则设计和验收时快速定位检查方向。

二、维度之间的关系：不是孤立检查，而是组合约束

六个维度经常被误认为可以单独验收，实际上它们之间存在依赖和交叉。例如，一条记录“完整性”通过，但“有效性”可能失败：字段有值，但值不在允许的枚举范围内。再如，“唯一性”失败往往会导致“一致性”失败：重复客户记录会让汇总口径出现偏差，进而导致总账与明细不符。

因此，在规则体系设计中，建议按“先结构、后内容、再关系、最后时效”的顺序组织检查：先看字段是否存在（完整性），再看格式是否合法（有效性），然后看值是否准确（准确性），接着看跨表是否一致（一致性），同时检查是否重复（唯一性），最后看是否按时到达（及时性）。这个顺序能减少无效检查，提高规则执行效率。

三、方法流程：从维度到可执行规则

把维度落到验收，需要经过“维度→指标→规则→阈值→动作”的转化。以下是一个可复用的流程清单：

1. 确定检查对象：明确是对单字段、单表、跨表还是跨系统检查。例如“客户身份证号”是单字段，“总账与明细”是跨表。
2. 选择质量维度：同一对象可能同时受多个维度约束。客户身份证号既要有值（完整性），又要符合18位格式（有效性），还要不重复（唯一性）。
3. 定义度量指标：如空值率、重复率、延迟分钟数、勾稽差异金额、枚举越界率。
4. 设置阈值与分级：例如空值率≤0.1%为通过，0.1%~1%为警告，>1%为阻断。
5. 绑定处置动作：通过则放行，警告则通知数据 steward，阻断则暂停下游任务并生成工单。

四、案例与场景：一次日终清算的验收复盘

某银行日终清算批次在T+1上午6点完成，但下游报表在8点仍无法生成。排查发现：交易明细表中有3条记录的交易金额为空（完整性失败），导致汇总金额为NULL；同时客户表中有2个客户编号重复（唯一性失败），导致客户维度汇总出现双倍计数；此外，总账余额与明细汇总相差120万元（一致性失败）。

复盘后，团队在验收规则中增加了以下检查：

-- 完整性检查：交易金额不能为空
SELECT COUNT(*) AS null_amt_cnt
FROM txn_detail
WHERE txn_amt IS NULL;

-- 唯一性检查：客户编号不能重复
SELECT cust_id, COUNT(*) AS cnt
FROM customer
GROUP BY cust_id
HAVING COUNT(*) > 1;

-- 一致性检查：总账与明细汇总勾稽
SELECT ABS(g.total_amt - d.sum_amt) AS diff
FROM gl_balance g
JOIN (SELECT SUM(txn_amt) AS sum_amt FROM txn_detail) d
ON 1=1;

这三条规则分别对应完整性、唯一性和一致性，执行后能在批次结束前拦截问题，避免下游报表返工。

五、常见误区与纠正

• 误区一：把完整性等同于准确性。字段有值不代表值正确。完整性只回答“有没有”，准确性才回答“对不对”。
• 误区二：只做单表检查，忽略跨表一致性。金融数据大量依赖勾稽关系，单表通过不代表全局通过。
• 误区三：唯一性只查主键。主键天然唯一，真正要查的是业务键组合，如“客户号+产品号+日期”。
• 误区四：及时性只看批次完成时间。还要看关键表的最早到达时间和最晚到达时间，避免“批次完成但核心表迟到”。
• 误区五：有效性规则写得太死。业务枚举会变化，规则应支持版本管理和灰度生效。