返回数据系统模块
Data Systems / Tutorial

数据质量六维度实战教程

把数据质量当作工程问题:用六个维度定义质量,把维度落地为校验规则、监控与对账,让每一次数据异常都可复现、可定位、可闭环。

9 个章节金融资产数据案例六维度 + 校验规则
01

为什么数据质量是工程问题

问题先于工具

贯穿案例:金融资产数据保障

一条资产数据会这样流转:交易 → 清算 → 持仓与估值 → 报表与风控。估值晚一天、持仓多一笔、余额口径不一致,都会顺着链条传导到净值、对账和监管报送。本教程所有规则都围绕这套数据展开。

临时写 SQL 查一查为什么不够:每次判断标准不统一、检查结果不沉淀、没有告警和责任人、下次同样的错误还会发生。数据质量问题的特征是“重复发生”,所以要把它当作工程问题。

数据质量事故的表现与影响

事故表现典型场景影响
记录缺失日终批次漏跑,持仓表缺估值日记录净值与风险指标缺失,客户资产查询无数据
记录重复同一账户、证券在估值日被写入两次资产总额虚高,监管报送对账失败
口径不一余额字段在持仓表与总账定义不同跨系统对账永远不平,难以定位
延迟到达行情文件 T+1 才送达估值迟发,错过披露与结算时点
脏数据混入证券代码不在证券字典中计算报错,报表出现幽灵持仓
02

数据质量的六个维度

检查的视角

维度是视角,不是分类

同一条数据可能同时违反多个维度:一次对账失败,往往既是“一致性”问题也是“准确性”问题。按维度组织检查规则,是为了让规则可复用、责任可到人、问题可归类。

六维度定义与金融案例

维度定义检查方式金融案例
完整性该有的字段和记录不缺失必填字段空值扫描、表间记录数比对、外键关联检查持仓表 valuation_date 为空,估值少算一天
准确性数据与真实业务结果一致抽样核对、与上游或对账单比对、公式复算实收金额与交易金额对不上,资金账不平
一致性同一事实在不同表或系统中口径一致跨表 join 比对、口径字典核对日终余额与总账余额不一致,对账失败
唯一性业务键在作用域内唯一主键与唯一约束、分组计数同一账户加证券加估值日出现两条持仓
时效性数据在约定时间内可用批处理时延监控、最新数据新鲜度检查行情迟到,估值错过披露时点
有效性取值符合枚举、范围与字典规则枚举校验、范围校验、字典关联校验证券代码不在字典中,状态出现非法值
六维度不要割裂使用。落地时先问“这条数据最怕哪种坏法”,再选主导维度写规则;定位问题时再回到全维度去排查。
03

把维度落地为校验规则

维度到规则到断言

固定链路:维度 → 规则 → SQL/断言

一个可落地的规则,要把“感觉哪里不对”翻译成“查什么、怎么判、谁处置”。维度决定看什么,规则描述判定,SQL 或断言是执行载体。

规则描述模板
规则编号: DQ-CHECK-003
维度: 完整性
对象: asset_position 持仓表, 近 7 天分区
判定: valuation_date 空值计数为 0
阈值: 0
频率: 每个交易日 02:00 批次结束后
处置: 失败则告警并挂起当日估值发布
责任人: 数据应用组

一条规则的必备要素

要素要回答的问题示例
对象规则作用在哪张表、哪个分区asset_position 近 7 天
判定什么条件算通过空值计数等于 0
阈值允许的最大偏差行数偏差小于 1%
频率多久查一次批次后、小时级、实时
处置失败后自动做什么告警、阻断发布、生成工单
规则的数量要克制。每新增一条规则,都要能回答:它抓到过什么真实问题?如果只是“听起来合理”,就先不要写。
04

逐维度校验的 SQL 示例

SQL 即检查
完整性与唯一性
-- 完整性: 持仓表估值日为空
SELECT COUNT(*) AS null_count
FROM asset_position
WHERE valuation_date IS NULL;

-- 唯一性: 同一账户、证券、估值日重复
SELECT account_id, security_code, valuation_date, COUNT(*) AS cnt
FROM asset_position
GROUP BY account_id, security_code, valuation_date
HAVING COUNT(*) > 1;
准确性与一致性
-- 准确性: 持仓数量或冻结数量为负
SELECT COUNT(*) AS negative_count
FROM asset_position
WHERE quantity < 0 OR frozen_quantity < 0;

-- 一致性: 持仓市值与总账余额按日核对
SELECT p.account_id, p.valuation_date
FROM asset_position p
JOIN account_balance b
  ON b.account_id = p.account_id
 AND b.biz_date = p.valuation_date
WHERE ABS(p.market_value - b.balance_amount) > 0.01;
时效性与有效性
-- 时效性: 最近 7 天估值数据是否到齐
SELECT MAX(valuation_date) AS latest_valuation_date
FROM asset_position
WHERE valuation_date >= CURRENT_DATE - INTERVAL 7 DAY;

-- 有效性: 证券代码不在证券字典中
SELECT DISTINCT p.security_code
FROM asset_position p
LEFT JOIN security_dict d
  ON d.security_code = p.security_code
WHERE d.security_code IS NULL;
SQL 是“探测器”,不是“修复器”。规则的价值是把异常暴露出来并留下证据;修复永远要回到上游源头,而不是在检查层打补丁。
05

