hive一次补跑数据遇到的坑

1.问题背景

介绍下这次遇到补数问题的背景。补数是数仓从事人员经常会碰到的问题,比如修复了历史错误的逻辑,需要修复历史数据,这种行为称之为补数,首先补数一般针对的都是周期快照表,如果表无分区,压根就不需要补数。由于补数一般是针对或长或短的时间周期,一般采用并发跑,可以加快补数速率。现在公司的任务调度平台一般都支持并发调度任务。根据之前介绍的数据仓库分层架构设计,虽然有公共逻辑下沉的好处,但是一旦底层模型逻辑出现问题,就需要从底层开始逐一往上修复,我们称之为修复任务上下依赖。

2.修复步骤

1.定位问题现象,比如某报表数据异常(一般报表数据位于应用层),并找出异常字段(一般来讲只会有少部分字段异常)。
2.定位数据异常原因,即找出异常逻辑位于哪一层,哪个表。
3.修改异常表的逻辑。
4.开始补数,根据异常表所在层数-》报表所在层,形成任务依赖链。
5.逐一检查依赖链范围内每一层的上下依赖关系,列出所有跟异常字段计算逻辑有关的上下依赖表。
6.从最底层的依赖表开始重跑,直到修复报表层的表为止。(可以借助任务调度平台的依赖关系)

3.问题现象

根据修复步骤试跑了一天数据以后,查看报表数据,发现没有问题,但是同时并发跑多天数据,如产生如下问题:
1.相同记录存在多份,理论上来讲该个分区只有一条数据,但是结果却会产生多条相同的记录。
2.发现有许多字段的值为空

4.定位问题

定位问题思路一定要清晰,首先根据问题现象排查问题,跑一天数据没有问题,说明上下游逻辑是没有问题的,但是并发跑多天就会发现问题,我们刚开始是怀疑平台任务调度的bug,但是本着一切问题先从自身定位的精神,开始深思。
任务跑的每个表都是带分区的,理论上来讲并发跑任务应该是不会影响到其他分区的数据,除非计算逻辑里面用的表存在没有带分区的,带着这个疑问,再次去检查每个任务详细的计算逻辑,还真的发现,存在部分hive sql计算生成的临时表没有带分区,由于临时表在使用的时候,会先drop if exist,由于并发跑任务对于这些临时表的操作是没有锁的概念的,所有会产生计算结果部分字段为空的现象。至于记录为什么会重复的原因也很好解释了,肯定是由于存在多个任务并发往一张表里面插入数据,所以会存在记录重复。

5.后期改进措施

由这个问题,我们应该引起注意,应该整个数仓建设过程当中,往往是多个人同时参与,怎么能做到不在出现该问题。后续我们引入一下两点来避免:
1.平台增加自依赖机制(即一个任务必须上一个周期执行完成,才能继续执行下一个周期)
2.在数据模型的角度解决问题,所有临时表都必须带分区

最后说一句,坑很多,补不完,但是要做到踩一个,少一个。

你可能感兴趣的:(hive一次补跑数据遇到的坑)