統一移動應用數據采集與分析平臺設計與實現

翁湦元，錢克非，郝曉培

（中國鐵道科學研究院集團有限公司 電子計算技術研究所，北京 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種數據分析模式，兼顧數據分析的準確性與實時性。該平臺提供的跨渠道移動應用數據采集與分析服務具有低代碼侵入、易于快速部署的特點，可有效整合來自各種應用終端的日志數據，實現移動互聯網服務多渠道移動終端應用的集中監控與分析。

目前，該平臺基于日志數據僅實現了一般性統計分析功能，下一步將針對典型業務場景下的用戶行為分析，利用日志數據開展深入的專題研究。