Flink实时数据，在电商618大屏对数方案

今天收到原创作者投稿，感谢?作者对小晨说数据平台的认可。

作者简介：

目前就职于一线互联网公司，从事大数据相关工作。了解互联网、大数据，一直在努力的路上。

对于一个实时数据产品人员、或者开发人员来说，产品上展示的实时数据，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人员。

关注小晨说数据，获取更多大厂技术干货分享

回复“spark”，“flink”，“机器学习”，“前端”获取海量学习资料～～～