數(shù)據(jù)采集技術(shù)簡(jiǎn)介

前言

本系列的技術(shù)文章不涉及實(shí)現(xiàn)細(xì)節(jié)，僅探討實(shí)現(xiàn)思路。由于數(shù)據(jù)倉(cāng)庫(kù)不僅僅是一個(gè)理論概念，其數(shù)據(jù)質(zhì)量等原則包含了大量的技術(shù)實(shí)現(xiàn)細(xì)節(jié)，因此從數(shù)據(jù)采集開始，到數(shù)據(jù)處理，至最終的數(shù)據(jù)展現(xiàn)，都需要進(jìn)行原理上和實(shí)現(xiàn)上的思路分析，才能保證最終數(shù)據(jù)倉(cāng)庫(kù)理論的完整實(shí)現(xiàn)。另外，需要強(qiáng)調(diào)的是，本系列文章非原創(chuàng)，是筆者多年從業(yè)經(jīng)歷的一種思路整理，對(duì)于日常理解數(shù)據(jù)倉(cāng)庫(kù)的實(shí)現(xiàn)有著很大的幫助，因而用到了非常多其他文章的引用，并介紹很多業(yè)界的好用工具及優(yōu)秀做法。

一、技術(shù)路線圖

二、Web端日志采集的業(yè)務(wù)概述

Web端數(shù)據(jù)采集主要通過三種方式實(shí)現(xiàn)：服務(wù)器日志、URL解析及JS回傳，詳情如下：

• 服務(wù)器日志，指Web服務(wù)器軟件，例如Httpd、Nginx、Tomcat等自帶的日志，例如Nginx的access.log日志等。

• URL解析，指訪問服務(wù)器時(shí)，將URL信息及攜帶的參數(shù)進(jìn)行解析后，上傳服務(wù)器，例如訪問百度首頁(yè)：https://www.baidu.com/s?ie=utf-8&wd=你好，我們可以獲得本次訪問的word為“你好”。

• JS回傳，指在Web頁(yè)面上添加的各類統(tǒng)計(jì)插件，通過在頁(yè)面嵌入自定義的Javascript代碼來(lái)獲取用戶的訪問行為(比如鼠標(biāo)懸停的位置，點(diǎn)擊的頁(yè)面組件等)，然后通過Ajax請(qǐng)求到后臺(tái)記錄日志。

瀏覽器的日志采集種類可以分為兩大類：

• 頁(yè)面瀏覽日志：別名為“展現(xiàn)日志”；指當(dāng)一個(gè)頁(yè)面被瀏覽器加載時(shí)所采集的日志，該類型為最基礎(chǔ)的互聯(lián)網(wǎng)日志，也是PV及UV統(tǒng)計(jì)的基礎(chǔ)。

• 頁(yè)面交互日志：別名為“點(diǎn)擊日志”；指當(dāng)頁(yè)面加載和渲染完成后，用戶可以在頁(yè)面上執(zhí)行的各類操作，以便量化感知用戶的興趣點(diǎn)。

除此之外，還有一些針對(duì)特定場(chǎng)合統(tǒng)計(jì)的日志，例如頁(yè)面曝光時(shí)長(zhǎng)日志、用戶在線操作監(jiān)控等，但原理都基于上述兩類日志，只是在統(tǒng)計(jì)上有所區(qū)分。

Web端重要指標(biāo)主要包括三個(gè)部分：

• 頁(yè)面瀏覽：PV、UV、IP、跳出率、平均訪問時(shí)長(zhǎng)、轉(zhuǎn)化次數(shù)等。

• 頁(yè)面交互：搜索詞、控件點(diǎn)擊、頁(yè)面跳轉(zhuǎn)等。

• 其他：轉(zhuǎn)化路徑分析、設(shè)備分析、訪客分析、系統(tǒng)環(huán)境、地域分布等。

三、Web端日志采集流程

目前典型的網(wǎng)頁(yè)訪問過程是以瀏覽器請(qǐng)求、服務(wù)器響應(yīng)并返回所請(qǐng)求的內(nèi)容為主，主要傳輸HTML文檔，瀏覽器和服務(wù)器之間的通信普遍遵守HTTP協(xié)議，并逐漸過渡到最新的HTTP2.0版本。一次典型的訪問過程由如下幾部分組成：

