1.问题背景
介绍下这次遇到补数问题的背景。补数是数仓从事人员经常会碰到的问题，比如修复了历史错误的逻辑，需要修复历史数据，这种行为称之为补数，首先补数一般针对的都是周期快照表，如果表无分区，压根就不需要补数。由于补数一般是针对或长或短的时间周期，一般采用并发跑，可以加快补数速率。现在公司的任务调度平台一般都支持并发调度任务。根据之前介绍的数据仓库分层架构设计，虽然有公共逻辑下沉的好处，但是一旦底层模型逻辑出现问题，就需要从底层开始逐一往上修复，我们称之为修复任务上下依赖。
2.修复步骤
1.定位问题现象，比如某报表数据异常（一般报表数据位于应用层），并找出异常字段（一般来讲只会有少部分字段异常）。
2.定位数据异常原因，即找出异常逻辑位于哪一层，哪个表。
3.修改异常表的逻辑。
4.开始补数，根据异常表所在层数-》报表所在层，形成任务依赖链。
5.逐一检查依赖链范围内每一层的上下依赖关系，列出所有跟异常字段计算逻辑有关的上下依赖表。
6.从最底层的依赖表开始重跑，直到修复报表层的表为止。（可以借助任务调度平台的依赖关系）
3.问题现象
根据修复步骤试跑了一天数据以后，查看报表数据，发现没有问题，但是同时并发跑多天数据，如产生如下问题：
1.相同记录存在多份，理论上来讲该个分区只有一条数据，但是结果却会产生多条相同的记录。
2.发现有许多字段的值为空
4.定位问题
定位问题思路一定要清晰，首先根据问题现象排查问题，跑一天数据没有问题，说明上下游逻辑是没有问题的，但是并发跑多天就会发现问题，我们刚开始是怀疑平台任务调度的bug，但是本着一切问题先从自身定位的精神，开始深思。
任务跑的每个表都是带分区的，理论上来讲并发跑任务应该是不会影响到其他分区的数据，除非计算逻辑里面用的表存在没有带分区的，带着这个疑问，再次去检查每个任务详细的计算逻辑，还真的发现，存在部分hive sql计算生成的临时表没有带分区，由于临时表在使用的时候，会先drop if exist，由于并发跑任务对于这些临时表的操作是没有锁的概念的，所有会产生计算结果部分字段为空的现象。至于记录为什么会重复的原因也很好解释了，肯定是由于存在多个任务并发往一张表里面插入数据，所以会存在记录重复。
5.后期改进措施
由这个问题，我们应该引起注意，应该整个数仓建设过程当中，往往是多个人同时参与，怎么能做到不在出现该问题。后续我们引入一下两点来避免：
1.平台增加自依赖机制（即一个任务必须上一个周期执行完成，才能继续执行下一个周期）
2.在数据模型的角度解决问题，所有临时表都必须带分区
最后说一句，坑很多，补不完，但是要做到踩一个，少一个。
