对数据漂移处理的一点理解

《大数据之路》一书中对数据漂移的处理是这么说的：

通常我们把从源系统同步进人数据仓库的第一层数据称为 ODS或者staging 层数据，阿里巴巴统称为 ODS 。数据漂移是 ODS 数据的一个顽疾，通常是指 ODS 表的同一个业务日期数据中包含前一天或后凌晨附近的数据或者丢失当天的变更数据。

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

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

理论上，这几个时间应该是 致的，但是在实际生产中，这几个时间往往会出现差异，可能的原因有以下几点：

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

处理方法主要有以下两种：

( 1）多获取后 天的数据既然很难解决数据漂移的问题，那么就在 ODS 每个时间分区中向前、向后多冗余 些数据，保障数据只会多不会少，而具体的数据切分让下游根据自身不同的业务场景用不同的业务时间 proc time 来限制但是这种方式会有一些数据误差，例如 个订单是当天支付的，但是第天凌晨申请退款关闭了该订单，那么这条记录的订单状态会被更新，下游在统计支付订单状态时会出现错误。

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

下面来看处理淘宝交易订单的数据漂移的实际案例。

我们在处理“双 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日志。

1、准备三台虚拟机，选择两台mysql作为keepalived（一台master 一台backup），一台做客户端访问用。

2、给两台mysql安装keepalived制作高可用生成VIP

我这里用的是mysqld

yum安装mysql

实施步骤：

一、mysql 主主同步 <略>

二、安装keepalived---两台机器都 *** 作

三添加库用于测试

四 在任意一台机器作为客户端

测试的时候记得检查mysql用户的可不可以远程登录。

实现了VIP的漂移，实现了mysql的高可用。

mysql的双主或主从都是通过binlog的传输来对数据的一致性进行保障。

换句话说就是A写入了，其实A会把binlog发给B，B也会同时写入。

如果你是不希望同时写入，那你只能寄望于共享存储。

两台机共用一个存储设备，当A坏了B马上接管A的工作。

因为A和B都是使用同一个存储设备，所以不存在同步的问题。

---