我们平时看到的报表复杂而多样，能够通过多种纬度的数据评估用户的使用习惯和对应功能的价值。然而这些报表是如何产生的呢?今天咱们就看看上报数据一步一步变成报表的大致流程。
所有上报的数据都是为了记录一次事件的发生或者描述一个状态，具体的上报数据可以设计为KEY-VALUE的形式或者数据组合的形式。KEY- VALUE的形式主要用来统计简单的计数类上报，如按钮点击的次数，某个选项的值等，KEY用来区分不同的事件，VALUE代表事件发生的次数、状态值等;数据组合的主要用来描述一个事件或者状态需要多种属性描述的场景，比如下载成功事件，描述这个事件的数据组合可能包括对应的下载地址、下载渠道来源、下载耗时等信息。
当上报数据设计好后，后续的工作才能正常开展。下面一步一步说。
1、埋点
所谓「埋点」，就是在正常的功能逻辑中添加统计逻辑。拿统计微信右上角「+」的点击次数为例，上报的数据可以采用KEY-VALUE形式，我们定义 KEY为「CLICK_ADD_BTN」，VALUE的值为点击的次数。当用户点击「+」时，展示菜单的代码会通过按钮的「回调」(详见《聊聊同步、异步和回调》)来触发执行，程序猿在业务代码执行完后，又加上了统计代码，把「CLICK_ADD_BTN」对应的VALUE加1，「+」被统计到了一次使用。
2、上报
并不是每统计到一次事件或者状态就会发起数据上报，客户端统计到的数据会先暂时存储在内存或者磁盘上，当用户启动、退出应用程序的时候，或者在其他更合适的时机，将当前周期统计到的事件批量上报到服务器，这样做的目的主要是考虑到与服务器多次建立连接的性能损耗(详见《不得不知的TCP和UDP》) 和流量问题(相同大小的数据分多次发送比一次发送要消耗更多流量)，另外客户端在上报具体的统计事件之外，还会将标识用户的ID一并上报，后续用于计算用户相关的数据如日使用用户和留存率等。
3、后台记录日志
数据上报到服务器后，服务器会将客户端上报的原始数据存储到服务器的磁盘中。一般来说，非强实时性的数据上报到服务器后，并不会立即参与计算，获得最终的统计结果，比如一个功能的日使用次数，日用户数，日留存等数据，而是等到服务器负载较低的时间段利用预先配置的计划任务进行离线处理。这样处理的目的是为了节约服务器资源(钱)，因为大家肯定不想因为计算统计数据而影响实时业务的处理效率。
4、计算&入库
报表中展示的数据，并不是客户端上报的原始数据，比如「+」的使用次数、使用用户数、日留存率这三组数据，都是通过对客户端上报的「CLICK_ADD_BTN」对应VALUE值的累加并结合上报用户ID二次计算得出的。
如果我们的产品达到微信这种日登陆数五六亿，那么每天上报的统计数据将是海量的，为了从这种海量的数据中计算出「+」的使用次数、使用用户数等信息，就需要用到「数据仓库工具」，比如当下流行的Hive处理工具，它基于Hadoop分布式系统基础框架，利用计算机集群的能力进行分布式计算。当「数据仓库工具」计算出最终的结果后，计划任务会将结果(「+」的日使用次数、日使用用户数等数据)保存到数据库中，也就是「入库」过程。「入库」后的数据才能与前端对接，组成报表展示系统。
一般情况下，原始数据经过数据仓库工具处理后，对应的日志文件还会在服务器上保留一段时间(一般3~7天)，以便追溯统计问题，所以，如果发现统计数据有问题问题，一定要及时反馈给负责的程序猿，否则就会「死」无对证咯。
5、展示
当数据「入库」后，报表的展示就水到渠成了。报表系统通过前端页面用户的输入获取查询条件，然后通过后台数据库查询获得结果，在前端展示出来。
这里只是简述了埋点数据上报、统计的大致流程，每个过程中还有很多细节要解决，如后台日志乱码问题、客户端异常导致数据丢失等。一旦数据出现问题，经常需要联系各方人员定位原因。在此呼吁广大的产品大虾一定要关心、爱护为你做统计需求的程序猿，他们上辈子都是偷了蟠桃的孙悟空。
对咯，今天别忘了看报表哦。
