系列 | 实时数仓实践第二篇NO.2『数据质量』

点击上方蓝色字体，置顶/星标哦

目前10000+人已关注加入我们

  作者

author

诸葛子房，现就职于一线互联网公司，中国Hbase技术社区委员，从事大数据相关工作。了解互联网、大数据，一直在努力的路上。

 

对于一个实时数据产品人员、或者开发人员来说，产品上展示的实时数据，pv、uv、gmv等等，怎么知道这些数据是不是正确的呢？当其他的小组开发的产品的数据(或者其他的数据提供方)又是另外一个数字，那么究竟该如何判断自己的数据还是别人的数据是正确的呢？

这就需要一套实时数据对数方案（实时数仓数据质量之准确性），本文主要从背景、实时数据计算方案、对数方案、总结四方面来介绍，说服老板或者让其他人相信自己的数据是准确的、无误的。

 

一、背景

相信做过实时数据统计的朋友，肯定会遇到一个问题，怎么知道自己算的数据是不是对的呢？比如：pv、uv、dau、gmv、订单等等统计数据。

 

二、实时指标统计

上述流程图描述了一般的实时数据计算流程，接收日志或者MQ到kafka，用Flink进行处理和计算，将最终计算结果存储在redis中，最后查询出redis中的数据给大屏、看板等展示。

但是在整个过程中，不得不思考一下，最后计算出来的存储在redis中指标数据是不是正确的呢？怎么能给用户或者老板一个信服的理由呢？相信这个问题一定是困扰所有做实时数据开发的朋友。

比如说：离线的同事说离线昨天的数据订单是1w，实时昨天的数据确实2w，存在这么大的误差，到底是实时计算出问题了，还是离线出问题了呢？

 

三、实时指标之数据质量

还是拿上面离线和实时的订单数据为例，两者不一致。离线的同事说，这边有明细数据，可以对，但是实时这边只有redis的统计结果数据，肯定是没办法说服别人的。因此，对于上图中加工的实时宽表数据，可以进行持久化，进行存储。

这样，实时数据也有明细数据，就可以和离线数据进行比对了，到底是日志丢失还是消息没有发送或者计算的业务逻辑有问题，就能够一目了然。

这就需要对flink加工的实时宽表进行存储了，这边考虑两种解决方案。

(1) 实时宽表数据存储至elasticsearch

将加工的宽表数据通过Flink写入es，这样可以得到所有数据的明细数据，拿着明细和其他数据提供方进行比对即可。

(2) 实时宽表数据存储至HDFS，通过Hive进行查询

但是有一些朋友可能会说，es对应的sql count、group by语法操作，非常复杂，况且也不是用来做线上服务，而只是用与对数，所以时效性也不需要完全考虑，这样的话，就可以考虑将数据回写至HDFS了。

因此可以考虑采用下图的方案，将加工的宽表通过Flink写入到HDFS，然后新建hive表进行关联HDFS数据进行关联查询。

写HDFS与es相比，存在非常明显的优点：

• a.学习成本低、会sql的基本就可以了，而不需要重新学习es负责的count、group by 等语法操作

• b.可以非常方便地和离线表数据进行关联查询(大多数情况下都是和离线数据比对)，两张Hive表的关联查询，容易找出两张表的数据差异

 

四、总结语

实时计算能提供给用户查看当前的实时统计数据，但是数据的准确性确实一个很大的问题，如何说服用户或者领导数据计算是没有问题的，就需要和其他的数据提供方进行比对了。问题的关键就在于，只要有明细数据，就可以和任意一方进行比对，毕竟有明细数据。不服？我们就对一对啊。

明细数据的存储、设计也很有讲究，可以和离线或者其他提供方的数据字段进行对齐，这样就非常方便进行比对了，而采用hive这种方式又是最简便的方式了，毕竟大多数人都是会sql的，无论开发人员还是数据人员或者BI人员。

觉得内容还不错的话，请分享给更多的朋友哦

您的分享，使我们创作最大的鼓励！

 

▼ 社区推荐 ▼ 

Apache Flink 及大数据领域盛会 Flink Forward Asia 2019 将于 11月28-30日在北京国家会议中心举办，大会议程已上线，后台回复「门票」可免费领取大会门票。

▼ 

▼ 

（点击图片可查看 Flink Forward Asia 2019 详情）

你也「 在看 」吗？