2014年，馬云提出，“人類正從IT時(shí)代走向DT時(shí)代”。如果說在IT時(shí)代是以自我控制、自我管理為主，那么到了DT (Data Technology)時(shí)代，則是以服務(wù)大眾、激發(fā)生產(chǎn)力為主。以互聯(lián)網(wǎng)(或者物聯(lián)網(wǎng))、云計(jì)算、大數(shù)據(jù)和人工智能為代表的新技術(shù)革命正在滲透至各行各業(yè)，悄悄地改變著我們的生活。

? ? ? 在DT時(shí)代，人們比以往任何時(shí)候更能收集到更豐富的數(shù)據(jù)。IDC的報(bào)告顯示：預(yù)計(jì)到2020年，全球數(shù)據(jù)總量將超過40ZB (相當(dāng)于40萬億GB)，這一數(shù)據(jù)量是2011年的22倍!正在呈“爆炸式”增長(zhǎng)的數(shù)據(jù)，其潛在的巨大價(jià)值有待發(fā)掘。數(shù)據(jù)作為一種新的能源，正在發(fā)生聚變，變革著我們的生產(chǎn)和生活，催生了當(dāng)下大數(shù)據(jù)行業(yè)發(fā)展熱火朝天的盛景。

? ? ? ?但是如果不能對(duì)這些數(shù)據(jù)進(jìn)行有序、有結(jié)構(gòu)地分類組織和存儲(chǔ)，如果不能有效利用并發(fā)掘它，繼而產(chǎn)生價(jià)值，那么它同時(shí)也成為一場(chǎng)“災(zāi)難”。無序、無結(jié)構(gòu)的數(shù)據(jù)猶如堆積如山的垃圾，給企業(yè)帶來的是令人昨舌的高額成本。

? ? ? 同時(shí)，日益豐富的業(yè)態(tài)，也帶來了各種各樣、紛繁復(fù)雜的數(shù)據(jù)需求。如何有效地滿足來自員工、客戶和企業(yè)管理自身的多樣化數(shù)據(jù)需求，提高他們對(duì)數(shù)據(jù)使用的滿意度，是數(shù)據(jù)服務(wù)和數(shù)據(jù)產(chǎn)品需要面對(duì)的挑戰(zhàn)。

? ? ? 如何建設(shè)高效的數(shù)據(jù)模型和體系，使數(shù)據(jù)易用，避免重復(fù)建設(shè)和數(shù)據(jù)不一致，保證數(shù)據(jù)的規(guī)范性；如何有效管理和控制日益增長(zhǎng)的存儲(chǔ)和計(jì)算消耗；如何保證數(shù)據(jù)服務(wù)的穩(wěn)定，保證其性能；如何設(shè)計(jì)有效的數(shù)據(jù)產(chǎn)品高效賦能于外部客戶和內(nèi)部員工，這些給大數(shù)據(jù)系統(tǒng)的建設(shè)提出了更多復(fù)雜的要求。

? ? ? 企業(yè)組織在經(jīng)歷多年的信息化建設(shè)后，散落于各異構(gòu)系統(tǒng)的數(shù)據(jù)每天都在增加，隨著移動(dòng)互聯(lián)網(wǎng)、物聯(lián)網(wǎng)的蓬勃發(fā)展，采集數(shù)據(jù)的渠道和設(shè)備越來越多，數(shù)據(jù)采集作為大數(shù)據(jù)系統(tǒng)體系的第一環(huán)尤為重要。因此三點(diǎn)一四建立了一套標(biāo)準(zhǔn)的數(shù)據(jù)采集體系方案，致力全面、高性能、規(guī)范地完成海量數(shù)據(jù)的采集、并將其傳輸?shù)酱髷?shù)據(jù)平臺(tái)。

? ? ? 騰空數(shù)據(jù)采集系統(tǒng)的日志采集體系方案包括兩大體系：在線采集和離線采集。在線采集是指Web端日志采集、App端日志采集、小程序日志采集、H5日志采集、HTTP API日志采集方案。離線采集是指服務(wù)器日志采集、文本數(shù)據(jù)采集、數(shù)據(jù)庫(kù)同步方案。

? ? ? ?本文對(duì)Web端日志采集、App端日志采集兩個(gè)方面的技術(shù)方案詳細(xì)說明。

騰空采集系統(tǒng)

? ? ? ?騰空數(shù)據(jù)采集系統(tǒng)是三點(diǎn)一四推出的大數(shù)據(jù)采集系統(tǒng)級(jí)產(chǎn)品。騰空使命是為中小型企業(yè)用戶提供數(shù)據(jù)采集、傳輸、清洗、計(jì)算等數(shù)據(jù)上云一站式端到端的綜合解決方案。

? ? ? ?騰空采集系統(tǒng)以助力企業(yè)全面觸網(wǎng)，實(shí)現(xiàn)智能化數(shù)據(jù)決策為使命，提供DT時(shí)代的大數(shù)據(jù)基礎(chǔ)服務(wù)。

• 通過實(shí)時(shí)/離線數(shù)據(jù)采集，快速構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)中心，幫助中小企業(yè)低成本實(shí)現(xiàn)數(shù)據(jù)創(chuàng)新和數(shù)據(jù)決策。
• 中小企業(yè)構(gòu)建PB級(jí)數(shù)據(jù)倉(cāng)庫(kù)，實(shí)現(xiàn)異構(gòu)環(huán)境大規(guī)模數(shù)據(jù)集成，對(duì)數(shù)據(jù)進(jìn)行資產(chǎn)化管理。
• 智能化的監(jiān)控，保障數(shù)據(jù)安全和穩(wěn)定。

采集方案

1. Web端日志采集

