数仓链路保障体系与数据测试方法

1.数据链路介绍

应用服务层、数据网关层、应用存储层、数据仓库，并且作业开发、元数据管理等平台为数据计算、任务调度以及数据查询提供了基础能力。

对于质量把控来说，最核心的两个部分是：数据仓库以及数据应用部分。因为这两部分属于数据链路中的核心环节，相对于其他层级而言，日常改动也更为频繁，出现问题的风险也比较大。

2.数据层测试

数据层的质量保障，可以分成三个方面：数据及时性、完整性、准确性。

2.1 数据及时性

测试数据需要按时产出。

定时调度时间、优先级以及数据deadline。其中任务的优先级决定了它获取数据计算资源的多少，影响了任务执行时长。数据deadline则是数据最晚产出时间的统一标准，需要严格遵守。

数据deadline是最重要的一环: 针对deadline, 及时性的保障策略分为两种:

1. 监控离线数据任务是否执行结束。这种方式依赖于有赞作业开发平台的监控告警，若数据任务在deadline时间点未执行完成，则会有邮件、企微、电话等告警形式，通知到相应人员。
2. 检查全表条数或者检查分区条数。这种方式依赖接口自动化平台，通过调用dubbo接口，判断接口返回的数据指标是否为0，监控数据是否产出。

其次我们可以关注失败、重试次数，当任务执行过程中出现多次失败、重试的异常情况，可以抛出告警让相关人员感知。这部分的告警是对deadline告警的补充，目前在有赞作业开发平台上也有功能集成。

2.2 数据完整性

• 数据不多：一般是检查全表数据、重要枚举值，看数据有没有多余、重复或者数据主键是否唯一。

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

可见数据完整性和业务本身关联度没有那么密切，更多的是数仓表的通用内容校验。所以从一些基础维度，我们可以将测试重点拆成表级别、字段级别两个方向。

表级别完整性：

• 全表维度，通过查看全表的总行数/表大小，若出现表总行数/总大小不变或下降，说明表数据可能出现了问题。

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

字段级别完整性：

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

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

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

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

一旦出现数据完整性问题，对数据质量的影响很大。所以完整性策略更适用于ods层，因为我们更期望从源头发现并解决数据不合理问题，及时止损，避免脏数据进入下游之后，数据污染扩大。

数据完整性作为一个工具:

• 针对所有表来说，普世性的规则，比如表主键的唯一性。

• 针对不同类型比如数值、String、枚举、日期格式类型，列举出常见的数据判断规则。

• 给每项规则进行等级划分，比如表的主键不唯一，记为critical。String类型字段的空值比例大于70%，记为warning。

• 根据表数据是否满足上述这些规则，最终落地一份可视化报告，测试人员可根据报告内容评估数据质量。

2.3 数据准确性

3.应用层测试

基本的前端页面 + 服务端接口测试，和一般业务测试关注点是一致的

4.后续规划

目前在实际项目的数据准确性对比中，数据对比工具因为暂不支持sql函数，所以只能代替50%的手工测试，一些复杂的横向和纵向数据对比还是需要编写sql。后续计划支持sum、count、max、min等sql函数，把工具覆盖范围提升到75%以上，大大降低数据对比的成本。

目前“数据形态报告”、“数据对比工具”更多的运用项目测试当中，后续计划将形态检查和数据对比做成线上巡检，将自动化和数据工具相结合，持续保障数仓表的质量。

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