数据质量监控与对账

闭环监控
质量监控闭环
定义规则阈值与频率
调度巡检批次内与批次后
指标看板行数、金额、空值率
分级告警提示或阻断发布
工单处置修复与复盘

对账的本质

对账是“用另一份可信来源交叉验证”。批次跑完不等于数据正确,还要拿上游文件、总账或清算结果来核对。

批次对账伪代码
上游文件 rows 与下游表记录 rows 对账:
1) 行数: 上游计数 == 下游计数
2) 金额: SUM(amount) 偏差 <= 0.01
3) 键集: 双方业务键集合相等, 差集即异常
4) 抽样: 对相同键的行做字段拼接并 md5, 两侧一致
全部通过 -> 批次标记 SUCCESS
任一失败 -> 进入对账异常队列并告警

对账的三个级别

级别比较内容频率能发现的问题
文件级行数、总金额、文件 MD5批次结束漏传、截断、整批重复
表级主键唯一、空值率、外键缺失日终加工错误、连接丢失
指标级净额、持仓市值、估值差额小时或日口径偏差、延迟累积

看板至少盯住四个数字

  • 行数趋势:突然变多或变少都可能是漏传或重复。
  • 关键金额:净额、持仓市值,偏差即告警。
  • 空值率:必填字段空值占比的基线变化。
  • 数据新鲜度:最新估值日距今天数,超过阈值说明延迟。
06

数据质量问题的根因定位

按层定位

四类根因与定位手段

根因常见表现定位手段
源头缺失上游系统未生成或生成不全核对源头表计数与上游版本号
传输丢失文件迟到、行数变少、部分分区缺失检查传输日志、文件 MD5 与送达时间
加工错误清洗、合并、汇总逻辑出错对照输入与输出,复算关键指标
口径分歧字段定义不同导致两边对不平查阅口径字典,逐字段比对定义
数据链路分层
源头数据产生
传输文件与消息到达
加工清洗与汇总
落地表与指标
消费报表与模型
定位顺序永远从下往上:先确认数据到底有没有进来,再怀疑加工逻辑,最后才是口径分歧。跳过前面直接改 SQL,往往是白忙一场。
07

与测试体系的衔接

测试视角

线上体检 + 出厂检验

监控和校验规则是“线上体检”,自动化测试是“出厂检验”。测试保证这次改动不破坏输入输出关系,监控保证线上每天都在正确数据上运行,两者互补。

数据管道测试伪代码
def test_日终持仓加工_正确汇总在途与冻结():
    input_trades = 样例交易流水(成交 2 笔, 冻结 1 笔)
    output = run_position_pipeline(input_trades)
    assert output.quantity == 2
    assert output.frozen_quantity == 1
    assert output.total_amount == Decimal("9999.99")
数据一致性测试伪代码
def test_持仓表与总账余额_同一估值日口径一致():
    positions = query("SELECT * FROM asset_position WHERE valuation_date = TODAY")
    balances = query("SELECT * FROM account_balance WHERE biz_date = TODAY")
    for pos in positions:
        bal = balances[pos.account_id]
        assert abs(pos.market_value - bal.balance_amount) <= 0.01
一致性测试要写清三件事:比什么、和谁比、允许多少偏差。含糊的断言等于没测。
08

AI 数据质量:模型可信的前提是数据可信

GIGO

从数据到模型

训练数据、线上特征、推理输入,任何一端被脏数据污染,模型表现都会失真。金融场景里,模型判断直接对应资金与风险,数据可信是不可妥协的前提。

三条底线

  • 训练与推理使用同一套字段口径。
  • 线上特征必须能回溯到原始数据。
  • 分布漂移要有告警与重训机制。
特征漂移检查
-- 近 7 天交易金额分布
SELECT AVG(amount) AS avg_amount,
       STDDEV(amount) AS std_amount,
       COUNT(*) AS cnt
FROM asset_trade
WHERE trade_time >= NOW() - INTERVAL 7 DAY;
-- 与训练分布比较, 偏差超过阈值触发漂移告警
09

练习与检查

综合练习

练习:为金融资产数据建立质量基线

  1. 挑选一张核心表(如 asset_position),列出全部字段与业务含义。
  2. 为六个维度各写出一条可执行的校验规则。
  3. 为准确性规则找到可信的上游对账来源。
  4. 为每条规则定义阈值、频率与责任人。
  5. 用异常样例验证规则会报警,用干净样例验证规则通过。
  6. 模拟一次上游漏传,观察监控与对账如何发现。
  7. 记录一次真实数据问题的根因定位过程,归类到四类根因之一。
  8. 为一条数据管道补充输入样例与期望输出的测试。

规则可落地

  • 六维度各有一条规则
  • 阈值、频率、责任人明确
  • 规则有异常样例验证
  • 误报能及时收敛调整

监控看得见

  • 看板含行数、金额、空值率
  • 对账失败能定位到层级
  • 告警有分级与接收人
  • 历史趋势可回溯

质量有闭环

  • 问题有根因记录
  • 规则随真实问题补强
  • 口径变化有文档
  • 数据管道有回归测试

你已经能把数据质量当作工程问题来管理。下一步,把这些校验规则接入 CI,让质量检查成为数据发布的一部分。

回到数据系统模块