DataTalk：迟到的数据该怎样处理？

0x00 前言

本篇是关于数据延迟的处理，这种问题在处理的时候首先应该考虑的事业务场景的特性，因为业务的特性以及业务方对数据的容忍度才是最终决定数据方案的因素。

这个主题参与讨论者比较多，因此有比较多的对话环节。

问题：

一般的app数据采集可能会存在数据上报延时，因此数据会存在两个时间：数据生成的时间和服务器收到的时间。

由于我们底层数据都是按时间来做天的分区，那么该用数据生成的时间还是服务器收到的时间？

回答：

服务器收到时间。

问：

如若用服务器时间。那么面对查询某app或者某用户某天的明细数据的时候这个如何操作？

回答：

有三种方式来处理：

问：

但是即使这样问题还是会存在，有些数据延迟可能会很久。例如一周、一个月才到。

一些定时按天等汇总的dw表操作早就执行过了。即会出现重新在ODS上执行的汇总操作和dw表上的数据不一致。

这是行业原因，车开进地库了，就没有4G信号了。然后车主可能一周后再出车，此时数据才上来。。

答：

这种情况，我有两个建议：

问：

我总结一下大家的大致意思：无论按服务器时间还是数据生成时间，因为dw是定期执行的，数据延迟到达的话无论如何都无法避免。。此时只能针对特定业务来处理，和业务确认一个合理的最大延迟时间。超过最大延迟的丢弃。合理时间内的dw按数据生成时间来做，然后某些在dw上汇总统计操作再定期重跑。

首先，数据延迟会有两种主要的产生原因：数据上报延迟和数据处理延迟，两种都会比较常见，一般情况下第一种更多的会由业务特性引起，第二种则常出现在业务爆量的场景。

本次讨论的主题主要是车联网场景的业务特性造成的数据延迟，面对这种特定业务场景，可以考虑使用数据生成时间。如果对这种延迟敏感度不高的业务来讲，可以考虑直接使用服务器落地时间即可，因为这样对程序的要求会低一些。

另外还有一个数据可解释性的问题存在。

如果要处理延迟数据的话，要想清楚这一块该怎么解释清楚。比如说，今天数据分析来看数据的时候，26号的统计数据有1w条，明天再看的时候26号的数据变成了1.1w条，再过一个月来看，发现26号的数据变成了1.12w条。

特别是涉及到对外数据输出的时候，这种数据的可解释性一定要明确。

欢迎关注我的微信公众号！坚持原创技术分享，您的支持将鼓励我继续创作！打赏

微信支付