• 用戶在瀏覽器中點(diǎn)擊網(wǎng)頁(yè)鏈接。

• 瀏覽器在執(zhí)行時(shí)，會(huì)解析用戶請(qǐng)求內(nèi)容，并按照HTTP協(xié)議中約定的格式將其轉(zhuǎn)化為一個(gè)HTTP請(qǐng)求發(fā)送出去。

• 服務(wù)器按照業(yè)務(wù)邏輯處理本次請(qǐng)求，并按照HTTP協(xié)議規(guī)定的格式，將響應(yīng)結(jié)果返回瀏覽器。

• 瀏覽器收到服務(wù)器相應(yīng)內(nèi)容，并將其按照文檔規(guī)范展現(xiàn)給用戶。

在實(shí)際的處理過程中，前三步是無(wú)法采集用戶的瀏覽日志，采集主要在第四步，也就是瀏覽器解析文檔時(shí)才能進(jìn)行。因此可以很自然的想得到，HTML文檔中適當(dāng)位置增加一個(gè)日志采集節(jié)點(diǎn)，當(dāng)瀏覽器解析到這個(gè)節(jié)點(diǎn)時(shí)，便會(huì)發(fā)出一個(gè)特定的HTTP請(qǐng)求到日志采集服務(wù)器，日志采集服務(wù)器接收到請(qǐng)求時(shí)，便可以確定瀏覽器已經(jīng)成功接收和打開了頁(yè)面。目前業(yè)界常見的日志采集方案，只是在實(shí)現(xiàn)的細(xì)節(jié)上有所不同，原理都是相通的。

但只統(tǒng)計(jì)頁(yè)面流浪是不能滿足業(yè)務(wù)需求的，很多場(chǎng)合下用戶的具體行為特征也需要采集，因?yàn)橥鶗?huì)在特定的位置添加一個(gè)JS空間，當(dāng)用戶在頁(yè)面上執(zhí)行某個(gè)行為時(shí)，便會(huì)觸發(fā)一個(gè)異步請(qǐng)求，按照約定的格式向日志服務(wù)器發(fā)送點(diǎn)擊、等待、報(bào)錯(cuò)等交互行為。

四、Web端日志的清洗和預(yù)處理

在大部分場(chǎng)合下，直接收到的日志不能提供給下游使用，只能作為ODS基礎(chǔ)日志進(jìn)行保存，由于大數(shù)據(jù)平臺(tái)的半結(jié)構(gòu)化特征要求，需要進(jìn)行一些修正，轉(zhuǎn)化為DWD基礎(chǔ)日志才可以使用，具體原因有如下幾種：

• 反作弊、反爬蟲、反攻擊要求：由于Web端日志是互聯(lián)網(wǎng)行業(yè)大數(shù)據(jù)分析的基礎(chǔ)數(shù)據(jù)源，在實(shí)際業(yè)務(wù)場(chǎng)景下，往往會(huì)包含比例不小的惡意攻擊行為，例如流量作弊、爬蟲抓取、流量攻擊等，導(dǎo)致日志相關(guān)統(tǒng)計(jì)指標(biāo)發(fā)生明顯的偏差。為此需要進(jìn)行日志合法性的校驗(yàn)，并由專門的團(tuán)隊(duì)來(lái)處理相關(guān)攻擊，這是一個(gè)長(zhǎng)期而艱苦的過程。

• 數(shù)據(jù)項(xiàng)修正：為了保證后續(xù)日志應(yīng)用的統(tǒng)計(jì)口徑統(tǒng)一，往往需要對(duì)日志中一些公用且重要的數(shù)據(jù)值做歸一、標(biāo)準(zhǔn)化處理或反向補(bǔ)正。例如用戶登錄后，需要對(duì)登錄前的日志做身份信息回補(bǔ)、例如當(dāng)金額信息因?yàn)椴糠衷虺霈F(xiàn)負(fù)值時(shí)，需要人工進(jìn)行補(bǔ)正操作，等等。