? ? ? Web網(wǎng)站產(chǎn)品日志采集可以分為兩大類：

? ? ? （1）頁(yè)面瀏覽日志采集。顧名思義，頁(yè)面瀏覽日志是指當(dāng)一個(gè)頁(yè)面被瀏覽器加載呈現(xiàn)時(shí)采集的日志。此類日志是最基礎(chǔ)的互聯(lián)網(wǎng)日志，也是目前所有互聯(lián)網(wǎng)產(chǎn)品的兩大基本指標(biāo)：頁(yè)面瀏覽量（Page View，PV）和訪客數(shù)（UniqueVisitors，UV）的統(tǒng)計(jì)基礎(chǔ)。頁(yè)面瀏覽日志是目前成熟度和完備度最高，同時(shí)也是最具挑戰(zhàn)性的日志采集任務(wù)，我們將重點(diǎn)講述此類日志的采集。

? ? ? （2）頁(yè)面交互日志采集。當(dāng)頁(yè)面加載和渲染完成之后，用戶可以在頁(yè)面上執(zhí)行各類操作。隨著互聯(lián)網(wǎng)前端技術(shù)的不斷發(fā)展，用戶可以瀏覽器內(nèi)與網(wǎng)頁(yè)進(jìn)行的互動(dòng)已經(jīng)豐富到只有想不到?jīng)]有做不到的程度，互動(dòng)設(shè)計(jì)都要求采集用戶的互動(dòng)行為數(shù)據(jù)，以便通過量化獲知用戶的興趣點(diǎn)或者體驗(yàn)優(yōu)化點(diǎn)。交互日志采集就是為此類業(yè)務(wù)場(chǎng)景而生的。

1.1 頁(yè)面瀏覽日志采集流程

? ? ? 網(wǎng)站頁(yè)面是互聯(lián)網(wǎng)服務(wù)的基本載體，即使在如今傳統(tǒng)互聯(lián)網(wǎng)形態(tài)逐漸讓位于移動(dòng)互聯(lián)網(wǎng)的背景下，HTML頁(yè)面依舊是最普遍的業(yè)務(wù)形態(tài)，對(duì)于以網(wǎng)頁(yè)為基本展現(xiàn)形式的互聯(lián)網(wǎng)產(chǎn)品和服務(wù)，衡量其業(yè)務(wù)水平的基本指標(biāo)是網(wǎng)頁(yè)瀏覽量（PV）和訪客數(shù)（UV）。為此，我們需要采集頁(yè)面被瀏覽加載展現(xiàn)的記錄，這是最原始的互聯(lián)網(wǎng)日志采集需求，也是一切互聯(lián)網(wǎng)數(shù)據(jù)分析得改展開的基礎(chǔ)和前提。

? ? ? 目前典型的網(wǎng)頁(yè)訪問過程是以瀏覽器器請(qǐng)求、服務(wù)器響應(yīng)并返回所請(qǐng)求的內(nèi)容這種模式進(jìn)行的，瀏覽器和服務(wù)器之間的通信普遍遵守HTTP協(xié)議。瀏覽器發(fā)起的請(qǐng)求被稱為HTTP請(qǐng)求，服務(wù)器的返回則被稱為HTTP響應(yīng)。

? ? ? 我們以訪問百度首頁(yè)（www.baidu.com）為例，一次典型的頁(yè)面訪問過程描述如下圖所示。

一次網(wǎng)頁(yè)請(qǐng)求過程

? ? ? （1）用戶在瀏覽器內(nèi)點(diǎn)擊百度首頁(yè)（或在地址欄中輸入www.baidu.com并回車）。

? ? ? （2）瀏覽器向百度服務(wù)器發(fā)起HTTP請(qǐng)求。按照HTTP協(xié)議，一個(gè)標(biāo)準(zhǔn)的HTTP請(qǐng)求由三個(gè)部分組成。

• 請(qǐng)求行——包括請(qǐng)求方法、所請(qǐng)求資源的URL以及HTTP協(xié)議版本號(hào)。
• 請(qǐng)求報(bào)頭——請(qǐng)求報(bào)頭是瀏覽器在請(qǐng)求時(shí)服務(wù)器提交的附加信息。
• 請(qǐng)求正文——這一部分是可選的，一般HTTP請(qǐng)求的正文都是空的，可以忽略。

? ? ? ?（3）服務(wù)器接收并解析請(qǐng)求。服務(wù)器端的業(yè)務(wù)處理模塊按業(yè)務(wù)邏輯處理本次請(qǐng)求并按照HTTP協(xié)議規(guī)定的格式，將處理結(jié)果以HTTP響應(yīng)形式發(fā)回瀏覽器。與HTTP請(qǐng)求相對(duì)應(yīng)，一個(gè)標(biāo)準(zhǔn)的HTTP響應(yīng)也由三部分構(gòu)成。

• 狀態(tài)行——狀態(tài)行標(biāo)識(shí)了服務(wù)器對(duì)于此次HTTP請(qǐng)求的處理結(jié)果。如代表成功響應(yīng)的200和代表所請(qǐng)求的資源在服務(wù)器端沒有找到的404。
• 響應(yīng)報(bào)頭——服務(wù)器在執(zhí)行響應(yīng)時(shí)，同樣可以附加一些數(shù)據(jù)項(xiàng)，這些數(shù)據(jù)項(xiàng)將在瀏覽器端被讀取和使用。
• 響應(yīng)正文——和請(qǐng)求正文一樣，這一部分在協(xié)議中也被定義為可選部分，但對(duì)于大多數(shù)HTTP響應(yīng)而言，這一部分都是非空的，瀏覽器請(qǐng)求的文檔、圖片、腳本等，其實(shí)就是被包裝在正文內(nèi)返回瀏覽器的。

