数据加载测试

加载：数据按照对应的映射关系加载到数据应用库表的过程。
整个ETL过程最后一个环节就是加载，数据的推送，就是把我们大数据这边已经处理好的数据和表推送到业务系统、数据平台、报表平台等。

这一部分主要关注数据和调度，数据量和之前的采集环节相类似，有一点需要特别关注，oracle、MySQL这些传统数据库中的数据表，我们需要关注一下索引、约束以及注释和字段类型是否正确。

第二块是我们配置的调度是否合理，任务的运行时间是否合理。

 数据监控

前面讲的是我们在测试环节要做的事情，后面这部分我们讲一下，整个数据表上线之后，应该怎么去做一些线上冒烟的测试。首先我们做了一个数据监控。

数据监控是针对生产数据的变化按照一定的技术手段、业务规则进行监控、预警，并及时反馈异常数据。

为什么要做数据监控呢？首先是因为生产数据的不确定性，业务系统的数据是我们大数据这边无法管控的。第二个是缺乏高效的自动化手段，数据的自动化成本是很高的，效果和投入不成正比。第三个原因是生产操作经常会存在一些不规范情况。最后一个是数据链路过长，整个集群和计算框架都会存在一些不稳定的因素。

基于以上原因，我们做了一套数据监控。
数据监控的标准还是针对数据本身，所以我们还是以数据质量的标准去制定我们的监控标准：数据完整性、数据一致性、数据准确性、数据及时性、数据可用性。

监控的范围主要包括三方面：调度任务、表、字段。
调度任务主要是我知道调度任务的运行状态是否成功，包括调度任务的数据量、运行时间是否合理。表主要以数据波动为主，包括数据是否为0。字段主要以值域的判断和枚举值的判断为主。

下面是我们这边的一个数据监控平台，有一些规则，包括一些数据量、总和、空值、平均值的一些检测。底层以sql为主，进行的一个封装。把sql的查询结果和你预期的结果进行对比，如果查询的结果在你预期的范围之内，这个任务就会通过。如果不在范围之内，就会以告警的方式通知相关人员，然后去判断是业务的问题还是代码逻辑的问题。

下面是我列举的一些规则，我们一起看一下。首先是调度任务的运行时间、状态，可能有一些会加一个开始时间，看一下任务有没有及时的开始。

表这一部分主要是监查数据量是不是为0，每天的数据增量对比，同比环比的数据，检查一下表里面是不是有测试数据的存在，平均值的波动以及重复数据的检查，主要的检查范围就是这些。

第三个维度是字段，包括刚刚提到的枚举值，极限值，也是我们刚刚提到的值域的判断，以及空值率、格式的检查和关联字段的检查。

我这里只是给大家列举了一些类别，但是具体的规则还是需要大家自己根据业务去制定的。

下面给大家举了一个案例：

波动分析
首先我们来看一下波动分析，就是整个数据量的波动，我们可以看到中间这个地方有一个数据量特别的高。如果这块数据的波动突然出现异常了，我们就需要对这部分数据进行分析。

是业务系统今天本身就产生了这么多数据？还是我们的数据任务有问题？还是数据加工有问题？

时效分析
时效是指任务是否能够按照预定的时间完成。前面我们也讲过了，我们在衡量整个数据仓库质量的时候，有一个很重要的特性就是数据的时效性。如果任务运行的时间过长，就会影响下游的任务，影响下游任务的产出时间。

从下面这张图我们可以看到，11月5日这一天，任务跑了70分分钟，那我们需要去分析判断一下，到底是什么原因。如果是代码问题，那需要进行优化修改。如果资源不够，我们需要去进行一些资源的优化，或者通过加机器的方式去解决。

值域分析
接下来的部分是值域分析，主要针对字段。这里给大家举了一个公司员工年龄的例子，我们正常的公司员工一般在20岁到65岁这样一个区间，如果超出这个范围，这个数据就是异常的、不应该被采集到的。

通过下面这个图片我们可以看到有一条数据是20岁以下，有一条数据是在70岁左右。70岁一般来说是已经退休了，20岁以下一般大学还没有毕业，应该是采集不到的。所以我们要分析下，看到底是用户在填入信息的时候填写错了？还是因为什么其他原因导致的？否则会影响我们后面数据的判断的质量。