• 無(wú)效數(shù)據(jù)剔除：在很多情況下，因?yàn)闃I(yè)務(wù)變更等原因，會(huì)導(dǎo)致采集到的非常多的無(wú)意義數(shù)據(jù)，在特定統(tǒng)計(jì)情況下會(huì)干擾最終指標(biāo)的實(shí)現(xiàn)。要知道，很多運(yùn)營(yíng)對(duì)于哪怕一個(gè)百分點(diǎn)都要扣的非常仔細(xì)，如果發(fā)現(xiàn)因?yàn)橐恍o(wú)效數(shù)據(jù)導(dǎo)致KPI發(fā)生了偏差，結(jié)果會(huì)非常不妙。為了避免此類異常的發(fā)生，需要定時(shí)更新處理代碼，以處理掉已經(jīng)不需要的統(tǒng)計(jì)日志。

• 日志隔離分發(fā)：如果團(tuán)隊(duì)規(guī)模變得非常龐大時(shí)，很多數(shù)據(jù)，例如實(shí)際金額等，就不可能全部對(duì)外公開了，需要走特殊的采集流程，以保障數(shù)據(jù)的安全和隱私。?

五、漏斗模型簡(jiǎn)介

Web端的分析經(jīng)常用到的模型為：漏斗模型。這里介紹漏斗模型，對(duì)于理解一些常見的統(tǒng)計(jì)方式有比較好的幫助，例如淘寶SPM體系，當(dāng)你熟悉和了解之后，會(huì)發(fā)現(xiàn)它真的很好用。

漏斗模型全稱為“搜索營(yíng)銷效果轉(zhuǎn)化漏斗”，對(duì)應(yīng)了企業(yè)搜索營(yíng)銷的各個(gè)環(huán)節(jié)，反映了從展現(xiàn)、點(diǎn)擊、訪問、咨詢，直到生成訂單過程中的客戶數(shù)量及流失。從最大的展現(xiàn)量到最小的訂單量，這個(gè)一層層縮小的過程表示不斷有客戶因?yàn)楦鞣N原因離開，對(duì)企業(yè)失去興趣或放棄購(gòu)買。可以說(shuō)，互聯(lián)網(wǎng)商業(yè)價(jià)值的體現(xiàn)，與漏斗模型有著直接的關(guān)聯(lián)關(guān)系，因此也是一系列技術(shù)實(shí)現(xiàn)及數(shù)據(jù)分析的重點(diǎn)。

漏斗模型是一個(gè)線性流程，從開始到結(jié)束，用戶在每一個(gè)環(huán)節(jié)，都會(huì)產(chǎn)生流失，就像漏斗一樣。以電商為例，最常見漏斗模型就是：瀏覽/搜索-加購(gòu)-下單-支付-復(fù)購(gòu)，因此對(duì)于統(tǒng)計(jì)數(shù)據(jù)而言，找出用戶購(gòu)買一個(gè)商品的搜索過程，來(lái)反思用戶的行為，就顯得十分有必要。數(shù)據(jù)人要做的工作，就是整理出路徑中各個(gè)環(huán)節(jié)的數(shù)據(jù)，考慮用戶流失的因素，進(jìn)行對(duì)應(yīng)的優(yōu)化，或者通過縮短用戶路徑來(lái)優(yōu)化產(chǎn)品體驗(yàn)。其實(shí)不論在電商平臺(tái)、招聘平臺(tái)、廣告平臺(tái)等常見的互聯(lián)網(wǎng)業(yè)務(wù)模式中，漏斗模型始終是數(shù)據(jù)分析工作的重點(diǎn)。這里通過一個(gè)圖來(lái)理解漏斗模型的商業(yè)價(jià)值：

但說(shuō)實(shí)話，很多公司在數(shù)據(jù)統(tǒng)計(jì)上，可能并沒有這么強(qiáng)的需求來(lái)搭建一個(gè)完整的平臺(tái)，也有很多公司想從不同的地方來(lái)看一看自己的數(shù)據(jù)是否準(zhǔn)備，這時(shí)大家都會(huì)選擇Google GA來(lái)進(jìn)行統(tǒng)計(jì)或者是對(duì)比數(shù)據(jù)。公司的統(tǒng)計(jì)往往是兩條線，一條是自有線的統(tǒng)計(jì)，另一條便是發(fā)給Google GA來(lái)進(jìn)行對(duì)比分析。因此在統(tǒng)計(jì)平臺(tái)的功能設(shè)置上，經(jīng)常要與Google GA對(duì)標(biāo)，因此數(shù)據(jù)倉(cāng)庫(kù)不僅是一個(gè)過程的搭建，還有很多固有的業(yè)務(wù)邏輯在其中。

