前言
? ? ? ? 今天開始重新回顧電商數倉項目,結合《阿里巴巴大數據之路》和尚硅谷的《劍指大數據——企業級電商數據倉庫項目實戰 精華版》來進行第二次深入理解學習。之前第一次學習數倉,雖然盡量放慢速度力求深入理解,但是不可能一遍掌握,尤其是關于數倉建模,那需要實打實的經驗!
????????好在最近發現了這兩本好書,但是發現紙質版雖然很好,但是標注那么多零碎的知識點復習起來還是不夠直觀,所以這里用博客的形式把我第二遍學習中學到的東西記錄下來(只針對我的問題)對于一些理論比如基礎的工具使用,一些專業術語不多廢話,最多一句帶過。
? ? ? ? 兩本書對整個數倉的開發步驟基本是一致的,所以學習的時候會結合著一起學,互相彌補各自的不足(《阿里巴巴大數據之路》理論非常豐富,《劍指大數據—企業級電商數倉實戰》更加貼近實戰)。
? ? ? ? 文章的結構我會按照《阿里巴巴大數據之路》來分層,每個章節總結到博客應該又是一篇萬字長文。
1、📄日志采集
? ? ? ? 電商項目的日志采集主要分為兩部分:瀏覽器(Web 端)和無線客戶端(APP、小程序),阿里巴巴對于這兩部分日志的采集方案分別為 Aplus.js(瀏覽器)和 UserTrack (APP)。
1.1、🌍瀏覽器的頁面日志采集
瀏覽器頁面的日志采集可以分為兩類:
- 頁面瀏覽日志
????????也就是一個網頁被加載的次數,因為只有網頁被加載成功時才會被記錄為日志。頁面瀏覽日志有兩大基本指標:PV(頁面瀏覽量)和 UV(用戶訪客數)。
- 頁面交互日志
? ? ? ? 即捕獲用戶的行為操作,通過采集用戶的行為數據,以便量化獲知用戶的興趣點和體驗優化點。
1.1.1、🌍瀏覽器的瀏覽日志采集流程
- 1??用戶在瀏覽器地址欄輸入一個請求地址
- 2??瀏覽器發送一個?http 請求
- 一個標準的 http 請求分為 3 部分:
- 請求行(請求方法、URL、http協議版本)
- 請求頭(附加信息,比如 Cookie)
- 請求體(可選,一般為空)
- 一個標準的 http 請求分為 3 部分:
- 3??服務器接收并響應請求
- 一個標標準的 http 相應也分為 3 部分:
- 狀態行(狀態碼,比如 200)
- 響應頭(附加信息,比如 Cookie)
- 響應體(非空,比如 json、html、image、text、mp4等)
- 一個標標準的 http 相應也分為 3 部分:
- 4??瀏覽器接受響應內容并渲染
????????日志采集的動作發生在上面的第 4 步,也就是在瀏覽器解析響應的頁面的時候。所以實現日志采集的思路就是:在 HTML 文檔合適的位置插入一個日志采集節點(比如一段 js 腳本),當瀏覽器解析到這個節點的時候,將自動觸發發送一個特定的 http 請求到日志采集服務器。
具體采集日志的過程如下:
- 1??客戶端日志采集
- 由植入到 HTML 文檔中的一段 JS 腳本來執行,在執行時采集當前頁面參數,瀏覽器行為的上下文信息(比如該頁面的上一頁)以及一些運行換信息(比如當前瀏覽器的版本、屏幕大小、操作系統信息)
- 具體的采集腳本可以是提前寫入到 HTML 中,也可以是在返回響應時動態植入。
- 2??客戶端日志發送
- 采集腳本執行時,會向日志服務器發送起一個 http 請求,將采集到的日志發送到日志服務器。
- 采集到的日志信息一般以 URL 參數的形式放在 HTTP 請求行中。
- 3??服務器端日志收集
- 日志服務器接收到客戶端發來的日志請求后,一般會立即返回一個請求成功的響應,防止客戶端頁面長時間等待。
- 同時,日志服務器會把該日志的內容寫入一個緩沖區內,完成對這條日志的收集。
- 4??服務器端日志解析存檔
- 日志緩沖區中的日志會被順序讀出并解析,解析出的數據會被轉存到標準的日志文件,而且如果有實時分析需求的話會被注入到實時消息通道供其它后端程序讀取并加工。
經過格式化的日志,為后面日志的加工和計算得以順利進行打下了基礎。
1.1.2、🌍頁面的交互日志采集
????????PV 日志解決了頁面流量和流量來源統計的問題,但是隨著業務的發展,僅了解用戶訪問的頁面和路徑,已經遠遠不能滿足用戶細分研究的需求。很多場景下更需要了解用戶訪問某個頁面時的互動行為數據(比如鼠標焦點的變化)。所以這些行為無法通過常規的 PV 日志采集方法解決。
? ? ? ? 交互日志采集和瀏覽日志采集完全不同,交互日志千變萬化,呈現出高度自定義的業務特征,但是阿里巴巴有自己的一套專門用來采集交互日志的技術方案(也叫“黃金令箭”)。這里丟這個技術不多介紹,畢竟書里也沒有過多透露關于這個技術的細節,大概流程就是:
- 1??業務方(比如程序員)通過這套系統(“黃金令箭”)將具體的業務場景下的交互采集點注冊到系統當中,系統會自動生成與之對應的交互日志采集模板。
- 2??業務方將采集模板植入到目標頁面,并將采集代碼與需要監測的交互行為進行綁定。
- 3??當用戶在頁面交互觸發制定行為時,采集代碼會被觸發執行并通過 HTTP 請求發送到日志服務器。
- 4??日志服務器接收到日志后將數據進行轉存。
????????之后,業務方就可以對這部分行為數據根據業務需求進行解析處理,并可以與瀏覽數據進關聯運算。
1.1.3、🌍頁面日志的服務器端清洗和預處理
????????經過上面采集處理后的數據一般并不會直接提供給下游使用,基于下面的 4 個原因,在時效性寬松的情況下還需要對數據進行一些離線預處理。
- 1??識別流量攻擊,網絡爬蟲和流量作弊
- 2??數據項補正
- 對日志中一些公共并且重要的字段取值歸一(將數據特征縮放到一個特定的范圍當中,比如 [ 0,1 ] ,以消除不同量綱和量綱單位對數據分析結果的影響)、標準化處理或反向補正(根據新日志對舊日志中的個別數據項做回補,比如用戶登錄后,對用戶登錄之前的頁面做身份信息的回補)。
- 3??無效數據剔除
- 采集到的數據難免會存在一些無意義的數據(比如因為業務變更、采集配置不當或者冗余的數據),會消耗存儲和算力。所以需要定時檢查采集配置并按照配置對無效數據進行剔除。
- 4?? 日志隔離分發
- 考慮到數據安全,一般會對一些日志進入到公共環境之前做隔離。
????????至此,頁面日志(瀏覽日志和行為日志)的采集流程就算完成了,此時的日志已經具備了結構化或半結構的特征,可以被關系型數據庫裝載和使用了(Hive 當然也可以)。
1.2、📲客戶端的日志采集
? ? ? ? 移動端的數據采集一方面是為了服務于開發者,幫助他們進行一些數據分析(設備信息、用戶行為信息);另一方面是為了對 APP 進行不斷的優化,提升用戶體驗。
? ? ? ? 瀏覽器的網頁日志是使用 JS 腳本來采集的,而這里的移動客戶端的日志采集使用采集SDK 來完成。移動端的日志采集根據不同的用戶行為分為不同的事件,常用的包括頁面事件(頁面瀏覽)和控件點擊事件(頁面交互)等。
? ? ? ? 阿里巴巴對于移動端的日志采集使用的是 UserTrack (簡稱 UT)。
1.2.1、📲頁面事件
?每條頁面事件日志記錄三類信息:
- 設備和用戶基本信息
- 被訪問頁面的信息(比如商品id、所屬店鋪)
- 訪問的基本路徑(頁面來源、來源的來源)
????????對于頁面事件,有的采集 SDK 選擇在頁面創建時就發送日志。而阿里巴巴的 UT ,它提供了兩個接口,分別在頁面展現和頁面退出時調用。當進入該店鋪詳情頁時,調用頁面展現的接口,該接口會記錄一些頁面進入時的狀態信息,但是不發送日志。當從該店鋪詳情頁離開時(比如退出手機淘寶,或者返回上一頁),這是才會調用頁面退出接口,該接口會發送日志。
? ? ? ? 除了頁面展現和退出這兩個基礎接口外,UT 還提供了頁面擴展信息的接口,在頁面離開前,該接口會給頁面添加一些擴展信息,比如店鋪ID、店鋪類別(天貓/淘寶)等。
? ? ? ? 上面的三個接口必須配合使用,其中頁面展現和退出必須成對使用,而頁面擴展接口必須在這兩個接口使用的前提下使用。
日志發送的時機:
? ? ? ? 對于網頁瀏覽日志,基本都是頁面加載之后,當瀏覽器解析到相關的日志發送JS腳本就會自動執行發送。而對于移動端日志發送,則是在頁面離開后發送,因為移動端可以對頁面停留時長進行一個準確的計算。
用戶行為路徑還原:
? ? ? ? 在很多場景下需要采集更多的信息來減少計算分析的成本,UT 針對這種情況提功力透傳參數的功能。所謂透傳參數就是把當前頁面的某些信息傳遞到下一個或者下下一個頁面的日志中。比如我搜索 "手機" 之后給我推薦了很多商品,我點進去一個商品之后,我的搜索詞也應該被記錄到該商品日志當中去。
1.2.2、📲控件點擊和其它事件
? ? ? ? 和網頁交互日志一樣,交互類行為呈現出高度自定義的業務特征。對于控件點擊事件,它首先也會記錄基本的設備和用戶信息,此外,它還會記錄頁面名稱、控件名稱、控件的業務參數等。
? ? ? ? 除此之外,UT 還提供了一些默認的日志采集方法,比如自動捕獲應用崩潰,應用的退出、頁面的前后臺切換等。
1.2.3、📲特殊場景
日志聚合:
? ? ? ? 上面所有的場景(頁面事件和交互事件)都是一個行為產生一條日志,比如一次瀏覽、一次點擊。對于用戶量很大的公司,為了平衡日志的大小,減少流量消耗、日志服務器的壓力、網絡傳輸壓力等,采集 SDK 提供了聚合功能。對于一下曝光或者性能技術類的日志,可以選擇對這類日志進行一個聚合,以減少對日志采集服務器的請求量,適當減小日志的大小。比如對于曝光日志,手機一次滾動屏幕可能會觸發幾十個商品的曝光,我們總不可能讓它生成幾十個曝光日志,所以采集 SDK 提供了本地聚合的功能,在客戶端對這類日志進行聚合,然后再去發送到日志采集服務器。
1.2.4、📲設備標識
? ? ? ? 這里簡單介紹,設備標識用來標識用戶的唯一性。對于 UV 指標,可以通過用戶 ID? 來進行唯一標識,但是很多網頁或軟件并不要求用戶必須登錄,所以就難以標識日志的來源。對于這種情況 PC 端可以通過 Cookie 來解決,但是移動端就難以解決了。
? ? ? ? 對于單APP的公司,設備標識并不是非要攻克的難題,但是對于阿里巴巴有大量APP的大公司,唯一標識就必須解決。阿里巴巴使用的是 UTDID ,它是通過特定的算法來生成的,大部分情況下可以唯一標識一個設備。
1.2.5、📲日志傳輸
? ? ? ? 移動端的日志傳輸一般先存儲在客戶端本地,然后伺機上傳(啟動后、使用過程中 、切換后臺時)。觸發上傳日志的時機并不是單純依靠間隔時間,還要結合日志的大小以及上傳時網絡的耗時不斷調整上傳機制。
? ? ? ? 移動端上傳日志是向日志服務器發送 POST 請求,當天的日志會被存儲到當天的日志文件中。
之后當這些日志需要被下游使用時,一般會把日志放到消息隊列(比如 Kafka ,阿里巴巴用的是 TimeTunel)供下游消費者(比如 Hadoop 等,阿里巴巴用的是 MaxCompute)消費。
總結
? ? ? ? 日志采集這一部分主要是《阿里巴巴大數據之路》中專門拎出來講,學完之后確實對數據采集的過程有了更深刻的印象和理解。