数仓链路保障体系与数据测试方法经验分享.docx

《数仓链路保障体系与数据测试方法经验分享.docx》由会员分享，可在线阅读，更多相关《数仓链路保障体系与数据测试方法经验分享.docx（20页珍藏版）》请在第一文库网上搜索。

1、数仓链路保障体系与数据测试方法经验分享导读有赞数据报表中心为商家提供了丰富的数据指标，包括30+页面，100+数据报表以及400+不同类型的数据指标，它们帮助商家更合理、科学地运营店铺，同时也直接提供分析决策方法供商家使用。并且，每天在跑的底层任务和涉及的数据表已经达到千级别。面对如此庞大的数据体系，作为测试如何制定质量保障策略呢？这篇文章将从：1有赞数据链路、2数据层测试、3 .应用层测试、4.后续规划这四个方面展开。一、有赞数据链路1、数据链路介绍首先介绍有赞的数据总体架构图:散据网关总体架构图数据统一服务点质量保位应用存储数据仓库9点质量保H基础平台自顶向下可以大致划分为应用服务层、数据

2、网关层、应用存储层、数据仓库，并且作业开发、元数据管理等平台为数据计算、任务调度以及数据查询提供了基础能力。以上对整体架构做了初步的介绍，对于质量把控来说，最核心的两个部分是：数据仓库以及数据应用部分。因为这两部分属于数据链路中的核心环节，相对于其他层级而言，日常改动也更为频繁，出现问题的风险也比较大。二、数据层测试1、整体概览首先，针对数据层的质量保障，可以分成三个方面：数据及时性、完整性、准确性。数据层测试数据准确性数据及时性数据完整性自身检查code review2、数据及时性数据及时性，顾名思义就是测试数据需要按时产出。及时性重点关注的三个要素是：定时调度时间、优先级以及数据deadl

3、ine。其中任务的优先级决定了它获取数据计算资源的多少,影响了任务执行时长。数据deadline则是数据最晚产出时间的统一标准，需要严格遵守。这三要素中，属于“普世规则”且在质量保障阶段需要重点关注的是：数据deadline。那么我们基于数据deadline,针对及时性的保障策略就可分为两种：监控离线数据任务是否执行结束。这种方式依赖于有赞作业开发平台的监控告警，若数据任务在deadline时间点未执行完成，则会有邮件、企微、电话等告警形式，通知到相应人员。IS止WW： 2021-Q5-13 00：00：00 J 2036-01-01 00：00：00.v7点作为统一散据产出deadline,

4、 4点+ 180分钟;7点授督用户:件 X X 电恬 X失K发量：件 wa X 电话XgWIseg*O 180分售%逑道x vo$.data0.teamTotalPvvo$.data0.orderUvv0响应断言：$.data0.orderAmountv0$.dataO.payUvvo$.data0.payAmountvo访客数0O浏览量0O下单人数0O下单金额0n支付人数0Q支付金额0O断言判断数据指标0,若等于0,则表示数据未产出其次我们可以关注失败、重试次数，当任务执行过程中出现多次失败、重试的异常情况，nJ以抛出告警让相关人员感知。这部分的告警是对deadline告警的补充，目前在有赞

5、作.业开发平台上也有功能集成。3、数据完整性数据完整性，顾名思义看数据是不是全，重点评估两点：数据不多、数据不少。数据不多：一般是检查全表数据、重要枚举值，看数据有没有多余、重复或者数据主键是否唯一。数据不少：一般是检查全表数据、重要字段（比如主键字段、枚举值、日期等），看字段的数值是否为空、为null等。可见数据完整性和业务本身关联度没有那么密切，更多的是数仓表的通用内容校验。所以从一些基础维度，我们可以将测试重点拆成表级别、字段级别两个方向。数据完整性袤级别袤行数袅大小分区行数分区大小字段级别非空唯一枚举数据有效性表级别完整性:全表维度，通过查看全表的总行数/表大小，若出现表总行数/总大小

6、不变或下降，说明表数据可能出现了问题。分区维度，通过查看当日分区表的数据行数/大小，若和之前分区相比差异太大（偏大或偏小），说明表数据可能出现了问题。目前有赞元数据管理平台已集成相关数据视图:字段含义历史趋势数据欣堡变更记录敬据成本质量提升形态报告30 天更新时刻：每日首次更新总行敬增量行效字段级别完整性:唯一性判断：保证主键或某些字段的唯一性，防止数据重复导致和其他表join之后数据翻倍，导致最终统计数据偏大。比如判断ods层订单表中的订单号是否唯一，编写sql：select count(ordcr_no), count (distinct order_no) from ods. xx_or

