突然发现仪表盘中的数据为0 ... ... ?

图片来自（极客时间-数据中台实战课）

由结果表顺着向上游排查，查了30分钟之后发现是某个dwd表的解析出了问题，部分脏数据影响了下游，导致没报错，但其实数据写入失败。

一套盘查下来用了半天，业务方也对数据部门感到呵呵。

这是个经典问题，暴露了数据质量不完善：

  • 业务方发现时间早于数据部门，客户满意度直线下降；
  • 出现问题后，数据部门无法快速定位，排查时间过长；
  • 故障没有对应的报警；

常见问题根源：

  • 业务源系统变更
  • 数据开发BUG （大多数）
  • 物理资源不足，任务失败
  • 运维故障，基础设施
    • Hadoop Bug

提升质量的方法：提前发现问题

  • 稽核校验任务
    • 根据出表结果，按业务规则，设计校验逻辑，确保数据完整性、一致性和准确性；
      • 规则： 数据有无， 数据值落在合理区间；
      • 规则未通过，承接报警策略

规则设计

规则的分类

完整性， 有无数据

一致性， 两个表当中 A表的a1 a2指标 可计算出B表的b1 b2 即跨表间存在的公式， 一致性依赖。

准确性，数据记录的正确性，如商品类目的格式，IP格式

唯一性，不应产生重复数据的表，出现了重复行。

及时性，数据生产的最晚接受时间 DDL。

规则分级

强规则，弱规则取决于业务上对该表出问题的容忍度。

比如和公司金钱有关的、核心指标有关的，都得设置为强规则（电话+短信+IM+ 邮件，能提醒的都用上）
反之采用弱规则。

如何衡量数据质量

凡事都得量化，才能做到优化。

怎样衡量数据仓库的数据质量，可以采用

🟥 6点30分钟核心报表生产率 （这里6点30分钟是一个虚时间，也可以定为5点30分，取决于业务）

🟦 稽核规则命中率， 不同规则对应的表负责人处理的报警次数，反向指标。

🟩 数据产品SLA， 反向指标。 如果指标超过9点还没产出，示为不可用。 每天之中将可用数据的占比计算出来，取补即为当天可用指标， 如99.9%

数据质量中心（Data Quality Center）

即为这样的定义稽核规则、控制报警、执行任务明细、指标打分和评级

DQC首页是质量大屏，展示当前任务的核心质量指标。 （上面的🟥🟦🟩 三级指标）

一些典型的数据故障

  • 协作事故
    • 跨部门， 服务端修改了上游数据（换库改表）
    • 同部门，集群内调整了运行参数