? ? ? ?（4）瀏覽器接收到服務(wù)器的響應(yīng)內(nèi)容，并將其按照文檔規(guī)范展現(xiàn)給用戶，從而完成一一次請(qǐng)求。

? ? ? 上面描述了一次典型的網(wǎng)頁(yè)瀏覽過程，如果需要記錄這次瀏覽行為，則采集日志的動(dòng)作必然是附加在上述四個(gè)步驟中的某一環(huán)節(jié)內(nèi)完成的。在第一步和第二步，用戶的請(qǐng)求尚未抵達(dá)服務(wù)器，而直到第三步完成，我們也只能認(rèn)為服務(wù)器處理了請(qǐng)求，不能保證瀏覽器能夠正確地解析和渲染頁(yè)面，尚不能確保用戶已確實(shí)打開頁(yè)面，因此在前三步是無法采集用戶的瀏覽日志的。那么采集日志的動(dòng)作，需要在第四步，也就是瀏覽器開始解析文檔時(shí)才能進(jìn)行。根據(jù)前文所述，可以很自然地得出在這一模式下最直接的日志采集思路：在HTML文檔內(nèi)的適當(dāng)位置增加一個(gè)日志采集節(jié)點(diǎn)，當(dāng)瀏覽器解析到這個(gè)節(jié)點(diǎn)時(shí)，將自動(dòng)觸發(fā)一個(gè)特定的HTTP請(qǐng)求到日志采集服務(wù)器。如此一來，當(dāng)日志采集服務(wù)器接收到這個(gè)請(qǐng)求時(shí)，就可以確定瀏覽器已經(jīng)成功地接收和打開了頁(yè)面。這就是目前幾乎所有互聯(lián)網(wǎng)網(wǎng)站頁(yè)面瀏覽日志采集的基本原理，而業(yè)界的各類網(wǎng)頁(yè)日志采集的解決方案只是在實(shí)施的細(xì)節(jié)、自動(dòng)采集內(nèi)容的廣度以及部署的便利性上有所不同。

? ? ?目前騰空采用的頁(yè)面瀏覽日志采集方案的流程框架如下圖所示。

頁(yè)面瀏覽日志采集方案流程框架

? ? ?在上圖所示的頁(yè)面瀏覽日志采集過程中，所涉及的日志相關(guān)的幾個(gè)主要過程簡(jiǎn)單介紹如下:

? ? ? （1）客戶端日志采集。日志采集工作一般由一小段被植人頁(yè)面HTML文檔內(nèi)的Javascript腳本來執(zhí)行。采集腳本被瀏覽器加載解析后執(zhí)行，在執(zhí)行時(shí)采集當(dāng)前頁(yè)面參數(shù)、瀏覽行為的上下文信息以及一些運(yùn)行環(huán)境信息。在HTML文檔內(nèi)植人日志采集腳本的動(dòng)作可以由業(yè)務(wù)服務(wù)器在響應(yīng)業(yè)務(wù)請(qǐng)求時(shí)動(dòng)態(tài)執(zhí)行，也可以在開發(fā)頁(yè)面時(shí)由開發(fā)人員手動(dòng)植入。在騰空中，這兩種方式均有采用，其中前一種方式的占比較高，這一點(diǎn)與業(yè)界的普遍狀況有所不同。上圖中的第三、四步描述了騰空業(yè)務(wù)服務(wù)器端植入日志采集腳本的過程。

? ? ? （2）客戶端日志發(fā)送。采集腳本執(zhí)行時(shí)，會(huì)向日志服務(wù)器發(fā)起一個(gè)日志請(qǐng)求，以將采集到的數(shù)據(jù)發(fā)送到日志服務(wù)器。在大多數(shù)情況下，采集完成之后會(huì)立即執(zhí)行發(fā)送；但在個(gè)別場(chǎng)景下，日志采集之后可能會(huì)經(jīng)過一段時(shí)間的延遲才被發(fā)出。日志采集和發(fā)送模塊一般會(huì)集成在同一個(gè)JavaScript腳本文件內(nèi)，且通過互聯(lián)網(wǎng)瀏覽器必然支持的HTTP協(xié)議與日志服務(wù)器通信，采集到的日志信息一般以URL參數(shù)形式放在HTTP日志請(qǐng)求的請(qǐng)求行內(nèi)。

? ? ? （3）服務(wù)器端日志收集。日志服務(wù)器接收到客戶端發(fā)來的日志請(qǐng)求后，一般會(huì)立即向?yàn)g覽器發(fā)回一個(gè)請(qǐng)求成功的響應(yīng)，以免對(duì)頁(yè)面的正常加載造成影響;同時(shí)，日志服務(wù)器的日志收集模塊會(huì)將日志請(qǐng)求內(nèi)容寫人一個(gè)日志緩沖區(qū)內(nèi)，完成此條瀏覽日志的收集。

? ? ? （4）服務(wù)器端日志解析存檔。服務(wù)器接收到的瀏覽日志進(jìn)入緩沖區(qū)后，會(huì)被一段專門的日志處理程序順序讀出并按照約定的日志處理邏輯解析。由日志采集腳本記錄在日志請(qǐng)求行內(nèi)的參數(shù)，將在這個(gè)環(huán)節(jié)被解析（有時(shí)候伴隨著轉(zhuǎn)義和解碼）出來，轉(zhuǎn)存人標(biāo)準(zhǔn)的日志文件中并注人實(shí)時(shí)消息通道內(nèi)供其他后端程序讀取和進(jìn)一-步加工處理。

