数据漂移问题及解决方案

手机

iphone11大小尺寸是多少？苹果iPhone11和iPhone13的区别是什么？

警方通报辅警执法直播中被撞飞：犯罪嫌疑人已投案

数据漂移问题及解决方案

2023-03-06 19:56:28 来源：博客园

什么是数据漂移？

数据漂移是 ODS 数据的一个顽疾，通常指 ODS 表的同一个业务日期数据中包含前一天或后一天凌晨附近的数据或者丢失当天的变更数据。

(资料图)

实际场景

公司主营互联网金融业务，因此有了一张数据量庞大的申请人信息记录表。这张表里的时间字段非常多，因为整个业务场景涉及到好几段流程：

客户提交申请贷款请求 → 我们接受申请贷款请求 → 进入决策引擎 → 决策引擎调用第三方数据系统 →决策引擎返回结果报告 → 匹配发送记录和返回报告 → 反馈给客户发送结果

可见每一段子流程（子域）里都会有相应的时间字段。选择使用客户的提交申请时间来做分区字段，也是为了贴近客户的实际体验。即某一天的申请记录明细就应该是那一天客户提交给我们的所有申请信息。实际上并给如此，主要有两种场景导致了异样的发生：

1、通道延迟

我们接受到客户的申请贷款的请求后，到提交给核心信贷系统以及决策引擎系统这段时间理论上是很快的，秒级响应。但某些时候因为网络波动或者服务器故障，会导致申请积压，卡在某一环节，如果正好卡在落库之前，这时客户在 T 天提交贷款申请请求，积压解决后申请记录落库实际发生在 T+1 天。导致 T+1 天凌晨做ETL 数据同步时这批申请信息记录获取不到，最终数据平台丢失了一部分数据。

2、特殊业务场景

有一类特殊的业务场景叫”先提后审“，客户提交一种特殊的申请贷款请求后，需要客服审核内容，审批通过后才可实际发送。如果客户在客服下班时间段提交了这种申请贷款请求，那么实际要到第二天客服上班后才会实际被提交，落库也发生在客服审批之后。同上一种情况，也会发生丢失数据的情况。

解决方案

1、延迟重传

某些公司采用了很粗暴的解决方案，T+1 天允许 T 这天的数据存在数据漂移的现象。但是在 T+7 天，对 T天数据进行重传，恢复这些丢失数据，保证最终状态的数据是完整的。这种方式跟公司业务也是跟契合的，因为申请贷款的状态会在 7 天内做更新（因为决策引擎系统返回的状态报告也会有几天的延迟，约定 7 天内不返回报告计为未知状态不再更新）。这种方式本意是用作数据更新的，结果顺带缓解了数据漂移。（不算解决是因为 T+1 天到 T+7 天，数据仍然有丢失，不完美）

2、更合理的时间切分字段

既然按照申请贷款时间戳切分，会出现数据漂移，那么就考虑换一个业务场景的时间戳。在申请贷款这个业务场景下，选择放款时间作为时间切分字段。放款一旦发生，就不会变化；放款作为核心关键功能，除非巨大故障也极少发生延迟现象。（当然真的发生了后期再补数据，因不可抗拒因素产生的问题是无解的，只要做到可补救即可）。如果系统有一个统一的放款服务，这个字段的一致性也是有保证的。

但公司没有采用这种切分方式，我的理解是有两个原因：1）存在月结客户，并不是所有客户的业务都是先申请再放款的，一些特殊业务大客户是先放款再申请的。针对这些客户，并不存在真正的放款操作。2）目前放款服务是散落在系统的各个地方的，并没有统一管理起来，导致放款这个操作本就不具备业务逻辑上的统一性。

针对问题 1），其实是有解的，对月结客户仍然可以走一遍放款流程，记录下一个“伪放款时间”，甚至真放款也无不可，无非额度扣成负数。当然公司目前没有这么操作，针对月结客户，额度是直接锁死的。月结客户的还款计划依赖月度的离线计算脚本。这样的操作同时带来了数据不统一的问题，在线客户的账单来自交易记录（放款，系统操作），而月结客户的账单来自申请记录统计（离线统计，脚本计算）。因为这种数据源的不统一，公司的核心账务计算一直不如意，实在是一个遗憾。

针对问题 2），公司的线上申请贷款业务发展了*年，这么多年里新增了许许多多的业务模块、功能、乃至针对大客户的特权特殊服务。放款操作并不统一，甚至存在一小部分客户是非系统操作，而是由计算脚本放款的。不统一的放款服务也带来了一定的混乱局面，实为另一个遗憾。所幸这个问题以及在推进解决中，公司已经在规划一个放款整体的服务，作为各业务线的中台应用，解决这个历史顽疾。当然放款时间作为切分字段，针对申请贷款业务来说是很合适的。可惜并不是所有业务场景下都能找得到这样的业务时间。很多公司的情况有很多许多业务功能，使用单一的业务时间会遗漏很多其他过程的变化记录，比如很常见的电商业务，就有下单、支付、退款、售后等过程，并不适合以某一单一业务时间做切分字段。

3、前后冗余

既然取一天的数据会有数据漂移现象且发生在凌晨，那么自然而然就有一种方式：我们多向前一天要一部分数据，也向后一天多要一部分数据。根据经验，一般是15 分钟。保证数据只多不少，切分时按照需要的业务时间再过滤，这样可以解决那些因为延迟造成的数据漂移，但同时也带来了问题：如果多获取了 T+1 天的一些更新变化，会导致 T 天的最终状态没有被保留，最终存储在 T 天的数据实际是T+1 天凌晨的状态。这对下游的相关统计会造成一些误差。另外，上边提到的特殊业务场景也并没有解决。

4、多时间字段共同限制

这一部分的感受不是很深刻，按照一些文章的说法：根据日志时间冗余前后数据，然后用修改时间过滤非当天数据，这一步几乎和之前描述一样，保证系统原因的遗漏不发生；根据日志时间冗余后一天数据的部分，按照主键以日志时间升序取第一条，为了获取最接近 T 天状态的数据；将 1，2 步骤的数据做全外连接，限制业务时间来获取 T 天数据。

相对而言，贷款申请业务是一种比较单一、简单的业务场景。而简单的业务场景，解决方案自然也比较简单粗暴。目前**某些公司采用的 T+7 重传，很好地解决了数据更新与数据漂移的问题。虽然我认为统一的放款时间做时间切分会更合理，对财务计算更更友好。

关键词：解决方案特殊业务最终状态