统一移动应用数据采集与分析平台设计与实现

翁湦元，钱克非，郝晓培

（中国铁道科学研究院集团有限公司 电子计算技术研究所，北京 100081）

移动应用是用户访问移动互联网服务的入口，其用户体验、运行效率及稳定性尤为重要[1]。当前移动互联网服务的访问渠道主要有App[2]、微信公众号[3]、支付宝生活号以及各种应用平台小程序。为以低成本获得更多用户，越来越多的移动互联网服务提供多种访问渠道，以Web技术为主的多渠道混合式移动应用逐渐成为主流。

随着移动终端硬件处理能力和性能不断增强，以及大数据技术的日渐成熟，由大量移动终端设备实时产生的海量用户数据可以被快速地采集和分析处理，为移动应用运行质量监控、用户行为数据实时采集与分析提供了有力支撑。

目前，国内较为成熟的移动应用数据采集与分析商用方案多为嵌入软件开发工具包（SDK，Software Development Kit）形式，需要由开发人员编写代码进行移动应用数据采集埋点，并通过定义统计指标来实现业务分析。同时，国内还有无埋点的解决方案[4]，简化了移动应用数据采集流程，但需要对原始日志数据进行二次加工，后续数据分析处理的难度较大。此外，既有的移动应用数据采集与分析工具往往是针对不同渠道的移动应用分别设置数据统计指标，不能对多渠道移动应用数据进行综合分析，无法满足整体业务分析需求。

为此，本文结合实际业务需求，研究开发一套可定制、低代码侵入的移动应用数据采集客户端，并提供统一的多渠道移动应用监控与分析服务，帮助运营人员全面掌控移动应用的运行情况，及时发现故障并告警，支持用户行为分析，对增强服务稳定性、提升用户体验有积极作用。

1 平台设计

1.1 平台结构

统一移动应用数据采集与分析平台（简称：平台）分为移动应用端与服务端2个部分。移动应用端以SDK形式，嵌入进各渠道移动应用中。移动应用端SDK规定了统一的调用接口、数据结构和处理功能，可实现不同移动互联网服务访问方式对上层应用的透明。后端SDK完成日志数据采集，并通过消息队列（MQ，Message Queue）[5]服务将采集的日志数据传输给移动应用数据分析服务进行处理，如图1所示。

图1 统一移动应用数据采集与分析平台结构示意

1.2 移动应用端分层结构

为全面收集移动应用运行情况及用户行为数据，移动应用端SDK应实现以下核心功能：自定义事件采集、错误信息采集、页面核心数据采集及数据上报。目前主要存在4类移动应用[6]：纯Web网页应用、以微信及支付宝等平台的小程序应用、基于iOS系统及Android系统开发的纯原生应用、在iOS系统以及Android系统中利用WebView混合H5与原生结合[7]方式开发的跨平台移动应用。在满足功能需求的同时，移动应用端SDK在架构设计上需兼顾不同的移动应用形式，应具有尽可能低的代码侵入性、较高的灵活性、可拓展性以及鲁棒性。

移动应用端SDK采用分层结构化设计，划分为接口层、应用层、数据层和网络层，如图2所示。

图2 移动应用端SDK分层结构设计

（1）接口层：暴露SDK核心接口，用户/应用可通过这些接口来调用移动应用端SDK的核心功能，如初始化与自定义事件的上报等。

（2）应用层：为数据采集的核心模块，负责移动应用端SDK的事件处理接口定义及对应平台的接口实现，如通用事件处理、错误信息处理、页面信息处理、业务信息处理等。同时，应用层提供处理器插件机制[8]，移动应用端SDK初始化时，以不同插件组合的形式兼容不同渠道的移动应用，实现日志数据的采集与上报；如移动应用端项目使用Vue框架时，用户可以在初始化时引入Vue处理器插件和Vue路由处理器插件，插件会对Vue中的错误信息、生命周期信息、路由跳转信息等进行自动采集。

（3）数据层：为数据处理的核心模块，对应用层采集的原始日志数据进行加工处理，并补充移动终端的设备信息、移动应用端SDK信息、设备所处网络信息、用户信息等内容。

