統(tǒng)一移動應用數(shù)據(jù)采集與分析平臺設(shè)計與實現(xiàn)

翁湦元，錢克非，郝曉培

（中國鐵道科學研究院集團有限公司 電子計算技術(shù)研究所，北京 100081）

移動應用是用戶訪問移動互聯(lián)網(wǎng)服務(wù)的入口，其用戶體驗、運行效率及穩(wěn)定性尤為重要[1]。當前移動互聯(lián)網(wǎng)服務(wù)的訪問渠道主要有App[2]、微信公眾號[3]、支付寶生活號以及各種應用平臺小程序。為以低成本獲得更多用戶，越來越多的移動互聯(lián)網(wǎng)服務(wù)提供多種訪問渠道，以Web技術(shù)為主的多渠道混合式移動應用逐漸成為主流。

隨著移動終端硬件處理能力和性能不斷增強，以及大數(shù)據(jù)技術(shù)的日漸成熟，由大量移動終端設(shè)備實時產(chǎn)生的海量用戶數(shù)據(jù)可以被快速地采集和分析處理，為移動應用運行質(zhì)量監(jiān)控、用戶行為數(shù)據(jù)實時采集與分析提供了有力支撐。

目前，國內(nèi)較為成熟的移動應用數(shù)據(jù)采集與分析商用方案多為嵌入軟件開發(fā)工具包（SDK，Software Development Kit）形式，需要由開發(fā)人員編寫代碼進行移動應用數(shù)據(jù)采集埋點，并通過定義統(tǒng)計指標來實現(xiàn)業(yè)務(wù)分析。同時，國內(nèi)還有無埋點的解決方案[4]，簡化了移動應用數(shù)據(jù)采集流程，但需要對原始日志數(shù)據(jù)進行二次加工，后續(xù)數(shù)據(jù)分析處理的難度較大。此外，既有的移動應用數(shù)據(jù)采集與分析工具往往是針對不同渠道的移動應用分別設(shè)置數(shù)據(jù)統(tǒng)計指標，不能對多渠道移動應用數(shù)據(jù)進行綜合分析，無法滿足整體業(yè)務(wù)分析需求。

為此，本文結(jié)合實際業(yè)務(wù)需求，研究開發(fā)一套可定制、低代碼侵入的移動應用數(shù)據(jù)采集客戶端，并提供統(tǒng)一的多渠道移動應用監(jiān)控與分析服務(wù)，幫助運營人員全面掌控移動應用的運行情況，及時發(fā)現(xiàn)故障并告警，支持用戶行為分析，對增強服務(wù)穩(wěn)定性、提升用戶體驗有積極作用。

1 平臺設(shè)計

1.1 平臺結(jié)構(gòu)

統(tǒng)一移動應用數(shù)據(jù)采集與分析平臺（簡稱：平臺）分為移動應用端與服務(wù)端2個部分。移動應用端以SDK形式，嵌入進各渠道移動應用中。移動應用端SDK規(guī)定了統(tǒng)一的調(diào)用接口、數(shù)據(jù)結(jié)構(gòu)和處理功能，可實現(xiàn)不同移動互聯(lián)網(wǎng)服務(wù)訪問方式對上層應用的透明。后端SDK完成日志數(shù)據(jù)采集，并通過消息隊列（MQ，Message Queue）[5]服務(wù)將采集的日志數(shù)據(jù)傳輸給移動應用數(shù)據(jù)分析服務(wù)進行處理，如圖1所示。

圖1 統(tǒng)一移動應用數(shù)據(jù)采集與分析平臺結(jié)構(gòu)示意

1.2 移動應用端分層結(jié)構(gòu)

