一、攜程實時用戶數(shù)據(jù)采集系統(tǒng)設(shè)計實踐

隨著移動互聯(lián)網(wǎng)的興起，特別是近年來，智能手機(jī)、pad 等移動設(shè)備憑借便捷、高效的特點風(fēng)靡全球，同時各類 APP 的快速發(fā)展進(jìn)一步降低了移動互聯(lián)網(wǎng)的接入門檻，越來越多的網(wǎng)民開始從傳統(tǒng) PC 轉(zhuǎn)移至移動終端上。但傳統(tǒng)的基于 PC 網(wǎng)站和訪問日志的用戶數(shù)據(jù)采集系統(tǒng)已經(jīng)無法滿足實時分析用戶行為、實時統(tǒng)計流量屬性和基于位置服務(wù)(LBS)等方面的需求。

我們針對傳統(tǒng)用戶數(shù)據(jù)采集系統(tǒng)在實時性、吞吐量、終端覆蓋率等方面的不足，分析了在移動互聯(lián)網(wǎng)流量劇增的背景下，用戶數(shù)據(jù)采集系統(tǒng)的需求，研究在多種訪問終端和多種網(wǎng)絡(luò)類型的場景下，用戶數(shù)據(jù)實時、高效采集的方法，并在此基礎(chǔ)上設(shè)計和實現(xiàn)實時、有序和健壯的用戶數(shù)據(jù)采集系統(tǒng)。此系統(tǒng)基于 Java NIO 網(wǎng)絡(luò)通信框架(Netty)和分布式消息隊列(Kafka)存儲框架實現(xiàn)，其具有實時性、高吞吐、通用性好等優(yōu)點。

1. 技術(shù)選型和設(shè)計方案：

一個典型的數(shù)據(jù)采集分析統(tǒng)計平臺，對數(shù)據(jù)的處理，主要由如下五個步驟組成：

圖 1(數(shù)據(jù)平臺處理流程)

其中，數(shù)據(jù)采集步驟是最核心的問題，數(shù)據(jù)采集是否豐富、準(zhǔn)確和實時，都直接影響整個數(shù)據(jù)分析平臺的應(yīng)用的效果。本論文關(guān)注的步驟主要在數(shù)據(jù)采集、數(shù)據(jù)傳輸和數(shù)據(jù)建模存儲這三部分。

為滿足數(shù)據(jù)采集服務(wù)實時、高效性、高吞吐量和安全性等方面的要求，同時能借鑒互聯(lián)網(wǎng)大數(shù)據(jù)行業(yè)一些優(yōu)秀開源的解決方案，所以整個系統(tǒng)都將基于 Java 技術(shù)棧進(jìn)行設(shè)計和實現(xiàn)。整個數(shù)據(jù)采集分析平臺系統(tǒng)架構(gòu)如下圖所示：

圖 2(數(shù)據(jù)采集分析平臺系統(tǒng)架構(gòu))

其中整個平臺系統(tǒng)主要包括以上五部分：客戶端數(shù)據(jù)采集 SDK 以 Http(s)/Tcp/Udp 協(xié)議根據(jù)不同的網(wǎng)絡(luò)環(huán)境按一定策略將數(shù)據(jù)發(fā)送到 Mechanic(UBT-Collector) 服務(wù)器。服務(wù)器對采集的數(shù)據(jù)進(jìn)行一系列處理之后將數(shù)據(jù)異步寫入 Hermes(Kafka) 分布式消息隊列系統(tǒng)。為了關(guān)聯(lián)業(yè)務(wù)服務(wù)端用戶業(yè)務(wù)操作埋點、日志，業(yè)務(wù)服務(wù)器需要獲取由客戶端 SDK 統(tǒng)一生成的用戶標(biāo)識(C-GUID)，然后業(yè)務(wù)服務(wù)器將用戶業(yè)務(wù)操作埋點、日志信息以異步方式寫入 Hermes(Kafka) 隊列。

最后數(shù)據(jù)消費分析平臺，都從 Hermes(Kafka) 中消費采集數(shù)據(jù)，進(jìn)行數(shù)據(jù)實時或者離線分析。其中 Mechanic(UBT-Collector) 系統(tǒng)還包括對采集數(shù)據(jù)和自身系統(tǒng)的監(jiān)控，這些監(jiān)控信息先寫入 Hbase 集群，然后通過 Dashboard 界面進(jìn)行實時監(jiān)控。

