《大数据之路》一书中对数据漂移的处理是这么说的：
数据漂移的处理
通常我们把从源系统同步进人数据仓库的第一层数据称为 ODS或者staging 层数据，阿里巴巴统称为 ODS 。数据漂移是 ODS 数据的一个顽疾，通常是指 ODS 表的同一个业务日期数据中包含前一天或后凌晨附近的数据或者丢失当天的变更数据。
由于 ODS 需要承接面向历史的细节数据查询需求，这就需要物理落地到数据仓库的 ODS 表按时间段来切分进行分区存储 ，通常的做法是按某些时间戳字段来切分，而实际上往往由于时间戳字段的准确性问题导致发生数据漂移。
通常，时间戳字段分为四类：
- 数据库表中用来标识数据记录更新时间的时间戳字段（假设这类字段叫 modified time ）。
- 数据库日志中用来标识数据记录更新时间的时间戳字段·（假设这类宇段叫 log_time）。
- 数据库表中用来记录具体业务过程发生时间的时间戳字段 （假设这类字段叫 proc_time）。
- 标识数据记录被抽取到时间的时间戳字段（假设这类字段extract time）。
理论上，这几个时间应该是 致的，但是在实际生产中，这几个时间往往会出现差异，可能的原因有以下几点：
- 由于数据抽取是需要时间的， extract_time 往往会晚于前三个时间。
- 前台业务系统手工订正数据时未更新 modified_time
- 由于网络或者系统压力问题， log_time 或者 modified_time 会晚proc_time。
通常的做法是根据其中的某 个字段来切分 ODS 表，这就导致产生数据漂移。下面我们来具体看下数据漂移的几种场景。
- 根据 extract_time 来获取数据。这种情况数据漂移的问题最明显
- 根据 modified_time 限制。在实际生产中这种情况最常见，但是往往会发生不更新 modified time 而导致的数据遗漏，或者凌晨时间产生的数据记录漂移到后天。根据 log_time 限制。由于网络或者系统压力问题， log_time 会晚proc_time ，从而导致凌晨时间产生的数据记录漂移到后一天。
例如，在淘宝“双 11 ”大促期间凌晨时间产生的数据量非常大，用户支付需要调用多个接口，从而导致 log time 晚于实际的支付时间。 - 根据 proc_time 限制。仅仅根据 proc_time 限制，我们所获取的ODS 表只是包含一个业务过程所产生的记 ，会遗漏很多其他过程的变化记录，这违背了 ODS 和业务系统保持 致的设计原则。
处理方法主要有以下两种：
( 1）多获取后 天的数据既然很难解决数据漂移的问题，那么就在 ODS 每个时间分区中向前、向后多冗余 些数据，保障数据只会多不会少，而具体的数据切分让下游根据自身不同的业务场景用不同的业务时间 proc time 来限制但是这种方式会有一些数据误差，例如 个订单是当天支付的，但是第天凌晨申请退款关闭了该订单，那么这条记录的订单状态会被更新，下游在统计支付订单状态时会出现错误。
( 2）通过多个时间戳字段限制时间来获取相对准确的数据
- 首先根据 log_time 分别冗余前一天最后 15 分钟的数据和后一天凌晨开始 15 分钟的数据，并用 modified time 过滤非当天数据，
确保数据不会因为系统问题而遗漏。 - 然后根据 log_time 获取后一天 15 分钟的数据 针对此数据，按照主键根据 log_time 做升序排列去重。因为我们需要获取的是最
接近当天记录变化的数据（数据库日志将保留所有变化的数据，但是落地到 DS 表的是根据主键去重获取最后状态变化的数据）。 - 最后将前两步的结果数据做全外连接，通过限制业务时间proc_time 来获取我们所需要的数据。
下面来看处理淘宝交易订单的数据漂移的实际案例。
我们在处理“双 11”交易订单时发现，有大批在11月11日23:59:59 左右支付的交易订单漂移到了12日 。主要原因是用户下单支
付后系统需要调用支付宝的接口而有所延迟，从而导致这些订单最终生成的时间跨天了。即 modified_time和log_time 都晚于proc_time
如果订单只有一个支付业务过程，则可以用支付时间来限制就能获取到正确的数据。但是往往实际订单有多个业务过程 下单、支付、成
功，每个业务过程都有相应的时间戳字段，并不只有支付数据会漂移。如果直接通过多获取后 天的数据，然后限制这些时间，则可以获
取到相关数据，但是后 天的数据可能已经更新多次，我们直接获取到的那条记录已经是更新多次后的状态，数据的准确性存在 定的问题。
因此，我们可以根据实际情况获取后15分钟的数据，并限制个业务过程的时间戳字段（下单、支付、成功）都是“双 ”当天的，然后对这些数据按照订单的 modified_time 升序排列，获取每个订单首次数据变更的那条记录。
此外，我们可以根据 log_time 分别冗余前 天最后15 分钟的数据和后 天凌晨开始 15 分钟的数据，并用 modified_time 过滤非当天数据，
针对每个订单按照 log_time 进行降序排列 ，取每个订单当天最后一次数据变更的那条记录。
最后将两份数据根据订单做全外连接，将漂移数据回补到当天数据中。
==========================分割线==========================
上面讲的比较晦涩，例子由于没有具体数据的支撑也比较难以理解。我凭着自己的理解和对实际数据的想象对上面的例子做一点解释。
首先场景是在双11当天的23:59:59时有大量支付订单由于调用链路长以及网络延迟等原因，最终数据入库的实际漂移到了12日。
在我理解这里面的数据应该是mysql库的binlog日志。
- proc_time：数据的产生的事件时间。不同的业务过程理解不同，支付的是支付时间，下单的是下单时间。
- modified_time：数据更新时间，不同的业务过程可能有多个状态的数据，比如支付有待支付和已支付等状态。
- log_time：binlog日志时间。
正常proc_time<log_time<modified_time
由于每个业务过程可能经过很多状态的变化，所以只获取漂移后的第一个状态数据，因为有可能在后一天已经对漂移的数据做了状态变更过。
主要分两步操作：
1.获取当天漂移的数据。获取后一天15分钟的数据，限制业务过程时间戳proc_time=双11，并按modified_time升序排序，取第一条。
proc_time=双11，即获取双11漂移到12日的数据，modified_time升序排序为了取第一条状态的数据。
2.获取当天未漂移的数据并剔除前一天漂移过来的数据。根据 log_time 分别冗余前一天最后15 分钟的数据和后一天凌晨开始15 分钟的数据，并用modified_time 过滤非当天数据，针对每个订单按照 log_time 进行降序排列 ，取每个订单当天最后一次数据变更的那条记录。
分别冗余前一天最后15分钟和后一天前15分钟数据，目的是考虑到有往前漂移的场景。
modified_time 过滤非当天数据，即modified_time！=双11，过滤掉前后两天的正常数据。
log_time 降序排列 ，只取每个订单当天最后一次数据变更。只取订单当天即log_time=双11，剔除前一天漂移过来的数据。
最后对这两部分数据做全外连接即得到当天所有的数据。
