大数据下的质量体系建设

一、背景

      大数据、人工智能是当前也是未来几年IT部门的重点建设方向，新的技术可以为业务突破盈利瓶颈，带来新的增长点，同时我们也发现数据中台也频频在最近的企业财报予以体现，相关的技术岗位需求也是供不应求，与之形成对比的是，我们发现在招聘网站上很少有专职的数据测试岗位。
      我们相信技术始终是为业务创造价值的，大数据也要输出他的产品（数据），产品必须要有质量的管控才可信，测试人员可以借助这个契机进行赛道的转换，在数据测试中形成自己的一套方法论参与到这个新技术引领的浪潮中。

二、数据开发在做什么

2.1 数据开发过程

我们可以通过上面这个图先来简单的去理解数据开发主要做什么

1. 根据需求找业务开发获取源数据；

2. 通过相关的工具把源数据同步到数据平台的表中；

3. 按照模型进行数据的清洗；

4. 将清洗结果写入到结果数据表中。

2.2 数据开发与应用开发的区别

1. 数据量大，这是他的首要特征，量大一个是消耗资源多，一个是性能问题，能否按时完成作业

2. 算法、模型运用较多，涉及到比如用户标签，营销预测，风控等需求开发，往往就是需要一些算法和模型的使用

3. 最终产出是数据，这个与应用开发交付的是代码不一样，应用开发的代码上线后，正常就是正常，但是数据开发的代码上线后，还需要把数据跑出来才算交付

4. 开发语言偏重于SQL、python、java，数据开发使用最多的就是sql了,另外就是python和java会做一些数据转换处理的函数开发，这块对测试人员来说相对比较好接入

5. 业务能力强且广，数据开发会涉及到公司的各个业务应用的数据，所以对业务的熟悉是开发的前提

三、测试需要关注什么

3.1 数据测试的出发点

在了解数据开发的过程和相关技术运用后，我们发现测试人员要接入数据开发测试流程，需要做好如下几点准备

1. 数据的持续关注，也就是要关注数据的完整流向，从哪里获取，各种条件下的清洗规则，数据最终又流向了哪里，这个在4.1部分中会有相应的解决方案，就是元数据管理和模型设计文档

2. 业务的熟悉，在业务应用的测试中，往往是每个测试人员负责几块业务内容，但是在数据测试中，测试人员需要对公司某个领域所包含的的业务需求了解透彻，比如做用户画像的开发，会涉及到账户体系、订单模块

3. SQL、python、java能够使用，在数据测试过程中，由于不像应用开发通过界面操作进行测试，往往是通过构造输入数据，执行相关的sql和函数，确认输出数据，所以有相关语言的基础会更方便我们的测试进行

3.2 数据测试关注什么

1. 准确性

• 完整性，就是数据通过每一次流转后，首先我们要看数据是否如预期的完整，不多不少

• 准确性，数据经过采集或者清洗流转后，是符合业务需求的；或者通过算法模型做预测，数据是符合一般性规律的，比如28定律、正太分布等

2. 及时性
   数据能够在预期的时间完成清洗产出

3. 性能

• 资源使用，主要关注对资源的消耗

• 数据接口性能，提供的API性能是否满足需求

四、数据开发测试流程

4.1 文档规范很重要

我们在做业务测试的时候，需要需求文档、设计文档，同样在做数据测试时，也需要有文档上的规范性要求

1. 产品需求文档

2. 模型设计文档，ETL的规则要有清晰的说明，这样测试才能更好的进入设计测试用例

3. 调度设计文档，每个节点的调度周期、运行顺序、上下游依赖、是否定时执行，运行预期时间都需要说明，方便去理解上下游关系和线上监控配置

4. 发布文档，告知是否需要重跑数据，重跑哪个时间段的数据，测试在执行生产发布的时候需要依据该文档进行相关操作

5. 公司级的数据库设计规约，单独提这个文档，是因为数据开发的数据来源都是从业务系统采集过来，业务应用数据库设计、变更这些对数据开发来说都是有一定的影响的，所以我们需要一份规约，来统一数据库的设计，库表变更的同步流程等

6. 业务变更的同步，当业务端需求变化可能会导致取数的逻辑发生变化，也是需要同步到数据端做相应的评估

4.2 开发和生产环境的独立

开发人员在需求开发的过程中，也需要通过反复的调试来完成代码的开发，为了不影响生产环境的正常使用，我们也需要像业务应用开发那样，有多套独立的环境来进行正常的开发和生产。
由于数据环境的相对复杂性和硬件资源的需求比较大，在数据部门组建初期，可以先只设立开发和生产两套独立的环境。
多套环境相应的就有权限的控制，不同角色岗操作的环境、数据权限都要有相应的管控

4.3 数据开发测试流程

1 完整流程

2数据开发流程

关键产出文档：

• ETL文档，数据的清洗规则需要有相应的文档输出，测试可以根据该文档了解开发的模型设计，并辅助进行相应的测试用例设计