? ? ? ?經(jīng)過采集——發(fā)送——收集——解析存檔四個(gè)步驟，我們將一次頁(yè)面瀏覽日志成功地記錄下來?？梢?，除了采集代碼在某些場(chǎng)合下需要手動(dòng)的人之外，整個(gè)過程基本都是依照HTML規(guī)范和HTTP協(xié)議自動(dòng)進(jìn)行的，這種依賴協(xié)議和規(guī)范自動(dòng)運(yùn)行的采集機(jī)制最大限度地減少了人工干預(yù)的擾動(dòng)，進(jìn)而保證了日志的準(zhǔn)確性。

? ? ? 騰空的頁(yè)面瀏覽日志采集框架，不僅指定了上述的采集技術(shù)方案，同時(shí)也規(guī)定了PV日志的采集標(biāo)準(zhǔn)規(guī)范，其中規(guī)定了PV日志應(yīng)采集和可采集的數(shù)據(jù)項(xiàng)，并對(duì)數(shù)據(jù)格式做了規(guī)定。這些格式化日志，為后續(xù)的日志加工和計(jì)算得以順利開展打下了基礎(chǔ)。

1.2 頁(yè)面交互日志采集流程

? ? ? ?PV日志的采集解決了頁(yè)面流量和流量來源統(tǒng)計(jì)的問題，但隨著互聯(lián)網(wǎng)業(yè)務(wù)的發(fā)展，僅了解用戶到訪過的頁(yè)面和訪問路徑，已經(jīng)遠(yuǎn)遠(yuǎn)不能滿足用戶細(xì)分研究的需求。在很多場(chǎng)合下，需要了解用戶在訪問某個(gè)頁(yè) ?滿足用戶細(xì)分研究的需求。在很多場(chǎng)合下， ?人焦點(diǎn)的 ?移動(dòng)變化(代表用戶面時(shí)具體的互動(dòng)行為特征，比如鼠標(biāo)或輸入焦點(diǎn)的移動(dòng)變化、對(duì)某些頁(yè)面交互的反應(yīng)等。因?yàn)檫@些行為往往并不觸發(fā)瀏覽器加載新頁(yè)面，所以無法通過常規(guī)的PV日志采集方法來收集。

? ? ? ?因?yàn)榻K端類型、頁(yè)面內(nèi)容、交互方式和用 ?戶實(shí)際行為的千變?nèi)f化不可預(yù)估，交互日志的采集和PV日志的采集不同，無法規(guī)定統(tǒng)一的采集內(nèi)容。例如，活動(dòng)頁(yè)面的游戲交互和購(gòu)物車頁(yè)面的功能交互兩者相比，所需記錄的行為類型、行為數(shù)據(jù)以及數(shù)據(jù)的結(jié)構(gòu)化程度都截然不同，呈現(xiàn)出高度自定義的業(yè)務(wù)特征。與之相適應(yīng)，在騰空的日志采集實(shí)踐中，交互日志的采集是以技術(shù)服務(wù)的形式呈現(xiàn)的。

? ? ? 具體而言，交互日志采集是一個(gè)開放的基于HTTP協(xié)議的日志服務(wù)，需要采集交互日志的業(yè)務(wù)，經(jīng)過如下步驟即可將自助采集的交互日志發(fā)送到日志服務(wù)器。

? ? ? （1）業(yè)務(wù)方在交互日志采集的元數(shù)據(jù)管理界面依次注冊(cè)需要采集交互日志的業(yè)務(wù)，具體的業(yè)務(wù)場(chǎng)景以及場(chǎng)景下的具體交互采集點(diǎn)，在注冊(cè)完成之后，系統(tǒng)將生成與之對(duì)應(yīng)的交互日志采集代碼模板。

? ? ? （2）業(yè)務(wù)方將交互日志采集代碼植入目標(biāo)頁(yè)面，并將采集代碼與需要監(jiān)測(cè)的交互行為做綁定。

? ? ? （3）當(dāng)用戶在頁(yè)面上產(chǎn)生指定行為時(shí)，采集代碼和正常的業(yè)務(wù)互動(dòng)響應(yīng)代碼一起被觸發(fā)和執(zhí)行。

? ? ? （4）采集代碼在采集動(dòng)作完成后將對(duì)應(yīng)的日志通過HTTP協(xié)議發(fā)送到日志服務(wù)器，日志服務(wù)器接收到日志后，對(duì)于保存在HTTP請(qǐng)求參數(shù)部分的自定義數(shù)據(jù)，即用戶上傳的數(shù)據(jù)，原則上不做解析處理，只做簡(jiǎn)單的轉(zhuǎn)儲(chǔ)。

? ? ? ?經(jīng)過上述步驟采集到的日志服務(wù)器的業(yè)務(wù)隨后可被業(yè)務(wù)方按需自行解析處理，并可與正常的PV日志做關(guān)聯(lián)運(yùn)算。

2. App端日志采集

? ? ? 眾所周知，日志采集多是為了進(jìn)行后續(xù)的數(shù)據(jù)分析。移動(dòng)端的數(shù)據(jù)采集，一是為了服務(wù)于開發(fā)者，協(xié)助開發(fā)者分析各類設(shè)備信息；二是為了幫助各APP更好地了解自己的用戶，了解用戶在APP上的各類行為，幫助各應(yīng)用不斷進(jìn)行優(yōu)化，提升用戶體驗(yàn)。

? ? ? 無線客戶端的日志采集采用采集SDK來完成，在三點(diǎn)一四騰空系統(tǒng)中，多使用名為TengKong的SDK來進(jìn)行無線客戶端的日志采集。無線客戶端的日志采集和瀏覽器的日志采集方式有所不同，移動(dòng)端的日志采集根據(jù)不同的用戶行為分成不同的事件，“事件”為無線客戶端日志行為的最小單位?；诔Ｒ?guī)的分析，TengKong（TK）把事件分成了幾類，常用的包括頁(yè)面事件（同前述的頁(yè)面瀏覽）和控件點(diǎn)擊事件（同前述的頁(yè)面交互）等。