(1). 基于 NIO 的 Netty 網(wǎng)絡(luò)框架方案

要滿足前面提到的高吞吐、高并發(fā)和多協(xié)議支持等方面的要求。我們調(diào)研了幾種開源異步 IO 網(wǎng)絡(luò)服務(wù)組件(如 Netty、MINI、xSocket)，用它們和 Nginx Web 服務(wù)器進(jìn)行了性能對比，決定采用 Netty 作為采集服務(wù)網(wǎng)絡(luò)組件。下面對它進(jìn)行一些概要介紹：Netty 是一個高性能、異步事件驅(qū)動的 NIO 框架，它提供了對 TCP、UDP 和文件傳輸?shù)闹С郑琋etty 的所有 IO 操作都是異步非阻塞的，通過 Future-Listener 機(jī)制，用戶可以方便的主動獲取或者通過通知機(jī)制獲得 IO 操作結(jié)果。

圖 3(Netty 框架內(nèi)部組件邏輯結(jié)構(gòu))

Netty 的優(yōu)點有：

功能豐富，內(nèi)置了多種數(shù)據(jù)編解碼功能、支持多種網(wǎng)絡(luò)協(xié)議。

高性能，通過與其它主流 NIO 網(wǎng)絡(luò)框架對比，它的綜合性能最佳。

可擴(kuò)展性好，可通過它提供的 ChannelHandler 組件對網(wǎng)絡(luò)通信方面進(jìn)行靈活擴(kuò)展。

易用性，API 使用簡單。

經(jīng)過了許多商業(yè)應(yīng)用的考驗，在互聯(lián)網(wǎng)、網(wǎng)絡(luò)游戲、大數(shù)據(jù)、電信軟件等眾多行業(yè)得到成功商用。

Netty 采用了典型的三層網(wǎng)絡(luò)架構(gòu)進(jìn)行設(shè)計，邏輯架構(gòu)圖如下：

圖 4(Netty 三層網(wǎng)絡(luò)邏輯架構(gòu))

第一層：Reactor 通信調(diào)度層。該層的主要職責(zé)就是監(jiān)聽網(wǎng)絡(luò)的連接和讀寫操作，負(fù)責(zé)將網(wǎng)絡(luò)層的數(shù)據(jù)讀取到內(nèi)存緩沖區(qū)中，然后觸發(fā)各種網(wǎng)絡(luò)事件，例如連接創(chuàng)建、連接激活、讀事件、寫事件等，將這些事件觸發(fā)到 Pipeline 中，再由 Pipeline 充當(dāng)?shù)穆氊?zé)鏈來進(jìn)行后續(xù)的處理

第二層：職責(zé)鏈 Pipeline 層。負(fù)責(zé)事件在職責(zé)鏈中有序的向前(后)傳播，同時負(fù)責(zé)動態(tài)的編排職責(zé)鏈。Pipeline 可以選擇監(jiān)聽和處理自己關(guān)心的事件。

第三層：業(yè)務(wù)邏輯處理層，一般可分為兩類：a. 純粹的業(yè)務(wù)邏輯處理，例如日志、訂單處理。b. 應(yīng)用層協(xié)議管理，例如 HTTP(S) 協(xié)議、FTP 協(xié)議等。

我們都知道影響網(wǎng)絡(luò)服務(wù)通信性能的主要因素有：網(wǎng)絡(luò) I/O 模型、線程(進(jìn)程)調(diào)度模型和數(shù)據(jù)序列化方式。

在網(wǎng)絡(luò) I/O 模型方面，Netty 采用基于非阻塞 I/O 的實現(xiàn)，底層依賴的是 JDK NIO 框架的 Selector。

在線程調(diào)度模型方面，Netty 采用 Reactor 線程模型。常用的 Reactor 線程模型有三種，分別是：

Reactor 單線程模型：Reactor 單線程模型，指的是所有的 I/O 操作都在同一個 NIO 線程上面完成。對于一些小容量應(yīng)用場景，可以使用單線程模型。

Reactor 多線程模型：Rector 多線程模型與單線程模型最大的區(qū)別就是有一組 NIO 線程處理 I/O 操作。主要用于高并發(fā)、大業(yè)務(wù)量場景。

