7.数据流水线

       我们看到的数据埋点报表，都得益于对数据的采集清洗和落库，但是目前的代码都崇尚面向对象开发，也就是说采集到的数据入库之前都是在一个一个的对象结构体中，但是入库就需要将这些结构体中的数据解析出来，放入sql语句中才能成功落库，当需要查询并利用数据时候又得从数据库中读出并组装成一个对象结构才能和下游程序相互使用，这个解析组装的过程由于非常规范，已经有现成的代码块可以用来实现，这种已经模块化的代码块就是ORM

       要想实现数据的观测需要从源头了解数据的采集收集清洗落库展示流程

1.数据的采集

需要先进行埋点，所谓的埋点就是在正常的代码中加入监控用户行为或者交互行为的数据统计监测代码，这样的采集可以是记录一个事件的发生或者是描述一个状态。数据的上报格式可以设计成k-v格式或者是数据组合格式。

k-v一般主要用来统计简单的计数，比如按钮点击次数，某个选项选择的个数等，数据组合一般用来记录一组数据，比如一次下载成功需要上报下载地址，下载耗时、下载渠道号等信息

当用户点击某个按钮时候，给这个动作起名为click_button那么k就等于click_button，用户每次点击都会给这个k的value上报一个1，通过这个点击动作的回调代码上报一次1

2.数据的上报

当然虽然是通过回调上报，但是未必是每次+1都实时上报，app的数据统计会先存放到设备的内存或者磁盘上，等待用户启动或者退出app时候或者在其他合适的时候再进行统一上报，这样做主要是错开业务高峰和节省用户流量

3.记录日志

上报到服务器的数据，会存放在服务器磁盘中并不会立刻参与计算，等到服务器负载较为低的时候再进行清洗日志归纳数据整理计算

4.入库&计算

如果日志中数据量非常大，就需要借助hive这样的数据仓库来处理日志，hive可以实现hadoop的分布式计算，并最终将统计数据落库

5.报表展示

数据入库后就方便通过接口或者其余同步机制进行支持前端报表的展示

6.数据报表常见问题

1）数据有上报但是报表展示为0

由于可以通过抓包等形式确定数据是否有上报，如果数据的确上报了但是报表是0所以一定是入库出现问题，因为上报就能够形成日志，那么只可能发生在日志没有成功落库hive仓库可能出现问题

2）数据大范围下降

如果各个异常点的抓包没问题证明上报没问题，日志问题也不大，然而又不是说都没有数据，数据报表还有数据说明数据仓库功能没问题，所以一定是日志到仓库过程丢了日志，有可能是运维的日志迁移导致的

3）数据突然变多

如果单独抓包没有数据多上报问题，且数据只是多并不是没有，所以入库没有问题，那么怀疑有刷量，可以将日志进行ip分析