? ? ? 對(duì)事件進(jìn)行分類的原因，除了不同事件的日志觸發(fā)時(shí)機(jī)、日志內(nèi)容和實(shí)現(xiàn)方式有差異之外，另一方面是為了更好地完成數(shù)據(jù)分析。在常見的業(yè)務(wù)分析中，往往較多地涉及某類事件，而非全部事件；故為了降低后續(xù)處理的復(fù)雜性，對(duì)事件進(jìn)行分類尤為重要。要更好地進(jìn)行日志數(shù)據(jù)分析，涉及很多方面的內(nèi)容，如需要處理Hybrid應(yīng)用，實(shí)現(xiàn)H5和Native日志的統(tǒng)一；又如識(shí)別設(shè)備，保證同一設(shè)備上各應(yīng)用獲取到的設(shè)備信息是唯一的。除此之外，對(duì)于采集到的數(shù)據(jù)如何上傳，以及后續(xù)又如何合理處理等，每個(gè)過程都值得我們進(jìn)行深入的研究和探索。

2.1 頁(yè)面事件

? ? ? 從實(shí)現(xiàn)方法上說，日志采集SDK對(duì)于不同事件的實(shí)現(xiàn)，大致是類似的；只是對(duì)于通用的用戶行為，抽象出來一些通用的接口方法。我們把常用的行為類別單獨(dú)列出來，作為單獨(dú)的事件來處理，如本節(jié)要講的頁(yè)面事件（頁(yè)面瀏覽行為）。每條頁(yè)面事件日志記錄三類信息：①設(shè)備及用戶的基本信息；②被訪問頁(yè)面的信息，這里主要是一些業(yè)務(wù)參數(shù)（如商品詳情頁(yè)的商品ID、所屬的店鋪等）；③訪問基本路徑（如頁(yè)面來源、來源的來源等），用于還原用戶完整的訪問行為。

? ? ? 對(duì)于頁(yè)面事件，不同的SDK有不同的實(shí)現(xiàn)，有些采集SDK選擇在頁(yè)面創(chuàng)建時(shí)即發(fā)送日志。結(jié)合業(yè)務(wù)分析，TK提供了頁(yè)面事件的無痕埋點(diǎn)，即無須開發(fā)者進(jìn)行任何編碼即可實(shí)現(xiàn)。本處主要講一下手動(dòng)模式的埋點(diǎn)。TK提供了兩個(gè)接口，分別在頁(yè)面展現(xiàn)和頁(yè)面退出時(shí)調(diào)用。當(dāng)進(jìn)入App頁(yè)面時(shí)，調(diào)用頁(yè)面展現(xiàn)的接口，該接口會(huì)記錄頁(yè)面進(jìn)人時(shí)的一些狀態(tài)信息，但此時(shí)不發(fā)送日志，當(dāng)從該頁(yè)面離開時(shí)，調(diào)用頁(yè)面退出的接口，該接口會(huì)發(fā)送日志。除了基礎(chǔ)的兩個(gè)接口外，還提供了添加頁(yè)面擴(kuò)展信息的接口；在頁(yè)面離開前，使用該接口提供的方法給頁(yè)面添加相關(guān)參數(shù)。

? ? ? 顯然，上述三個(gè)接口方法必須配合使用，即頁(yè)面展現(xiàn)和頁(yè)面退出方法必須成對(duì)使用，而頁(yè)面擴(kuò)展信息的接口必須在使用頁(yè)面展現(xiàn)和頁(yè)面退出方法的前提下使用。再來說說，為什么不在頁(yè)面進(jìn)人時(shí)就發(fā)送日志，而是在頁(yè)面離開時(shí)才發(fā)送日志呢？可以思考一下：基于瀏覽器的日志采集，在每次頁(yè)面進(jìn)人時(shí)就實(shí)現(xiàn)采集日志的發(fā)送，每個(gè)頁(yè)面停留時(shí)長(zhǎng)的計(jì)算一直困擾著分析師；而無線客戶端的日志采集，在頁(yè)面離開時(shí)發(fā)送日志，此時(shí)頁(yè)面停留時(shí)長(zhǎng)就是天然自帶的準(zhǔn)確值了。

? ? ? 上述三個(gè)方法是采集SDK提供的頁(yè)面事件采集的基礎(chǔ)方法；除此之外，為了平衡采集、計(jì)算和分析的成本，在部分場(chǎng)景下我們選擇采集更多的信息來減少計(jì)算及分析的成本。于是，TK提供了透?jìng)鲄?shù)功能。所謂透?jìng)鲄?shù)，即把當(dāng)前頁(yè)面的某些信息，傳遞到下一個(gè)頁(yè)面甚至下下一個(gè)頁(yè)面的日志中。舉個(gè)例子，在手機(jī)商城類App，先搜索“籃球鞋”，然后點(diǎn)從返回的列表中點(diǎn)擊某個(gè)商品進(jìn)入詳情頁(yè)。如果需要分析“籃球鞋”這個(gè)關(guān)鍵詞的來源搜索詞，此時(shí)就需要把“籃球鞋”這個(gè)關(guān)鍵詞帶入到搜索列表頁(yè)面日志、商品詳情頁(yè)日志中，這樣一來，分析搜索詞的效果就顯而易見了。

2.2 控件點(diǎn)擊及其他事件

? ? ? 為了和基于瀏覽器客戶端的日志采集做比較，我們暫且把除了頁(yè)面事件外的各類事件放到一起來說明。