主從 Reactor 多線程模型：主從 Reactor 線程模型的特點是服務(wù)端用于接收客戶端連接的不再是一個單獨的 NIO 線程，而是一個獨立的 NIO 線程池。利用主從 NIO 線程模型，可以解決一個服務(wù)端監(jiān)聽線程無法有效處理所有客戶端連接的性能不足問題。Netty 線程模型并非固定不變的，它可以支持三種 Reactor 線程模型。

在數(shù)據(jù)序列化方面，影響序列化性能的主要因素有：

序列化后的碼流大小(網(wǎng)絡(luò)帶寬占用)。

序列化和反序列化操作的性能(CPU 資源占用)。

并發(fā)調(diào)用時的性能表現(xiàn)：穩(wěn)定性、線性增長等。

Netty 默認(rèn)提供了對 Google Protobuf 二進(jìn)制序列化框架的支持，但通過擴(kuò)展 Netty 的編解碼接口，可以實現(xiàn)其它的高性能序列化框架，例如 Avro、Thrift 的壓縮二進(jìn)制編解碼框架。

通過對 Netty 網(wǎng)絡(luò)框架的分析研究以及對比測試(見后面的可行性分析測試報告)可判斷，基于 Netty 的數(shù)據(jù)采集方案能解決高數(shù)據(jù)吞吐量和數(shù)據(jù)實時收集的難點。

(2). 客戶端數(shù)據(jù)加解密和壓縮方案

對一些明感的采集數(shù)據(jù)，需要在數(shù)據(jù)傳輸過程中進(jìn)行加密處理。目前存在的問題是，客戶端采集代碼比較容易被匿名用戶獲取并反編譯(例如 Android、JavaScript)，導(dǎo)致數(shù)據(jù)加密的算法和密鑰被用戶竊取，較難保證數(shù)據(jù)的安全性。根據(jù)加密結(jié)果是否可以被解密，算法可以分為可逆加密和不可逆加密(單向加密)。具體的分類結(jié)構(gòu)如下：

圖 5(加密算法分類)

密鑰：對于可逆加密，密鑰是加密解算法中的一個參數(shù)，對稱加密對應(yīng)的加解密密鑰是相同的;非對稱加密對應(yīng)的密鑰分為公鑰和私鑰，公鑰用于加密，私鑰用于解密。私鑰是不公開不傳送的，僅僅由通信雙方持有保留;而公鑰是可以公開傳送的。非對稱密鑰還提供一種功能，即數(shù)字簽名。通過私鑰進(jìn)行簽名，公鑰進(jìn)行認(rèn)證，達(dá)到身份認(rèn)證的目的。

根據(jù)數(shù)據(jù)采集客戶端的特點，對于采集數(shù)據(jù)使用對稱加密算法是很明智的選擇，關(guān)鍵是要保證對稱密鑰的安全性。目前考慮的方案主要有：

將加解密密鑰放入 APP 中某些編譯好的 so 文件中，如果是 JavaScript 采集的話，構(gòu)造一個用 C 編寫的算法用于生成密鑰，然后借助 Emscripten 把 C 代碼轉(zhuǎn)化為 JavaScript 代碼，這種方案有較好的混淆作用，讓竊聽者不太容易獲取到對稱密鑰。

將密鑰保存到服務(wù)器端，每次發(fā)送數(shù)據(jù)前，通過 HTTPS 的方式獲取加密密鑰，然后對采集數(shù)據(jù)進(jìn)行加密和發(fā)送。

客戶端和服務(wù)器端保存一份公鑰，客戶端生成一個對稱密鑰 K(具有隨機(jī)性和時效性)，使用公鑰加密客戶端通信認(rèn)證內(nèi)容(UID+K)，并發(fā)送到服務(wù)器端，服務(wù)端收到通信認(rèn)證請求，使用私鑰進(jìn)行解密，獲取到 UID 和對稱密鑰 K，后面每次采集的數(shù)據(jù)都用客戶端內(nèi)存中的 K 進(jìn)行加密，服務(wù)器端根據(jù) UID 找到對應(yīng)的對稱密鑰 K，進(jìn)行數(shù)據(jù)解密。

這三種客戶端數(shù)據(jù)加密方式基本能解決客戶端采集數(shù)據(jù)傳輸?shù)陌踩噪y題。

采集數(shù)據(jù)壓縮。為了節(jié)省流量和帶寬，高效發(fā)送客戶端采集的數(shù)據(jù)，需要使用快速且高壓縮比的壓縮算法，目前考慮使用標(biāo)準(zhǔn)的 GZIP 和定制的 LZ77 算法。

