打点系统的价值
说到打点系统，我们先要梳理一下为什么打点系统要存在，也就是一个系统的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是比较适合打点系统的应用场景。
今天先说到这里，要开工了，下次我要讲一下，如何根据公司的技术栈、服务器资源、数据量等，去全面的权衡利弊，来设计一套符合于自己现状的打点系统。