為全面收集移動應用運行情況及用戶行為數(shù)據(jù)，移動應用端SDK應實現(xiàn)以下核心功能：自定義事件采集、錯誤信息采集、頁面核心數(shù)據(jù)采集及數(shù)據(jù)上報。目前主要存在4類移動應用[6]：純Web網(wǎng)頁應用、以微信及支付寶等平臺的小程序應用、基于iOS系統(tǒng)及Android系統(tǒng)開發(fā)的純原生應用、在iOS系統(tǒng)以及Android系統(tǒng)中利用WebView混合H5與原生結(jié)合[7]方式開發(fā)的跨平臺移動應用。在滿足功能需求的同時，移動應用端SDK在架構(gòu)設(shè)計上需兼顧不同的移動應用形式，應具有盡可能低的代碼侵入性、較高的靈活性、可拓展性以及魯棒性。

移動應用端SDK采用分層結(jié)構(gòu)化設(shè)計，劃分為接口層、應用層、數(shù)據(jù)層和網(wǎng)絡(luò)層，如圖2所示。

圖2 移動應用端SDK分層結(jié)構(gòu)設(shè)計

（1）接口層：暴露SDK核心接口，用戶/應用可通過這些接口來調(diào)用移動應用端SDK的核心功能，如初始化與自定義事件的上報等。

（2）應用層：為數(shù)據(jù)采集的核心模塊，負責移動應用端SDK的事件處理接口定義及對應平臺的接口實現(xiàn)，如通用事件處理、錯誤信息處理、頁面信息處理、業(yè)務(wù)信息處理等。同時，應用層提供處理器插件機制[8]，移動應用端SDK初始化時，以不同插件組合的形式兼容不同渠道的移動應用，實現(xiàn)日志數(shù)據(jù)的采集與上報；如移動應用端項目使用Vue框架時，用戶可以在初始化時引入Vue處理器插件和Vue路由處理器插件，插件會對Vue中的錯誤信息、生命周期信息、路由跳轉(zhuǎn)信息等進行自動采集。

（3）數(shù)據(jù)層：為數(shù)據(jù)處理的核心模塊，對應用層采集的原始日志數(shù)據(jù)進行加工處理，并補充移動終端的設(shè)備信息、移動應用端SDK信息、設(shè)備所處網(wǎng)絡(luò)信息、用戶信息等內(nèi)容。

（4）網(wǎng)絡(luò)層：為數(shù)據(jù)傳輸?shù)暮诵哪K，將數(shù)據(jù)層加工后的數(shù)據(jù)進行上傳，實現(xiàn)數(shù)據(jù)的本地暫存、批量上傳、失敗重傳等功能；在上傳數(shù)據(jù)時，會根據(jù)當前運行的移動終端應用類型調(diào)用對應的通信插件，支持多種數(shù)據(jù)傳輸方式，如Web端的XHR、sendBeacon、小程序的request、混合移動應用的橋接方式等。

移動應用端SDK采用分層結(jié)構(gòu)化設(shè)計與統(tǒng)一接口定義，使不同渠道移動應用的日志數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)采集及傳輸功能保持一致，通過為不同渠道移動應用定制處理器與插件，消除了渠道間差異性，實現(xiàn)移動應用的兼容多渠道。

1.3 服務(wù)端結(jié)構(gòu)與基本處理流程

服務(wù)端主要包括日志采集接口服務(wù)、Web服務(wù)、消息隊列服務(wù)、日志數(shù)據(jù)處理服務(wù)、實時分析服務(wù)、離線分析服務(wù)、實時監(jiān)控服務(wù)、數(shù)據(jù)存儲集群、數(shù)據(jù)庫及開放查詢服務(wù)，如圖3所示。

圖3 服務(wù)端結(jié)構(gòu)示意

（1）日志數(shù)據(jù)采集分為網(wǎng)關(guān)采集和Web服務(wù)采集2種方式，分別由日志采集接口服務(wù)和Web服務(wù)負責完成。對于小程序、App應用，通過Token[9]加密的用戶身份數(shù)據(jù)由網(wǎng)關(guān)解密并提取用戶身份信息后，發(fā)送至日志采集接口服務(wù)，用以生成完整的日志數(shù)據(jù)。對于基于會話的Web服務(wù)，則直接從服務(wù)內(nèi)部維持的會話中提取用戶身份信息。

