数据采集技术简介
數(shù)據(jù)采集技術(shù)簡介
前言
本系列的技術(shù)文章不涉及實現(xiàn)細節(jié)，僅探討實現(xiàn)思路。由于數(shù)據(jù)倉庫不僅僅是一個理論概念，其數(shù)據(jù)質(zhì)量等原則包含了大量的技術(shù)實現(xiàn)細節(jié)，因此從數(shù)據(jù)采集開始，到數(shù)據(jù)處理，至最終的數(shù)據(jù)展現(xiàn)，都需要進行原理上和實現(xiàn)上的思路分析，才能保證最終數(shù)據(jù)倉庫理論的完整實現(xiàn)。另外，需要強調(diào)的是，本系列文章非原創(chuàng)，是筆者多年從業(yè)經(jīng)歷的一種思路整理，對于日常理解數(shù)據(jù)倉庫的實現(xiàn)有著很大的幫助，因而用到了非常多其他文章的引用，并介紹很多業(yè)界的好用工具及優(yōu)秀做法。
一、技術(shù)路線圖
二、Web端日志采集的業(yè)務(wù)概述
Web端數(shù)據(jù)采集主要通過三種方式實現(xiàn)：服務(wù)器日志、URL解析及JS回傳，詳情如下：
服務(wù)器日志，指Web服務(wù)器軟件，例如Httpd、Nginx、Tomcat等自帶的日志，例如Nginx的access.log日志等。
URL解析，指訪問服務(wù)器時，將URL信息及攜帶的參數(shù)進行解析后，上傳服務(wù)器，例如訪問百度首頁：https://www.baidu.com/s?ie=utf-8&wd=你好，我們可以獲得本次訪問的word為“你好”。
JS回傳，指在Web頁面上添加的各類統(tǒng)計插件，通過在頁面嵌入自定義的Javascript代碼來獲取用戶的訪問行為(比如鼠標懸停的位置，點擊的頁面組件等)，然后通過Ajax請求到后臺記錄日志。
瀏覽器的日志采集種類可以分為兩大類：
頁面瀏覽日志：別名為“展現(xiàn)日志”；指當一個頁面被瀏覽器加載時所采集的日志，該類型為最基礎(chǔ)的互聯(lián)網(wǎng)日志，也是PV及UV統(tǒng)計的基礎(chǔ)。
頁面交互日志：別名為“點擊日志”；指當頁面加載和渲染完成后，用戶可以在頁面上執(zhí)行的各類操作，以便量化感知用戶的興趣點。
除此之外，還有一些針對特定場合統(tǒng)計的日志，例如頁面曝光時長日志、用戶在線操作監(jiān)控等，但原理都基于上述兩類日志，只是在統(tǒng)計上有所區(qū)分。
Web端重要指標主要包括三個部分：
頁面瀏覽：PV、UV、IP、跳出率、平均訪問時長、轉(zhuǎn)化次數(shù)等。
頁面交互：搜索詞、控件點擊、頁面跳轉(zhuǎn)等。
其他：轉(zhuǎn)化路徑分析、設(shè)備分析、訪客分析、系統(tǒng)環(huán)境、地域分布等。
三、Web端日志采集流程
目前典型的網(wǎng)頁訪問過程是以瀏覽器請求、服務(wù)器響應(yīng)并返回所請求的內(nèi)容為主，主要傳輸HTML文檔，瀏覽器和服務(wù)器之間的通信普遍遵守HTTP協(xié)議，并逐漸過渡到最新的HTTP2.0版本。一次典型的訪問過程由如下幾部分組成：
用戶在瀏覽器中點擊網(wǎng)頁鏈接。
瀏覽器在執(zhí)行時，會解析用戶請求內(nèi)容，并按照HTTP協(xié)議中約定的格式將其轉(zhuǎn)化為一個HTTP請求發(fā)送出去。
服務(wù)器按照業(yè)務(wù)邏輯處理本次請求，并按照HTTP協(xié)議規(guī)定的格式，將響應(yīng)結(jié)果返回瀏覽器。
瀏覽器收到服務(wù)器相應(yīng)內(nèi)容，并將其按照文檔規(guī)范展現(xiàn)給用戶。
在實際的處理過程中，前三步是無法采集用戶的瀏覽日志，采集主要在第四步，也就是瀏覽器解析文檔時才能進行。因此可以很自然的想得到，HTML文檔中適當位置增加一個日志采集節(jié)點，當瀏覽器解析到這個節(jié)點時，便會發(fā)出一個特定的HTTP請求到日志采集服務(wù)器，日志采集服務(wù)器接收到請求時，便可以確定瀏覽器已經(jīng)成功接收和打開了頁面。目前業(yè)界常見的日志采集方案，只是在實現(xiàn)的細節(jié)上有所不同，原理都是相通的。
但只統(tǒng)計頁面流浪是不能滿足業(yè)務(wù)需求的，很多場合下用戶的具體行為特征也需要采集，因為往往會在特定的位置添加一個JS空間，當用戶在頁面上執(zhí)行某個行為時，便會觸發(fā)一個異步請求，按照約定的格式向日志服務(wù)器發(fā)送點擊、等待、報錯等交互行為。
四、Web端日志的清洗和預(yù)處理
在大部分場合下，直接收到的日志不能提供給下游使用，只能作為ODS基礎(chǔ)日志進行保存，由于大數(shù)據(jù)平臺的半結(jié)構(gòu)化特征要求，需要進行一些修正，轉(zhuǎn)化為DWD基礎(chǔ)日志才可以使用，具體原因有如下幾種：
反作弊、反爬蟲、反攻擊要求：由于Web端日志是互聯(lián)網(wǎng)行業(yè)大數(shù)據(jù)分析的基礎(chǔ)數(shù)據(jù)源，在實際業(yè)務(wù)場景下，往往會包含比例不小的惡意攻擊行為，例如流量作弊、爬蟲抓取、流量攻擊等，導致日志相關(guān)統(tǒng)計指標發(fā)生明顯的偏差。為此需要進行日志合法性的校驗，并由專門的團隊來處理相關(guān)攻擊，這是一個長期而艱苦的過程。
數(shù)據(jù)項修正：為了保證后續(xù)日志應(yīng)用的統(tǒng)計口徑統(tǒng)一，往往需要對日志中一些公用且重要的數(shù)據(jù)值做歸一、標準化處理或反向補正。例如用戶登錄后，需要對登錄前的日志做身份信息回補、例如當金額信息因為部分原因出現(xiàn)負值時，需要人工進行補正操作，等等。
無效數(shù)據(jù)剔除：在很多情況下，因為業(yè)務(wù)變更等原因，會導致采集到的非常多的無意義數(shù)據(jù)，在特定統(tǒng)計情況下會干擾最終指標的實現(xiàn)。要知道，很多運營對于哪怕一個百分點都要扣的非常仔細，如果發(fā)現(xiàn)因為一些無效數(shù)據(jù)導致KPI發(fā)生了偏差，結(jié)果會非常不妙。為了避免此類異常的發(fā)生，需要定時更新處理代碼，以處理掉已經(jīng)不需要的統(tǒng)計日志。
日志隔離分發(fā)：如果團隊規(guī)模變得非常龐大時，很多數(shù)據(jù)，例如實際金額等，就不可能全部對外公開了，需要走特殊的采集流程，以保障數(shù)據(jù)的安全和隱私。?
五、漏斗模型簡介
Web端的分析經(jīng)常用到的模型為：漏斗模型。這里介紹漏斗模型，對于理解一些常見的統(tǒng)計方式有比較好的幫助，例如淘寶SPM體系，當你熟悉和了解之后，會發(fā)現(xiàn)它真的很好用。
漏斗模型全稱為“搜索營銷效果轉(zhuǎn)化漏斗”，對應(yīng)了企業(yè)搜索營銷的各個環(huán)節(jié)，反映了從展現(xiàn)、點擊、訪問、咨詢，直到生成訂單過程中的客戶數(shù)量及流失。從最大的展現(xiàn)量到最小的訂單量，這個一層層縮小的過程表示不斷有客戶因為各種原因離開，對企業(yè)失去興趣或放棄購買。可以說，互聯(lián)網(wǎng)商業(yè)價值的體現(xiàn)，與漏斗模型有著直接的關(guān)聯(lián)關(guān)系，因此也是一系列技術(shù)實現(xiàn)及數(shù)據(jù)分析的重點。
漏斗模型是一個線性流程，從開始到結(jié)束，用戶在每一個環(huán)節(jié)，都會產(chǎn)生流失，就像漏斗一樣。以電商為例，最常見漏斗模型就是：瀏覽/搜索-加購-下單-支付-復購，因此對于統(tǒng)計數(shù)據(jù)而言，找出用戶購買一個商品的搜索過程，來反思用戶的行為，就顯得十分有必要。數(shù)據(jù)人要做的工作，就是整理出路徑中各個環(huán)節(jié)的數(shù)據(jù)，考慮用戶流失的因素，進行對應(yīng)的優(yōu)化，或者通過縮短用戶路徑來優(yōu)化產(chǎn)品體驗。其實不論在電商平臺、招聘平臺、廣告平臺等常見的互聯(lián)網(wǎng)業(yè)務(wù)模式中，漏斗模型始終是數(shù)據(jù)分析工作的重點。這里通過一個圖來理解漏斗模型的商業(yè)價值：
但說實話，很多公司在數(shù)據(jù)統(tǒng)計上，可能并沒有這么強的需求來搭建一個完整的平臺，也有很多公司想從不同的地方來看一看自己的數(shù)據(jù)是否準備，這時大家都會選擇Google GA來進行統(tǒng)計或者是對比數(shù)據(jù)。公司的統(tǒng)計往往是兩條線，一條是自有線的統(tǒng)計，另一條便是發(fā)給Google GA來進行對比分析。因此在統(tǒng)計平臺的功能設(shè)置上，經(jīng)常要與Google GA對標，因此數(shù)據(jù)倉庫不僅是一個過程的搭建，還有很多固有的業(yè)務(wù)邏輯在其中。
六、淘寶SPM碼
漏斗模型比較優(yōu)秀的應(yīng)用案例為淘寶SPM碼。查看淘寶網(wǎng)頁的源代碼會經(jīng)常看到http://detail.tmall.com/item.htm?id=XXX&&spm=2014.123456789.1.2這樣的例子，這是淘寶提供的SPM是淘寶社區(qū)電商業(yè)務(wù)（xTao）為外部合作伙伴（外站）提供的一套跟蹤引導成交效果數(shù)據(jù)的解決方案。簡單說來，SPM編碼是一種用來跟蹤頁面模塊位置的編碼，標準spm編碼由4段組成，采用a.b.c.d的格式（建議全部使用數(shù)字），其中：
a代表站點類型，對于xTao合作伙伴（外站），a為固定值，a=2014。
b代表外站ID（即外站所使用的TOP appkey），比如您的站點使用的TOP appkey=123456789，則b=123456789。
c代表b站點上的頻道ID，比如是外站某個團購頻道，某個逛街頻道，某個試用頻道等。
d代表c頻道上的頁面ID，比如是某個團購詳情頁，某個寶貝詳情頁，某個試用詳情頁等。
完整的SPM四位編碼能標識出某網(wǎng)站中某一個頻道的某一個具體頁面。比如xTao合作伙伴（a=2014）中某個外站appkey為123456789（b=123456789），頻道ID為1（c=1），頁面ID為2（d=2），那么spm=2014.123456789.1.2，就唯一標識外站123456789的頻道1上的頁面2，從這個頁面點擊出去的鏈接，后面都應(yīng)該攜帶spm=2014.123456789.1.2的參數(shù)串。這樣，通過這個編碼，我們就能唯一的定位到一個url是由外站中哪個具體頁面點擊生成的。?
因為spm編碼本身是有層次的，因此，我們可以：
單獨統(tǒng)計spm的a部分，我們可以知道某一類站點的訪問和點擊情況，以及后續(xù)引導和成交情況。
單獨統(tǒng)計spm的a.b部分，我們可以用來評估某一個站點的訪問和點擊效果，以及后續(xù)引導和成交情況。
單獨統(tǒng)計spm的a.b.c部分，我們可以用來評估某一個站點上某一頻道的訪問和點擊效果，以及后續(xù)引導和成交情況。
單獨統(tǒng)計spm的a.b.c.d部分，我們可以用來評估某一個頻道上某一具體頁面的點擊效果，以及后續(xù)引導和成交情況。?
基于SPM可以得到的效果統(tǒng)計指標：
PV：通過指定spm編碼引導到寶貝詳情頁面的PV。
UV：通過指定spm編碼引導到寶貝詳情頁面的UV。
支付寶成交人數(shù)：通過指定spm編碼引導到寶貝詳情頁面的用戶當天對同店商品的支付寶成交人數(shù)。
轉(zhuǎn)化率=支付寶成交人數(shù)/UV，代表通過指定spm編碼引導的用戶最終轉(zhuǎn)化為購買用戶的比率。?
七、客戶端日志采集
與網(wǎng)頁日志對應(yīng)的，是手機應(yīng)用為基礎(chǔ)的客戶端日志，由于早期手機網(wǎng)絡(luò)通訊能力較差，因而SDK往往采用延遲發(fā)送日志的方式，也就是將日志統(tǒng)計在本地，然后選擇在Wifi環(huán)境下上傳，因而往往會出現(xiàn)統(tǒng)計數(shù)據(jù)延遲的情況。現(xiàn)如今網(wǎng)絡(luò)環(huán)境好了很多，4G、5G流量充足，尤其是視頻類APP基本上都是一直聯(lián)網(wǎng)，因而很多統(tǒng)計能夠做到實時統(tǒng)計。
客戶端的日志統(tǒng)計主要通過SDK來完成，根據(jù)不同的用戶行為分成不同的事件，“事件”是客戶端日志行為的最小單位，根據(jù)類型的不同，可以分為頁面事件（類比頁面瀏覽）和控件點擊事件（類比頁面交互）。
頁面事件的統(tǒng)計主要統(tǒng)計如下三類信息：
設(shè)備及用戶的基本信息，例如IMEI、用戶賬號等。
被訪問頁面的信息，例如商品ID、瀏覽店鋪等。
訪問的路徑信息，例如上一個頁面來源等。
與Web日志采集類似的是，交互日志的采集同樣無法規(guī)定統(tǒng)一的采集內(nèi)容，除了記錄基本的設(shè)備信息和用戶信息外，很多統(tǒng)計的方式是可以由業(yè)務(wù)方自定義統(tǒng)計的，也就是根據(jù)業(yè)務(wù)需求的不同，產(chǎn)品在配置平臺上自定義一個統(tǒng)計項，下次SDK更新時便可以加入統(tǒng)計項，自主看到統(tǒng)計內(nèi)容，便于自動化的管理運維。但在每個事件上，會提供一些額外的統(tǒng)計信息，例如事件名稱、事件時長、事件屬性、事件頁面等。
八、客戶端日志的聚合
由于事件的統(tǒng)計涉及到很多參數(shù)，基本上是一個行為能夠產(chǎn)生一條日志，不僅客戶端會產(chǎn)生大量的記錄數(shù)據(jù)，對于服務(wù)端的接收通常會產(chǎn)生很大的流量負擔。因此統(tǒng)計SDK往往會有聚合和壓縮的功能，對于一些展現(xiàn)場景，可以適當?shù)暮喜⑷罩?#xff0c;以減少數(shù)據(jù)量。例如在淘寶等APP中，一次商品頁的瀏覽會產(chǎn)生上百條日志，從下游分析的角度來看，只需要知道哪些內(nèi)容被曝光了即可，因此完全可以在一條日志中記錄曝光的ID，而無需每個都統(tǒng)計一遍。
還有一種場景，因為APP存在回退的情況，因此在訪問路徑的分析中，往往會產(chǎn)生干擾統(tǒng)計，因此在統(tǒng)計時需要添加一些特殊的標識，來鑒別該行為是否屬于回退行為。
九、統(tǒng)計SDK
市面上最常見的，如友盟、Talkingdata、百度統(tǒng)計、騰訊云分析、GA等第三方統(tǒng)計服務(wù)提供商，也誕生了很多在某些分析方面更加專一、深入的統(tǒng)計服務(wù)商，比如諸葛io、growingio、神策等，看自己需求進行配置。
十、唯一設(shè)備標識符
在客戶端的相關(guān)統(tǒng)計中，如何鑒定一個用戶是非常難的，因為網(wǎng)頁有統(tǒng)一的Cookie來進行識別，但客戶端并沒有。歷史上，IMEI、IMSI、MAC地址、蘋果禁用之前的UDID，都可以用，但由于用戶自我保護意識的提高及系統(tǒng)的升級，很多基本的設(shè)備信息都難以獲取到了，Android也進行了設(shè)備信息獲取的限制。對于單個App的公司來說，識別唯一用戶并不是難事，但對于多App的公司來說，這一點就尤為重要，也這是業(yè)界難題。
十一、H5與Native的統(tǒng)一
App有兩種類型，一種是純Native的App，另一種是既有Native，也有H5頁面嵌入的App，目前大部分的App都是兩者兼有的狀況。Native頁面的數(shù)據(jù)統(tǒng)計主要通過SDK進行，但H5頁面的數(shù)據(jù)統(tǒng)計還是基于瀏覽器的頁面日志來進行，由于采集方式的不同，很多情況下兩個頁面互相跳轉(zhuǎn)時，便無法還原用戶訪問路徑，對于數(shù)據(jù)的統(tǒng)計分析產(chǎn)生很嚴重的影響。解決的思路有兩種，一種是Native日志歸攏到H5日志中，另一種是H5日志歸攏到Native日志中，但綜合考慮，歸攏到Native日志更為合理，因為SDK能夠采集更為全面的日子信息。具體實現(xiàn)方式上，可以在H5頁面中嵌入JS代碼，通過調(diào)用WebView框架中的JSBridge接口，來實現(xiàn)參數(shù)的傳入，并由統(tǒng)計SDK進行日志的封裝。當然方法不是萬能的，有其他的好方式也可以嘗試。
十二、大促保障
大促保障指在雙十一等類似場景下，流量短時間內(nèi)保障的情況，需要對系統(tǒng)進行一定的改造。在高并發(fā)場景下，從數(shù)據(jù)的埋點采集，到日志服務(wù)器的收集，再到數(shù)據(jù)傳輸，再到數(shù)據(jù)的分析和統(tǒng)計，任何一個環(huán)節(jié)出現(xiàn)問題，大促保障就是失效的。由于日志處理的鏈路非常長，因此可以通過限制流量、消息隊列削弱峰值、異步處理、內(nèi)存緩沖、擴展服務(wù)等方式進行，在日志采集環(huán)節(jié)中，可以通過延遲非核心日志上傳的方式，優(yōu)先處理核心日志，以保障統(tǒng)計效果。在天貓雙十一中，可以經(jīng)常看到暫停部分服務(wù)的通知，便是這種方式的實現(xiàn)。
熱門文章
直戳淚點！數(shù)據(jù)從業(yè)者權(quán)威嘲諷指南！
數(shù)據(jù)分析師做成了提數(shù)工程師，該如何破局？
全棧型VS專精型，團隊到底需要什么樣的人？
數(shù)據(jù)驅(qū)動業(yè)務(wù)，比技術(shù)更重要的是思維的轉(zhuǎn)變
最近面了十多個數(shù)據(jù)分析師，聊一聊我發(fā)現(xiàn)的一些問題
你也「在看」嗎？????
總結(jié)
- 上一篇： springboot2.0 多数据源整合
- 下一篇： 用session实现html登录页面跳转