六、淘寶SPM碼

漏斗模型比較優(yōu)秀的應(yīng)用案例為淘寶SPM碼。查看淘寶網(wǎng)頁(yè)的源代碼會(huì)經(jīng)常看到http://detail.tmall.com/item.htm?id=XXX&&spm=2014.123456789.1.2這樣的例子，這是淘寶提供的SPM是淘寶社區(qū)電商業(yè)務(wù)（xTao）為外部合作伙伴（外站）提供的一套跟蹤引導(dǎo)成交效果數(shù)據(jù)的解決方案。簡(jiǎn)單說(shuō)來(lái)，SPM編碼是一種用來(lái)跟蹤頁(yè)面模塊位置的編碼，標(biāo)準(zhǔn)spm編碼由4段組成，采用a.b.c.d的格式（建議全部使用數(shù)字），其中：

• a代表站點(diǎn)類型，對(duì)于xTao合作伙伴（外站），a為固定值，a=2014。

• b代表外站ID（即外站所使用的TOP appkey），比如您的站點(diǎn)使用的TOP appkey=123456789，則b=123456789。

• c代表b站點(diǎn)上的頻道ID，比如是外站某個(gè)團(tuán)購(gòu)頻道，某個(gè)逛街頻道，某個(gè)試用頻道等。

• d代表c頻道上的頁(yè)面ID，比如是某個(gè)團(tuán)購(gòu)詳情頁(yè)，某個(gè)寶貝詳情頁(yè)，某個(gè)試用詳情頁(yè)等。

完整的SPM四位編碼能標(biāo)識(shí)出某網(wǎng)站中某一個(gè)頻道的某一個(gè)具體頁(yè)面。比如xTao合作伙伴（a=2014）中某個(gè)外站appkey為123456789（b=123456789），頻道ID為1（c=1），頁(yè)面ID為2（d=2），那么spm=2014.123456789.1.2，就唯一標(biāo)識(shí)外站123456789的頻道1上的頁(yè)面2，從這個(gè)頁(yè)面點(diǎn)擊出去的鏈接，后面都應(yīng)該攜帶spm=2014.123456789.1.2的參數(shù)串。這樣，通過這個(gè)編碼，我們就能唯一的定位到一個(gè)url是由外站中哪個(gè)具體頁(yè)面點(diǎn)擊生成的。?

因?yàn)閟pm編碼本身是有層次的，因此，我們可以：

• 單獨(dú)統(tǒng)計(jì)spm的a部分，我們可以知道某一類站點(diǎn)的訪問和點(diǎn)擊情況，以及后續(xù)引導(dǎo)和成交情況。

• 單獨(dú)統(tǒng)計(jì)spm的a.b部分，我們可以用來(lái)評(píng)估某一個(gè)站點(diǎn)的訪問和點(diǎn)擊效果，以及后續(xù)引導(dǎo)和成交情況。

• 單獨(dú)統(tǒng)計(jì)spm的a.b.c部分，我們可以用來(lái)評(píng)估某一個(gè)站點(diǎn)上某一頻道的訪問和點(diǎn)擊效果，以及后續(xù)引導(dǎo)和成交情況。

• 單獨(dú)統(tǒng)計(jì)spm的a.b.c.d部分，我們可以用來(lái)評(píng)估某一個(gè)頻道上某一具體頁(yè)面的點(diǎn)擊效果，以及后續(xù)引導(dǎo)和成交情況。?

基于SPM可以得到的效果統(tǒng)計(jì)指標(biāo)：

• PV：通過指定spm編碼引導(dǎo)到寶貝詳情頁(yè)面的PV。

• UV：通過指定spm編碼引導(dǎo)到寶貝詳情頁(yè)面的UV。

• 支付寶成交人數(shù)：通過指定spm編碼引導(dǎo)到寶貝詳情頁(yè)面的用戶當(dāng)天對(duì)同店商品的支付寶成交人數(shù)。

• 轉(zhuǎn)化率=支付寶成交人數(shù)/UV，代表通過指定spm編碼引導(dǎo)的用戶最終轉(zhuǎn)化為購(gòu)買用戶的比率。?