（2）消息隊列服務(wù)負責兩方面任務(wù)：①將日志采集接口服務(wù)以及Web服務(wù)生成的日志數(shù)據(jù)傳輸至日志數(shù)據(jù)處理服務(wù)；②將實時分析服務(wù)產(chǎn)生的結(jié)果傳輸至實時監(jiān)控服務(wù)。采用消息隊列服務(wù)傳輸數(shù)據(jù)可使不同服務(wù)間的數(shù)據(jù)處理解耦[10]，保證平臺的可擴展性與健壯性；同時，消息隊列服務(wù)也作為日志數(shù)據(jù)緩沖區(qū)，可避免瞬時生成的大量數(shù)據(jù)對實時分析服務(wù)、數(shù)據(jù)存儲集群以及實時監(jiān)控服務(wù)造成沖擊。

（3）日志處理服務(wù)從消息隊列服務(wù)接收日志數(shù)據(jù)，進行日志數(shù)據(jù)校驗，并將校驗后的日志數(shù)據(jù)復制分發(fā)至實時分析服務(wù)以及數(shù)據(jù)存儲集群。

（4）實時分析服務(wù)從日志數(shù)據(jù)處理服務(wù)接收日志數(shù)據(jù)，按統(tǒng)計要求在緩存中完成實時計算，保證統(tǒng)計結(jié)果的實時性；在數(shù)據(jù)處理過程中，統(tǒng)計指標計算結(jié)果可通過消息隊列服務(wù)傳輸至實時監(jiān)控服務(wù)。

（5）實時監(jiān)控服務(wù)為運維人員提供移動應用的實時運行狀態(tài)信息，并在移動應用發(fā)生故障時發(fā)出告警。

（6）離線分析服務(wù)使用Spark[11]作為離線分析引擎，對存儲在數(shù)據(jù)存儲集群中的日志數(shù)據(jù)進行處理分析，滿足報表生成、定制化分析需求，提供更精確的數(shù)據(jù)，用于糾正實時分析服務(wù)的分析結(jié)果。

（7）數(shù)據(jù)存儲集群采用Hadoop分布式文件系統(tǒng)（HDFS）[12]，能支持高吞吐量的數(shù)據(jù)訪問，非常適合大規(guī)模數(shù)據(jù)集上的應用。

（8）數(shù)據(jù)庫采用傳統(tǒng)關(guān)系型數(shù)據(jù)庫PostgreSQL，用于存儲由實時分析服務(wù)與離線分析服務(wù)處理生成的日志數(shù)據(jù)分析結(jié)果。

（9）開放查詢服務(wù)為平臺用戶提供數(shù)據(jù)統(tǒng)計指標的查詢功能。

2 日志數(shù)據(jù)結(jié)構(gòu)及處理流程

2.1 日志數(shù)據(jù)結(jié)構(gòu)

日志數(shù)據(jù)（LogPayload）包括業(yè)務(wù)數(shù)據(jù)（Business）、設(shè)備數(shù)據(jù)（Device）、事件數(shù)據(jù)（Event）、用戶數(shù)據(jù)（User）、日志采集器版本數(shù)據(jù)（SDKVer）、設(shè)備所處網(wǎng)絡(luò)數(shù)據(jù)（Network）。日志數(shù)據(jù)實體關(guān)系如圖4所示。

圖4 日志數(shù)據(jù)結(jié)構(gòu)

