关于数据仓库:如何保障数仓数据质量

导读

有赞数据报表核心为商家提供了丰盛的数据指标，包含 30+ 页面，100+ 数据报表以及 400+ 不同类型的数据指标，它们帮忙商家更正当、迷信地经营店铺，同时也间接提供剖析决策办法供商家应用。并且，每天在跑的底层工作和波及的数据表曾经达到千级别。

面对如此宏大的数据体系，作为测试如何制订品质保障策略呢？这篇文章将从：1. 有赞数据链路、2. 数据层测试、3. 应用层测试、4. 后续布局这四个方面开展。

数仓建设保姆级教程 PDF 文档

一、有赞数据链路

1、数据链路介绍

首先介绍有赞的数据总体架构图：

自顶向下能够大抵划分为应用服务层、数据网关层、利用存储层、数据仓库，并且作业开发、元数据管理等平台为数据计算、任务调度以及数据查问提供了根底能力。

以上对整体架构做了初步的介绍，对于品质把控来说，最外围的两个局部是： 数据仓库以及数据利用局部 。因为这两局部属于数据链路中的外围环节，绝对于其余层级而言，日常改变也更为频繁，呈现问题的危险也比拟大。

二、数据层测试

1、整体概览

首先，针对数据层的品质保障，能够分成三个方面：数据及时性、完整性、准确性。

2、数据及时性

数据及时性，顾名思义就是测试数据须要按时产出。及时性重点关注的三个因素是： 定时调度工夫、优先级以及数据 deadline。其中工作的优先级决定了它获取数据计算资源的多少，影响了工作执行时长。数据 deadline 则是数据最晚产出工夫的统一标准，须要严格遵守。

这三要素中，属于“ 普世规定 ”且在品质保障阶段须要重点关注的是：数据 deadline。那么咱们基于数据 deadline，针对及时性的保障策略就可分为两种：

• 监控离线数据工作是否执行完结。这种形式依赖于有赞作业开发平台的监控告警，若数据工作在 deadline 工夫点未执行实现，则会有邮件、企微、电话等告警模式，告诉到相应人员。

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

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

3、数据完整性

数据完整性，顾名思义看数据是不是全，重点评估两点：数据不多、数据不少。

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

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

表级别完整性：

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

目前有赞元数据管理平台已集成相干数据视图：

字段级别完整性：

• 唯一性判断：保障主键或某些字段的唯一性，避免数据反复导致和其余表 join 之后数据翻倍，导致最终统计数据偏大。

比方判断 ods 层订单表中的订单号是否惟一，编写 sql：

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

若两者相等，则阐明 order\_no 值是表内惟一的；否则阐明 order\_no 表内不惟一，表数据存在问题。

• 非空判断：保障重要字段非空，避免空数据造成和表 join 之后数据失落，导致最终统计数据偏少。

比方判断 ods 层订单表中的订单号是否呈现 null，编写 sql：

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

若后果等于 0，则阐明 order\_no 不存在 null；若后果大于 0，则阐明 order\_no 存在 null 值，表数据存在问题。

• 枚举类型判断：保障枚举字段值都在预期范畴之内，避免业务脏数据，导致最终统计后果呈现脱漏 / 多余的数据类型。

比方判断 ods 层订单表中的 shop\_type 字段中所有枚举值是否合乎预期，编写 sql：

select shop_type from ods.xx_order group by shop_type

剖析查问后果是否满足预期，确保不会呈现脱漏 / 多余的枚举类型。

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

一旦呈现数据完整性问题，对数据品质的影响很大。所以完整性策略更实用于 ods 层，因为咱们更冀望从源头发现并解决数据不合理问题，及时止损，防止脏数据进入上游之后，数据净化扩充。

另外，咱们看到完整性校验内容逻辑简略，且比拟固定，略微进行简略的形象就能将其模板化。那么作为测试，咱们更偏向于将数据完整性校验做成工具。目前有赞“数据状态工具”曾经落地，上面给出我的一些思路：

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

4、数据准确性

数据准确性，顾名思义数据要“精确”。“精确”这个概念比拟形象，因为咱们很难通过一个强逻辑性的判断，来阐明数据有多准，大部分都存在于理性的认知中。所以准确性测试也是在数据品质保障过程中思维绝对发散的一个方向。

通过总结，咱们能够从字段本身查看、数据横向比照、纵向比照、code review 等方面，去把控数据的准确性，这些测试点和业务的关联也比拟亲密。

4.1 本身查看

数据本身查看，是指在不和其余数据比拟的前提下，用本身数据来查看精确的状况，属于最根本的一种查看。常见的本身查看包含：查看数值类指标大于 0、比值类指标介于 0 - 1 范畴。这类根底规定，同数据完整性，也能够联合“数据状态工具”辅助测试。

