返回数据系统模块
质量监控闭环
数据链路分层
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
练习与检查
综合练习练习:为金融资产数据建立质量基线
- 挑选一张核心表(如 asset_position),列出全部字段与业务含义。
- 为六个维度各写出一条可执行的校验规则。
- 为准确性规则找到可信的上游对账来源。
- 为每条规则定义阈值、频率与责任人。
- 用异常样例验证规则会报警,用干净样例验证规则通过。
- 模拟一次上游漏传,观察监控与对账如何发现。
- 记录一次真实数据问题的根因定位过程,归类到四类根因之一。
- 为一条数据管道补充输入样例与期望输出的测试。
规则可落地
- 六维度各有一条规则
- 阈值、频率、责任人明确
- 规则有异常样例验证
- 误报能及时收敛调整
监控看得见
- 看板含行数、金额、空值率
- 对账失败能定位到层级
- 告警有分级与接收人
- 历史趋势可回溯
质量有闭环
- 问题有根因记录
- 规则随真实问题补强
- 口径变化有文档
- 数据管道有回归测试
你已经能把数据质量当作工程问题来管理。下一步,把这些校验规则接入 CI,让质量检查成为数据发布的一部分。
回到数据系统模块