圖4中，業(yè)務(wù)數(shù)據(jù)（Business）記錄了日志數(shù)據(jù)來源的移動應用和渠道的信息，是實現(xiàn)跨渠道分析的基礎(chǔ)。設(shè)備數(shù)據(jù)（Device）記錄了運行移動應用的終端設(shè)備的品牌、型號、屏幕尺寸和設(shè)備簽名等硬件信息。事件數(shù)據(jù)（Event）記錄了移動應用運行中以及用戶操作時發(fā)生事件的信息，如頁面訪問、自定義事件、頁面異常等。日志采集器版本數(shù)據(jù)（SDKVer）記錄了采集日志數(shù)據(jù)的客戶端的版本等基本信息。設(shè)備所處網(wǎng)絡(luò)數(shù)據(jù)（Network）記錄了客戶端側(cè)網(wǎng)絡(luò)情況。為確保信息安全，用戶數(shù)據(jù)（User）不是由終端設(shè)備直接生成，而是由網(wǎng)關(guān)或Web服務(wù)從服務(wù)訪問請求中提取用戶信息來生成的。

2.2 日志數(shù)據(jù)處理流程

2.2.1 日志數(shù)據(jù)采集流程

日志數(shù)據(jù)以JSON[13]形式進行傳輸，由原生App渠道產(chǎn)生的日志數(shù)據(jù)使用RPC加密方式傳輸，小程序和Web等渠道產(chǎn)生的日志數(shù)據(jù)則采用HTTPS方式傳輸。日志數(shù)據(jù)在發(fā)送前統(tǒng)一進行簽名處理和壓縮，以最大限度地保證數(shù)據(jù)傳輸效率和數(shù)據(jù)安全。

日志數(shù)據(jù)在由移動終端產(chǎn)生直至最終被數(shù)據(jù)分析服務(wù)處理的過程中，是逐步被豐富完善的，完整的日志數(shù)據(jù)采集流程如圖5所示。

圖5 完整的日志數(shù)據(jù)采集流程

移動終端采集的原始日志數(shù)據(jù)經(jīng)過加密、壓縮后，通過網(wǎng)絡(luò)進行傳輸；在網(wǎng)絡(luò)傳輸過程中，內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN，Content Delivery Network）服務(wù)商會根據(jù)用戶設(shè)備IP地址，在日志數(shù)據(jù)中添加用戶地理位置等信息，并將其傳輸至服務(wù)端；網(wǎng)關(guān)或者Web服務(wù)對所接收的用戶信息進行解密后，將用戶信息添加進日志數(shù)據(jù)中，并將日志數(shù)據(jù)傳遞給日志采集服務(wù)；日志采集服務(wù)對日志數(shù)據(jù)進行校驗、規(guī)范化處理后，再通過消息隊列服務(wù)轉(zhuǎn)發(fā)至數(shù)據(jù)分析服務(wù)進行處理。

2.2.2 日志數(shù)據(jù)分析流程

日志數(shù)據(jù)經(jīng)過日志處理服務(wù)的校驗與復制后，分別用于實時分析與離線分析，具體的日志數(shù)據(jù)分析流程，如圖6所示。

圖6 日志數(shù)據(jù)分析流程

日志數(shù)據(jù)通過消息隊列服務(wù)發(fā)送給日志處理服務(wù)，經(jīng)過二次校驗后，分別投遞給數(shù)據(jù)緩存（用于分類計數(shù)[14]）和數(shù)據(jù)存儲集群（用于存儲原始日志數(shù)據(jù)）。

實時分析服務(wù)定時讀取緩存中的分類計數(shù)數(shù)據(jù)，對其進行匯總處理后，作為實時統(tǒng)計結(jié)果保存在數(shù)據(jù)庫中，同時通過消息隊列服務(wù)將實時統(tǒng)計結(jié)果傳輸給實時監(jiān)控服務(wù)。

離線分析服務(wù)從數(shù)據(jù)存儲集群中讀取原始日志數(shù)據(jù)進行分析處理，滿足更精確的數(shù)據(jù)分析、歷史數(shù)據(jù)定制化統(tǒng)計查詢、以及數(shù)據(jù)報表查詢等實時性要求不高的應用需求。

3 日志統(tǒng)計分析

