数据质量保障建设（一）：测试分层和数仓造数

在数据测试中，需要划分好测试边界，数据质量保障除了要关注数据层的测试（指标/模型/数仓表），更不可忽视的是数仓是整条业务链路中的一环，对接全域业务提供的查询能力及造数能力亦是需要重点关注的地方。数据产品的数据来源是严选的业务链路，产出的数据也是要反哺业务链路，最终实现推动业务发展。以下从数据测试能力分层、数仓造数能力展开严选数据质量保障建设之路的介绍。

1 前言

严选的数据产品，是依托于严选电商业务链路，通过离线和实时两种数据处理方式提供分析型数据，并最终希望实现数据驱动业务发展。先来看下严选的数据产品的架构层级图：从层级图可以看出，数据产品应用是最上层的数据表现层。从数据产品层级图，我们可以对比下，数据产品测试跟应用测试的流程区别到底在哪儿： 非数据产品的测试流程一般是： 数据产品的测试流程则为： 从以上链路可以看出，数据产品的测试链路更长，复杂度也多了一块数据链路的测试。

2 数据产品测试的现状及痛点 

根据目前现状，严选数据产品测试存在的一些明显的痛点： 数据质量保障的测试不管从业务需求和产品定位上都应该是优先级更高的测试线路，要对数据质量本身提供更高的关注度。 数据指标正确性的人工核对的方式也让QA很难更好的把控整体的数据质量，自动化的回归能力也不具备。 因为数据敏感性的问题，数据产品相关的测试工作（如：接口测试）只能通过本地部署的一些测试框架来支持，一直没有平台化。 严选数仓一直没有测试环境，目前所有数据产品项目的测试环境都是使用的生产数据，业务线测试环境中涉及的模型数据不能展示及查询。 

3 脱敏服务原理及使用 

3.1 脱敏原理 

从业务使用角度，我们希望脱敏服务能提供怎样的能力： 采用SDK+独立脱敏服务架构，具备多种灵活自定义脱敏方式； 支持黑白名单配置的定制化脱敏需求； 即插即用的轻量级开发。 基于以上几个方面的原则，我们经过一段时间的调研，最终敲定了脱敏服务的架构：未接入脱敏服务：正常的业务流程是后端服务通过dqs从数仓模型中查询数据，经过一定的聚合处理，返回给前端展示。接入脱敏服务：应用后端先通过dqs从数仓中查询数据，此时应用中嵌入的sdk会通过openid或者ntess解析中拿到的uid和请求的url返回给脱敏服务，脱敏服务，根据是否uid在脱敏白名单中，来决定是不是继续走脱敏服务。当命中uid白名单，服务会继续判断要对应用中的哪些返回（接口粒度）做脱敏，做何种具体规则的脱敏。也可以对接口中的字段粒度做是否脱敏的黑名单配置，灵活度很高。从配置文件详细解读脱敏服务流程： 识别要脱敏的账号（白名单） 支持接口粒度的脱敏配置，支持正则（白名单） 识别需要脱敏的数据类型（int percent double long） 识别脱敏字段黑名单（黑名单） 脱敏字段的脱敏规则设定 

3.2 适用场景及脱敏效果 

数据脱敏服务采用SDK+独立脱敏服务架构，具备多种灵活自定义脱敏方式。目前已在伏羲&VIPAPP落地，且同时具有对PC端和app端脱敏的能力。数据敏感产品线已具备测试分层能力，并可支持前端开发使用外包人员。亦可支持，其他同类型的数据产品项目接入，可以灵活拔插。

3.3 在实际业务线上面的数据脱敏效果 

伏羲页面数据指标趋势图脱敏前后对比：脱敏前：脱敏后：4 脱敏服务演进之数仓造数服务 

脱敏服务，它是脱敏，但是我们希望它不仅仅是脱敏。它本质上是Mock能力的一部分，但是它从线上引流生产数据来做Mock的思想是可以指导我们在测试环境的造数能力上再上一个台阶。数据脱敏服务的持续演进，正式解决了上述问题，当前在严选已经提供了一站式生产数据引流下行及脱敏能力，结合数据工厂，MOCK中心对于各业务线数据相关场景提供了更丰富和贴近线上的造数能力。

4.1 什么样的问题催生了数仓造数服务的诞生 