七、客戶端日志采集

與網(wǎng)頁(yè)日志對(duì)應(yīng)的，是手機(jī)應(yīng)用為基礎(chǔ)的客戶端日志，由于早期手機(jī)網(wǎng)絡(luò)通訊能力較差，因而SDK往往采用延遲發(fā)送日志的方式，也就是將日志統(tǒng)計(jì)在本地，然后選擇在Wifi環(huán)境下上傳，因而往往會(huì)出現(xiàn)統(tǒng)計(jì)數(shù)據(jù)延遲的情況。現(xiàn)如今網(wǎng)絡(luò)環(huán)境好了很多，4G、5G流量充足，尤其是視頻類APP基本上都是一直聯(lián)網(wǎng)，因而很多統(tǒng)計(jì)能夠做到實(shí)時(shí)統(tǒng)計(jì)。

客戶端的日志統(tǒng)計(jì)主要通過SDK來(lái)完成，根據(jù)不同的用戶行為分成不同的事件，“事件”是客戶端日志行為的最小單位，根據(jù)類型的不同，可以分為頁(yè)面事件（類比頁(yè)面瀏覽）和控件點(diǎn)擊事件（類比頁(yè)面交互）。

頁(yè)面事件的統(tǒng)計(jì)主要統(tǒng)計(jì)如下三類信息：

• 設(shè)備及用戶的基本信息，例如IMEI、用戶賬號(hào)等。

• 被訪問頁(yè)面的信息，例如商品ID、瀏覽店鋪等。

• 訪問的路徑信息，例如上一個(gè)頁(yè)面來(lái)源等。

與Web日志采集類似的是，交互日志的采集同樣無(wú)法規(guī)定統(tǒng)一的采集內(nèi)容，除了記錄基本的設(shè)備信息和用戶信息外，很多統(tǒng)計(jì)的方式是可以由業(yè)務(wù)方自定義統(tǒng)計(jì)的，也就是根據(jù)業(yè)務(wù)需求的不同，產(chǎn)品在配置平臺(tái)上自定義一個(gè)統(tǒng)計(jì)項(xiàng)，下次SDK更新時(shí)便可以加入統(tǒng)計(jì)項(xiàng)，自主看到統(tǒng)計(jì)內(nèi)容，便于自動(dòng)化的管理運(yùn)維。但在每個(gè)事件上，會(huì)提供一些額外的統(tǒng)計(jì)信息，例如事件名稱、事件時(shí)長(zhǎng)、事件屬性、事件頁(yè)面等。

八、客戶端日志的聚合

由于事件的統(tǒng)計(jì)涉及到很多參數(shù)，基本上是一個(gè)行為能夠產(chǎn)生一條日志，不僅客戶端會(huì)產(chǎn)生大量的記錄數(shù)據(jù)，對(duì)于服務(wù)端的接收通常會(huì)產(chǎn)生很大的流量負(fù)擔(dān)。因此統(tǒng)計(jì)SDK往往會(huì)有聚合和壓縮的功能，對(duì)于一些展現(xiàn)場(chǎng)景，可以適當(dāng)?shù)暮喜⑷罩?#xff0c;以減少數(shù)據(jù)量。例如在淘寶等APP中，一次商品頁(yè)的瀏覽會(huì)產(chǎn)生上百條日志，從下游分析的角度來(lái)看，只需要知道哪些內(nèi)容被曝光了即可，因此完全可以在一條日志中記錄曝光的ID，而無(wú)需每個(gè)都統(tǒng)計(jì)一遍。

還有一種場(chǎng)景，因?yàn)锳PP存在回退的情況，因此在訪問路徑的分析中，往往會(huì)產(chǎn)生干擾統(tǒng)計(jì)，因此在統(tǒng)計(jì)時(shí)需要添加一些特殊的標(biāo)識(shí)，來(lái)鑒別該行為是否屬于回退行為。

九、統(tǒng)計(jì)SDK

市面上最常見的，如友盟、Talkingdata、百度統(tǒng)計(jì)、騰訊云分析、GA等第三方統(tǒng)計(jì)服務(wù)提供商，也誕生了很多在某些分析方面更加專一、深入的統(tǒng)計(jì)服務(wù)商，比如諸葛io、growingio、神策等，看自己需求進(jìn)行配置。