(3). 基于攜程分布式消息中間件 Hermes 的數(shù)據(jù)存儲方案

Hermes 是基于開源的消息中間件 Kafka 且由攜程自主設(shè)計研發(fā)。整體架構(gòu)如圖：

圖 6(Hermes 消息隊列整體架構(gòu))

Hermes 消息隊列存儲有三種類型：

MySQL 適用于消息量中等及以下，對消息治理有較高要求的場景。

Kafka 適用于消息量大的場景。

Broker 分布式文件存儲(擴(kuò)展 Kafka、定制存儲功能)。

由于數(shù)據(jù)采集服務(wù)的消息量非常大，所以采集數(shù)據(jù)需要存儲到 Kafka 中。Kafka 是一種分布式的，基于發(fā)布 / 訂閱的消息系統(tǒng)。它能滿足采集服務(wù)高吞吐量、高并發(fā)和實時數(shù)據(jù)分析的要求。它有如下優(yōu)秀的特性：

以時間復(fù)雜度為 O(1) 的方式提供消息持久化能力，即使對 TB 級以上數(shù)據(jù)也能保證常數(shù)時間復(fù)雜度的訪問性能。

高吞吐率。即使在非常廉價的商用機(jī)器上也能做到單機(jī)支持每秒 100K 條以上消息的傳輸。

支持 Kafka Server 間的消息分區(qū)，及分布式消費，同時保證每個 Partition 內(nèi)的消息順序傳輸。

同時支持離線數(shù)據(jù)處理和實時數(shù)據(jù)處理。

Scale out，即支持在線水平擴(kuò)展。

一個典型的 Kafka 集群中包含若干 Producer(可以是 Web 前端產(chǎn)生的采集數(shù)據(jù)，或者是服務(wù)器日志，系統(tǒng) CPU、Memory 等)，若干 broker(Kafka 支持水平擴(kuò)展，一般 broker 數(shù)量越多，集群吞吐率越高)，若干 Consumer Group，以及一 Zookeeper 集群。Kafka 通過 Zookeeper 管理集群配置，選舉 leader，以及在 Consumer Group 發(fā)生變化時進(jìn)行 rebalance。Producer 使用 push 模式將消息發(fā)布到 broker，Consumer 使用 pull 模式從 broker 訂閱并消費消息。Kafka 拓?fù)浣Y(jié)構(gòu)圖如下：

圖 7(Kafka 拓?fù)浣Y(jié)構(gòu))

我們知道，客戶端用戶數(shù)據(jù)的有序性采集和存儲對后面的數(shù)據(jù)消費和分析非常的重要，但是在一個分布式環(huán)境下，要保證消息的有序性是非常困難的，而 Kafka 消息隊列雖然不能保證消息的全局有序性，但能保證每一個 Partition 內(nèi)的消息是有序的。在用戶數(shù)據(jù)采集和分析的系統(tǒng)中，我們主要關(guān)注的是同一個用戶的數(shù)據(jù)是否能保證有序，如果我們在數(shù)據(jù)采集服務(wù)端能將同一個用戶的數(shù)據(jù)存儲到 Kafka 的同一個 Partition 中，那么就能保證同一個用戶的數(shù)據(jù)是有序的，因此基本上能解決采集數(shù)據(jù)的有序性。

(4). 基于 Avro 格式的數(shù)據(jù)災(zāi)備存儲方案

當(dāng)出現(xiàn)網(wǎng)絡(luò)嚴(yán)重中斷或者 Hermes(Kafka) 消息隊列故障情況下，用戶數(shù)據(jù)需要進(jìn)行災(zāi)備存儲，目前考慮的方案是基于 Avro 格式的本地文件存儲。其中 Avro 是一個數(shù)據(jù)序列化反序列化框架，它可以將數(shù)據(jù)結(jié)構(gòu)或?qū)ο筠D(zhuǎn)化成便于存儲或傳輸?shù)母袷?，Avro 設(shè)計之初就用來支持?jǐn)?shù)據(jù)密集型應(yīng)用，適合于遠(yuǎn)程或本地大規(guī)模數(shù)據(jù)的存儲和交換。