7、der若两者相等，则说明ordejno值是表内唯一的；否则说明ordejno表内不唯一，表数据存在问题。非空判断：保证重要字段非空，防止空数据造成和表join之后数据丢失，导致最终统计数据偏少。比如判断ods层订单表中的订单号是否出现null,编写sql：select count(*) from ods. xx_order where order_no is null若结果等于0,则说明order_no不存在null；若结果大于0,则说明order_no存在null值，表数据存在问题。枚举类型判断：保证枚举字段值都在预期范围之内，防止业务脏数据，导致最终统计结果出现遗漏/多余的数据类型。比如判

8、断ods层订单表中的shop_type字段中所有枚举值是否符合预期，编写sql：select shop_type from ods. xx_order group by shop_type分析查询结果是否满足预期，确保不会出现遗漏/多余的枚举类型。数据有效性判断：判断数据格式是否满足预期，防止字段的数据格式不正确导致数据统计的错误以及缺失。常见的有日期格式yyyymmdd。一旦出现数据完整性问题，对数据质量的影响很大。所以完整性策略更适用于。ds层，因为我们更期望从源头发现并解决数据不合理问题，及时止损，避免脏数据进入下游之后，数据污染扩大。另外，我们看到完整性校验内容逻辑简单，且比较固定，稍

9、微进行简单的抽象就能将其模板化。那么作为测试，我们更倾向于将数据完整性校验做成工具。目前有赞“数据形态工具”已经落地，下面给出我的一些思路：1.针对所有表来说，普世性的规则，比如表主键的唯一性。2.3.针对不同类型比如数值、String,枚举、日期格式类型，列举出常见的数据判断规则。4.5.给每项规则进行等级划分，比如表的主键不唯一，记为critical。String类型字段的空值比例大于70%,记为warn ingo6.7.根据表数据是否满足上述这些规则，最终落地一份可视化报告，测试人员可根据报告内容评估数据质量。报告解读通用规则总数/失败critical40/17规则详情1 .根据主键计算

10、数据不唯一，可能存在重复数据，请检查主键和数据2 .数值字段卜ds_id有null值3 .数值字段。bute_typeWnulKf4枚举字段ate_type的枚举值只有1种，枚举值为null5.数值字段a r*u jcycle有null值6枚举字段a r八cycle的枚举值只有1种，枚举值为null7.数值字段s t .tic scope有null!8枚举字段J；/_scope的枚举值只有1种，枚举值为null9枚举字段| 0的枚举值只有1种，枚举值为10 .字段caq ,)unt值都是011 .数值字段c it_buyer_id有null值12 .字段orc. . Fjnt值都是013 .数

11、值字段卜(、r_buyer_id有null值14 .数值字段卜冉.amount有null值15 .字段pay. : int值都是016 .数值字段口 /_buyer_id有 null 值17 .数值字段j_amoum有null值9/0warning校验失败的数据已在报告中分别以红、橙颜色标出，请关注。规则详细请戳，欢迎大家反馈补充。4、数据准确性数据准确性，顾名思义数据要“准确”。“准确”这个概念比较抽象，因为我们很难通过一个强逻辑性的判断，来说明数据有多准，大部分都存在于感性的认知中。所以准确性测试也是在数据质量保障过程中思维相对发散的一个方向。经过总结，我们可以从字段自身检查、数据横向对比

12、、纵向对比、code review等方面，去把控数据的准确性，这些测试点和业务的关联也比较密切。4.1 自身检查数据自身检查，是指在不和其他数据比较的前提下，用自身数据来检查准确的情况，属于最基本的一种检查。常见的自身检查包括：检查数值类指标大于0、比值类指标介于0-1范围。这类基础规则，同数据完整性，也可以结合“数据形态工具”辅助测试。举个例子，比如针对订单表，支付金额必然是大于等于0,不会出现负数的情况，编写sql：seiect count(pay_price) from dw. dws xx order where par = 20211025 and pay_price=下单人数，编写

13、sql：select kdt_id, goods_id, count(order_no), count(distinct buyer_id) from dw. dws_xx_orderwhere par = 5 20211025, group by kdt_id, goods_idhavingcount(order_no)count(distinct buyer_id)若查询结果不存在记录，则说明不存在 订单数下单人数，反向说明订单数二下单人数，则符合预期；否则若查询结果的记录大于0,则不符合预期。4.3 表间横向数据对比表间横向对比可以理解为两张表或多张表之间，其中具有业务关联或者业务含义一致的字段，可以用来做数据对比：同类型表之间对比：针对hive里的支付表A和支付表B,里面都有支付金额字段，那么同样维度下的表A.支付金额=表B.支付金额。多套存储之间对比：比如有赞数据报表中心针对支付表，应用层存储分别用到了 mysql和kylin,用作主备切换，那么相同维度下的kylin-表A.支付金额=mysql-表B.支付金额。多个系统之间对比：跨系统之间，比如有赞的数据报表中心和erm系统，两个系统都有客户指标数据，那么相同维度下的数据报表中心-表A.客户指标=erm-表B.客户指