业务背景：日亿万级请求日志收集如何不影响主业务

系统简介

• 系统名：电商系统

• 主要功能：

  用户行为日志收集：因业务快速发展，某天某公司的日活用户高达500万，基于当时的业务模式，业务侧要求根据用户的行为做埋点，旨在记录用户在特定页面的所有行为，以便开展数据分析，以及与第三方进行费用结算。

• 限制条件：

  在数据行为日志采集的过程中，业务侧还要求在后台能实时查询用户行为数据及统计报表。

• 业务分析：

  根据业务场景，项目组提炼出了 6 点业务需求，并针对业务需求梳理了技术选型相关思路：

  1. 原始数据海量：对于这一点，初步考虑使用HBase进行持久化。

  2. 对于埋点记录的请求响应要快：埋点记录服务会把原始埋点记录存放在一个缓存层，以此保证响应快速。

  3. 可通过后台查询原始数据：如果直接使用HBase作为查询引擎，查询速度太慢，所以还需要使用Elasticsearch 来保存查询页面上作为查询条件的字段和活动ID。

  4. 各种统计报表的需求：数据可视化工具也有很多选择，比如Kibana、Grafana等，考虑到使用过程的灵活性，最终选择自己设计功能。

  5. 能根据埋点日志生成费用结算数据：将费用结算数据保存在MySQL中。

  6. 需要一个框架将缓存中的数据进行处理，并保存到Elasticsearch、HBase和MySQL中：因为业务有准实时查询的需求，所以需要使用实时处理工具。

• 方案：

  采用了大数据领域中典型的用户行为日志收集架构。

• 结果：

  方案落地以后，丢数据的情况并不多，而且其架构的扩展性也很好，之后日活达到了几千万，系统仍然可以使用，当然，还是要多加机器，并且定时清理一些旧的原始数据。

关键表结构

原始数据结构

指 标	备 注
IMEI	用户设备的 IMEI
定位点	经纬度
用户ID	用户唯一ID
目标 ID	每个页面、按钮、banner都有唯一ID
目标类型	页面、按钮、banner 等
事件动作	点击、进人、跳出等
FromURL	来源 URL
CurrentURL	当前 URL
TOURL	去向 URL
动作时间	触发这个动作的时间
进人时间	进人该页面的时间
跳出时间	跳出该页面的时间

通过以上数据结构，在后台查询原始数据时，业务侧不仅可以将城市（根据经纬度换算）、性别（需要从业务表中抽取）、年龄（需要从业务表中抽取）、目标类型、目标ID、事件动作等作为查询条件来实时查看用户行为数据，还可以从时间（天/周/月/年）、性别、年龄等维度实时查看每个目标ID的总点击数、平均点击次数、每个页面的转化率等作为统计报表数据。

费用结算数据结构

字 段	备 注
日期	结算的日期
目标 ID	原始数据中的目标 ID，比如页面 ID、按钮ID、banner ID
点击人数	有多少人点击了目标 (同一人点多次算一次)
点击人次	有多少人次点击(同一人点多次算多次)
费用	此目标ID当天的收费总计