（4）网络层：为数据传输的核心模块，将数据层加工后的数据进行上传，实现数据的本地暂存、批量上传、失败重传等功能；在上传数据时，会根据当前运行的移动终端应用类型调用对应的通信插件，支持多种数据传输方式，如Web端的XHR、sendBeacon、小程序的request、混合移动应用的桥接方式等。

移动应用端SDK采用分层结构化设计与统一接口定义，使不同渠道移动应用的日志数据结构、数据采集及传输功能保持一致，通过为不同渠道移动应用定制处理器与插件，消除了渠道间差异性，实现移动应用的兼容多渠道。

1.3 服务端结构与基本处理流程

服务端主要包括日志采集接口服务、Web服务、消息队列服务、日志数据处理服务、实时分析服务、离线分析服务、实时监控服务、数据存储集群、数据库及开放查询服务，如图3所示。

图3 服务端结构示意

（1）日志数据采集分为网关采集和Web服务采集2种方式，分别由日志采集接口服务和Web服务负责完成。对于小程序、App应用，通过Token[9]加密的用户身份数据由网关解密并提取用户身份信息后，发送至日志采集接口服务，用以生成完整的日志数据。对于基于会话的Web服务，则直接从服务内部维持的会话中提取用户身份信息。

（2）消息队列服务负责两方面任务：①将日志采集接口服务以及Web服务生成的日志数据传输至日志数据处理服务；②将实时分析服务产生的结果传输至实时监控服务。采用消息队列服务传输数据可使不同服务间的数据处理解耦[10]，保证平台的可扩展性与健壮性；同时，消息队列服务也作为日志数据缓冲区，可避免瞬时生成的大量数据对实时分析服务、数据存储集群以及实时监控服务造成冲击。

（3）日志处理服务从消息队列服务接收日志数据，进行日志数据校验，并将校验后的日志数据复制分发至实时分析服务以及数据存储集群。

（4）实时分析服务从日志数据处理服务接收日志数据，按统计要求在缓存中完成实时计算，保证统计结果的实时性；在数据处理过程中，统计指标计算结果可通过消息队列服务传输至实时监控服务。

（5）实时监控服务为运维人员提供移动应用的实时运行状态信息，并在移动应用发生故障时发出告警。

（6）离线分析服务使用Spark[11]作为离线分析引擎，对存储在数据存储集群中的日志数据进行处理分析，满足报表生成、定制化分析需求，提供更精确的数据，用于纠正实时分析服务的分析结果。

（7）数据存储集群采用Hadoop分布式文件系统（HDFS）[12]，能支持高吞吐量的数据访问，非常适合大规模数据集上的应用。

（8）数据库采用传统关系型数据库PostgreSQL，用于存储由实时分析服务与离线分析服务处理生成的日志数据分析结果。

（9）开放查询服务为平台用户提供数据统计指标的查询功能。

2 日志数据结构及处理流程

2.1 日志数据结构

日志数据（LogPayload）包括业务数据（Business）、设备数据（Device）、事件数据（Event）、用户数据（User）、日志采集器版本数据（SDKVer）、设备所处网络数据（Network）。日志数据实体关系如图4所示。

图4 日志数据结构

图4中，业务数据（Business）记录了日志数据来源的移动应用和渠道的信息，是实现跨渠道分析的基础。设备数据（Device）记录了运行移动应用的终端设备的品牌、型号、屏幕尺寸和设备签名等硬件信息。事件数据（Event）记录了移动应用运行中以及用户操作时发生事件的信息，如页面访问、自定义事件、页面异常等。日志采集器版本数据（SDKVer）记录了采集日志数据的客户端的版本等基本信息。设备所处网络数据（Network）记录了客户端侧网络情况。为确保信息安全，用户数据（User）不是由终端设备直接生成，而是由网关或Web服务从服务访问请求中提取用户信息来生成的。

2.2 日志数据处理流程

2.2.1 日志数据采集流程

日志数据以JSON[13]形式进行传输，由原生App渠道产生的日志数据使用RPC加密方式传输，小程序和Web等渠道产生的日志数据则采用HTTPS方式传输。日志数据在发送前统一进行签名处理和压缩，以最大限度地保证数据传输效率和数据安全。

