一、平台开发目的

在没有数据分析支撑的情况下，很多时候只能依靠经验来决策，但在现在庞大数据和信息的时代下，光凭经验还不够精准。猎户平台研发的目的就是助力产品运营实现数据驱动，提升产品竞争力。

二、系统架构演变及功能介绍

平台的架构经历了两版升级，主要涉及的方面：丰富埋点数据上报的客户端JS SDK，数据接收子系统解耦成前置模块与提取器模块，优化数据存储模块增加R2M（公司内部Redis产品）及异步刷盘任务，提升系统稳定性抗压性。

猎户监控平台系统架构1.0版2-1

猎户监控平台系统架构2.0版2-2

猎户监控平台最新系统功能2-3

三、SDK埋点数据上报及平台数据接收

1、客户端：目前包括Java SDK，Android/ iOS SDK，JS SDK。Java SDK方式的数据上报是通过发送JMQ消息到平台，其他都是通过Https协议上报数据。

2、基本指标：PV/UV统计的埋点数据上报，如果是需要同时统计PV和UV的只要上报一条数据即可，由数据接收服务端进行拆分。

3、用户访问路径行为埋点数据上报：涉及到多端的情况，下面单独介绍用户访问路径分析的时候具体讲。

4、平台提供公网的Https接口：需要支持jsonp及跨域访问。接收到数据之后数据校验无误的直接写入JMQ，我们将这块功能单独拆出一个前置模块，主要考虑是尽量少依赖，数据无状态，可自由扩容缩容，尽量减少系统上线对线上接收数据的影响。整体处理流程图如下：

平台接收埋点数据流程图3-1

四、平台埋点数据解析PV/UV

不断的拉取前置发出的埋点jmq数据，然后整理落库。其中有两点希望着重说明一下。

第一点：UV的幂等校验问题：当SDK埋点数据需要统计UV的时候，绕不过去的就是如何校验同一个业务同一用户一天之内是否已经统计过了，最初采用的方式估计大部分人都是这样想的，直接在Hbase中建一个表，先根据key查询，如果能查到则表示已统计否则未统计表示数据可以入库，这样的方式在数据存储上肯定没有压力，但当数据量达到一定程度的时候，对Hbase的读写压力是可想而知的，性能自然不能达标。后面又想到既然数据仅需一天内的有效，那么能否将数据存入Redis，这样自然读写性能得到提升，可是存储量上又是个大问题，太费Redis资源了。最后我们通过调研分析采用布隆过滤器原理来处理，因为本平台有个特点就是对校验准确率不是那么严苛，理论上能达到99%就能满足要求，布隆过滤器正是此方面的利器。最后我们采用Redis的BitMap数据结构加布隆过滤器原理顺利解决有限资源和性能瓶颈问题。测试效果是：100W的数据占用Redis5.4M空间，准确率达到99.9999%。

第二点：数据落库存储问题: 最初将拆分整理过的数据直接入库Hbase，可是当数据量达到一定程度的时候，此种方式性能达到瓶颈，不是说Hbase不能扛而是数据量实在太大了。后面我们升级的方案是，先写Redis（Pipeline方式），然后每分钟再定时将Redis里的热点数据刷盘到Hbase（批量方式），Redis里面的数据根据不同时间维度设置过期时间，这样Hbase的压力骤减，Redis的资源消耗也有限，性能得到大幅提升，满足目前系统业务要求。

好了，废话少说直接上图：

数据解析入口整体处理流程图4-1

五、用户访问路径分析

用户访问路径分析整体功能图5-1

1、用户行为数据采集：

客户端通过JS SDK或者Android/iOS SDK，将用户预埋点数据上报猎户监控平台，因为涉及到用户可能在同一设备通过H5页面打开原生（Android/iOS）或者通过原生打开H5页面，但H5又无法获取到设备的信息如：Mac地址、Imei等，所以此处H5通过外部JS SDK生成一个唯一ID叫EID，故需要将设备与EID在数据采集到后进行绑定。

2、每天活跃设备：

在数据获取后以天的维度将设备信息幂等单独存储。因为后面在做数据分析的时候将以设备及天的维度来处理。

3、设备与EID绑定关系：

上面数据采集的时候也讲到了，因为H5无法获取设备信息Mac地址、Imei等，所以当原生打开H5或者H5打开原生的时候，需要H5将EID或者原生将设备信息通过cookie带到下一个页面，页面收到信息之后需将自己的EID或者设备信息上报到猎户监控平台，平台收到EID和设备信息时将记录到后端DB中。用于后边用户访问路径分析时找到相应的访问记录。关系如下图：

设备绑定关系图5-2

4、用户与设备绑定关系：

如果用户是登陆态，上报数据将包含用户登录ID，此时猎户监控平台将用户与设备进行绑定存储DB，有人可能会问，如果一个用户同时在多个设备访问那将如何记录？当前采用的方式是按照最后一条关系记录。因为用户访问路径分析不按照用户ID来做区分，而是按照设备，此处记录仅用于后端运营人员根据用户ID来查询分析单个用户行为。

5、用户访问路径流程分析：

日终将根据每天的活跃用户设备信息按照用户维度逐条从DB中load出，然后按照一定规则拆分成多条链路，这也就形成了用户的访问路径，运行流程如下图：

用户访问路径分析流程图5-3

最终我们将得到如下的结果：

用户访问路径分析结果图5-4

调试数据漏斗图5-5

六、二次业务分析

SDK上报到猎户监控平台的数据，经过整理，拆分转存到大数据平台数据仓库与集市，供业务数据分析师通过HiveSQL做二次数据分析。为更加业务化的个性化的需求提供方便。

七、应对大促我们做的

猎户监控平台经历过2次大促，一次双11，一次618。在这两次考验中我们做了如下应对方案：

扩容JMQ，由于单个JMQ主题分配的broker队列数是有限制的，即使无限扩容应用也不能提升数据拉取量，故将上报数据区分PV、UV并分别分散发送到多个JMQ主题上，同时每个应用单独配置消费不同的JMQ主题，这样消费端拉取数据量的瓶颈得到解决。
使用线程池提升消费JMQ性能。
减少R2M的访问，UV幂等校验由之前的先读取然后写入方式修改为直接写入再根据返回结果判断，建模分析数据由之前的单条写入方式改成PipeLine方式。
增加R2M分片，防止单台机器TPS过高。
增加布隆过滤器容量，提升准确率，hash次数调低，减少R2M的压力。
限制服务器处理最大任务数，防止机器资源耗尽。限制线程池大小，调整拒绝策略为阻塞队列。

八、写在最后

虽然经过优化调整平台已经可靠稳定运行了，但距离高可靠高稳定还有距离，大促高峰时CPU负载超高，存在大量数据积压JMQ，并需要较长时间消费处理，所以后面我们的升级改造方案是：去JMQ而采用更高吞吐量的kafka，去tomcat应用而采用最新的流式计算框架Flink，减少依赖Redis。

我们希望本平台能为产品、运营、数据分析师和管理者提供实时监控、大数据分析完整解决方案，为此我们一直在路上，欢迎感兴趣的小伙伴一起沟通交流。

创作场景

京东支付 - 猎户数据监控平台