数据仓库：如何解决ODS数据零点漂移问题-Toy模板网

这篇具有很好参考价值的文章主要介绍了数据仓库：如何解决ODS数据零点漂移问题。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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