一、概述
- 數據采集渠道：主要采集 Web 端和 App 端日志數據；
- 數據加工分層理念：操作數據層（Operational Data Store ，ODS）、明細數據層（Data Warehouse Detail，DWD）、匯總數據層（Data Warehouse Summary，DWS）、應用數據層（Application Data Store，ADS）。
- 元數據模型整合及應用主要組成部分：數據源元數據、數據倉庫元數據、數據鏈路元數據、工具類元數據、數據質量類元數據等。
- 元數據：其應用主要面向數據發現、數據管理等，如用於存儲、計算和成本管理等。
- 數據服務層對外提供數據服務主要通過統一的數據服務平台（OneService）。
- OneService 以數據倉庫整合計算好的數據作為數據源，對外通過接口的方式提供數據服務，主要提供：簡單數據查詢、復雜數據查詢（承接集團用戶識別、用戶畫像等）、實時數據推送。
二、瀏覽器的日志采集
- 頁面瀏覽日志采集：當一個頁面被瀏覽器加載呈現時采集的日志。（是目前所有互聯網產品的兩大基本指標：頁面瀏覽量(Page View，PV) 和訪問量(Unique Visitors，US) 的統計基礎。）
- 頁面交互日志采集：當頁面加載和渲染完成后，用戶在頁面上的各種操作。
1、網頁瀏覽日志采集
1）網頁瀏覽過程
- 網頁訪問過程：瀏覽器請求、服務器響應並返回請求的內容；（瀏覽器和服務器之間通信准守 HTTP 協議，瀏覽器發起的請求稱 HTTP 請求(HTTP Requesst)，服務器的返回稱 HTTP 響應(HTTP Response)）
- 1/1 ：瀏覽器發起請求
# 一個標准的 HTTP 請求：請求行（HTTP Request Line）、請求報頭（HTTP Message Header）、請求正文（HTTP Message Body）。
# 請求行三要素：請求方法、所請求資源的 URL 以及 HTTP 協議版本號。（例：GET、http://www.taobao.com、HTTP1.1）
# 請求報頭：瀏覽器在請求時向服務器提交的附加信息。
# 請求報頭一般包含很多內容項（每個內容項稱為一個頭域(Header Field)），如果用戶瀏覽過網址或者已經登錄，請求頭中會附加一個或多個Cookie 項。
# 請求正文：該部分是可選的，一般 HTTP 請求的正文都是空白的。
- 1/2 ：服務器接收並分析請求
- 一個標准的 HTTP 響應：狀態行、響應報頭、響應正文。
# 狀態行：標識服務器懟此次 HTTP 請求的處理結果。
# 主要內容一個三位數狀態碼。（例，202：成功響應、404：所請求的資源在服務器端沒有被找到）
# 響應報頭：最重要的一類 Header 為 Cookie；
- 例：如果用戶在頁面登錄，服務器會在登錄請求的響應報頭內指示瀏覽器新增一個名為 userid 的 Cookie 項，其中記錄了登錄用戶的 id，當用戶隨后再次訪問該網站時，瀏覽器自動在請求報頭內附加這個 Cookie，服務器由此即可得知本次請求對應的用戶到底是誰；如果服務器發現瀏覽器在請求時傳遞過來的 Cookie 有缺失、錯誤或需要更新，則會在響應報頭內指令瀏覽器增加或更新對應的 Cookie。
# 響應正文：為可選部分，但一般不為空，瀏覽器請求的文檔、圖片、腳本等，被包含在響應正文中。
- 1/3：瀏覽器接收到服務器的響應內容，並將其按照文檔（HTML 文檔）規范展現給用戶，從而完成一次請求。
2）采集
- 方法：在 HTML 文檔適當位置增加一個日志采集節點，當瀏覽器解析到這個節點時，將觸發一個特定的 HTTP 請求到日志采集服務器，當日志采集服務器接收到這個請求時，即可確定瀏覽器已經成功地接收和打開了頁面。
- 日志采集節點不能放在網頁瀏覽過程的前兩步中，只能放在瀏覽器開始解析 HTML 文檔中，因為只有瀏覽器開始解析 HTML 文檔時才能確保用戶已確實打開頁面。
- 2/1：客戶端日志采集
- 日志采集工作由一段被植入頁面 HTML 文檔內的 JavaScript 腳本執行。
- 采集腳本被瀏覽器加載解析后執行，在執行時采集當前頁面參數、瀏覽行為的上下文信息（如讀取用戶訪問當前頁面時的上一步頁面）、運行環境信息（如當前的瀏覽器和分辨率等）。
- 采集腳本可以由業務服務器在響應業務請求時動態執行，也可以在開發頁面時由開發人員手動植入。
- 2/2：客戶端日志發送
- 采集腳本執行時，向日志服務器發起一個日志請求，以將采集到的數據發送到日志服務器。
- 大多數情況，采集完成后會立即執行發送，但在個別場景下，日志采集后可能會經過一段的時間延遲才被發送。
- 日志采集和發送模塊一般集成在同一個 JavaScript 腳本文件內，通過 HTTP 協議與日志服務器通信，將采集到的日志一般以 URL 參數形式放在 HTTP 日志請求的請求行。
- 2/3：服務器端日志收集
- 日志服務器收到客戶端發來的日志請求后，一般會立即向瀏覽器發送一個請求成功的響應，以免對頁面的正常加載造成影響；同時，日志服務器的日志收集模塊會將日志請求內容寫入一個日志緩沖區，完成此條瀏覽器日志的收集。
- 2/4：服務器日志解析存檔
- 服務器接收到的瀏覽日志進入緩沖區后，被一段專門的日志處理程序順序讀出並按照約定的日志處理邏輯解析。由日志采集腳本記錄在日志請求行內的參數，將在這個環節被解析（有時候伴隨着轉義和解碼）出來，轉存入標准的日志文件中並注入實時消息通道內供其他后端程序讀取和進一步加工處理。
2、頁面交互日志采集
- PV 日志采集得到用戶訪問過的頁面和訪問路徑，不能得到用戶訪問某個頁面時具體的互動行為特征，比如鼠標或輸入焦點的移動變化（代表用戶關注內容的變化）、對某些頁面交互的反應（可借此判斷用戶是否對某些頁面元素發生認知困難）等。
- 阿里交互日志采集（基於“黃金令箭”(一個開放的基於 HTTP 協議的日志服務)）
- 業務方在“黃金令箭”的元數據管理界面依次注冊需要采集交互日志的業務、具體的業務場景以及場景下的具體交互采集點，系統將生產與之對應的交互日志采集代碼模板。
- 業務方將交互日志采集代碼植入目標頁面，並將采集代碼與需要檢測的交互行為做綁定。
- 當用戶在頁面上產生制定行為時，采集代碼和正常的業務互動響應代碼一起被觸發和執行。
- 采集代碼在采集動作完成后將對應的日志通過 HTTP 協議發送到日志服務器，日志服務器接收到日志后，對於保存在 HTTP 請求參數部分的自定義數據，即用戶上傳的數據，原則上不做解析處理，只做簡單的轉存。
3、頁面日志的服務器端清洗和預處理
- 采集到的頁面瀏覽日志與交互日志，不能直接提供給下游使用，需要進行相應的離線預處理：
# 1）識別流量攻擊、網絡爬蟲、流量作弊（虛假流量）
# 依托算法識別非正常的流量並歸納出對應的過濾規則加以濾除。
# 2）數據缺項補正
# 為了便利后續的日志應用、保證基本的數據統計口徑一致，需要對日志中的一些公用且重要的數據做取值歸一、標准化處理或反向補正。
# 反向補正：根據新日志對稍早收集的日志中的個別數據項做回補或修訂。
# 3）無效數據剔除
# 因業務變更或配置不當，產生無意義、已經失效或者冗余的數據。
# 定期檢查配置並依照配置剔除無效數據。
# 4）日志隔離分發
# 分離原因：基於數據安全或者業務特性。
- 預處理后的數據，具備了結構化或者半結構化，才能被關系型數據庫裝載和使用。
三、無線客戶端的日志采集
- 無線客戶端的日志采集采用 “采集 SDK” 來完成。（阿里內部多采用 UserTreak）
- 移動端的日志采集根據不同的用戶行為分成不同的事件，“事件” 為無線客戶端日志行為的最小單位，SDK 把事件分成了幾類，常用的：頁面事件（同頁面瀏覽）、控件點擊事件（同頁面交互）。
1、頁面事件
- 每條頁面事件日志幾類三類信息：設備及用戶的基本信息、被訪問頁面的信息（主要是業務參數：如商品詳情頁的商品ID、所屬店鋪等）、訪問基本路徑（頁面來源等），基於這三類信息，還原用戶完整的訪問行為。
- 對於頁面事件，不同的 SDK 有不同的實現，UT 采用無痕埋點，即無須開發者進行任何編碼即可實現。
- UT 的手動埋點：UT 提供了連個接口，分別在頁面展現和頁面退出時調用。
- 例進入手機淘寶某店鋪詳情頁：當進入店鋪詳情頁時，調用頁面展現接口（記錄頁面進入時的狀態信息），但不發送日志；當從該店鋪詳情頁離開時，調用頁面退出接口，該接口會發送日志。
- 除了頁面展現和頁面退出連個基礎接口，UT 還提供了添加頁面擴展信息的接口：在頁面離開前，使用該接口提供的方法給頁面添加相關的參數（如店鋪ID、店鋪類別等）。
- 在頁面進入時不發送日志，而在頁面退出時發送日志的原因：考慮用戶瀏覽頁面的時長。
- UT 還提供了透傳參數功能 SPM：用於實現用戶行為路徑還原。
2、控件點擊及其他事件
- 控件點擊事件：操作頁面上的某個控件，記錄基本的設備信息、用戶信息，以及控件所在頁面名稱、控件名稱、控件的業務參數等。一般只需將相關基礎信息告訴 SDK 即可。
- 其他事件：用戶可以根據業務場景需要，使用自定義事件來采集相關信息。
3、特殊場景
- 頁面瀏覽和交互為行為日志。
- 對於巨大的業務量來說，為了平衡日志大小、減小流量消耗、采集服務器壓力、網絡傳輸壓力等，采集 SDK 提供了聚合功能。
- 聚合功能：對日志適當聚合，減少對日志采集服務器的請求、減小日志大小。
- 聚合功能的思路：每一個曝光的元素一般屬於一個頁面，利用頁面的生命周期來實現適當的聚合及確定發送時機。
- 例：曝光日志，如果商品的一次曝光對應一條日志，那么在搜索結果頁的一次滾動瀏覽過程中將產生幾十條甚至上百條日志，從下游使用及分析角度來講，其實只想知道哪些內容被曝光，此時為了平衡業務需求及減少全鏈路資源消耗，采集 SDK 提供了本地聚合功能，在客戶端對這類日志進行聚合，上傳聚合后的日志到采集服務器即可，
- 回退操作：在進行業務分析時，用戶的回退操作作為特殊場景對待。（利用頁面的生命周期，識別頁面的復用，配合棧的深度來識別是否是回退行為）
4、H5 & Native 日志統一
- Native APP：使用原生系統內核的，相當於直接在系統上操作。是我們傳統意義上的軟件，更加穩定。
- H5 APP：先得調用系統的瀏覽器內核，相當於是在網頁中進行操作，較原生APP穩定性稍差。
- Hybrid APP：既有Native，又有H5頁面嵌入。是當前大多數 APP 模式。
- Hybrid APP 日志采集的問題難點：Native 采用采集 SDK 進行日志采集，H5 采用基於瀏覽器的頁面日志采集方式進行采集，由於采集方式不同，采集到的內容及采集服務器均分離開。但是若要進行完整的數據分析，需要將兩類日志在數據處理是進行關聯，增加了計算成本。而且就算不考慮處理成本，在很多情況下，Native 和 H5 互跳，及時關聯也無法還原用戶路徑，數據丟失嚴重。（現實工作中：產品經理、運營、管理、數據分析人員，需要在不同終端采用不同的方案采集日志，一不同的算法來做日志統計，忍受多端的數據隔離，並對此導致的多樣數據口徑進行整理分析和解釋）
- H5 & Natative 日志統一：
- 思路：將兩類日志進行歸一（兩種方法：把 Native 日志向 H5 日志歸，或者把 H5 日志向 Native 日志歸——具體選擇時根據業務情況而定）。
- 阿里集團一般講 H5 日志向 Native 日志歸，原因有二：
- 一是采用采集 SDK 可以采集到更多的設備相關數據，這在移動端的數據分析中尤為重要；
- 二是采集 SDK 處理日志，會先在本地緩存，而后借機上傳，在網絡狀態不佳時延遲上報，保證數據不丟失。
- 日志歸一流程：
- 1）H5 頁面瀏覽和頁面交互的數據，在執行時通過加載日志采集的 JavaScript 腳本，采集當前頁面參數，包括瀏覽行為的上下文信息以及一些運行環境信息。
- 在 APP 中打開 H5 頁面和瀏覽器中的處理完全一樣，在簽訂頁面的開發中無須做任何特殊的處理，只需在頁面開發時手動植入日志采集的 JavaScript 腳本即可。
- 2）在瀏覽器日志采集的 JavaScript 腳本中實現將所采集的數據打包到一個對象中，然后調用 WebView 框架的 JSBridge 接口，調用移動客戶端對應的接口方法，將埋點數據對象當做參數傳入。
- 3）移動客戶端日志采集 SDK，封裝提供接口，實現將傳入的內容裝換稱移動客戶端日志格式。
- 采集 SDK 會根據日志類別來識別是頁面瀏覽事件，還是控件點擊事件，人后調用內部響應的接口進行處理，將埋點數據裝緩存移動客戶端日志的統一格式。而后就同移動客戶端的日志處理一樣，先記錄到本地日志緩存中，擇機上傳，
- 通過日志類別的識別類做不同的日志格式轉換，這樣，未來如果要實現新的事件類別，比如自定義事件，就不需要改動 WebView 層的接口，只需要改動 JavaScript 的部分內容及移動客戶端日志采集 SDK 中對應的實現即可。
- 日志歸一方法的弊端：必須要瀏覽器采集 JavaScript 、WebView、客戶端采集 SDK 的配合，而往往很多時候業務並不希望做任何調整，更多的是希望減少依賴。
5、設備標識
- PC 端一般使用 Cookie 信息來作為設備的唯一信息。
- APP ，一般使用 UDID，但是由於手機系統權限控制，需要用戶授權才能獲取。（阿里集團無線設備唯一標識使用 UTDID）
6、日志傳輸
- 無線客戶端日志的上傳，不是產生一條日志上傳一條，而是無線客戶端產生日志后，先存儲在客戶端本地，任何再伺機上傳。
- （伺機：需要有數據分析的支持，如在啟動后、使用過程中、切換到后台時這些場景下分別多久觸發一次上傳動作。）
- （單純地靠間隔時間來決定上傳動作是不夠的，還需要考慮日志的大小及合理性(如單條日志超大，很可能就是錯誤日志)，另外還需要考慮上傳時網絡的耗時，來決定是否調整上傳機制）
- 上傳過程：
- 客戶端向服務器發送 POST 請求；
- 服務器端出來上傳請求，對請求進行相關校驗，將數據追加到本地文件中進行存儲（存儲方式：使用 Nginx 的 access_log，access_log 的切分維度為天，即當天接收的日志存儲到當天的日志文件中）。
- 分流：由於后續的數據處理，以及特殊是不同日志的保障級別，對日志進行分流。
- 例：阿里集團的 Ada是（無線日志服務器處理程序），根據應用及事件類型對每日高達數千億的日志進行了分流。（如“雙11”時，日常數千億的日志可能沖高達萬億，此時服務器及后續的數據計算壓力就非常大，而對於重要的數據計算來說，很可能只需要頁面事件及控件點擊事件即可，此時就可以適當地釋放其他類型日志的資源來處理更重要的頁面事件及控件點擊事件。）
- 日志采集服務器的日志怎么給到下游？
- 方法很多，阿里集團主要使用消息隊列（TimeTunel，TT），TT 將消息收集功能部署到日志采集服務器上進行消息的收集，而后續的應用可以是實時的應用實時來訂閱 TT 收集到的消息，進行實時計算，也可以是離線的應用定時來獲取消息，完成離線的計算。
四、日志采集的挑戰
- 目前，面對海量的數據，各類采集方案提供者所面臨的主要挑戰不是日志采集技術本身，而是如何實現日志數據的結構化和規范化組織，實現更為高效的下游統計計算，提供符合業務特性的數據展現，以及為算法提供更編輯、靈活的支持等。
1、典型場景
- 兩個實例場景及阿里集團采用的解決方案：
- 1）日志分流與定制處理
- 問題：大型互聯網網站的日志類型和日志規模都呈現出高速增長態勢，而且往往會出現短時間的流量熱點爆發，是的在日志服務器端采用集中統一的解析處理方案變得不可能，其要求在日志解析和處理過程中必須考慮業務分流（相互之間不應存在明顯的影響，爆發熱點不應干擾定常業務日志的處理）、日志優先級控制，以及根據業務特點實現定制處理。
- 例：電商網站，數據分析人員對位於點擊流前端的促銷頁面和位於后端的商品頁面的關注點是不一樣的，而這兩類頁面的流量有往往同等重要且龐大，如果采用統一的解析處理方案，往往需要在資源浪費（盡可能多地進行預處理）和需求覆蓋不全（僅對最重要的內容進行預處理）兩個選擇間進行取舍。
- 阿里集團解決方案：分治。（阿里互聯網日志采集體系基本原則）
- 盡可能靠前地布置路由差異，可以盡可能早地進行分流。（降低日志處理過程中的分支判斷消耗，並作為后續的計算資源調配的前提，提高資源利用效率）
- 特點：非常高的更新頻次，實現更新的配置化，不僅考慮注入日志分流處理之類的日志服務器端分布計算方案，而且將匪類任務前置到客戶端以實現整個系統的效能最大化。
- 2）采集與計算一體化設計
- PV 日志采集之后的基本操作是日志的歸類與匯總。
- 早期的互聯網日志分析實踐中，是以 URL 路徑，繼而以 URL（正則）規則集為依托來進行日志分類的。
- （特點及弊端：在網絡規模較小時運行，但隨着網站的大型化和開發人員的增加，URL 規則集的維護和使用成本增長到不現實的程度）
- 解決方法：將日志采集與計算作為一個系統來考量，進行一體化設計。
- 阿里方案：兩套日志規范和與之對應的元數據中心。
- PV 日志：SPM 規范和 SPM 元數據中心。（通過 SPM 的注冊和簡單部署，用戶即可將任意的頁面流量進行聚類，統計得到的流量、轉化漏斗、引導交易等數據，以及頁面各元素點擊數據的可視化）
- 自定義日志（交互日志）：黃金令箭（Goldlog）/APP 端的點擊或其他日志規范及其配置中心。
- 互聯網日志的規模化采集方案必須具備一個與終端設備的技術特點無關，具有高度擴展彈性和適應性，同時深入契合應用需求的業務邏輯模型，並基於此制定對應的采集規范交友產品開發人員執行。若非如此，則不足以保障采集——解析——處理——應用整個流程的通暢。
- 日志本身不是日志采集的目的，服務於基於日志的后續應用，才是日志采集正確的着眼點。
2、大促保障
- 從端上埋點采集，到日志服務器收集，經過數據傳輸，再到日志實時解析、實時分析，任何一個環節出現問題，全鏈路保障就是失敗的。
- 必須考慮的情況：服務器的收集能力（如峰值 QPS）、數據傳輸能力（TT 的搬運速度）、實時解析的吞吐量、實時業務分析的處理能力。
- 數據處理全鏈路的特點：
- 端上實現了服務器推送配置到客戶端，且做到高到達率；
- 對日志做了分流，結合日志的重要程度及各類日志的大小，實現了日志服務器端的拆分；
- 在實時處理方面，做了不少的優化以提高應用的吞吐量。
- 在上面幾項的基礎上，結合實時處理能力，評估峰值數據量，在高峰期通過服務器端推送配置的方式對非重要日志濟寧適當限流，錯峰后逐步恢復。
- 服務器推送配置包含較多內容：
- 首先是作用范圍，可以針對應用、平台、事件、事件中的某個場景；
- 其次是具體實施，包括延遲上報、部分采樣等；
- （延遲上報：配置生效后，滿足條件的日志將被暫時存在客戶端，待配置恢復后再上傳到服務器）；
- （部分采樣：配置生效后，滿足條件的日志將被實施采樣（對於一些技術類日志，如頁面加載情況、消耗內存等，可以實施采樣），只上報部分日志到服務器）
- 對於實時性要求較高的業務場景，上鏈路不能滿足需求：從業務上進行改造，采用端上記錄；另一方面，在鏈路各個環節做優化，如從采集服務器直接完成解碼並調用業務 API 完成業務的計算（省去中間的傳輸和過多的處理）。