举个例子，比方针对订单表，领取金额必然是大于等于 0，不会呈现正数的状况，编写 sql：

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

若后果为 0，阐明领取金额都是大于 0，满足预期；否则若 count 后果大于 0，阐明数据存在问题。

4.2 表内横向数据比照

表内横向比照能够了解为同一张表内，业务上相关联的两个或多个字段，他们存在肯定的逻辑性关系，那么就能够用来做数据比照。

比方针对订单表，依据理论业务剖析易得：针对任何一家店铺的任意一款商品，都满足订单数 >= 下单人数，编写 sql：

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)

若查问后果不存在记录，则阐明不存在 订单数 \< 下单人数，反向阐明订单数 >= 下单人数，则合乎预期；否则若查问后果的记录大于 0，则不合乎预期。

4.3 表间横向数据比照

表间横向比照能够了解为两张表或多张表之间，其中具备业务关联或者业务含意统一的字段，能够用来做数据比照：

• 同类型表之间比照：针对 hive 里的领取表 A 和领取表 B，外面都有领取金额字段，那么同样维度下的 表 A. 领取金额 = 表 B. 领取金额。
• 多套存储之间比照：比方有赞数据报表核心针对领取表，应用层存储别离用到了 mysql 和 kylin，用作主备切换，那么雷同维度下的 kylin- 表 A. 领取金额 = mysql- 表 B. 领取金额。
• 多个零碎之间比照：跨零碎之间，比方有赞的数据报表核心和 crm 零碎，两个零碎都有客户指标数据，那么雷同维度下的数据报表核心 - 表 A. 客户指标 = crm- 表 B. 客户指标。

咱们深度分析数据横向比照的底层逻辑，实质就是两张表的不同字段，进行逻辑运算符的比拟，也比拟容易形象成工具。目前有赞“数据比对工具”曾经落地，上面给出我的一些思路：

• 输出两张表，别离设置两表的主键。
• 输出两张表中须要比照的字段，且设置比照的运算符，比方 >、=、\<。
• 依据设置的规定，最终数据比照通过、不通过的记录，落地一份可视化报告，测试人员可依据报告内容评估数据品质。

4.4 纵向数据比照

纵向比照就是上下游的数据比拟，目标是确保重要字段在上下游的加工过程中没有呈现问题。

比方数仓 dw 层存在订单的明细表，数据产品 dm 层存在订单数的聚合表，那么二者在雷同维度下的数据统计后果，应该保持一致。

4.5 code review

首先，在进行 code review 之前的需要评审阶段，咱们先要明确数据统计的具体口径是什么，上面举两个理论的需要例子。

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

明确需要之后，上面具体介绍 code review 的一些常见关注点：

1）关联关系 \& 过滤条件

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

2）指标的统计口径解决

数据指标的统计波及到两个基本概念：

• 可累加指标：比方领取金额，浏览量等，能够通过简略数值相加来进行统计的指标，针对这类指标，sql 中应用的函数个别是 sum。
• 不可累加指标：比方访客数，不能通过简略相加，而是须要先去重再求和的形式进行统计，针对这类指标，sql 中个别应用 count(distinct)。

3）insert 插入数据

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

三、应用层测试

1、整体概览

根本的前端页面 + 服务端接口测试，和个别业务测试关注点是统一的，不再赘述。本篇重点开展“数据利用“测试须要额定关注的中央。

2、降级策略

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

蓝条介绍：有赞告知商家离线数据尚未产出的页面顶部蓝条，其中的“产出工夫”= 以后拜访工夫 + 2 小时，动静计算失去。

• 测试比率类指标时，关注被除数 = 0 的非凡场景。在后端 code review、测试页面性能阶段，关注该点。目前有赞针对这种状况，前端对立展现的是“-”。

3、主备策略

遇到有主备切换策略时，测试过程中留神数据失常双写，且通过配置，取数时能在主备数据源之间切换。

4、数据安全

关注数据查问的权限管控，重点测试横向越权、纵向越权的场景。

四、后续布局

目前在理论我的项目的数据准确性比照中，数据比照工具因为暂不反对 sql 函数，所以只能代替 50\% 的手工测试，一些简单的横向和纵向数据比照还是须要编写 sql。后续打算反对 sum、count、max、min 等 sql 函数，把工具覆盖范围晋升到 75\% 以上，大大降低数据比照的老本。

目前“数据状态报告”、“数据比照工具”更多的使用我的项目测试当中，后续打算将状态检查和数据比照做成线上巡检，将自动化和数据工具相结合，继续保障数仓表的品质。

目前针对 sql code review 的形式次要靠人工，咱们打算把一些根底的 sql 查看，比方 insert into 查看，join on 条件的唯一性查看、字段插入程序查看等作成 sql 动态扫描，整合到大数据测试服务中，并且赋能给其余业务线。

参考

数仓建设保姆级教程 PDF 文档