系统名：电商系统
主要功能：
用户行为日志收集：因业务快速发展，某天某公司的日活用户高达500万，基于当时的业务模式，业务侧要求根据用户的行为做埋点，旨在记录用户在特定页面的所有行为，以便开展数据分析，以及与第三方进行费用结算。
限制条件：
在数据行为日志采集的过程中，业务侧还要求在后台能实时查询用户行为数据及统计报表。
业务分析：
根据业务场景，项目组提炼出了 6 点业务需求，并针对业务需求梳理了技术选型相关思路：
原始数据海量：对于这一点，初步考虑使用HBase进行持久化。
对于埋点记录的请求响应要快：埋点记录服务会把原始埋点记录存放在一个缓存层，以此保证响应快速。
可通过后台查询原始数据：如果直接使用HBase作为查询引擎，查询速度太慢，所以还需要使用Elasticsearch 来保存查询页面上作为查询条件的字段和活动ID。
各种统计报表的需求：数据可视化工具也有很多选择，比如Kibana、Grafana等，考虑到使用过程的灵活性，最终选择自己设计功能。
能根据埋点日志生成费用结算数据：将费用结算数据保存在MySQL中。
需要一个框架将缓存中的数据进行处理，并保存到Elasticsearch、HBase和MySQL中：因为业务有准实时查询的需求，所以需要使用实时处理工具。
方案：
采用了大数据领域中典型的用户行为日志收集架构。
结果：
方案落地以后，丢数据的情况并不多，而且其架构的扩展性也很好，之后日活达到了几千万，系统仍然可以使用，当然，还是要多加机器，并且定时清理一些旧的原始数据。
IMEI
用户设备的 IMEI
定位点
经纬度
用户ID
用户唯一ID
目标 ID
每个页面、按钮、banner都有唯一ID
目标类型
页面、按钮、banner 等
事件动作
点击、进人、跳出等
FromURL
来源 URL
CurrentURL
当前 URL
TOURL
去向 URL
动作时间
触发这个动作的时间
进人时间
进人该页面的时间
跳出时间
跳出该页面的时间
通过以上数据结构，在后台查询原始数据时，业务侧不仅可以将城市（根据经纬度换算）、性别（需要从业务表中抽取）、年龄（需要从业务表中抽取）、目标类型、目标ID、事件动作等作为查询条件来实时查看用户行为数据，还可以从时间（天/周/月/年）、性别、年龄等维度实时查看每个目标ID的总点击数、平均点击次数、每个页面的转化率等作为统计报表数据。
日期
结算的日期
原始数据中的目标 ID，比如页面 ID、按钮ID、banner ID
点击人数
有多少人点击了目标 (同一人点多次算一次)
点击人次
有多少人次点击(同一人点多次算多次)
费用
此目标ID当天的收费总计