全量改增量数据验证
为了确保改造前后的数据一致性，我们需要进行全面的数据验证。
- 首先，对已有的全量表进行数据探查，从不同维度对数据进行预估，并与实际值进行对比。
- 这包括检查全表条数是否为0，分区条数是否为0；
- 常规认知、业务认知、值的分布是否异常；
- 时间维度上的比较
- 同一数据产出批次内，数值的历史数据波动性的检查，数值的历史数据一致性检查；
- 不同数据产出批次之间，线上旧数据和线下新数据的比对；
- 空间维度上的比较
- 上下游对比、与系统内的其他数据对比，异构数据对比、数据同构对比；
- 与系统外的其他数据对比。
此外，参考已有的全量数据，对合并后的全量数据进行一致性对比。预期结果为：改造后，同一时间分区，开发环境与生产环境的数据一致。
全量改增量的思考
- 每个任务在接收后，可以先进行拆解，制定相应的计划和步骤，然后再进行具体的开发和执行。
- 在解决问题的过程中，遇到问题可以独立思考，尝试寻找解决方案。但同时也要注意不可过于自信，适时的讨论和请教可以帮助我们更快地解决问题。
遇到的问题及解决方法
（一）数据激增问题
在进行数据探查时，我们发现某个月底的全量数据存在异常增长的情况。经过深入调查，我们发现有两个导入任务同时对该表进行了插入操作。之前数据符合预期的原因是其中一个任务是直接进行insert操作，而另一个任务是先进行truncate再insert。由于这两个任务的时间安排问题，导致月底当天其中一个任务执行时间晚于另一个任务，从而造成了数据激增的情况。
为了解决这个问题，我们将其中一个任务改造为增量导入任务，并设置了相应的依赖关系。这样可以确保数据的正确性和一致性。
（二）数据映射关系错位问题
另外，在进行创建增量di表时，客户反馈其他任务的上游字段有变更，造成数据错位，需要重新刷数。这提醒我需要仔细检查字段的对应关系，不出所料新的di任务也存在类似的问题，我及时进行相应的调整和修正。
（三）数据缺失问题
在执行合并任务时，发现生产与开发环境在10月3日的数据仅相差了1条，由于实际结果与预期结果不一致，我与同事进行了CR讨论和分析。但同事认为我的合并逻辑有误，所以要求我修改后，再进行重新跑数，不然会存在数据不一致性问题。尤其是存量数据被删除时，经过仔细排查后最终找到了原因。得出结论如下：
1、客户说xx全量表不会有删除数据的操作，实际全量更新时，业务源系统会有物理删除数据的情况。客户之前说明的信息有误，实际需要按业务口径为准，于是三方开会讨论并得出该问题的结论，允许该情况发生，每月月底进行全量覆盖，防止数据不一致情况出现周期过长；
2、我的合并逻辑实现方法并无错误，全量改增量的功能无需修改；
方法A | 方法B |
|---|---|
select case when b.uid is not null then b.uid else a.uid end as uid,case when b.uid is not null then b.uname else a.uname end as uname,case when b.uid is not null then b.optime else a.optime end as optimefrom dw_user_inc a full outer join ods_user_inc bon a.uid = b.uid | SELECT NVL(b.uid,a.uid) AS uid ,NVL(di.uname,df.uname) AS uname ,NVL(di.optime,df.optime) AS optimefrom dw_user_inc a full outer join ods_user_inc bon a.uid = b.uid |
这两个SQL语句的结果是相同的。因为NVL函数和CASE WHEN语句都是用来处理NULL值的，只是写法不同。这两个函数的作用是相似的，都可以在某个值不存在时返回另一个值。
3、遗漏的数据的更新时间为10月4日的凌晨0点2分，以修改时间作为增量字段，取的应该为10月3日当天的增量数据，10月4日不在该范围内；
在进行数据一致性验证时，我们需要注意时间的准确性。如果发现生产环境和开发环境的数据存在差异，我们需要仔细排查并找到原因。在这个过程中，我们需要了解数据的来源、处理过程和结果输出等各个环节。只有确保每个环节的正确性才能保证最终数据的准确性和一致性。
（四）数据安全性问题
此外，我们还应该注意保护客户的数据安全。在排查问题时，我们应该避免将敏感字段如姓名、手机号等未经加密就展示出来。对于这些敏感字段，我们应该进行脱敏处理后再进行展示。这样可以保护客户的隐私和数据安全。
