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

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

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

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

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

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

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

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

騰空采集系統(tǒng)

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

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

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

采集方案

1. Web端日志采集

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

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

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

1.1 頁面瀏覽日志采集流程

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

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

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

一次網(wǎng)頁請求過程

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

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

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

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

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

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

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

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

頁面瀏覽日志采集方案流程框架

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

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

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

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

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

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

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

1.2 頁面交互日志采集流程

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

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

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

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

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

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

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

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

2. App端日志采集

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

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

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

2.1 頁面事件

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

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

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

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

2.2 控件點擊及其他事件

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

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

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

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

? ? ? ?1. 事件名稱；

? ? ? ?2. 事件時長；

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

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

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

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

2.3 特殊場景

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

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

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

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

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

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

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

? ? ? 具體的流程如下：

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

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

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

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

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

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

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

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

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

2.6 日志傳輸

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

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

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

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

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

圖片來源于站酷海洛

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