得物交易域数据仓库数据质量保障体系建设

目前数仓测试，划分成交易、增长、社区等多个模块，不同的数仓测试域，都会有一名测试人员负责跟进，根据每个版本每个域资源实际投入情况，组内会适当的调整资源，以满足日常迭代需要；单交易域这块，版本迭代需求数，通常都要并行支持多个，且随着公司业务的发展，从承接的需求复杂度，或验证的指标量，都会有所提升，面对如此庞大的数据体量，在有限的时间/人力资源情况下，如何制定测试策略，保障数据质量按时上线，对我们测试人员而言，无疑挑战性是非常大的。基于此，本篇主要介绍、梳理、总结了在数仓测试实践过程中常用的一些方法，希望在以后相关的测试工作中，对大家有所帮助，可以避点坑；,数仓交易域，数据测试范围涵盖了订单、履约、商家、商品、出价、库存、用户、寄存、财务、流量等多个模块，通常每个模块数仓这边都有维护一张或者多种对应的模型表。比如订单（ 子订单明细表），里面记录订单号，类型，状态，支付时间等基础信息；再比如履约（订单履约表），里面维护了订单号，商家，履约状态，未履约原因，未履约责任方等信息；,,数仓这边，会在现有模型口径的基础上，进行日常迭代调整，同时根据prd需求不同，也会相应的新增宽表、指标，以满足业务需求；比如我们近期做核心指标宽表，需要基于商品spu维度，统计商品首次上架时间，动销商品数、出价商品数、曝光/点击uv等，需要汇总商品，订单，出价，流量等多个模块组合数据；,在介入测试前，我们先简单的梳理下，数仓数据链路层次，自下到上，大致分为ods(源数据层)->dwd（数据清洗层）->dws(轻度汇总层)->ads/dm(数据应用层)，在生成最终结果表的过程中，也可能会使用到temp(临时层)和dim(维表层)，用于指标加工计算；,,一般而言，标准数仓分为 ODS,DWD,DIM,DWS,ADS 等，且每层分工不同,每层具体有哪些功能，下面有详细的描述，大家可以了解下，有个整体的认知，已经熟悉的同学这部分可以跳过；,ODS：存储原始业务数据,数据原封不动同步到到ODS,不做任何修改，并且备份，备份时可以压缩；,DWD：数据清洗，脱敏，规范化，一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联,代表业务最小粒度层。任何数据的记录都可以从这一层获取，为后续的DWS做准备。另外，在该层也会做一部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性；,DIM:    DWD同级别维度,比如时间维度、用户维度、权限维度、省份维度等；,DWS：又称数据集市或宽表。按照业务划分,比如订单，用户，商家，商品等，基于各个主题在加工和使用，进行轻度汇总,如统计各个主题7天，30天，90天的行为，用户购买行为，商品动销行为等，在DWD基础上关联DIM维度数据汇总，用于提供后续的业务查询，OLAP分析等；,ADS：要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、ClickHouse、Redis等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用,一般在DWS基础上生成指标,主题宽表,主要用于具体的业务服务,TEMP：每一层的计算都会有很多临时表，专设一个temp层来存储我们数据仓库的临时表,对于质量把控来说，最核心的主要在于两个部分，dws层和ads层，原因如下：,ods的源数据同步及dwd层的数据清洗，目前datawork已经有相对完善的工作机制，可以保证数据质量，测试几乎可以不投入资源；,大部分数据加工、处理都是在dws层/ads层完成，而且相对于其他层级而言，日常改动、迭代更为频繁，同时出现问题的风险也比较大；,正常项目常规的流程，分析业务和需求->制定测试方案和测试计划->设计测试用例和准备测试数据->测试执行→生成测试报告→验收上线，数仓需求类似但又有所区别，如在需求评审阶段，我们更关注指标口径对齐，在口径明确的前提下，落到prd文档，开发才可以依据进行开发，测试作为标准进行验证。,从版本时间上，分别从移交测试前、冒烟/测试阶段、预发阶段、生产阶段，每个阶段关注的点不同，具体如下：,,（1）移交测试前,指标口径对齐，举个非常简单的例子，统计商家半年以内全部品牌销售数量，测试前，如下口径点，都需要和产品/数分去沟通、明确；,,（2）冒烟/测试阶段,（3）预发阶段,（4）生产阶段阶段,（1）数分需求,有数分介入，需明确业务口径，对齐后，作为测试验数参考，走DQC验证；,如统计商家销售成交明细，已提供了明确的业务/技术口径，可以编写DQC脚本，和对应的数仓报表口径进行比对；,（2）回流需求,没有数分介入，产品往往只能给到业务口径，具体的技术口径一般情况下是提供不了的，这时就要依赖平时积累的测试口径，需要自己写sql比对，和数仓报表数据进行校验；,以交易域需求为例，数分，研发，测试都有梳理沉淀具体的口径文档，在口径不明确的情况下，可以借鉴：,,（1） 黑盒测试,开发移交后，我们根据表名，就可以开始初步的测试，类似冒烟，这个环节对业务的口径不需要非常清楚就可以进行；,（2）白盒测试,需要对开发的代码走读，check指标处理逻辑。同时测试也需要准备验证脚本，或者查找到可以作为验证参考的数据，便于口径核对，这个环节，对测试人员的指标口径沉淀有一定的要求。在发现指标数据存在差异的情况，需要协助开发人员一起定位差异原因，时常需要在现有的口径基础上，在数仓空间往上翻多层，或者一个指标定义不够清晰，需要自行去数分空间查找口径定义。另外，在测试通过后，需要编写相应的DQC脚本，及时监控生产数据质量。这些对测试来说，需要有一定的sql功底；,白盒测试阶段，常见的开发问题汇总,以下面为例，统计卖家任务发货当天的订单量，需加上id_del判断，剔除无效数据。,以下面为例，统计卖家历史订单量和gmv，因为数仓目前统计的是T+1的数据，所以需要过滤掉当天跨零点数据；,以下面为例，商家表同一个用户号可能有多条数据，如果主表根据用户号会导致结果数据膨胀；,以下面为例，在线出价商品缺货率=在线出价商品缺货数/在线商品出价数，需要加上分母为0/空的情况，给到默认值0；,如统计近7天_实际支付金额GMV指标，使用的是DATEADD函数，统计近7天数据，需往前推6天，对应的前置条件应调整为‘-6’,（1）DQC对比,适用场景：,例：卖家履约数据迁移需求为例，根据卖家id+履约统计时间为组合维度，校验迁移前后卖家履约率是否一致；,（2）多维度对比,适用场景：新增报表需要聚合多维度指标数据,例：卖家核心指标需求为例，需要统计在仓库存数、出价卖家数、提交订单量、履约订单量、笔单价等100+个指标值，每个指标都要在不同统计维度下，如卖家类型+三级类目+品牌、卖家类型+一级类目+品牌、卖家类型+一级类目等情况下计算相应的数据，同时又分为日，周，月维度报表，单一个出价卖家数指标就有3（时间维度）*9（统计维度）=27种情况，如果在加上指标个数100+的话，需要验证的指标条数就多达2700条，显然没有这么多资源去验证，用这种方法，可以大大的提升我们测试验证时效；,,（3）表间横向数据对比,例：订单费率迁移项目，费率迁移后，基于订单维度，订单侧t1表、t2表、t3表这3张表的，每笔跨境订单费率数据应该保持全部一致，如存在差异数据，需要拉出明细，和开发，关联方一一确认影响；,（4）表内横向数据对比,例1：同一个商品，正常来说，浏览量>=加入购物车>=生成订单>=支付订单>=完成交易，对于订单部分，实际业务下单量肯定大于支付量，编写sql如下：,例2:商家统计月内，应履约订单量满足以下条件，等于（实际履约量+超时未发货量+虚假量+鉴定未通过量+其他卖家原因而关闭的订单量）,这些字段都落履约表了，就可以直接对比，编写sql如下,（5）execl对比,例1：核心报表需求，多个迭代版本需要验证的新指标数有1000+，如果按照以前的方法，验证起来会非常吃力，需要编写的测试脚本，验证数据工作量都非常巨大，如果使用execl，对于口径明确的情况下，只需要一、两个简单的select脚本，就可以将数据指标数据放到表格里，通过自动的if函数做个判断就行，可以快速核对指标，且后续也方面开发对齐修复，数分验收起来，也可以大大的缩短时间；,例2：财务补贴需求，新增两个指标，平台实收操作服务费和平台实收技术服务费，看似非常简单的一个需求，但实际处理起来，需要涉及到10多个原有的财务指标关联计算，且指标之间又存在依赖关系，加上计算过程中涉及到乘除，在统计订单数据较多的情况下，很容易因为精度问题，导致最终结果存在失真情况。如果按照prd需求进行口径验证，测试要编写上千行代码，光脚本就要花费1天（整个需求测试估时：1.5天），在和开发报表数据做对比，因为都存在上述的失真情况，差异数据排查起来，需要把计算逻辑一层一层的比对，验证起来非常耗时；,但通过execl处理，只要将对应的计算因子数据放到里面，通过工具本身自带的函数，可以快速的得到预期结果；,不同行业有不同的评估数据质量的标准。一般来说，数据质量可以从完整性、准确性、一致性和及时性共四个角度进行评估。,目前线上数据质量监控，数仓测试这边大多是通过DQC（Data Quality Center）数据质量中心配置进行，通过配置数据质量校验规则，自动在数据处理任务过程中进行数据质量方面的监控，根据离线任务的运行情况实时决策是否告警、何时告警、告警方式、告警给谁；具体的配置，使用方式，数据部门已经有了非常详细的操作文档，我就不过多介绍，感兴趣的可以直接拿来看看；,数据校验的方式有多种多样，以上只是汇总了数仓测试过程中常用到的一些方法，实际应用中，还需要结合具体的需求，方法选取得当，可以起到事半功倍的效果。个人觉得，数据类测试，非常考验人的耐心，面对繁杂的指标，需要花费更多的时间，静下心来，去不断梳理、总结、沉淀，慢慢打磨形成一套可以作为自身验证标准的方法论，也只有在不断的熟悉本身业务的过程中，才能提升测试人员本身对数据敏感性，从而降低数据质量风险；,目前除了dqc生产配置，可以自动监控数据质量运行情况，日常迭代数仓测试过程，大多数情况还是通过人工去核对数据，在后续工作里，希望可以结合公司现有的业务，探索出更多可以提效的数据验证方法，测试比对工具，降低数据对比的成本，不断的完善现有的数据测试体系，持续保障数仓质量。