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

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

? ? ? ?但是如果不能對這些數據進行有序、有結構地分類組織和存儲，如果不能有效利用并發掘它，繼而產生價值，那么它同時也成為一場“災難”。無序、無結構的數據猶如堆積如山的垃圾，給企業帶來的是令人昨舌的高額成本。

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

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

? ? ? 企業組織在經歷多年的信息化建設后，散落于各異構系統的數據每天都在增加，隨著移動互聯網、物聯網的蓬勃發展，采集數據的渠道和設備越來越多，數據采集作為大數據系統體系的第一環尤為重要。因此三點一四建立了一套標準的數據采集體系方案，致力全面、高性能、規范地完成海量數據的采集、并將其傳輸到大數據平臺。

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

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

騰空采集系統

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

? ? ? ?騰空采集系統以助力企業全面觸網，實現智能化數據決策為使命，提供DT時代的大數據基礎服務。

• 通過實時/離線數據采集，快速構建數據倉庫和數據中心，幫助中小企業低成本實現數據創新和數據決策。
• 中小企業構建PB級數據倉庫，實現異構環境大規模數據集成，對數據進行資產化管理。
• 智能化的監控，保障數據安全和穩定。

采集方案

1. Web端日志采集

? ? ? Web網站產品日志采集可以分為兩大類：

? ? ? （1）頁面瀏覽日志采集。顧名思義，頁面瀏覽日志是指當一個頁面被瀏覽器加載呈現時采集的日志。此類日志是最基礎的互聯網日志，也是目前所有互聯網產品的兩大基本指標：頁面瀏覽量（Page View，PV）和訪客數（UniqueVisitors，UV）的統計基礎。頁面瀏覽日志是目前成熟度和完備度最高，同時也是最具挑戰性的日志采集任務，我們將重點講述此類日志的采集。

? ? ? （2）頁面交互日志采集。當頁面加載和渲染完成之后，用戶可以在頁面上執行各類操作。隨著互聯網前端技術的不斷發展，用戶可以瀏覽器內與網頁進行的互動已經豐富到只有想不到沒有做不到的程度，互動設計都要求采集用戶的互動行為數據，以便通過量化獲知用戶的興趣點或者體驗優化點。交互日志采集就是為此類業務場景而生的。

1.1 頁面瀏覽日志采集流程

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

? ? ? 目前典型的網頁訪問過程是以瀏覽器器請求、服務器響應并返回所請求的內容這種模式進行的，瀏覽器和服務器之間的通信普遍遵守HTTP協議。瀏覽器發起的請求被稱為HTTP請求，服務器的返回則被稱為HTTP響應。

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

一次網頁請求過程

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

? ? ? （2）瀏覽器向百度服務器發起HTTP請求。按照HTTP協議，一個標準的HTTP請求由三個部分組成。

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

? ? ? ?（3）服務器接收并解析請求。服務器端的業務處理模塊按業務邏輯處理本次請求并按照HTTP協議規定的格式，將處理結果以HTTP響應形式發回瀏覽器。與HTTP請求相對應，一個標準的HTTP響應也由三部分構成。

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

? ? ? ?（4）瀏覽器接收到服務器的響應內容，并將其按照文檔規范展現給用戶，從而完成一一次請求。

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

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

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

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

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

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

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

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

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

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

1.2 頁面交互日志采集流程

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

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

? ? ? 具體而言，交互日志采集是一個開放的基于HTTP協議的日志服務，需要采集交互日志的業務，經過如下步驟即可將自助采集的交互日志發送到日志服務器。

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

? ? ? （2）業務方將交互日志采集代碼植入目標頁面，并將采集代碼與需要監測的交互行為做綁定。

? ? ? （3）當用戶在頁面上產生指定行為時，采集代碼和正常的業務互動響應代碼一起被觸發和執行。

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

? ? ? ?經過上述步驟采集到的日志服務器的業務隨后可被業務方按需自行解析處理，并可與正常的PV日志做關聯運算。

2. App端日志采集

? ? ? 眾所周知，日志采集多是為了進行后續的數據分析。移動端的數據采集，一是為了服務于開發者，協助開發者分析各類設備信息；二是為了幫助各APP更好地了解自己的用戶，了解用戶在APP上的各類行為，幫助各應用不斷進行優化，提升用戶體驗。

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

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

2.1 頁面事件

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

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

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

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

2.2 控件點擊及其他事件

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

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

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

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

? ? ? ?1. 事件名稱；

? ? ? ?2. 事件時長；

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

? ? ? ?4. 事件對應的頁面。

當然，具體實現什么功能，需要帶哪些內容，各個采集SDK可以自行決定。

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

2.3 特殊場景

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

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

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

2.4 H5&Native日志統一

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

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

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

? ? ? 具體的流程如下：

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

? ? ? （2）在瀏覽器日志采集的JavaScript腳本中實現將所采集的數據打包到一個對象中，然后調用WebView框架的JSBridge接口，調用移動客戶端對應的接口方法，將埋點數據對象當作參數傳入。

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

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

2.5 設備標識

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

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

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

? ? ? 騰空系統使用基于Open UUID方案的TKUID唯一標識設備。

2.6 日志傳輸

? ? ? 在上面的章節中大概講述了如何從無線客戶端采集日志，本節將簡單介紹一下無線客戶端日志的上傳、壓縮及傳輸的特殊性。

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

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

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

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

圖片來源于站酷海洛

本文有部分內容參考節選自阿里巴巴《大數據之路》一書。