关于打点系统（选型介绍篇）

打点系统的价值

说到打点系统，我们先要梳理一下为什么打点系统要存在，也就是一个系统的ROI在哪里。

那么我们先看在创业初期阶段，打点系统能给我们带来什么产出呢？

答：页面的PV UV 曝光等数据

这些数据能做什么呢

1、行为预测：

      给产品分析用户的行为，例如一个页面有10个事件，产品可以通过数据查看这些事件触发的分布，用来判断入口设计的是否合理。

2、数据诊断：

      可以结合业务数据作出数据漏斗。曝光→点击→下单→支付→成交等。通过数据漏斗来分析出哪一个阶段的转化出了问题，优化这个阶段的体验。

3、流量评估：

      通过PV UC等数据，来给系统提供更多的流量参考，技术可以用来做压测评估，业务可以通过流量来做一些PR活动，一些广告的售卖等。

打造低成本的打点系统

要做一个打点系统，我们首先要设计他的数据结构，下面我们列一个关键字段

APP区分、用户ID、应用设备、设备号、事件ID、创建时间、业务ID1（商品ID）、业务ID2（订单ID）......

他们我们根据实际业务场景举例，

例1：我们要查看某个商品某天的PV

select cout(*) from 打点表 where 事件ID = 商品P事件 AND 商品ID = XXXX

那么下一步，就是关于技术的选型了。

标准的埋点系统可分为两部分，打点 & 采集。

采集就有很多种方式，有基于MYSQL的，有基于Hadoop的，有基于Steam的，ELK等等。

PS：我要摒除“无埋点”，这种埋点方式比较粗暴，基于CSS变化产生了大量无效数据，虽然他的优点是可以节省大量代码，但却需要在数据上产生很大维护成本，并且信息的存储费用也是一笔不晓得支出。

那我们来具体分析，我们先来看基于日志的，他的做法是，将打点的日志直接落在磁盘上，格式类似于这样

101，1001，IOS，XS201，P100098，2017-05-09 17:23:07.......

再利用日志收集工具，可以使apache flume、Logstash，或者自己写工具，核心实现思路就是流式处理，将日志批量读取到内存中，用split 逗号分隔成字段。

最后是落盘，因为一般打点的数据量都会非常大，大概是PV的百倍以上，经验来看，UV在万级的应用每天的打点日志就应该会达到上亿。在这个数量级上，首先关系型数据库的代表，MYSQL不合适，无法承载这么巨大的量级。那么想到大数据量存储&计算，一定会想到 mongo、hbase、hadoop等一些技术，那我们来剖析一下这些技术。

首先mongo我并不赞同用语生产环境中，在我所知道的企业中，大多数都是用了mongo后，在一定数量级之后会转为hbase，mongo经历了很多版本迭代，但依然没有像hbase一样得到广泛应用。我记得当年我在的公司在mongo的数据达到20TB之后，读写性能急剧下降，几经优化无果后，切换了hbase。

那么说道HBASE，HBASE虽然对分布式支持的很好，但它到目前的版本都存在一个硬伤，就是二级索引。什么是二级索引呢，简单说就是我们自己手动创建的索引，与真实数据是剥离的，并且内存地址是连续的。

比如MYSQL我们就经常会创建二级索引，索引结构是B+tree，与具体数据剥离。

hbase主要以row_key的方式来存储，虽然row_key可以设置为最左前缀的组合索引，但因为row_key的字段是唯一的，因此相当于我们只有主键索引可以用到，这个与我们需要从打点系统里写复杂的where条件的需求不符合。

那么就来说hadoop，hadoop适合大规模数据运算，在这点方面，流式处理是无法与其媲美的，前提是“大规模数据计算”，因此，hadoop适合于我们计算的场景；hadoop的弱点是实时性无法保障，而打点系统对实时性没有很高的要求，完全可以接受t+1的数据。因此hadoop是比较适合打点系统的应用场景。

今天先说到这里，要开工了，下次我要讲一下，如何根据公司的技术栈、服务器资源、数据量等，去全面的权衡利弊，来设计一套符合于自己现状的打点系统。