? ? ? 和瀏覽器客戶端的日志采集一樣，交互日志的采集無法規(guī)定統(tǒng)一的采集內(nèi)容，交互類的行為呈現(xiàn)出高度自定義的業(yè)務(wù)特征。與之相適應(yīng)，在騰空采集系統(tǒng)的實(shí)踐中，將交互日志采集從頁(yè)面事件采集中剝離出來，這就是控件點(diǎn)擊事件和其他事件。

? ? ? 先來說說控件點(diǎn)擊事件?？丶c(diǎn)擊事件比頁(yè)面事件要簡(jiǎn)單得多，首先，它和頁(yè)面事件一樣，記錄了基本的設(shè)備信息、用戶信息；其次，它記錄了控件所在頁(yè)面名稱、控件名稱、控件的業(yè)務(wù)參數(shù)等。由于控件點(diǎn)擊事件的邏輯簡(jiǎn)單得多，就是操作頁(yè)面上的某個(gè)控件，因此只需把相關(guān)基礎(chǔ)信息告訴采集SDK即可。

? ? ? 再來說說其他事件。所謂其他事件，就是用戶可以根據(jù)業(yè)務(wù)場(chǎng)景需求，使用自定義事件來采集相關(guān)信息。從某種程度上說，它幾乎能滿足用戶的所有需求，包括頁(yè)面事件和控件點(diǎn)擊事件，只是若采用通用的頁(yè)面事件埋點(diǎn)方法，TK會(huì)幫助實(shí)現(xiàn)一些額外的功能（如上個(gè)頁(yè)面的信息）。TK提供了一個(gè)自定義埋點(diǎn)類，其包括：

? ? ? ?1. 事件名稱；

? ? ? ?2. 事件時(shí)長(zhǎng)；

? ? ? ?3. 事件所攜帶的屬性；

? ? ? ?4. 事件對(duì)應(yīng)的頁(yè)面。

當(dāng)然，具體實(shí)現(xiàn)什么功能，需要帶哪些內(nèi)容，各個(gè)采集SDK可以自行決定。

? ? ? 除了上述這些需要應(yīng)用開發(fā)者觸發(fā)的日志采集接口方法外，TK還提供了一些默認(rèn)的日志采集方法，比如可以自動(dòng)捕獲應(yīng)用崩潰，并且產(chǎn)生一條日志記錄崩潰相關(guān)信息。類似的日志采集方法還有很多，比如應(yīng)用的退出、頁(yè)面的前后臺(tái)切換等。諸如一些和業(yè)務(wù)信息不是非常相關(guān)，但又對(duì)分析起很大作用的日志采集，就完全沒有必要讓應(yīng)用開發(fā)者去觸發(fā)埋點(diǎn)了。

2.3 特殊場(chǎng)景

? ? ? 上述場(chǎng)景均為一個(gè)行為產(chǎn)生一條日志，如一次瀏覽、一次點(diǎn)擊等。如此用來處理普通的業(yè)務(wù)是足夠的，但對(duì)于某些場(chǎng)景下巨大的業(yè)務(wù)體量來說，為了平衡日志大小，減小流量消耗、采集服務(wù)器壓力、網(wǎng)絡(luò)傳輸壓力等，采集SDK提供了聚合功能，對(duì)某些場(chǎng)景如曝光或一些性能技術(shù)類日志，我們提倡在客戶端對(duì)這類日志進(jìn)行適當(dāng)聚合，以減少對(duì)日志采集服務(wù)器端的請(qǐng)求，適當(dāng)減小日志大小。總體思路就是每個(gè)曝光的元素一般都屬于一個(gè)面面，利用頁(yè)面的生命周期來實(shí)現(xiàn)適當(dāng)?shù)木酆霞按_定發(fā)送時(shí)機(jī)。拿曝光日志來舉例，若一個(gè)商品的一次曝光就對(duì)應(yīng)一條日志的話，那么在搜索結(jié)果頁(yè)的一次滾屏瀏覽過程中將產(chǎn)生幾十條甚至上百條日志，從下游使用及分析的角度來說，其實(shí)只是想知道哪些內(nèi)容被曝光，此時(shí)為了平衡業(yè)務(wù)需求及減少全鏈路資源消耗，采集SDK提供了本地聚合功能，在客戶端對(duì)這類日志進(jìn)行聚合，上傳聚合后的日志到采集服務(wù)器即可。同時(shí)對(duì)于一些只需要計(jì)數(shù)，而不需要知道具體內(nèi)容的場(chǎng)景，如需要分析某些接口的調(diào)用次數(shù)，此功能就更加凸顯出其作用了。

? ? ? 區(qū)別于瀏覽器的頁(yè)面訪問，在無線客戶端用戶的訪問行為路徑存在明顯的回退行為（如點(diǎn)擊回退按鈕、各種滑屏等），在進(jìn)行業(yè)務(wù)分析時(shí)，回退同樣作為特殊場(chǎng)景而存在。例如，在商城首頁(yè)——女裝分類——女裝店鋪A——回退到女裝分類——女裝店鋪B。在這個(gè)訪問路徑中，若只是按照普通的路徑來處理，則會(huì)認(rèn)為第二次瀏覽的女裝分類來源為店鋪A，就會(huì)把女裝分類的一次瀏覽效果記為女裝店鋪A帶來的。

? ? ? 倘若這樣處理，就會(huì)發(fā)現(xiàn)類似的活動(dòng)承接頁(yè)其來源有一大部分均為各類詳情頁(yè)（店鋪詳情頁(yè)/商品詳情頁(yè)），這必然干擾到分析。所以針對(duì)這種場(chǎng)景，我們做了特殊的設(shè)計(jì)，利用頁(yè)面的生命周期，識(shí)別頁(yè)面的復(fù)用，配合棧的深度來識(shí)別是否是回退行為。

