ARTICLE / 2 MIN READ
大数据平台的数据质量与可回补设计
把完整性、唯一性、及时性和对账变成每个批次都能执行的质量门禁。
数据量越大,偶发错误越容易变成长期错误。质量治理不能只靠人工抽查,而要让每个批次在进入下游前完成自动校验并留下证据。
四类基础规则
- 完整性:关键字段非空,分区和批次齐全。
- 唯一性:业务主键和事件 ID 不重复。
- 一致性:金额、状态和维度关系符合约束。
- 及时性:数据在承诺时间内到达并被处理。
质量规则应带上严重等级。关键指标失败时阻断发布,非关键字段异常可以隔离并告警。
CDC 的去重
CDC 消息可能重复、乱序或延迟。目标表需要保存 source_position、event_time 和版本字段,按业务主键选择最新合法版本。不能仅按到达时间覆盖,否则迟到旧事件会回退状态。
批次校验与对账
输入清单 -> 行数/大小校验
-> Schema 校验
-> 主键去重
-> 业务规则
-> 与来源系统对账
-> 发布成功快照
对账项包括行数、金额、状态分布、最大最小时间和抽样哈希。差异要关联到批次和任务版本,方便定位是源头变化还是加工逻辑问题。
可回补
所有任务都要能按日期、租户或事件范围重跑。回补使用临时分区和批次号,校验通过后再原子替换。下游汇总按受影响范围重新计算,不能把回补数据简单追加。
数据血缘
血缘至少记录来源表、字段映射、转换版本、下游任务和负责人。字段删除、口径变化或表下线前,先查看影响面并通知使用方。
运营视角
质量平台要有失败批次、规则趋势、延迟分位数、异常字段 Top、修复耗时和未关闭事件列表。治理的结果不是多出一套报表,而是减少错误数据被消费的概率,并缩短发现到修复的时间。
GITHUB DISCUSSION
评论与回复
评论保存在 GitHub Discussions,登录 GitHub 后即可参与,发布和回复都在本页完成。
评论区进入视口后自动加载。