大数据测试实践之全量改增量（下）

全量改增量数据验证

为了确保改造前后的数据一致性，我们需要进行全面的数据验证。

• 首先，对已有的全量表进行数据探查，从不同维度对数据进行预估，并与实际值进行对比。
  • 这包括检查全表条数是否为0，分区条数是否为0；
  • 常规认知、业务认知、值的分布是否异常；
• 时间维度上的比较
  • 同一数据产出批次内，数值的历史数据波动性的检查，数值的历史数据一致性检查；
  • 不同数据产出批次之间，线上旧数据和线下新数据的比对；
• 空间维度上的比较
  • 上下游对比、与系统内的其他数据对比，异构数据对比、数据同构对比；
  • 与系统外的其他数据对比。

此外，参考已有的全量数据，对合并后的全量数据进行一致性对比。预期结果为：改造后，同一时间分区，开发环境与生产环境的数据一致。

全量改增量的思考

• 每个任务在接收后，可以先进行拆解，制定相应的计划和步骤，然后再进行具体的开发和执行。
• 在解决问题的过程中，遇到问题可以独立思考，尝试寻找解决方案。但同时也要注意不可过于自信，适时的讨论和请教可以帮助我们更快地解决问题。

遇到的问题及解决方法

（一）数据激增问题

在进行数据探查时，我们发现某个月底的全量数据存在异常增长的情况。经过深入调查，我们发现有两个导入任务同时对该表进行了插入操作。之前数据符合预期的原因是其中一个任务是直接进行insert操作，而另一个任务是先进行truncate再insert。由于这两个任务的时间安排问题，导致月底当天其中一个任务执行时间晚于另一个任务，从而造成了数据激增的情况。

为了解决这个问题，我们将其中一个任务改造为增量导入任务，并设置了相应的依赖关系。这样可以确保数据的正确性和一致性。

（二）数据映射关系错位问题

另外，在进行创建增量di表时，客户反馈其他任务的上游字段有变更，造成数据错位，需要重新刷数。这提醒我需要仔细检查字段的对应关系，不出所料新的di任务也存在类似的问题，我及时进行相应的调整和修正。

（三）数据缺失问题

在执行合并任务时，发现生产与开发环境在10月3日的数据仅相差了1条，由于实际结果与预期结果不一致，我与同事进行了CR讨论和分析。但同事认为我的合并逻辑有误，所以要求我修改后，再进行重新跑数，不然会存在数据不一致性问题。尤其是存量数据被删除时，经过仔细排查后最终找到了原因。得出结论如下：

1、客户说xx全量表不会有删除数据的操作，实际全量更新时，业务源系统会有物理删除数据的情况。客户之前说明的信息有误，实际需要按业务口径为准，于是三方开会讨论并得出该问题的结论，允许该情况发生，每月月底进行全量覆盖，防止数据不一致情况出现周期过长；

2、我的合并逻辑实现方法并无错误，全量改增量的功能无需修改；

这两个SQL语句的结果是相同的。因为NVL函数和CASE WHEN语句都是用来处理NULL值的，只是写法不同。这两个函数的作用是相似的，都可以在某个值不存在时返回另一个值。

3、遗漏的数据的更新时间为10月4日的凌晨0点2分，以修改时间作为增量字段，取的应该为10月3日当天的增量数据，10月4日不在该范围内；

在进行数据一致性验证时，我们需要注意时间的准确性。如果发现生产环境和开发环境的数据存在差异，我们需要仔细排查并找到原因。在这个过程中，我们需要了解数据的来源、处理过程和结果输出等各个环节。只有确保每个环节的正确性才能保证最终数据的准确性和一致性。

（四）数据安全性问题

此外，我们还应该注意保护客户的数据安全。在排查问题时，我们应该避免将敏感字段如姓名、手机号等未经加密就展示出来。对于这些敏感字段，我们应该进行脱敏处理后再进行展示。这样可以保护客户的隐私和数据安全。