十、唯一設(shè)備標(biāo)識(shí)符

在客戶端的相關(guān)統(tǒng)計(jì)中，如何鑒定一個(gè)用戶是非常難的，因?yàn)榫W(wǎng)頁(yè)有統(tǒng)一的Cookie來(lái)進(jìn)行識(shí)別，但客戶端并沒有。歷史上，IMEI、IMSI、MAC地址、蘋果禁用之前的UDID，都可以用，但由于用戶自我保護(hù)意識(shí)的提高及系統(tǒng)的升級(jí)，很多基本的設(shè)備信息都難以獲取到了，Android也進(jìn)行了設(shè)備信息獲取的限制。對(duì)于單個(gè)App的公司來(lái)說(shuō)，識(shí)別唯一用戶并不是難事，但對(duì)于多App的公司來(lái)說(shuō)，這一點(diǎn)就尤為重要，也這是業(yè)界難題。

十一、H5與Native的統(tǒng)一

App有兩種類型，一種是純Native的App，另一種是既有Native，也有H5頁(yè)面嵌入的App，目前大部分的App都是兩者兼有的狀況。Native頁(yè)面的數(shù)據(jù)統(tǒng)計(jì)主要通過SDK進(jìn)行，但H5頁(yè)面的數(shù)據(jù)統(tǒng)計(jì)還是基于瀏覽器的頁(yè)面日志來(lái)進(jìn)行，由于采集方式的不同，很多情況下兩個(gè)頁(yè)面互相跳轉(zhuǎn)時(shí)，便無(wú)法還原用戶訪問路徑，對(duì)于數(shù)據(jù)的統(tǒng)計(jì)分析產(chǎn)生很嚴(yán)重的影響。解決的思路有兩種，一種是Native日志歸攏到H5日志中，另一種是H5日志歸攏到Native日志中，但綜合考慮，歸攏到Native日志更為合理，因?yàn)镾DK能夠采集更為全面的日子信息。具體實(shí)現(xiàn)方式上，可以在H5頁(yè)面中嵌入JS代碼，通過調(diào)用WebView框架中的JSBridge接口，來(lái)實(shí)現(xiàn)參數(shù)的傳入，并由統(tǒng)計(jì)SDK進(jìn)行日志的封裝。當(dāng)然方法不是萬(wàn)能的，有其他的好方式也可以嘗試。

十二、大促保障

大促保障指在雙十一等類似場(chǎng)景下，流量短時(shí)間內(nèi)保障的情況，需要對(duì)系統(tǒng)進(jìn)行一定的改造。在高并發(fā)場(chǎng)景下，從數(shù)據(jù)的埋點(diǎn)采集，到日志服務(wù)器的收集，再到數(shù)據(jù)傳輸，再到數(shù)據(jù)的分析和統(tǒng)計(jì)，任何一個(gè)環(huán)節(jié)出現(xiàn)問題，大促保障就是失效的。由于日志處理的鏈路非常長(zhǎng)，因此可以通過限制流量、消息隊(duì)列削弱峰值、異步處理、內(nèi)存緩沖、擴(kuò)展服務(wù)等方式進(jìn)行，在日志采集環(huán)節(jié)中，可以通過延遲非核心日志上傳的方式，優(yōu)先處理核心日志，以保障統(tǒng)計(jì)效果。在天貓雙十一中，可以經(jīng)常看到暫停部分服務(wù)的通知，便是這種方式的實(shí)現(xiàn)。

熱門文章

直戳淚點(diǎn)！數(shù)據(jù)從業(yè)者權(quán)威嘲諷指南！

數(shù)據(jù)分析師做成了提數(shù)工程師，該如何破局？

全棧型VS專精型，團(tuán)隊(duì)到底需要什么樣的人？

數(shù)據(jù)驅(qū)動(dòng)業(yè)務(wù)，比技術(shù)更重要的是思維的轉(zhuǎn)變

最近面了十多個(gè)數(shù)據(jù)分析師，聊一聊我發(fā)現(xiàn)的一些問題

你也「在看」嗎？????

總結(jié)

以上是生活随笔為你收集整理的数据采集技术简介的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。