日志数据在由移动终端产生直至最终被数据分析服务处理的过程中，是逐步被丰富完善的，完整的日志数据采集流程如图5所示。

图5 完整的日志数据采集流程

移动终端采集的原始日志数据经过加密、压缩后，通过网络进行传输；在网络传输过程中，内容分发网络（CDN，Content Delivery Network）服务商会根据用户设备IP地址，在日志数据中添加用户地理位置等信息，并将其传输至服务端；网关或者Web服务对所接收的用户信息进行解密后，将用户信息添加进日志数据中，并将日志数据传递给日志采集服务；日志采集服务对日志数据进行校验、规范化处理后，再通过消息队列服务转发至数据分析服务进行处理。

2.2.2 日志数据分析流程

日志数据经过日志处理服务的校验与复制后，分别用于实时分析与离线分析，具体的日志数据分析流程，如图6所示。

图6 日志数据分析流程

日志数据通过消息队列服务发送给日志处理服务，经过二次校验后，分别投递给数据缓存（用于分类计数[14]）和数据存储集群（用于存储原始日志数据）。

实时分析服务定时读取缓存中的分类计数数据，对其进行汇总处理后，作为实时统计结果保存在数据库中，同时通过消息队列服务将实时统计结果传输给实时监控服务。

离线分析服务从数据存储集群中读取原始日志数据进行分析处理，满足更精确的数据分析、历史数据定制化统计查询、以及数据报表查询等实时性要求不高的应用需求。

3 日志统计分析

利用采集的日志数据，可以针对不同业务需求开展统计分析，目前已实现数据大盘、渠道来源分析、事件转化分析。

（1） 数据大盘

数据大盘可提供跨渠道、跨应用的实时监控数据概览，快速掌握各类业务的用户来源分布、用户访问情况以及程序异常频次，如图7所示。

图7 数据大盘分析

（2） 渠道来源分析

渠道来源分析可揭示各项业务在不同渠道（如小程序、App）的用户分布情况，帮助运营人员评估各渠道应用投放效果分析，如图8所示。

图8 渠道来源分析

（3） 事件转化分析

事件转化分析[15]可帮助运营人员掌握用户在移动应用内的使用行为，通过分析漏斗路径[16]，如图9所示，了解在服务提供的各个步骤上用户转化及流失的情况，精准定位阻碍用户进入下一个步骤的具体原因，进而指导应用优化，以提高用户转化率。

图9 事件转化分析（漏斗路径）

4 关键技术

4.1 基于Spring Cloud的微服务技术

利用Spring Cloud框架，通过服务拆分与解耦，将平台服务端划分为相对独立、细粒度的业务服务，提升了系统可扩展性，有助于简单、高效地进行平台开发、部署及升级。

4.2 基于Rabbit MQ的消息队列技术

海量数据的实时处理采用了具有良好性能的Rabbit MQ技术，在面对瞬时大流量冲击时，可起到削峰填谷的作用，以保护后续的数据处理免受影响；此外，消息队列技术还实现了数据接收程序与数据处理程序的异步通信，可使平台内各服务间充分解耦。

4.3 基于Redis的分布式缓存技术

采用Redis分布式缓存技术，对日志数据进行解析时，可根据日志数据的不同属性生成计数器，并高速完成计数运算，并对各计数器计算结果进行统计计算，实时生成所需的各项统计指标，实现可灵活配置的高性能实时数据统计分析功能。

5 结束语

统一移动应用数据采集与分析平台包括移动应用端与服务端；移动应用端采用统一的数据采集与传输框架，分别实现了基于Vue、小程序与混合App框架的SDK，可做到对上层应用透明；服务端通过消息队列服务实现数据处理解耦，支持实时处理与离线处理2种数据分析模式，兼顾数据分析的准确性与实时性。该平台提供的跨渠道移动应用数据采集与分析服务具有低代码侵入、易于快速部署的特点，可有效整合来自各种应用终端的日志数据，实现移动互联网服务多渠道移动终端应用的集中监控与分析。

目前，该平台基于日志数据仅实现了一般性统计分析功能，下一步将针对典型业务场景下的用户行为分析，利用日志数据开展深入的专题研究。