利用采集的日志數(shù)據(jù)，可以針對不同業(yè)務(wù)需求開展統(tǒng)計分析，目前已實現(xiàn)數(shù)據(jù)大盤、渠道來源分析、事件轉(zhuǎn)化分析。

（1） 數(shù)據(jù)大盤

數(shù)據(jù)大盤可提供跨渠道、跨應用的實時監(jiān)控數(shù)據(jù)概覽，快速掌握各類業(yè)務(wù)的用戶來源分布、用戶訪問情況以及程序異常頻次，如圖7所示。

圖7 數(shù)據(jù)大盤分析

（2） 渠道來源分析

渠道來源分析可揭示各項業(yè)務(wù)在不同渠道（如小程序、App）的用戶分布情況，幫助運營人員評估各渠道應用投放效果分析，如圖8所示。

圖8 渠道來源分析

（3） 事件轉(zhuǎn)化分析

事件轉(zhuǎn)化分析[15]可幫助運營人員掌握用戶在移動應用內(nèi)的使用行為，通過分析漏斗路徑[16]，如圖9所示，了解在服務(wù)提供的各個步驟上用戶轉(zhuǎn)化及流失的情況，精準定位阻礙用戶進入下一個步驟的具體原因，進而指導應用優(yōu)化，以提高用戶轉(zhuǎn)化率。

圖9 事件轉(zhuǎn)化分析（漏斗路徑）

4 關(guān)鍵技術(shù)

4.1 基于Spring Cloud的微服務(wù)技術(shù)

利用Spring Cloud框架，通過服務(wù)拆分與解耦，將平臺服務(wù)端劃分為相對獨立、細粒度的業(yè)務(wù)服務(wù)，提升了系統(tǒng)可擴展性，有助于簡單、高效地進行平臺開發(fā)、部署及升級。

4.2 基于Rabbit MQ的消息隊列技術(shù)

海量數(shù)據(jù)的實時處理采用了具有良好性能的Rabbit MQ技術(shù)，在面對瞬時大流量沖擊時，可起到削峰填谷的作用，以保護后續(xù)的數(shù)據(jù)處理免受影響；此外，消息隊列技術(shù)還實現(xiàn)了數(shù)據(jù)接收程序與數(shù)據(jù)處理程序的異步通信，可使平臺內(nèi)各服務(wù)間充分解耦。

4.3 基于Redis的分布式緩存技術(shù)

采用Redis分布式緩存技術(shù)，對日志數(shù)據(jù)進行解析時，可根據(jù)日志數(shù)據(jù)的不同屬性生成計數(shù)器，并高速完成計數(shù)運算，并對各計數(shù)器計算結(jié)果進行統(tǒng)計計算，實時生成所需的各項統(tǒng)計指標，實現(xiàn)可靈活配置的高性能實時數(shù)據(jù)統(tǒng)計分析功能。

5 結(jié)束語

統(tǒng)一移動應用數(shù)據(jù)采集與分析平臺包括移動應用端與服務(wù)端；移動應用端采用統(tǒng)一的數(shù)據(jù)采集與傳輸框架，分別實現(xiàn)了基于Vue、小程序與混合App框架的SDK，可做到對上層應用透明；服務(wù)端通過消息隊列服務(wù)實現(xiàn)數(shù)據(jù)處理解耦，支持實時處理與離線處理2種數(shù)據(jù)分析模式，兼顧數(shù)據(jù)分析的準確性與實時性。該平臺提供的跨渠道移動應用數(shù)據(jù)采集與分析服務(wù)具有低代碼侵入、易于快速部署的特點，可有效整合來自各種應用終端的日志數(shù)據(jù)，實現(xiàn)移動互聯(lián)網(wǎng)服務(wù)多渠道移動終端應用的集中監(jiān)控與分析。

目前，該平臺基于日志數(shù)據(jù)僅實現(xiàn)了一般性統(tǒng)計分析功能，下一步將針對典型業(yè)務(wù)場景下的用戶行為分析，利用日志數(shù)據(jù)開展深入的專題研究。