Avro 定義了一個簡單的對象容器文件格式。一個文件對應(yīng)一個模式，所有存儲在文件中的對象都是根據(jù)模式寫入的。對象按照塊進(jìn)行存儲，在塊之間采用了同步記號，塊可以采用壓縮的方式存儲。一個文件由兩部分組成：文件頭和一個或者多個文件數(shù)據(jù)塊。其存儲結(jié)構(gòu)如下圖所示：

圖 8(Avro 對象容器文件格式)

災(zāi)備存儲處理過程是：當(dāng)網(wǎng)絡(luò)異常或者 Hermes(Kafka) 消息隊列出現(xiàn)故障時，將采集的用戶數(shù)據(jù)解析并轉(zhuǎn)化成 Avro 格式后，直接序列化存儲到本地磁盤文件中，數(shù)據(jù)按 Kafka-Topic 分成多個文件存儲，且每小時自動生成一個新的文件。當(dāng)網(wǎng)絡(luò)或者 Hermes(Kafka) 故障恢復(fù)后，后端線程自動讀取磁盤 Avro 文件，將數(shù)據(jù)寫入 Hermes(Kafka) 消息隊列的對應(yīng) Topic 和分區(qū)中。每個文件寫入成功后，自動刪除災(zāi)備存儲文件。這樣能增加用戶數(shù)據(jù)采集服務(wù)的健壯性和增強(qiáng)服務(wù)容錯性。

2. 架構(gòu)設(shè)計方案可行性分析

在相同配置的測試服務(wù)器上(包括數(shù)據(jù)采集服務(wù)器、Hermes(Kafka) 集群)做如下對比實驗測試：(使用 ApacheBenchmark 進(jìn)行 Web 性能壓力測試工具)

(1). Netty VS Nginx 處理網(wǎng)絡(luò)請求對比

在不對采集數(shù)據(jù)進(jìn)行業(yè)務(wù)處理的情況下(即只接請求并做響應(yīng)，不做業(yè)務(wù)處理，也不存儲采集數(shù)據(jù))，在 5000 并發(fā)，Keepalive 模式下均能達(dá)到每秒處理 4 萬多請求，其中 Nginx 的 CPU、內(nèi)存消耗會小一些。測試對比數(shù)據(jù)如下：( ab 參數(shù)： -k –n 10000000 –c 5000)

測試數(shù)據(jù)

(2). Netty 對采集數(shù)據(jù)進(jìn)行業(yè)務(wù)處理

Netty 服務(wù)加上采集數(shù)據(jù)解析相關(guān)業(yè)務(wù)處理，以及處理后的數(shù)據(jù)寫入 Hermes(Kafka) 消息隊列?？梢赃M(jìn)行簡單的間接估算。如果采集服務(wù)要求達(dá)到：每秒處理 3 萬左右請求，99% 的請求完成時間小于 800ms 的目標(biāo)，則采集數(shù)據(jù)解析和存儲流程的處理時間必須在 600ms 以內(nèi)。而這兩步又分為數(shù)據(jù)解析和數(shù)據(jù)存儲，可以分別進(jìn)行壓力測試加以驗證。 根據(jù)我們的壓力測試，采集數(shù)據(jù)解析和存儲也能完全滿足性能要求。

經(jīng)以上對比實驗測試表明，使用 Netty 服務(wù)組件收集、解析數(shù)據(jù)并直接寫入 Hermes(Kafka) 分布式消息隊列的方案初步具備可行性。

二. 相關(guān)數(shù)據(jù)分析產(chǎn)品介紹

基于實時采集到的用戶數(shù)據(jù)和系統(tǒng)監(jiān)控數(shù)據(jù)，我們開發(fā)了一套相關(guān)的數(shù)據(jù)分析產(chǎn)品。產(chǎn)品的內(nèi)容主要分以下幾部分：(1)、API 和頁面性能報表;(2)、頁面訪問和流量;(3)、用戶行為分析;(4)、系統(tǒng)異常崩潰分析;(5)、數(shù)據(jù)實時查詢工具;(6)、采集數(shù)據(jù)排障工具;(7)、其它。

其中詳細(xì)分類如下圖所示：

圖 9(數(shù)據(jù)分析產(chǎn)品分類)

現(xiàn)選取其中幾個比較常見的產(chǎn)品做下簡單介紹：

1. 單用戶瀏覽跟蹤

作用：實時跟蹤用戶瀏覽記錄，幫助產(chǎn)品優(yōu)化頁面訪問流程、幫助用戶排障定位問題。