严选数仓没有对接全业务域的测试环境，测试环境的数据请求数仓的线上环境，由于测试环境和生产数据不一致的原因，无法从数仓查询到数据返回，阻塞了进一步的测试环境的造数和测试流程。目前业务域获取数仓数据的返回，一般有三种方式： 屏蔽掉数仓的接口，开发额外实现mock开关以及mock相关代码，打开mock开关，在Apollo中配置相关测试数据进行测试，但是这种方式需要额外开发并会将部分测试代码带到线上。 使用测试环境和线上环境均存在的数据，比如skuid，记录下来后续持续使用。但是会有测试覆盖度的问题，且部分场景需要数据侧及算法侧的特殊配置。 通过数据开发同学配合,在数仓仓颉(数仓模型管理系统)建个测试模型，手工新建模型字段，按照数据格式造数据，然后去猛犸新建同步任务，将hive表同步到mysql，然后通过统一查询服务(dqs)来查询数据。 所以，我们希望按照脱敏服务线上引流然后修改数据的思路，针对当前业务某些链路上对数仓查询的功能，确保测试环境请求数仓统一查询服务（dqs）的每次查询都有对应的报文信息返回。同时，数仓查询落地到具体的业务链路，带有业务特色之后，亦能支持特殊业务规则下数仓数据的查询场景的造数及编排能力。

4.2 数仓造数服务

统一查询服务（dqs）是整个数仓为全域业务提供数仓数据查询的唯一出口。统一查询服务提供http形式的查询，可使用封装的SDK包来调用；把离线、实时等不同数据源的集市数据抽象为模型维度和指标，对各业务提供统一的数据查询服务。基本原理图如下：业务域通过dqs查询数仓数据的场景分为三大类： 全量查询类，没有具体查询字段。 特定模型字段值的查询（比如从模型dm_yx_sku_extend_info中查询skuId=10008650的数据），此时需要测试环境和线上环境数据一致从数仓获取数据（测试环境数据请求数仓线上环境）。 联动依赖查询下的场景，测试环境从数仓查询后，需要通过查询结果继续反查测试环境数据进行后续操作。 基于这些查询场景，我们对数仓造数服务需要提供的能力也就清楚了。第一，希望先解决测试环境请求线上，没有数据返回的问题；第二，通过修改返回的数据让线上环境查询数据跟测试环境对应起来；第三，支持有关联关系的多模型查询数据的编排能力。

4.2.1 数仓造数服务原理 原理图：方案思路：简述：输入基础信息-->发送查询模型请求-->脱敏线上模型数据--> Mock数据修改--> 生成规则链接替换dqs请求地址-->数据在测试环境回显① 业务方在严选数据工厂--数仓规则入口，输入需要查询的模型标识、字段，数据条数。② 首先根据输入的模型，select all查询到模型对应的全部的数据（如非首次查询，数仓造数服务首先缓存上次查询及修改结果，直接返回，不走后续查询链路）。③ 拉取线上模型数据后，进行数据脱敏后返回查询的模型数据和报文信息。④返回的模型数据及报文展示在数据工厂的数仓规则中，均支持根据实际业务场景修改为测试环境的测试数据。⑤数据修改完成，将生成的规则链接在接入业务系统中apolloy中替换DQS的请求地址。⑥业务系统中对应该查询模型的功能模块，会展示mock规则中保存的数据。4.2.2 适用场景 单模型查询，数据返回

①规则内单模型

②规则内多个模型配置（模型间无关联关系）

多模型查询

① 规则内查询的多个模型间有字段的关联关系

（以下截图中，字段关联关系不反应实际业务场景；仅表示支持多模型关联查询）

4.2.3 实际落地场景举例 

以严选采购系统举例，看下实际测试环境的mock数据回显情况：首先看下数仓模型规则的配置情况（截图数据均被脱敏）：规则中查询的数据（所有查询的字段均可在规则中修改，来支持测试环境的不同场景的造数要求），在采购系统测试环境的回显情况看下图（数据已脱敏）：4.2.4 带来的收益 

目前数仓造数服务完成跟严选主站和供应链的部分应用联调的接入，部分业务已经在线上稳定使用中。 人工造数时间节省目前秒级可以完成从数仓拉取任何模型任意数量的数据。也支持批量数据导入导出进行测试环境造数。按照之前在数仓构造测试模型-造数据-建同步任务的流程步骤，保守估计人力花费至少在一小时（不考虑部分模型的字段可能超过200+的情况），提效超过1000倍。 测试环境成本搭建节省目前数仓生产环境机器为330台，每台折旧3万左右，为990万。测试环境按照线上环境1/10比例缩减，每年机器上节约将近100万，同时也节省了其他人力维护的成本。 

5 总结 

之前应用测试的经验让我深刻感受到越是复杂的业务系统、模块越多，每个模块耦合关系，整个流程的造数，QA无疑是最清楚整个流程链路的人，在整个项目中的角色就更不可或缺。同样在数据测试中，仍然需要划分好测试边界，数据测试除了要关注数据层的测试（指标/模型/数仓表），更不可忽视的是数仓是整条业务链路中的一环，对接全域业务提供的查询能力及造数能力亦是需要重点关注的地方。数据产品的数据来源是严选的业务链路，产出的数据也是要反哺业务链路，最终实现推动业务发展。本文由作者授权严选技术团队发布