数据漂移解决方案

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

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

通常,时间戳字段分为四类: 1、 数据库中数据更新时间(假设这类字段叫modifiedtime) 2、 数据库日志中的数据记录更新时间(假设这类字段叫logtime) 3、 业务过程发生时间(假设这类字段叫proctime) 4、 数据被抽取的时间(假设这类字段叫extracttime)

理论上,这几个时间应该是一致的,但是在实际生产中,这几个时间往往会出现差异,可能的原因有以下几点: 1、 由于数据抽取需要时间, extracttime往往会晚于前三个时间。2、 前台业务系统手工订正数据时未更新modifiedtime. 3、 由于网络或者系统压力问题, logtime或者modifiedtime会晚于proc_time.

通常的做法是根据其中的某一个字段来切分ODS表,这就导致产生数据漂移。下面我们来具体看下数据漂移的几种场景。1、 根据extracttime来获取数据。这种情况数据漂移的问题最明显。2、 根据modifiedtime限制。在实际生产中这种情况最常见,但是往往会发生不更新modified time而导致的数据遗漏,或者凌晨时间产生的数据记录漂移到后一天。3、 根据logtime限制。由于网络或者系统压力问题, logtime会晚于 proctime,从而导致凌晨时间产生的数据记录漂移到后一天。例如,在淘宝“双11”大促期间凌晨时间产生的数据量非常大,用户支付需要调用多个接口,从而导致logtime晚于实际的支付时间。4、 根据proctime限制。仅仅根据proctime限制,我们所获取的ODS表只是包含一个业务过程所产生的记录,会遗漏很多其他过程的变化记录,这违背了ODS和业务系统保持一致的设计原则。处理方法主要有以下两种

1、 多获取后一天的数据 在ODS每个时间分区中向前、向后多冗余一些数据,保障数据只会多不会少,而具体的数据切分让下游根据自身不同的业务场景用不同的业务时间proctime来限制。但是这种方式会有一些数据误差。2、 通过多个时间截字段限制时间来获取相对准确的数据 (1) 首先根据logtime分别冗余前一天最后15分钟的数据和后一天凌晨开始15分钟的数据,并用modifiedtime过滤非当天数据,确保数据不会因为系统问题而遗漏。(2) 然后根据logtime获取后一天15分钟的数据;针对此数据,按照主键根据logtime做升序排列去重。因为我们需要获取的是最接近当天记录变化的数据(数据库日志将保留所有变化的数据,但是落地到ODS表的是根据主键去重获取最后状态变化的数据)。(3) 最后将前两步的结果数据做全外连接,通过限制业务时间proctime来获取我们所需要的数据。

下面来看处理淘宝交易订单的数据漂移的实际案例。我们在处理“双11”交易订单时发现,有一大批在11月11日 23:59:59左右支付的交易订单漂移到了12日。主要原因是用户下单支付后系统需要调用支付宝的接口而有所延迟,从而导致这些订单最终生成的时间跨天了。即modifiedtime和logtime都晚于proctime. 如果订单只有一个支付业务过程,则可以用支付时间来限制就能获取到正确的数据。但是往往实际订单有多个业务过程:下单、支付、成功,每个业务过程都有相应的时间戳字段,并不只有支付数据会漂移。如果直接通过多获取后一天的数据,然后限制这些时间,则可以获取到相关数据,但是后一天的数据可能已经更新多次,我们直接获取到的那条记录已经是更新多次后的状态,数据的准确性存在一定的问题。因此,我们可以根据实际情况获取后一天15分钟的数据,并限制多个业务过程的时间戳字段(下单、支付、成功)都是“双11"当天的,然后对这些数据按照订单的modified time做升序排列,获取每个订单首次数据变更的那条记录。此外,我们可以根据logtime分别冗余前一天最后15分钟的数据和后一天凌晨开始15分钟的数据,并用modifietime过滤非当天数据,针对每个订单按照logtime进行降序排列,取每个订单当天最后一次数据变更的那条记录。最后将两份数据根据订单做全外连接,将漂移数据回补到当天数据中。