2.4 H5&Native日志統(tǒng)一

? ? ? 簡(jiǎn)單來說，APP分為兩種:一種是純Native APP；一種是既有Native，又有H5頁(yè)面嵌人的APP，即HybridAPP。當(dāng)前，純NativeAPP已經(jīng)非常少了，一般都是Hybrid APP。Native 頁(yè)面采用采集SDK進(jìn)行日志采集，H5頁(yè)面一般采用基于瀏覽器的頁(yè)面日志采集方式進(jìn)行采集。在當(dāng)前的實(shí)踐中，由于采集方式的不同，采集到的內(nèi)容及采集服務(wù)器均分離開。若需要進(jìn)行完整的數(shù)據(jù)分析，就需要將兩類日志在數(shù)據(jù)處理時(shí)進(jìn)行關(guān)聯(lián)，而就算不考慮處理成本，在很多情況下，Native和H5互跳，即使關(guān)聯(lián)也無法還原用戶路徑，數(shù)據(jù)丟失嚴(yán)重。對(duì)于產(chǎn)品經(jīng)理以及運(yùn)營(yíng)、管理、數(shù)據(jù)分析人員而言，在不同的終端采用不同的方案采集日志，以不同的算法來做日志統(tǒng)計(jì)，忍受多端之間的數(shù)據(jù)隔離，并對(duì)由此導(dǎo)致的多樣數(shù)據(jù)口徑進(jìn)行整理分析和解釋，已經(jīng)是越來越不能容忍的切身之痛?？紤]到后續(xù)日志數(shù)據(jù)處理的便捷性、計(jì)算成本、數(shù)據(jù)的合理性及準(zhǔn)確性，我們需要對(duì)Native和H5日志進(jìn)行統(tǒng)一處理。

? ? ? 要想實(shí)現(xiàn)Native和H5日志的統(tǒng)一處理，就需要對(duì)Hybrid 日志有統(tǒng)一的方案。簡(jiǎn)單的思路就是首先將兩類日志進(jìn)行歸一。用什么方式把兩類日志歸一呢？是把Native日志向H5日志歸，還是把H5日志歸到Native日志呢？其實(shí)兩條路均可以實(shí)現(xiàn)，沒有絕對(duì)的答案。選擇時(shí)可以自行斟酌，在騰空系統(tǒng)中，分別考慮兩條路的優(yōu)缺點(diǎn)，考慮到兩種日志采集方式的特點(diǎn)以及關(guān)注點(diǎn)，我們選擇Native部署采集SDK的方式。

? ? ? 原因有二：一是采用采集SDK可以采集到更多的設(shè)備相關(guān)數(shù)據(jù)，這在移動(dòng)端的數(shù)據(jù)分析中尤為重要；二是采集SDK處理日志，會(huì)先在本地緩存，而后借機(jī)上傳，在網(wǎng)絡(luò)狀況不佳時(shí)延遲上報(bào)，保證數(shù)據(jù)不丟失?；谶@兩點(diǎn)，我們選擇將H5日志歸到Native日志。

? ? ? 具體的流程如下：

? ? ? （1）H5頁(yè)面瀏覽和頁(yè)面交互的數(shù)據(jù)，在執(zhí)行時(shí)通過加載日志采集的JavaScript腳本，采集當(dāng)前頁(yè)面參數(shù)，包括瀏覽行為的上下文信息以及一些運(yùn)行環(huán)境信息。在APP中打開H5頁(yè)面和在瀏覽器中的處理完全一樣，在前端頁(yè)面的開發(fā)中無須做任何特殊的處理，只需在頁(yè)面開發(fā)時(shí)手動(dòng)植人日志采集的JavaScript腳本即可。

? ? ? （2）在瀏覽器日志采集的JavaScript腳本中實(shí)現(xiàn)將所采集的數(shù)據(jù)打包到一個(gè)對(duì)象中，然后調(diào)用WebView框架的JSBridge接口，調(diào)用移動(dòng)客戶端對(duì)應(yīng)的接口方法，將埋點(diǎn)數(shù)據(jù)對(duì)象當(dāng)作參數(shù)傳入。

? ? ? （3）移動(dòng)客戶端日志采集SDK，封裝提供接口，實(shí)現(xiàn)將傳入的內(nèi)容轉(zhuǎn)換成移動(dòng)客戶端日志格式。采集SDK會(huì)根據(jù)日志類別來識(shí)別是頁(yè)面瀏覽事件，還是控件點(diǎn)擊事件，然后調(diào)用內(nèi)部相應(yīng)的接口進(jìn)行處理，將埋點(diǎn)數(shù)據(jù)轉(zhuǎn)換成移動(dòng)客戶端日志的統(tǒng)一格式。而后就同移動(dòng)客戶端的日志處理一樣，先記錄到本地日志緩存中，擇機(jī)上傳。通過日志類別的識(shí)別來做不同的日志格式轉(zhuǎn)換，這樣，未來如果要實(shí)現(xiàn)新的事件類別，比如自定義事件，就不需要改動(dòng)WebView層的接口，只需改動(dòng)JavaScript的部分內(nèi)容及移動(dòng)客戶端日志采集SDK中對(duì)應(yīng)的實(shí)現(xiàn)即可。

? ? ? 基于這種統(tǒng)一的方案，為后續(xù)構(gòu)建完整的用戶行為路徑還原樹打下了基礎(chǔ)。當(dāng)然，此方案也有其局限性，必須要瀏覽器采集JavaScript、WebView、客戶端采集SDK的配合。而往往很多時(shí)候業(yè)務(wù)并不希望做任何調(diào)整，更多的是希望減少依賴，所以在這方面我們需要尋求新的突破。

