数据漂移

转载链接：

https://paxinla.github.io/posts/2020/04/qian-tan-shu-ju-piao-yi.html

https://www.twblogs.net/a/5d4518ebbd9eee541c2fee9c/?lang=zh-cn

什么是数据漂移

数据漂移(Data Drift)，指的是将进入数据仓库的数据，偏离标准、正常或预期的情况。它三种表现形式:

Structural Drift ，指的是数据源的数据结构发生了改变，比如字段增减、字段数据类型变更等。

Semantic Drift ，源于(历史)数据的改变，比如过了一段时间后，才发现已入仓库的历史数据有错误等。

Infrastructure Drift ，源于系统依赖的软件或平台发生变化后，与变化前不兼容。

数据漂移的后果主要有3个1:

Garbage in, garbage out.

Trust takes a lifetime to build and only a moment to lose.

The biggest expense is opportunity cost.

传统的 ETL 过程是脆弱且不透明的，这意味着它对 structural drift 和 semantic drift 是敏感的。也就是说发生了“数据漂移”就是发生了异常状况。

如何处理数据漂移

国内面试一般提及“数据漂移”时，通常指的是 semantic drift ，特别是指 ETL 过程中的在预期的计算周期里不是刚好包含了所有预期的数据的情况。比如 ODS 里某个T+1表的同一个业务日期数据中包含前一天或者后一天凌晨附近的数据或者丢失当天的变更数据。这时就丢失了当天的变更数据，或者说“上一天”(D)的数据漂移到了“下一天”(D+1)。

传统的 ETL 过程大多是周期性调度的。典型的 ETL 调度将一系列相互之间有数据依赖关系的 ETL 任务，组织为一个 DAG ，整个 DAG 依据事先设定的调度周期或触发条件启动本轮的执行。

场景一: 因积压造成数据“迟到”

假设，在D日发生的新数据，因网络故障/服务器处理能力等原因积压，在 ETL 过程运行时，尚未完全落到数据源上。待积压解决后，部分D日的数据就被当成了D+1日的数据。这种场景在那些7×24小时连续发生的业务过程上较为常见。

网上有的解决方案是延迟重传。比如在D+4日对D日数据进行重传或重放，就能恢复在D日 ETL 时丢失的数据。这种做法，看起来能“修正”数据仓库中的历史数据，以使其“最终状态”是完整的。还有的方案是，既然知道了数据仓库的数据有漂移的情况，也知道漂移经常发生的时间长度，那么在使用这些数据的时候，就放宽时间窗口，往前往后都“多要”一部分数据。这样取到的数据就没有“丢失”了，但是会有“多余”的数据。

可是，除非数据仓库的下游能接受在D+4日后才使用D日的数据。否则，D日时已丢失数据造成的结果，包括当时进入仓库的数据及依赖于它们的统计数据，都已经对下游造成了影响。对这种场景，我认为要么只能是对 ETL 任务的依赖条件判断上，与源系统达成一致，能明确判断每个周期里，预期的源数据是否全部就绪；要么就接受在D+1日才就绪的数据就属于D+1的数据。其他的方法只能算是“修补”上了漂移的数据，并不算解决了漂移的问题。

场景二: 业务过程里的特例

在业务过程发生时，因对部分特别客户的优待(比如大客户付费时间不固定)或者人为因素不可控(比如某些必须依赖人工提交的D日数据，他就是要在D+1或D+2日提交)等，造成源数据就绪情况难以预测。

对这样的特殊业务，通常也只能根据各个企业自己实际的业务情况，在数据仓库用户的可接受范围内，采取特事特办的处理方法。

小结

如何处理迟到的数据，是 Kimball 的 ETL 子系统里的“迟到数据处理器”关注的情况。

我的看法是，总的来说，数据发生了“漂移”，就可以认为是发生了异常。只能根据每个企业具体场景去事后修补数据，并没有什么自动化的通用方法来处理“漂移”但是可重跑的任务和完整的历史数据，还是对这个修补的过程有助益。。最好还是尽量在设计 ETL 过程时，能够确定好各个数据源的数据就绪条件和判断手段，从根源上尽量避免数据漂移。