数据仓库：如何解决ODS数据零点漂移问题

本篇文章讲解的是从业务库同步数据至数仓导致的零点漂移，查看flume+kafka同步数据导致的零点漂移参考该文章：业务数据采集_零点漂移处理方法(Flume+Kafka+HDFS)

一、数据零点漂移概念

1、什么是零点漂移：

数据零点漂移指的是数据同步过程中，ODS表按时间字段分区时，同一个业务日期

(分区)

包含前一天的数据或丢失了当天的数据、或者包含后一天凌晨附近的数据。

由于ODS需要承接面向历史的细节数据查询需求，这就需要物理落地到数据仓库的ODS表按时间段来切分进行分区存储，通常的做法是按某些时间戳字段来切分，而实际上往往由于时间戳字段的准确性问题导致发生数据漂移。

1）这里讲的漂移是指ODS表按照某个字段分区会存在数据漂移现象，如果是全量抽取数据数据会存在该问题吗？全量抽取是否是延迟零点过几分去执行抽取？
2）目前小公司ods数据同步方式都是全量抽取的方式、因为数据量小。

2、为什么会产生数据漂移

当数仓ODS采用按时间段分区的方式存储数据，时间字段的选择会导致不同类型的数据漂移现象。

2.1、分区时间字段分类

通常，时间戳字段分为四类：

• 数据库表中用来标识数据记录更新时间的时间戳字段（modified_time）
• 数据库日志中用来标识数据记录更新时间的时间戳字段·（log_time）
• 数据库表中用来记录具体业务过程发生时间的时间戳字段（proc_time）
• 标识数据记录被抽取到时间的时间戳字段（extract_time）

理论上，上述四个时间戳应该是一致的，即proc_time = log_time = modified_time = extract_time,但实际生产中，这几个时间往往会出现差异。

2.2、分区时间大小关系

在现实中，四个时间戳的大小关系为：proc_time<log_time<modified_time<extract_time，造成这些差异的原因有：

• 由于数据产生后才能抽数，并且很难做到数据实时产生实时抽取，所以extract_time一般会晚于其他三个时间。
• 关系型数据库采用预写日志方式来更新数据，所以更新时间modified_time会晚于log_time
• 由于网络或系统压力问题，会导致数据延迟写入/数据延迟更新。log_time或者modified_time会晚于proc_time
• 前台业务系统手工修正数据时，未更新modified_time

2.3、不同的时间字段分区产生的问题

根据其中的某一个时间字段来切分ODS表，这就导致产生数据漂移。下面我们来具体看下数据漂移的几种场景。

• 根据extract_time抽取时间分区，这种情况数据漂移的问题最明显。
• 根据modified_time更新时间分区。在实际生产中这种情况最常见，但是往往会发生不更新modified_time而导致的数据遗漏，或者凌晨时间产生的数据记录漂移到后一天。
• 根据log_time分区。由于网络或者系统压力问题，log_time会晚于proc_time，从而导致凌晨时间产生的数据记录漂移到后一天。 例如，在淘宝“双11”大促期间凌晨时间产生的数据量非常大，用户支付需要调用多个接口，从而导致log_time晚于实际的支付时间。
• 根据proc_time业务过程分区。仅仅根据proc_time限制，我们所获取的ODS表只是包含一个业务过程所产生的记录，会遗漏很多其他过程的变化记录。

二、如何解决零点漂移

1、多获取后一天的数据

既然很难解决数据漂移的问题，那么就在ODS每个时间分区中向后多冗余一些数据，
在ods每个时间分区中向后多冗余一天数据，保障数据只会多，不会少，而具体的数据切分让下游根据自身不同的业务场景用不同的业务时间proc_time来限制。

但这种方式会有一些数据误差，因为后一天的数据可能已经更新多次，直接获取到的那条记录已经是更新多次后的状态了。

2、多个时间戳字段限制时间

通过多个时间戳字段限制时间，来获取相对准确的数据

• ①获取当天漂移的数据：根据modified_time获取后一天15分钟的数据，并限制多个和业务过程的时间戳为当天，然后根据这些数据按照modified_time升序排序，获取每个数据(主键唯一)首次数据变更的那条记录。
• ②获取当天未漂移的数据并剔除前一天漂移过来的数据：根据log_time分别冗余前一天最后15分钟的数据和后一天凌晨开始15分钟的数据，并用modified_time过滤非当天数据，并针对每个订单按照log_time进行降序排序，取每个订单当天最后一次数据变更的那条记录。
• ③将两部分数据根据订单做full join 全外连接，即可得到当天所有数据。

总而言之，在生产中数据漂移问题是存在的，我们只能通过一些规则限制获取相对准确的数据。比如约定通过修改时间来分区、这个字段如果存在不更新的情况就需要业务系统治理。

哎呀，写了这么多觉得对数据零点漂移还是没理解透彻~~~~~~慢慢完善
1）如果是动态分区如何处理？
2）如果是增量同步、新增及变化、全量同步的数据零点漂移如何处理？

三、数据零点漂移面试讲解

1、数据零点漂移指的是，ODS表按照时间字段分区时、同一个业务日期(分区)包含前一天的数据或丢失了当天的数据、或者包含后一天凌晨附近的数据。

2、导致的原因是：时间字段不更新；或者分区时间与业务实际发生时间有差异，比如凌晨时间产生的数据、时间记录漂移到了后一天（业务数据更新的原因）。

3、产生的影响：数据业绩计算不准确，当天数据漂移到了第二天

4、解决方法（数据漂移的问题很难解决，只能通过一些规则来获取相对准确的数据）：
1）系统侧：约束修改时间、日志记录修改时间必须更新
2）全量同步数据时，凌晨过几分去拉取数据
3）ODS根据时间字段分区时

• 每个分区多获取后一天的数据进行数据冗余，下游使用数据时在根据业务时间字段限制
• 通过多个时间戳字段限制时间

参考文章：
1、如何解决数据漂移问题
2、【数据仓库】数据漂移的处理