使用案例：根據(jù)用戶在客戶端上的唯一標(biāo)識 ID，如：手機(jī)號、Email、注冊用戶名、ClientId、VisitorId 等查詢此用戶在某一時間段順序瀏覽過的頁面和每個頁面的訪問時間及頁面停留時長等信息。如果用戶在瀏覽頁面過程中發(fā)生了異常崩潰退出情況，可以結(jié)合應(yīng)用崩潰信息關(guān)聯(lián)查詢到相關(guān)信息。

2 . 頁面轉(zhuǎn)化率

作用：實時查看各個頁面的訪問量和轉(zhuǎn)化情況，幫助分析頁面用戶體驗以及頁面布局問題。

使用案例：用戶首先配置頁面瀏覽路徑，如 p1023 -> p1201 -> p1137 -> p1300，然后根據(jù)用戶配置頁面瀏覽路徑查詢某個時間段各個頁面的轉(zhuǎn)化率情況。如有 1.4 萬用戶進(jìn)入 p1023 頁面, 下一步有 1400 用戶進(jìn)入下一頁面 p1201。這樣可推算出頁面 p1201 的轉(zhuǎn)化率為 10% 左右。這是最簡單的一種頁面轉(zhuǎn)化率，還有間接的頁面轉(zhuǎn)化率，即只匹配第一個和最后一個頁面的訪問量。同時可以按各種維度進(jìn)行條件篩選，比如：網(wǎng)絡(luò)、運(yùn)營商、國家、地區(qū)、城市、設(shè)備、操作系統(tǒng)等等。

3. 用戶訪問流

作用：了解每個頁面的相對用戶量、各個頁面間的相對流量和退出率、了解各維度下頁面的相對流量。

使用案例：用戶選擇查詢維度和時間段進(jìn)行查詢，就能獲取到應(yīng)用從第一個頁面到第 N 個頁面的訪問路徑中，每個頁面的訪問量和獨立用戶會話數(shù)、每個頁面的用戶流向、每個頁面的用戶流失量等信息。

4. 點擊熱力圖

作用：發(fā)現(xiàn)用戶經(jīng)常點擊的模塊或者區(qū)域，判斷用戶喜好、分析頁面中哪些區(qū)域或者模塊有較高的有效點擊數(shù)、應(yīng)用于 A/B 測試，比較不同頁面的點擊分布情況、幫助改進(jìn)頁面交互和用戶體驗。

使用案例：點擊熱力圖查看工具包括 Web 和 APP 端，統(tǒng)計的指標(biāo)包括：原始點擊數(shù)(當(dāng)前選中元素的原始點擊總數(shù))、頁面瀏覽點擊數(shù)(當(dāng)前選中元素的有效點擊數(shù)，同一次頁面瀏覽，多次點擊累計算 1 次點擊)、獨立訪客點擊數(shù)(當(dāng)前選中元素的有效點擊數(shù)， 同一用戶，多次點擊累計算 1 次點擊)。

5. 采集數(shù)據(jù)驗證測試

作用：快速測試是否能正常采集數(shù)據(jù)、數(shù)據(jù)量是否正常、采集的數(shù)據(jù)是否滿足需求等。

使用案例：用戶使用攜程 APP 掃描工具頁面的二維碼，獲取用戶標(biāo)識信息，之后正常使用攜程 APP 過程中，能實時地將采集到的數(shù)據(jù)分類展示在工具頁面中，對數(shù)據(jù)進(jìn)行對比測試驗證。

6. 系統(tǒng)性能報表

作用：監(jiān)控系統(tǒng)各業(yè)務(wù)服務(wù)調(diào)用性能(如 SOA 服務(wù)、RPC 調(diào)用等)、頁面加載性能、APP 啟動時間、LBS 定位服務(wù)、Native-Crash 占比、JavaScript 錯誤占比等。按小時統(tǒng)計各服務(wù)調(diào)用耗時、成功率、調(diào)用次數(shù)等報表信息。

基于前端多平臺(包括 iOS、Android、Web、Hybrid、RN、小程序)數(shù)據(jù)采集 SDK 的豐富的自動化埋點數(shù)據(jù)，我們可以對數(shù)據(jù)、用戶、系統(tǒng)三方面進(jìn)行多維度立體的分析。服務(wù)于系統(tǒng)產(chǎn)品和用戶體驗、用戶留存、轉(zhuǎn)換率及吸引新用戶。

來源：BigdataTina2016