今天上午被一个昨天就出现的bug硬控一早上,同事a昨天找我说一条数据没同步过来,查出来是因为没审批记录,当脏数据处理掉了。然后他昨天提交了几条测试数据,今天早上来查还是没有。就在群里@我问原因了(还艾特了我的主管,ohno)我赶忙拉着开发同学一起查,发现业务库是今早晨七点更新的,数据是凌晨同步当然同步不过来。
但是这样数据就变成T+2更新了。作为一个小菜鸡,我马上去请教了师兄,他告诉我可以配置二次调度,早上把这个链路的表再run一遍。嗯,今天又从bug中学到了一些处理方案!
所以今天回顾一下数仓中的数据飘移。
什么是数据漂移
通常是指ods表的同一个业务日期数据中包含了前一天或后一天凌晨附近的数据或者丢失当天变更的数据,这种现象就叫做漂移
为什么产生
时间戳字段分为4类:
- 数据库表中用来标识数据记录更新时间的时间戳字段(假设这类字段叫modified time)。
- 数据库日志中用来标识数据记录更新时间的时间戳字段·(假设这类宇段叫log time)。
- 数据库表中用来记录具体业务过程发生时间的时间戳字段(假设这类字段叫proc time)。
- 标识数据记录被抽取到时间的时间戳字段(假设这类字段 extract time)。
理论上四个时间戳字段一致,但是实际生产中会有差异。比如业务手工改数据但是没更新modified time;数据抽取需要时间;网络延迟log time晚于业务发生时间。
而我们通常选取一个时间字段来切分ODS,这就导致了数据漂移。
选取四个字段分别产生的数据漂移场景:
- modified time :实际生产中最多,但是这个更新时间不更新就会导致数据遗漏,或者凌晨产出的漂移到后一天;
- log time: 一般由于系统或网络压力大,log time会晚于proc time,凌晨产出漂移到后一天。举个例子,双十一数据量巨巨大,应该会有支付时间小于记录更新时间的数据。
- proc time : 一般一个表不会只有一个业务过程,如果只用一个业务时间会遗漏其他过程的变化数据。
- extract time: 这个的偏移会最明显。
解决数据漂移思路
两种方法:
方法一: 多获取一点后一天的数据,保障数据只多不少(简单粗暴)
ODS每个时间分区向前向后都冗余一些数据,具体的切分再让下游根据业务时间proc time来限制。但是这样也会有误差的,比如当天请假了,第二天凌晨撤销了这个申请,这条记录的(审批)状态会更新,下游统计状态会错误统计。
方法二: 多个时间戳字段来保障一定的准确性。
- 先根据log time 冗余前一天最后15分钟和后一天凌晨15分钟,再根据多个业务过程的modified time限制在当天。
- 后一天15分钟的这些数据,按主键用log time升序去重,这样获取最接近当天的状态变化
- 最后将前两步的数据做全外连接,通过限制业务时间 proc_time 来获取想要的数据。
看起来有点绕,简单理解就是做一些前后的冗余,再通过多个业务相关的发生时间限制在当天,再用时间字段排序取最接近当天状态的数据。