如何保障数仓的数据质量？

全文共 5168 个字，建议阅读 10 分钟

一、数据链路

数据链路介绍

二、数据层测试

1、整体概览

2、 数据及时性

• 监控离线数据任务是否执行结束。这种方式依赖于有赞作业开发平台的监控告警，若数据任务在deadline时间点未执行完成，则会有邮件、企微、电话等告警形式，通知到相应人员。

• 检查全表条数或者检查分区条数。这种方式依赖接口自动化平台，通过调用dubbo接口，判断接口返回的数据指标是否为0，监控数据是否产出。

3、数据完整性

• 数据不多：一般是检查全表数据、重要枚举值，看数据有没有多余、重复或者数据主键是否唯一。
• 数据不少：一般是检查全表数据、重要字段（比如主键字段、枚举值、日期等），看字段的数值是否为空、为null等。

• 全表维度，通过查看全表的总行数/表大小，若出现表总行数/总大小不变或下降，说明表数据可能出现了问题。
• 分区维度，通过查看当日分区表的数据行数/大小，若和之前分区相比差异太大（偏大或偏小），说明表数据可能出现了问题。

• 唯一性判断：保证主键或某些字段的唯一性，防止数据重复导致和其他表join之后数据翻倍，导致最终统计数据偏大。

select 
count(order_no)
,count(distinct order_no) 
from ods.xx_order

• 非空判断：保证重要字段非空，防止空数据造成和表join之后数据丢失，导致最终统计数据偏少。

select 
count(*) 
from ods.xx_order 
where order_no is null

• 枚举类型判断：保证枚举字段值都在预期范围之内，防止业务脏数据，导致最终统计结果出现遗漏/多余的数据类型。

select shop_type from ods.xx_order group by shop_type

• 数据有效性判断：判断数据格式是否满足预期，防止字段的数据格式不正确导致数据统计的错误以及缺失。常见的有日期格式yyyymmdd。

1. 针对所有表来说，普世性的规则，比如表主键的唯一性。
2. 针对不同类型比如数值、String、枚举、日期格式类型，列举出常见的数据判断规则。
3. 给每项规则进行等级划分，比如表的主键不唯一，记为critical。String类型字段的空值比例大于70%，记为warning。
4. 根据表数据是否满足上述这些规则，最终落地一份可视化报告，测试人员可根据报告内容评估数据质量。

4、数据准确性

4.1 自身检查

select 
count(pay_price) 
from 
dw.dws_xx_order 
where par = 20211025 and pay_price<0

4.2 表内横向数据对比

select 
kdt_id
,goods_id
,count(order_no)
,count(distinct buyer_id) 
from dw.dws_xx_order
where par = '20211025'
group by kdt_id,goods_id
having count(order_no)<count(distinct buyer_id)

4.3 表间横向数据对比

• 同类型表之间对比：针对hive里的支付表A和支付表B，里面都有支付金额字段，那么同样维度下的 表A.支付金额 = 表B.支付金额。
• 多套存储之间对比：比如有赞数据报表中心针对支付表，应用层存储分别用到了mysql和kylin，用作主备切换，那么相同维度下的kylin-表A.支付金额 = mysql-表B.支付金额。
• 多个系统之间对比：跨系统之间，比如有赞的数据报表中心和crm系统，两个系统都有客户指标数据，那么相同维度下的数据报表中心-表A.客户指标 = crm-表B.客户指标。

• 输入两张表，分别设置两表的主键。
• 输入两张表中需要对比的字段，且设置对比的运算符，比如>、=、<。
• 根据设置的规则，最终数据对比通过、不通过的记录，落地一份可视化报告，测试人员可根据报告内容评估数据质量。

4.4 纵向数据对比

4.5 code review

• 需求1：（错误示例）统计时间内店铺内所有用户的支付金额。问题所在：需求描述太过于简洁，没有阐述清楚数据统计的时间维度以及过滤条件，导致统计口径不清晰，要求产品明确口径。
• 需求2：（正确示例）有赞全网商家域店铺维度的离线支付金额。支持自然日、自然周、自然月。统计时间内，所有付款订单金额之和（剔除抽奖拼团、剔除礼品卡、剔除分销供货订单）。

• 关联表使用 outer join 还是 join，要看数据是否需要做过滤。
• 关联关系 on 字句中，左右值类型是否一致。
• 关联关系如果是1：1，那么两张表的关联键是否唯一。如果不唯一，那么关联会产生笛卡尔导致数据膨胀。
• where 条件是否正确过滤，以上述需求为例子，关注sql中是否正确剔除抽奖拼团、礼品卡和分销供货订单。

• 可累加指标：比如支付金额，浏览量等，可以通过简单数值相加来进行统计的指标，针对这类指标，sql中使用的函数一般是sum。
• 不可累加指标：比如访客数，不能通过简单相加，而是需要先去重再求和的方式进行统计，针对这类指标，sql中一般使用count(distinct )。

• 是否支持重跑。等价于看插入时是否有overwrite关键字，如果没有该关键字，重跑数据（多次执行该工作流）时不会覆盖脏数据，而是增量往表插入数据，进而可能会导致最终数据统计翻倍。
• 插入的数据顺序和被插入表结构顺序是否完全一致。我们要保证数据字段写入顺序没有出错，否则会导致插入值错乱。

三、应用层测试

1、整体概览

2、 降级策略

• 在页面新增数据表的时候，需求、技术评审阶段确认是否需要支持“蓝条”的功能，属于“测试左移”。

• 测试比率类指标时，关注被除数 = 0 的特殊场景。在后端code review、测试页面功能阶段，关注该点。目前有赞针对这种情况，前端统一展示的是“-”。

3、 主备策略

4、 数据安全

四、后续规划

目前针对sql code review的方式主要靠人工，我们计划把一些基础的sql检查，比如insert into检查，join on条件的唯一性检查、字段插入顺序检查等作成sql静态扫描，整合到大数据测试服务中，并且赋能给其他业务线。

据统计，99%的数据大咖都关注了这个公众号

👇