2.5 設(shè)備標(biāo)識(shí)

? ? ? 所有互聯(lián)網(wǎng)產(chǎn)品的兩大基本指標(biāo)是頁(yè)面瀏覽量（Page View，PV）和訪客數(shù)（Unique Visitors，UV）。關(guān)于UV，對(duì)于登錄用戶，可以使用用戶ID來進(jìn)行唯一標(biāo)識(shí)，但是很多日志行為并不要求用戶登錄，這就導(dǎo)致在很多情況下采集上來的日志都沒有用戶ID。PC端般使用Cookie信息來作為設(shè)備的唯一信息，對(duì)于APP來說，我們就要想辦法獲取到能夠唯一標(biāo)識(shí) 設(shè)備的信息。

? ? ? 歷史上，MEI、IMSI、MAC、蘋果禁用之前的UDID, ?曾經(jīng)都可以用，如果它們之中有一個(gè)是靠譜的話，那么設(shè)備唯一標(biāo)識(shí)就簡(jiǎn)單了。但事實(shí)上，隨著用戶的自我保護(hù)意識(shí)加強(qiáng)以及各系統(tǒng)升級(jí)，很多基本的設(shè)備信息獲取都不再那么容易。蘋果UDID禁用，IDFA、IMEI、 IMSI做了權(quán)限控制，Android新系統(tǒng)也對(duì)設(shè)備信息的獲取做了權(quán)限控制。

? ? ? 對(duì)于只有單APP的公司來說，設(shè)備唯標(biāo)識(shí)不是需要攻克的難題，但對(duì)于擁有眾多APP的公司來說，設(shè)備唯一標(biāo)識(shí)就顯得尤為重要。

? ? ? 騰空系統(tǒng)使用基于Open UUID方案的TKUID唯一標(biāo)識(shí)設(shè)備。

2.6 日志傳輸

? ? ? 在上面的章節(jié)中大概講述了如何從無線客戶端采集日志，本節(jié)將簡(jiǎn)單介紹一下無線客戶端日志的上傳、壓縮及傳輸?shù)奶厥庑浴?/span>

? ? ? 無線客戶端日志的上傳，不是產(chǎn)生一條日志上傳一條，而是無線客戶端產(chǎn)生日志后，先存儲(chǔ)在客戶端本地，然后再伺機(jī)上傳。所謂伺機(jī)，就需要有數(shù)據(jù)分析的支持，如在啟動(dòng)后、使用過程中、切換到后臺(tái)時(shí)這些場(chǎng)景下分別多久觸發(fā)一次上傳動(dòng)作。當(dāng)然單純地靠間隔時(shí)間來決定上傳動(dòng)作是不夠的，還需要考慮日志的大小及合理性（如單條日志超大，很可能就是錯(cuò)誤日志）。另外，還需要考慮上傳時(shí)網(wǎng)絡(luò)的耗時(shí)，來決定是否要調(diào)整上傳機(jī)制。

? ? ? ?客戶端數(shù)據(jù)上傳時(shí)是向服務(wù)器發(fā)送POST請(qǐng)求，服務(wù)器端處理上傳請(qǐng)求，對(duì)請(qǐng)求進(jìn)行相關(guān)校驗(yàn)，將數(shù)據(jù)追加到本地文件中進(jìn)行存儲(chǔ)，存儲(chǔ)方式使用Nginx 的access_ log, access ?_log的切分維度為天，即當(dāng)天接收的日志存儲(chǔ)到當(dāng)天的日志文件中?？紤]到后續(xù)的數(shù)據(jù)處理，以及特殊時(shí)期不同日志的保障級(jí)別，還對(duì)日志進(jìn)行了分流。比如騰空系統(tǒng)的TKProcessor（無線日志服務(wù)器端處理程序），根據(jù)應(yīng)用及事件類型對(duì)每日高達(dá)數(shù)億的日志進(jìn)行了分流。分流的好處顯而易見，高并發(fā)訪問時(shí)，日常數(shù)億的日志可能沖高到數(shù)十億，此時(shí)服務(wù)器及后續(xù)的數(shù)據(jù)計(jì)算壓力就非常大了；而對(duì)于重要的數(shù)據(jù)計(jì)算來說，很可能只需要頁(yè)面事件及控件點(diǎn)擊事件即可，此時(shí)就可以適當(dāng)?shù)蒯尫牌渌愋腿罩镜馁Y源來處理更重要的頁(yè)面事件及控件點(diǎn)擊事件。

? ? ? 從客戶端用戶行為，到日志采集服務(wù)器的日志，整個(gè)日志采集的過程就結(jié)束了。

? ? ? 那么日志采集服務(wù)器的日志怎么給到下游呢？方法有很多，騰空系統(tǒng)主要使用消息隊(duì)列來實(shí)現(xiàn)從日志采集服務(wù)器到數(shù)據(jù)計(jì)算的。簡(jiǎn)單來講，就是消息隊(duì)列服務(wù)部署到日志采集服務(wù)器上進(jìn)行消息的收集，而后續(xù)的應(yīng)用可以是實(shí)時(shí)的應(yīng)用實(shí)時(shí)來訂閱消息隊(duì)列收集到的消息，進(jìn)行實(shí)時(shí)計(jì)算，也可以是離線的應(yīng)用定時(shí)來獲取消息，完成離線的計(jì)算。

圖片來源于站酷海洛

本文有部分內(nèi)容參考節(jié)選自阿里巴巴《大數(shù)據(jù)之路》一書。