解决大数据测试痛点 质量监控平台DQ揭秘

今天跟大家分享，大数据部门数据测试的一些事儿~

数据测试VS应用测试

数据测试，顾名思义是针对数据进行测试，目前被测数据主要是来自于数仓ETL的数据。

数据测试与应用测试相比有一些显著不同，主要体现在：

测试用例：应用测试的测试用例一个用例覆盖一个场景，而数据测试的一个用例更趋近于覆盖一个字段、一组互相之前有关系的字段和一类指标；

处理逻辑：应用测试的项目处理逻辑一般有需求说明文档或者设计文档，而数据测试的逻辑一般都是通过分析代码得到；

测试内容：应用测试的测试内容主要在功能上，而数据测试除了要测试ETL过程的正确，还需要测试源数据和最终数据在业务上是否正确；

测试范围：应用测试的测试范围为每一类场景，而数据测试的测试范围为每一条数据。

如何展开数据测试

测试范围和测试内容决定了每天要测试的数据量巨大，人工抽查数据的方式很难覆盖到所有场景，所以数据测试基本上由测试脚本来执行，在设计脚本的时候主要会考虑以下指标：

数据量是否正确

记录是否唯一

空字符串是否替换为null值

必填项是否有null值

数据的边界是否正确

数据的逻辑转换是否正确

数据的限制条件是否正确

数据间的业务逻辑关系是否成立

当所有的测试SQL都执行通过后，只能代表当天的数据没有问题，但是每天的基础数据都在发生变化，只验证一天的数据并不能代表未来的数据都正确。

数据质量监控平台DQ系统

为了能够每日进行全量的数据回归测试，我们开发了数据质量监控平台DQ系统。

在DQ中，我们定义了3种对象：

INDEX：INDEX是DQ系统中最细的粒度，可以理解为传统测试中的测试用例，一个INDEX通常由两段测试SQL组成，分别对应测试用例中的预期结果和实际结果，DQ系统会分别执行这两段SQL，并给出相应的比较结果；

TABLE：为了方便对INDEX进行管理，我们在指标上层加了一层TABLE，每一个INDEX都必须归属于一个TABLE下面，不然则不能提交（运行INDEX时，会需要TABLE信息做一些校验）这里的TABLE和数仓中的数据表存在一一对应关系，所以我们的TABLE也直接引用数仓中的TABLENAME；

JOB：JOB为DQ系统中的调度任务的单位，对应着一批INDEX，这些INDEX可以是属于同一个table，也可以属于不同table，并且JOB也负责定义运行的频次和运行的时间。

DQ系统运行流程

如下图，测试人员在开发完测试SQL后，并在DQ系统中配置对应的JOB后，DQ会根据定时任务启动JOB，然后去MYSQL找到这个JOB下所有配置的INDEX并取出对应测试SQL，分多个线程放到HADOOP集群上并行运行。

每个线程会单独运行一个测试SQL，在运行之前会进行一系列逻辑检查，如果不符合规则会跳过当前执行的SQL，然后去运行下一个SQL。

一个INDEX中的所有测试SQL都运行完后，保存所有SQL的运行结果，并按照设置的比较方式进行比对，同时写到MYSQL库中。一个JOB下所有的SQL都运行完毕后，对整个JOB的运行结果进行判断，并邮件推送给相关人员。

DQ系统优势

DQ系统17年7月份上线，目前有10个项目，每天188个脚本在进行监控，优势明显：

可以每天进行大量表的全量测试SQL回归，并统一输出执行结果；

支持配置定时任务在上班之前就完成测试工作；

在定时任务的基础上检查每张数仓表的刷新情况，没刷完前不运行测试SQL，节约了集群资源；

支持对测试SQL设置依赖关系，确保执行顺序，前置测试SQL失败时，能跳过后面的测试SQL；

可以在测试SQL运行前，进行初始化SQL的执行；

同时支持HIVE/IMPALA；

可以对每个任务进行全部测试SQL重跑或者执行失败测试SQL重跑。

后续改进方向

虽然目前DQ系统已经释放了很大一部分人力，但是排查出错原因和测试SQL的开发，还是需要大量人工的介入，并且随着数据监控的表越来越多和发生异常时任务的重跑，邮件展示的监控结果也变得越来越多显得有些冗余，所以后续DQ系统会往【进一步减少人工介入】和【智能展示测试结果】2个方向继续努力。

最后感谢下部门对DQ系统提供技术支持的小伙伴，希望大家多提宝贵建议，让系统更强大~