成天看用户埋点数据，知道数据是咋来的吗?

咱们平时看到的报表复杂而多样，可以经过多种纬度的数据评估用户的使用习惯和对应功能的价值。然而这些报表是如何产生的呢?今天我们就看看上报数据一步一步变成报表的大体流程。

全部上报的数据都是为了记录一次事件的发生或者描述一个状态，具体的上报数据能够设计为KEY-VALUE的形式或者数据组合的形式。KEY- VALUE的形式主要用来统计简单的计数类上报，如按钮点击的次数，某个选项的值等，KEY用来区分不一样的事件，VALUE表明事件发生的次数、状态值等;数据组合的主要用来描述一个事件或者状态须要多种属性描述的场景，好比下载成功事件，描述这个事件的数据组合可能包括对应的下载地址、下载渠道来源、下载耗时等信息。

当上报数据设计好后，后续的工做才能正常开展。下面一步一步说。

一、埋点

所谓「埋点」，就是在正常的功能逻辑中添加统计逻辑。拿统计微信右上角「+」的点击次数为例，上报的数据能够采用KEY-VALUE形式，咱们定义 KEY为「CLICK_ADD_BTN」，VALUE的值为点击的次数。当用户点击「+」时，展现菜单的代码会经过按钮的「回调」(详见《聊聊同步、异步和回调》)来触发执行，程序猿在业务代码执行完后，又加上了统计代码，把「CLICK_ADD_BTN」对应的VALUE加1，「+」被统计到了一次使用。

二、上报

并非每统计到一次事件或者状态就会发起数据上报，客户端统计到的数据会先暂时存储在内存或者磁盘上，当用户启动、退出应用程序的时候，或者在其余更合适的时机，将当前周期统计到的事件批量上报到服务器，这样作的目的主要是考虑到与服务器屡次创建链接的性能损耗(详见《不得不知的TCP和UDP》) 和流量问题(相同大小的数据分屡次发送比一次发送要消耗更多流量)，另外客户端在上报具体的统计事件以外，还会将标识用户的ID一并上报，后续用于计算用户相关的数据如日使用用户和留存率等。

三、后台记录日志

数据上报到服务器后，服务器会将客户端上报的原始数据存储到服务器的磁盘中。通常来讲，非强实时性的数据上报到服务器后，并不会当即参与计算，得到最终的统计结果，好比一个功能的日使用次数，日用户数，日留存等数据，而是等到服务器负载较低的时间段利用预先配置的计划任务进行离线处理。这样处理的目的是为了节约服务器资源(钱)，由于你们确定不想由于计算统计数据而影响实时业务的处理效率。

四、计算&入库

报表中展现的数据，并非客户端上报的原始数据，好比「+」的使用次数、使用用户数、日留存率这三组数据，都是经过对客户端上报的「CLICK_ADD_BTN」对应VALUE值的累加并结合上报用户ID二次计算得出的。

若是咱们的产品达到微信这种日登录数五六亿，那么天天上报的统计数据将是海量的，为了从这种海量的数据中计算出「+」的使用次数、使用用户数等信息，就须要用到「数据仓库工具」，好比当下流行的Hive处理工具，它基于Hadoop分布式系统基础框架，利用计算机集群的能力进行分布式计算。当「数据仓库工具」计算出最终的结果后，计划任务会将结果(「+」的日使用次数、日使用用户数等数据)保存到数据库中，也就是「入库」过程。「入库」后的数据才能与前端对接，组成报表展现系统。

通常状况下，原始数据通过数据仓库工具处理后，对应的日志文件还会在服务器上保留一段时间(通常3~7天)，以便追溯统计问题，因此，若是发现统计数据有问题问题，必定要及时反馈给负责的程序猿，不然就会「死」无对证咯。

五、展现

 

当数据「入库」后，报表的展现就水到渠成了。报表系统经过前端页面用户的输入获取查询条件，而后经过后台数据库查询得到结果，在前端展现出来。

这里只是简述了埋点数据上报、统计的大体流程，每一个过程当中还有不少细节要解决，如后台日志乱码问题、客户端异常致使数据丢失等。一旦数据出现问题，常常须要联系各方人员定位缘由。在此呼吁广大的产品大虾必定要关心、爱护为你作统计需求的程序猿，他们上辈子都是偷了蟠桃的孙悟空。

对咯，今天别忘了看报表哦。