• 调度设计文档，作业的设置也是交付的一部分，需要有相应的调度设计文档来让我们知道生产的作业设置情况

• 发布操作文档，在发布代码到生产的时候需要该文档的支撑

3 测试阶段

产出物：测试用例、缺陷

4 发布阶段

产出物:上线邮件

5 线上缺陷修复流程

数据开发与业务开发有一点不一样的地方在于，数据开发交付的是数据，所以如果生产一旦出现异常，回滚代码是解决不了问题的，需要将数据同步进行修复

五、全流程的数据质量监控预警体系

我们通过开发测试流程保证了代码的可靠性，也通过本地环境的数据构造完成相关测试点执行，代码发布到生产之后，由于生产环境的数据与本地在量级和各种覆盖度上还是存在差异，就像我们对应用程序在生产建立监控预警来保证生产的稳定性一样，也需要建立一套完备的大数据监控体系来保证我们数据的及时性和准确性。

5.1 计算资源的监控

无论在做数据采集还是数据清洗，都是一件十分消耗计算资源的事情，当前生产的资源配置是否能够满足我们的业务场景，当资源出现瓶颈趋势能否提前通知相关人员，这个就需要我们进行计算资源的监控，我们可以从如下维度进行监控

1. CPU的使用量，比如当前的算力是100cu,使用了80cu我们就触发报警

2. 内存的使用量，数据存储是特别耗资源的一个事情，对内存也要最好提前量的监控

3. 等待作业数，当前时间点存在多少个作业在等待资源

4. 流量监控，对于数据的上传下载，需要设置流量带宽的监控

5.2 作业运行监控

我们的数据代码发布到生产后，会由调度平台按照节点运行的时间点设置成一个个的调度作业，作业是否及时、成功的运行，关系到数据的及时性和准确性

1. 作业的状态进行监控
   运行状态错误，作业执行失败了
   运行的效率，在预期的时间长度（30分钟）未执行完成
   运行的及时性，这份作业需要在1:00必须执行完成，结果超过1:00状态还不是成功

2. 作业日志进行监控
   对每一个节点，当运行完成后，我们写入一条日志数据存储，然后通过一个作业去轮询这个日志表的数据，如果某个时间点数据没有生成，触发报警

5.3 表、字段维度的数据监控

在做数据采集或者数据清洗，存在大量表的数据读写，过程中需要对数据的完整性、一致性和准确性进行监控，数据是否正常写入了，是否存在血缘关系表的数据的不一致，是否清洗过后出现数据异常等等都需要及时知道并进行干预，避免错误数据暴露给用户。我们可以通过在作业运行中加入表、字段的监控来实现

1. 监控等级
   根据数据的重要性，可以将监控设置为强、弱两种类型，如果是强监控性质的，一旦触发，作业立即停止运行，防止异常数据写入下游节点；如果是弱类型的，作业继续执行，数据继续写入，获取报警信息后人来确定是否进行干预。

2. 监控维度
   表中数据条数，表中数据不能少于某个值，或者在某个范围
   表中数据的周期波动率，在某个时间周期，比如3天，数据行数的波动范围
   字段数据，针对单个字段的监控，是否为空，是否唯一等

5.4 质量、效率与成本的平衡

因为数据量大，数据清洗对算力的要求高，高的算力能够帮我们规避或者延迟一些问题的暴露，比如作业等待。无限制的去扩容带来的是成本的无限增长，我们需要在质量、效率和成本中去寻找平衡。

1. 数据资产评级
   是不是所有的表、字段、作业都需要做监控呢？哪些作业需要优先执行呢？我们需要有科学的判断–对数据资产进行评级，特别重要的定义为A级，所有跟A级依赖的也采取同等级定义；不是很重要的定义为B级等等

2. 调度平台根据级别进行作业执行优先级设置
   根据上面的数据资产评级，我们在设置作业执行的顺序时，除去上下游的依赖关系，当两个作业在同一时间点谁先执行，就有了清晰的定义

3. 报警方式根据级别进行渠道定义
   报警的触发方式，可以是语音电话、短信、邮件、钉钉消息等，不同的渠道成本是不一样的，我们也可以根据数据资产的评级来进行选择，比如特别重要的预警通过语音电话直接触发，相对重要的平时工作时间通过钉钉，非工作时间通过短信触发等。

4. 数据生命周期管理
   数据存储因为数据量级的关系，特别消耗存储空间，我们需要对数据的生命周期有相应的管理策略，什么时候相关表的数据可以销毁，避免僵尸数据长期占用资源的情况

六、后记

任何技术通过小马快跑发展到一定阶段后，最终还是落地到是否能稳定的为业务提供服务，我们要做的就是抓住这个机遇和挑战，不断的在实践中丰富和完善整个质量体系的建立，流程、规范、执行、监控是我们在业务开发中采取的策略，同样适用于我们的数据开发，只不过是使用的工具不一样罢了。
你们也有数据测试实践吗，欢迎一起来探讨～