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

一、平台开发目的

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

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

平台的架构经历了两版升级，主要涉及的方面：丰富埋点数据上报的客户端 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。

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