美團(tuán)外賣(mài)流量數(shù)據(jù)的采集加工和應(yīng)用

1. 美團(tuán)外賣(mài)流量數(shù)據(jù)采集歷史

先介紹下我們團(tuán)隊(duì)做流量數(shù)據(jù)的歷史演進(jìn)過(guò)程，我們是從2015年開(kāi)始做流量數(shù)據(jù)建設(shè)，早期的需求比較簡(jiǎn)單，主要是分析一些用戶行為的 PV/UV。對(duì)此我們定義了一些code埋點(diǎn)，它是一種客戶端和服務(wù)端聯(lián)合的日志，同時(shí)在客戶端實(shí)現(xiàn)了鏈路追蹤，整體實(shí)現(xiàn)還是比較簡(jiǎn)單的。

2016 年開(kāi)始，我們業(yè)務(wù)整體發(fā)展迅速，需要深入分析用戶行為，所以我們?cè)诜?wù)端定義了一套完整的日志采集規(guī)范，定義了page（頁(yè)面）、block（模塊）、item（元素）、source（來(lái)源）、target（目標(biāo)）等采集內(nèi)容， 并且在數(shù)倉(cāng)層面完成了歸因統(tǒng)計(jì)的數(shù)據(jù)建設(shè)。

到了 2017 年，我們的數(shù)據(jù)采集使用集團(tuán)的流量體系，這套體系是客戶端日志，主要有下述三個(gè)部分：

• 埋點(diǎn)管理：按照業(yè)務(wù)通道隔離，埋點(diǎn)統(tǒng)一注冊(cè)、管理，業(yè)務(wù)字段管理，需求管理等

• 開(kāi)發(fā)者平臺(tái)：主要是面向RD，包括：客戶端&前端 RD 使用的埋點(diǎn) SDK 手冊(cè)，QA 使用的埋點(diǎn)驗(yàn)證工具，數(shù)據(jù) RD 使用的埋點(diǎn)數(shù)據(jù)表、數(shù)據(jù)服務(wù)接口等

• 事件分析工具：主要是一些分析工具提供基本數(shù)據(jù)分析能力，可以支持事件和頁(yè)面的埋點(diǎn)數(shù)據(jù)分析

下面簡(jiǎn)單介紹下埋點(diǎn)在技術(shù)上的分類，一般埋點(diǎn)分為前端埋點(diǎn)和后端埋點(diǎn)兩種。

前端埋點(diǎn)：

將采集的 SDK 集成在終端上，主要有三種：代碼埋點(diǎn)；可視化埋點(diǎn)；無(wú)埋點(diǎn)。美團(tuán)使用的是代碼埋點(diǎn)，它比較明顯的優(yōu)點(diǎn)是：

• 高度定制、控制精準(zhǔn)、采集的數(shù)據(jù)豐富準(zhǔn)確

• 比較方便、靈活，能方便手機(jī)到用戶在界面上的行為數(shù)據(jù)

可視化埋點(diǎn)和無(wú)埋點(diǎn)原理差不多，PM和運(yùn)營(yíng)同學(xué)可以在管理平臺(tái)配置需要的埋點(diǎn)，然后SDK定時(shí)檢測(cè)識(shí)別埋點(diǎn)的的控件，獲取埋點(diǎn)數(shù)據(jù)。相比而言可視化埋點(diǎn)實(shí)施成本很低，但是埋點(diǎn)質(zhì)量上我們覺(jué)得代碼埋點(diǎn)遠(yuǎn)高于可視化埋點(diǎn)，如果場(chǎng)景簡(jiǎn)單或者業(yè)務(wù)處在初期階段，建議使用可視化埋點(diǎn)或者無(wú)埋點(diǎn)這種成本較低的方案；如果業(yè)務(wù)比較復(fù)雜，公司研發(fā)規(guī)模比較大，而且對(duì)數(shù)據(jù)建設(shè)有比較高的要求，代碼埋點(diǎn)是最好的選擇。目前業(yè)界內(nèi)，神策數(shù)據(jù)這幾種方案都支持，GrowingIO主要是支持無(wú)埋點(diǎn)。

后端埋點(diǎn)： 

現(xiàn)在很少單獨(dú)使用，基本是和前端埋點(diǎn)搭配使用。它的優(yōu)點(diǎn)是內(nèi)網(wǎng)傳輸，即時(shí)性強(qiáng)，丟失風(fēng)險(xiǎn)小 。

2. 埋點(diǎn)信息與事件介紹

埋點(diǎn)采集的信息可以分為環(huán)境信息和業(yè)務(wù)信息兩大類。

• 環(huán)境信息：環(huán)境信息包括一些常見(jiàn)的地理、設(shè)備信息，應(yīng)用的信息，還有 SDK、事件生產(chǎn)信息等。

• 業(yè)務(wù)信息：業(yè)務(wù)信息主要是和當(dāng)前用戶行為有直接關(guān)系，比如說(shuō)：操作的模塊中業(yè)務(wù)字段，用戶操作的頁(yè)面的信息，還有喚起的信息等。

埋點(diǎn)事件分類主要分為三大類：

• PV：頁(yè)面事件或者叫做頁(yè)面曝光事件，就是當(dāng)用戶打開(kāi)美團(tuán) APP，每次進(jìn)入一個(gè)頁(yè)面的時(shí)候，就會(huì)立即上報(bào)一條頁(yè)面的 PV 日志，每個(gè)頁(yè)面都有自己的唯一標(biāo)識(shí) page_id

• MC：模塊點(diǎn)擊事件。點(diǎn)擊比較好理解，就是用戶每次點(diǎn)擊都立即上報(bào)一條 MC 日志，每個(gè)模塊都有唯一標(biāo)識(shí)

• MV：模塊曝光事件。曝光指用戶瀏覽某個(gè)模塊，就是用戶看到某模塊就會(huì)上報(bào)一條日志，在 APP 頁(yè)面上，某個(gè)模塊只要顯示（只有一個(gè)像素出現(xiàn)在屏幕上）就會(huì)上報(bào)一條日志，同樣每條 MV 日志都會(huì)記錄模塊的唯一標(biāo)識(shí)

如上圖中左下角是個(gè)實(shí)例：

在 APP 頁(yè)面的頂部，我們用綠色框圈中的部分是一個(gè) banner，上報(bào)這個(gè) banner 日志的時(shí)候會(huì)攜帶 page_id ，和首頁(yè) pv 日志的 page_id 值相同，上報(bào)曝光、點(diǎn)擊日志的時(shí)候都會(huì)有一個(gè)自己的唯一標(biāo)識(shí)。中間是頻道區(qū)，同上面的 banner 一樣上報(bào)時(shí)都會(huì)攜帶 page_id，每次點(diǎn)擊都會(huì)上報(bào)模塊唯一標(biāo)識(shí) click_id，這 15 個(gè)頻道會(huì)分別上報(bào)15條曝光日志，它們的 page_id、view_id 相同，通過(guò)位置字段（從 0 位到 14 位）來(lái)區(qū)分。再下面這個(gè)的 banner 位置日志上報(bào)規(guī)則同頂部 banner 相同。

在這樣的事件分類下，我們把一個(gè)用戶行為按照時(shí)間排序得到圖中右下角所示的序列：用戶首先進(jìn)入一個(gè)頁(yè)面上報(bào)PV日志，會(huì)看到很多模塊上報(bào)MV日志，然后點(diǎn)擊某個(gè)模塊上報(bào)MC日志，接著發(fā)生跳轉(zhuǎn)跳到新的頁(yè)面，然后接著瀏覽、點(diǎn)擊、跳轉(zhuǎn)、瀏覽 ......

從這樣一個(gè)序列中可以看出在整個(gè)上報(bào)日志中，數(shù)據(jù)量最大就是 MV 事件。

3. 埋點(diǎn)規(guī)范與協(xié)作流程

接下來(lái)介紹埋點(diǎn)規(guī)范與協(xié)作流程以及一些問(wèn)題點(diǎn)。埋點(diǎn)這個(gè)事情是一個(gè)多團(tuán)隊(duì)協(xié)作的事情，需要大家一起協(xié)同，所以流程、規(guī)范很重要，不然會(huì)發(fā)生不必要的分歧。

協(xié)作流程：我們的流程是這樣的，先由需求方提出需求交給業(yè)務(wù) PM，業(yè)務(wù) PM 在埋點(diǎn)平臺(tái)做埋點(diǎn)配置，埋點(diǎn)平臺(tái)根據(jù)配置生成代碼給到客戶端 RD，客戶端RD 使用埋點(diǎn) SDK 做埋點(diǎn)實(shí)施，實(shí)施之后由客戶端 QA 來(lái)測(cè)試校驗(yàn)然后上線，接著數(shù)據(jù)組 RD 使用日志數(shù)據(jù)表加工數(shù)據(jù)將數(shù)據(jù)結(jié)果交付給數(shù)據(jù)組 PM，最后將結(jié)果交付給需求方。這里簡(jiǎn)單說(shuō)下埋點(diǎn)配置環(huán)節(jié)，在美團(tuán)外賣(mài)是由業(yè)務(wù) PM 來(lái)統(tǒng)一負(fù)責(zé)，同時(shí)數(shù)據(jù)團(tuán)隊(duì)做規(guī)范的指導(dǎo)、定期參加一些埋點(diǎn)評(píng)審。

埋點(diǎn)規(guī)范：主要是約束一些字段的上報(bào)方法，包括字段名稱、上報(bào)時(shí)機(jī)等。

問(wèn)題排查：在問(wèn)題排查方面，我們有一套比較完整埋點(diǎn)問(wèn)題追蹤流程，也是方便后續(xù)做埋點(diǎn)問(wèn)題的復(fù)盤(pán)。

埋點(diǎn) SLA：我們專門(mén)制定了一套埋點(diǎn) SLA ( Service Level Agreement - 服務(wù)級(jí)別協(xié)議 ) 機(jī)制，目前這塊主要由客戶端 RD 和 QA 來(lái)保證 SLA，業(yè)務(wù) PM 根據(jù)埋點(diǎn)重要性提供需要保證的 SLA 列表，數(shù)據(jù)組提供監(jiān)控工具。

數(shù)據(jù)生產(chǎn)鏈路主要有以下幾個(gè)階段：需求、配置、埋點(diǎn)、驗(yàn)證、上報(bào)、日志表。

流程是：在需求確定之后會(huì)做埋點(diǎn)的配置，客戶端進(jìn)行測(cè)試上線。之后客戶端會(huì)根據(jù)用戶行為將日志上報(bào)（這里分為實(shí)時(shí)上報(bào)和延遲上報(bào)兩種）到 nginx 服務(wù)器，通過(guò) flume 將日志收集傳輸?shù)?kafka 里，然后做實(shí)時(shí)處理，包括數(shù)據(jù)校驗(yàn)、過(guò)濾、字段拆分等比較簡(jiǎn)單的數(shù)據(jù)處理，之后將數(shù)據(jù)落地到離線的 log 表，在離線階段的會(huì)進(jìn)行比較重的數(shù)據(jù)處理操作，比如去重、關(guān)聯(lián)、標(biāo)記等，最后產(chǎn)出公司級(jí)別數(shù)據(jù)表，提供公司各個(gè)業(yè)務(wù)部門(mén)使用。

4. 埋點(diǎn)注意事項(xiàng)

前面介紹了埋點(diǎn)的基本信息與規(guī)范流程，這里給大家介紹一些埋點(diǎn)的注意事項(xiàng)。個(gè)人覺(jué)得做埋點(diǎn)還是非常需要經(jīng)驗(yàn)的，甚至是需要更多的試錯(cuò)，這里給大家列了一些注意事項(xiàng)以供參考：

同質(zhì)參數(shù)的名稱和類型保持一致：主要就是體現(xiàn)在通用參數(shù)、業(yè)務(wù)參數(shù)、行為標(biāo)識(shí)的統(tǒng)一，盡量做到事前治理，給整個(gè)的數(shù)據(jù)加工、數(shù)倉(cāng)建設(shè)減輕工作量，當(dāng)然在數(shù)倉(cāng)加工過(guò)程中也一定要做一些容錯(cuò)；

通用復(fù)用：盡量少的創(chuàng)建新的事件，而是想辦法復(fù)用原來(lái)的事件，方便后續(xù)的埋點(diǎn)管理；比如某彈窗在很多頁(yè)面都出現(xiàn)過(guò)，彈窗模塊曝光標(biāo)識(shí)需要是唯一的，當(dāng)它出現(xiàn)在不同的頁(yè)面的時(shí)候，我們可以通過(guò)頁(yè)面標(biāo)識(shí) page_id 來(lái)區(qū)分，而不是每出現(xiàn)一個(gè)新的頁(yè)面就重新定義一個(gè)模塊標(biāo)識(shí)；

最小粒度：埋點(diǎn)定義到模塊內(nèi)的最小元素，可以避免重復(fù)上報(bào)；

合并上報(bào)：相同模塊的 MV 事件可以合并上報(bào)；某一頁(yè)面中一定出現(xiàn)的元素可以不用上報(bào) ( 這里是指 MV 曝光事件 )，或者和 PV 時(shí)間合并上報(bào)，在 PV 中加一個(gè)字段標(biāo)識(shí)即可；

歷史兼容：不能改變已有事件標(biāo)識(shí)的含義，不能改變屬性標(biāo)識(shí)的含義，不能改變參數(shù)值的含義；一般只做新增，不做修改，可以廢棄；

追蹤回溯：埋點(diǎn)設(shè)計(jì)文檔可以回退到歷史版本，便于排查問(wèn)題。

介紹完了埋點(diǎn)信息，接下來(lái)重點(diǎn)講解流量數(shù)倉(cāng)建設(shè)和歸因建設(shè)，首先介紹流量數(shù)倉(cāng)架構(gòu)。

1. 流量數(shù)倉(cāng)模型架構(gòu)

在整個(gè)流量數(shù)倉(cāng)建設(shè)過(guò)程中還是面對(duì)很多挑戰(zhàn)的，比如：

• 數(shù)據(jù)量大，每天幾百億條的日志，數(shù)倉(cāng)模型要使用成本低、查詢性能較好；

• 采集的客戶端種類多、日志種類多，數(shù)倉(cāng)建模過(guò)程中維度建設(shè)復(fù)雜、數(shù)據(jù)整合復(fù)雜；

• 業(yè)務(wù)系統(tǒng)變更頻繁，特別是資源位、廣告位變更頻繁，數(shù)倉(cāng)模型要及時(shí)響應(yīng)、運(yùn)維成本低；

• 多變的歸因統(tǒng)計(jì)需求 ( 目標(biāo)行為和來(lái)源行為都不固定 )，需要?dú)w因模型使用成本低且易用性高。

整個(gè)流量數(shù)倉(cāng)架構(gòu)如圖中所示，與之前惠明老師介紹的《美團(tuán)外賣(mài)離線數(shù)倉(cāng)建設(shè)實(shí)踐》基本相同，具體細(xì)節(jié)可參考原文，這里稍微講下：

ODL：Operational Data Layer，操作型數(shù)據(jù)層，這一層主要對(duì)采集到的數(shù)據(jù)進(jìn)行無(wú)損著陸、基礎(chǔ)字段清洗加工。ODL是原始日志明細(xì)寬表，完成了日志數(shù)據(jù)清洗過(guò)濾、歸因建設(shè)、公共維度建設(shè)等。全鏈路歸因建設(shè)在這一層實(shí)現(xiàn)。公共維度建設(shè)比如地理位置維度生成、常用維度代理鍵生成等，下沉到ODL來(lái)進(jìn)行，降低了運(yùn)維和下游使用成本，需要依賴于DIM層的環(huán)境維度表。

IDL：Integrated Data Layer，集成數(shù)據(jù)層，這一層在ODL之上，主要完成領(lǐng)域數(shù)據(jù)建模，描述業(yè)務(wù)對(duì)象屬性、業(yè)務(wù)對(duì)象間的關(guān)系、業(yè)務(wù)行為屬性、業(yè)務(wù)行為與業(yè)務(wù)對(duì)象的關(guān)系等。IDL層是明細(xì)寬表層，根據(jù)數(shù)據(jù)域和業(yè)務(wù)過(guò)程進(jìn)行主題劃分，在主題內(nèi)描述業(yè)務(wù)對(duì)象和業(yè)務(wù)行為，特別是對(duì)主題內(nèi)常用的擴(kuò)展維度字段進(jìn)行提取，并且進(jìn)一步使用維度退化手段，提高明細(xì)寬表的易用性、降低使用成本。例如搜索主題篩選了用戶搜索行為相關(guān)的日志，并將描述搜索業(yè)務(wù)的擴(kuò)展字段進(jìn)行提取。

CDL：Component Data Layer，元件數(shù)據(jù)層，這一層在IDL之上，主要完成分析實(shí)體識(shí)別，在主題劃分基礎(chǔ)上，形成分析實(shí)體/實(shí)體關(guān)系特征模型，對(duì)模型的指標(biāo)進(jìn)行加工，分為明細(xì)數(shù)據(jù)視圖和聚合數(shù)據(jù)表兩類。

MDL：Mart Data Layer，集市數(shù)據(jù)層，這一層在CDL之上，建立在主題劃分基礎(chǔ)上，通過(guò)維度層級(jí)匯總形成匯總表，通過(guò)維度主鍵關(guān)聯(lián)形成寬表，給數(shù)據(jù)應(yīng)用提供便利應(yīng)用的半成品數(shù)據(jù)集，例如，常見(jiàn)的商家流量寬表（商家的點(diǎn)擊、曝光、進(jìn)店統(tǒng)計(jì)）。

ADL：App Data Layer，應(yīng)用數(shù)據(jù)層，不屬于OneData內(nèi)統(tǒng)一建設(shè)，這一層在MDL之上，直接面對(duì)數(shù)據(jù)應(yīng)用，優(yōu)先使用MDL的數(shù)據(jù)，當(dāng)MDL不滿足時(shí)，可以向下使用CDL、IDL的數(shù)據(jù)。ADL作為數(shù)據(jù)應(yīng)用的個(gè)性化數(shù)據(jù)一般不對(duì)外提供數(shù)據(jù)服務(wù)。

DIM：公共維度層，包括了流量數(shù)倉(cāng)建設(shè)過(guò)程中使用的流量維表，分成主題維度表和環(huán)境維度表。其中主題維度表將埋點(diǎn)標(biāo)識(shí)（用戶行為標(biāo)識(shí)）映射成主題維度，是IDL、CDL進(jìn)行主題劃分的核心維度表。環(huán)境維度表包括了流量靜態(tài)屬性中常見(jiàn)的維度，例如app名稱、啟動(dòng)渠道、設(shè)備類型等，主要應(yīng)用于ODL層的公共維度建設(shè)。

2. 流量數(shù)倉(cāng)建設(shè)原則

在數(shù)倉(cāng)建設(shè)中有很多原則，這里拿出其中三個(gè)在流量數(shù)倉(cāng)中比較重要的原則跟大家分享下：

① 高內(nèi)聚和低耦合

將業(yè)務(wù)相近或相關(guān)、粒度相同、高概率同時(shí)訪問(wèn)的數(shù)據(jù)放在一起。具體在流量數(shù)倉(cāng)建設(shè)過(guò)程中，合理的主題劃分其實(shí)就是遵循高內(nèi)聚低耦合的原則。不合理的主題劃分會(huì)導(dǎo)致數(shù)據(jù)使用成本、運(yùn)維成本增大。主題劃分是和業(yè)務(wù)強(qiáng)相關(guān)的事情，需要大家定期 review 自己的主題劃分是否合理，一定要緊跟業(yè)務(wù)需求。

② 公共處理邏輯下沉且單一

越是底層公用的處理邏輯，越要放在數(shù)據(jù)底層封裝與實(shí)現(xiàn)，不要讓公共邏輯多處存在且暴露給上層的表。流量底層數(shù)據(jù)的公共處理邏輯主要是環(huán)境維度建設(shè)和歸因建設(shè)。

③ 成本與性能平衡

適當(dāng)?shù)倪M(jìn)行數(shù)據(jù)冗余來(lái)?yè)Q取查詢和刷新性能，但不要過(guò)度冗余與數(shù)據(jù)復(fù)制。這是最通俗易懂的原則，但在流量數(shù)倉(cāng)建設(shè)過(guò)程中，需要綜合考慮各種使用場(chǎng)景，實(shí)踐起來(lái)很難。美團(tuán)外賣(mài)每天的數(shù)據(jù)量幾百億條，這樣一份數(shù)據(jù)，如果在多處出現(xiàn)復(fù)制，對(duì)存儲(chǔ)資源就是很大的浪費(fèi)。成本與性能平衡確實(shí)需要多思考，在做數(shù)倉(cāng)規(guī)劃時(shí)就需要把這個(gè)事情考慮到。具體實(shí)踐如下：

• 僅在IDL層保留了明細(xì)的日志數(shù)據(jù)，且通過(guò)維度退化手段提高明細(xì)寬表表的易用性、降低使用成本。

• IDL層的主題劃分過(guò)程，如果B主題是A主題的子集，兩個(gè)主題的區(qū)別在于業(yè)務(wù)描述（業(yè)務(wù)擴(kuò)展維度字段）不同，那么A主題使用表來(lái)存儲(chǔ)邏輯和數(shù)據(jù)，B主題在A主題表之上使用視圖的方式存儲(chǔ)數(shù)據(jù)加工邏輯。舉例來(lái)說(shuō)，在美團(tuán)外賣(mài)app首頁(yè)存在著很多資源位，資源位中有有一部分是營(yíng)銷活動(dòng)的位置，那么營(yíng)銷活動(dòng)主題就是B主題，美團(tuán)外賣(mài)app首頁(yè)資源位主題就是A主題。

• 在CDL層對(duì)明細(xì)數(shù)據(jù)也使用了視圖，不再占用物理存儲(chǔ)。

3. 維度建設(shè)

為什么常說(shuō)流量數(shù)據(jù)在做數(shù)倉(cāng)建設(shè)時(shí)比業(yè)務(wù)數(shù)據(jù)困難，個(gè)人覺(jué)得是因?yàn)榱髁繑?shù)據(jù)的數(shù)據(jù)源本身是一些半結(jié)構(gòu)化的數(shù)據(jù)，沒(méi)有分析維度的概念，所以在數(shù)倉(cāng)的建設(shè)時(shí)我們要做很多的維度建設(shè)工作。因此維度建設(shè)是整個(gè)流量數(shù)倉(cāng)工作中最核心工作，同時(shí)也是最大的難點(diǎn)。

我們維度建設(shè)分為兩種，環(huán)境維度和主題維度。

環(huán)境維度：

環(huán)境維度是指用戶行為所處的環(huán)境描述，例如用戶的定位城市、用戶的設(shè)備類型、用戶使用的app名稱等，這些維度是在主題劃分基礎(chǔ)上，分析實(shí)體維度模型中最主要的維度，即用戶在選定業(yè)務(wù)過(guò)程后最主要的分析視角。環(huán)境維度建設(shè)主要遵守公共處理邏輯下沉且單一這個(gè)原則，在ODL完成建設(shè)。環(huán)境維度建設(shè)過(guò)程中，如果分析的維度在日志中已經(jīng)存在明確字段，且該字段具有業(yè)務(wù)含義并是自然主鍵，那么就會(huì)直接使用這個(gè)自然鍵和相對(duì)應(yīng)的維度屬性表。如果分析的維度需要日志中的多個(gè)字段聯(lián)合，這時(shí)我們會(huì)對(duì)這多個(gè)字段生成一個(gè)代理鍵，并構(gòu)建以這個(gè)代理鍵為主鍵的維度屬性表。

舉例來(lái)說(shuō)，終端維度需要由日志中的操作系統(tǒng)類型、app名稱、啟動(dòng)渠道這三個(gè)字段聯(lián)合生成。如下表所示，我們使用這三個(gè)字段生成了一個(gè)代理鍵終端id。特別說(shuō)明的是，終端id的映射維表并不是簡(jiǎn)單的可以通過(guò)操作系統(tǒng)、app名稱、啟動(dòng)渠道這三個(gè)字段關(guān)聯(lián)得到。比如，終端id = 3的這一行，操作系統(tǒng)字段可以為任意值（對(duì)上報(bào)日志不做要求）。這就要求我們?cè)谏纱礞I的時(shí)候需要采取一種更加靈活的方式，以應(yīng)對(duì)上游數(shù)據(jù)的不確定性沖擊。所以我們使用了UDF來(lái)實(shí)現(xiàn)：

UDF ( 操作系統(tǒng)，app名稱，啟動(dòng)渠道 ) = 終端id

• UDF中可以適配各種靈活多變的映射邏輯，這樣大大提高了我們的靈活性，降低了運(yùn)維成本。

• 代理鍵生成之后，我們構(gòu)建了終端id為主鍵的維度屬性表。

主題維度：

原始日志在采集上來(lái)之后，是不具備業(yè)務(wù)過(guò)程分類的，僅僅能通過(guò)埋點(diǎn)標(biāo)識(shí)來(lái)做區(qū)分。所以我們需要對(duì)日志進(jìn)行主題劃分，也就是業(yè)務(wù)過(guò)程劃分。舉例來(lái)說(shuō)，我們想知道一個(gè)用戶在外賣(mài)搜索頁(yè)的全部行為，我們就需要先找到外賣(mài)搜索頁(yè)的全部埋點(diǎn)標(biāo)識(shí)，然后從原始日志中過(guò)濾出來(lái)。主題劃分就是，將原始日志進(jìn)行按照埋點(diǎn)標(biāo)識(shí)劃分到不同的主題表中。

我們將外賣(mài)整體的業(yè)務(wù)過(guò)程按照實(shí)體加行為進(jìn)行抽象。外賣(mài)業(yè)務(wù)中，常見(jiàn)的實(shí)體包括用戶、商家、菜品、訂單。實(shí)體和實(shí)體之間通過(guò)行為來(lái)連接。比如，用戶和商家之間的行為可以有搜索、使用智能助手、使用購(gòu)物車(chē)、點(diǎn)擊商家資源位等。

我們將這個(gè)埋點(diǎn)標(biāo)識(shí)與主題表中的業(yè)務(wù)標(biāo)識(shí)構(gòu)建成主題維度表，用于管理埋點(diǎn)標(biāo)識(shí)與業(yè)務(wù)標(biāo)識(shí)的關(guān)系。在主題維表中，業(yè)務(wù)標(biāo)識(shí)使用代理鍵，并在IDL中通過(guò)主題維表關(guān)聯(lián)出代理鍵。主題劃分過(guò)程中，我們還需要將主題內(nèi)常用的擴(kuò)展維度字段進(jìn)行提取，對(duì)于不同的埋點(diǎn)提取這些字段的方式不太一樣，我們也將埋點(diǎn)標(biāo)識(shí)與主題擴(kuò)展維度提取方式的對(duì)應(yīng)關(guān)系維護(hù)在主題維度表中。

以資源位主題為例講解一下建設(shè)的過(guò)程：

業(yè)務(wù)過(guò)程描述：在做主題建設(shè)時(shí)我們首先要確定業(yè)務(wù)過(guò)程，這里的業(yè)務(wù)過(guò)程就是從外賣(mài)的資源位點(diǎn)擊開(kāi)始，用戶在點(diǎn)擊之后會(huì)進(jìn)入商家頁(yè)，然后進(jìn)入提單頁(yè)提交訂單，最后下單。

業(yè)務(wù)過(guò)程提?。?/span>描述清楚業(yè)務(wù)過(guò)程之后，要對(duì)業(yè)務(wù)過(guò)程進(jìn)行提取，即從 ODL 日志中找出所有瀏覽和點(diǎn)擊的日志，具體做法是：

• 首先維護(hù)一張資源位主題維度表，表中記錄下埋點(diǎn)與資源位的對(duì)應(yīng)關(guān)系

• 然后通過(guò) ODL 日志表與資源位主題維度表關(guān)聯(lián)即可獲得資源位埋點(diǎn)的瀏覽、點(diǎn)擊明細(xì)日志。

• 同時(shí)我們?cè)诿枋鲑Y源位這個(gè)業(yè)務(wù)活動(dòng)的時(shí)候需要看資源位位置，這個(gè)位置就是描述用戶點(diǎn)擊的商家在商家列表的第幾位，資源位位置在各個(gè)埋點(diǎn)里上報(bào)的值可能不一樣，所以需要在資源位主題維度表里記錄埋點(diǎn)標(biāo)識(shí)，記錄好之后在加工 IDL 表時(shí)就可以根據(jù)埋點(diǎn)標(biāo)識(shí)將資源位位置加工出來(lái)。

• 同理進(jìn)入商家頁(yè)、進(jìn)入提交訂單頁(yè)還有提交訂單的業(yè)務(wù)過(guò)程提取也是一樣的，先找出他們的日志，再根據(jù)維表信息關(guān)聯(lián)加工出 IDL 表，只不過(guò)這里的關(guān)聯(lián)字段使用的鏈路信息字段

維度管理：

在維度建設(shè)這邊，最后再聊下維度管理的事情，從剛才的內(nèi)容大家應(yīng)該也可以感受到，在流量數(shù)倉(cāng)中維度建設(shè)是最核心的內(nèi)容，它決定流量數(shù)倉(cāng)的分析視角以及流量數(shù)倉(cāng)的運(yùn)維成本，在做流量數(shù)倉(cāng)建設(shè)時(shí)建議認(rèn)真做下維度管理。

我們是專門(mén)做了一個(gè)工具來(lái)做維度管理。所有維度信息在管理平臺(tái)統(tǒng)一錄入、校驗(yàn)、更新，最后同步到數(shù)倉(cāng)的 DIM 層，給數(shù)倉(cāng)的生產(chǎn)使用。這樣降低了數(shù)倉(cāng)的運(yùn)維成本。

4. 歸因建設(shè)

歸因需求介紹：

前面內(nèi)容我們講了數(shù)倉(cāng)整體架構(gòu)以及維度建設(shè)方面內(nèi)容細(xì)節(jié)，接下來(lái)我們介紹流量數(shù)據(jù)最核心的、也是大家會(huì)經(jīng)常遇到的歸因建設(shè)。在流量數(shù)據(jù)分析場(chǎng)景中，有一類需求是基于單一埋點(diǎn)或埋點(diǎn)集合的且不需要進(jìn)行日志關(guān)聯(lián)的分析，比如某種用戶行為的人數(shù)、次數(shù)等；另一類需求是需要將日志進(jìn)行關(guān)聯(lián)并且對(duì)日志的先后順序有要求的分析，比如常見(jiàn)的統(tǒng)計(jì)經(jīng)過(guò)外賣(mài)首頁(yè)商家列表點(diǎn)擊后的成單行為人數(shù)、次數(shù)。第二類需求其實(shí)就是我們說(shuō)的流量數(shù)據(jù)歸因。

流量數(shù)據(jù)歸因建設(shè)在外賣(mài)業(yè)務(wù)場(chǎng)景下是非常難的，難點(diǎn)有二：數(shù)據(jù)量大，在幾百億條的日志中，將需要的日志進(jìn)行關(guān)聯(lián)是非常耗時(shí)、耗資源的；需求不固定，通常我們無(wú)法預(yù)知需求方想將哪些日志做歸因分析。

因此，流量數(shù)據(jù)歸因建設(shè)要重點(diǎn)解決這兩個(gè)難點(diǎn)問(wèn)題，特別是難點(diǎn)二，由于需求的不固定，我們要實(shí)現(xiàn)全鏈路的歸因建設(shè)，而不是只針對(duì)某些行為的日志做歸因建設(shè)。

首先，我們要將需求簡(jiǎn)化并且標(biāo)準(zhǔn)化，我們將所有的歸因統(tǒng)計(jì)抽象成如下問(wèn)題描述：

統(tǒng)計(jì)經(jīng)過(guò)A行為的B行為的次 ( 人 ) 數(shù)

應(yīng)對(duì)這樣的問(wèn)題，給出的偽SQL：

select count(1) from 日志 where 行為 = B and 鏈路信息 包含 A

經(jīng)過(guò)這樣抽象后，我們發(fā)現(xiàn)問(wèn)題變得清晰一些，這個(gè)偽SQL就是所有歸因分析場(chǎng)景的標(biāo)準(zhǔn)化查詢。問(wèn)題聚焦在"鏈路信息"的建設(shè)。我們要為每一個(gè)用戶行為建立一個(gè)鏈路信息字段。

什么是鏈路信息呢？在外賣(mài)業(yè)務(wù)場(chǎng)景下，鏈路信息是：某一行為的時(shí)間前序行為集合，集合中不包含相同頁(yè)面之間的行為。

鏈路信息建設(shè)：

在目標(biāo)表中，為每一行數(shù)據(jù)新增一列鏈路信息，使用數(shù)組格式來(lái)存儲(chǔ)當(dāng)前行的行為的鏈路信息。數(shù)組中每一個(gè)元素即代表一個(gè)時(shí)間前序行為（排除了MV事件），其中包含的字段會(huì)選取一些業(yè)務(wù)獨(dú)特的、與當(dāng)前行為不同的字段（不包括通用環(huán)境字段），這是由于一個(gè)行為的時(shí)間前序行為中，通用環(huán)境字段一般是相同的（比如設(shè)備號(hào)、操作系統(tǒng)等），且通用環(huán)境字段已經(jīng)作為了分組排序的條件。這樣設(shè)計(jì)表結(jié)構(gòu)的好處是：目標(biāo)表的行數(shù)沒(méi)有變多；對(duì)所有的用戶點(diǎn)擊行為和用戶進(jìn)入某一頁(yè)面行為加工了鏈路信息字段。

可能會(huì)有同學(xué)質(zhì)疑這個(gè)字段會(huì)不會(huì)特別長(zhǎng)，特別是當(dāng)用戶行為鏈路特別長(zhǎng)的時(shí)候，后面的行為日志這個(gè)字段值會(huì)很長(zhǎng)。這種場(chǎng)景下我們就需要考慮到底哪些行為應(yīng)該放在這個(gè)字段里，這里我們使用因果關(guān)系來(lái)判斷哪個(gè)行為是這行日志的原因行為。

我們將因果關(guān)系定義為為與相同頁(yè)面之間的事情無(wú)關(guān)。如上圖中事件序列記錄某用戶從 P1 點(diǎn)擊進(jìn)入 P2 再點(diǎn)擊進(jìn)入 P3，然后又回到 P2 接著回到了 P1 又點(diǎn)擊了其它模塊。在這段用戶行為中 P3 的鏈路信息如圖中所示彩色部分只包含第一次到達(dá) P3 時(shí)經(jīng)過(guò)的路徑；M5 模塊的鏈路信息如圖中彩色模塊所示，我們認(rèn)為圖中所示的兩個(gè) P2 之間的鏈路與 M5 鏈路信息無(wú)關(guān)；M7 的鏈路信息同理。

這樣我們屏蔽掉用戶操作過(guò)程中的回退操作，最終記錄的鏈路信息字段值不會(huì)很大，當(dāng)然這種因果關(guān)系一定要契合業(yè)務(wù)情況。

定義好鏈路信息和目標(biāo)表結(jié)構(gòu)之后，我們進(jìn)行數(shù)據(jù)加工，鏈路信息字段使用udf（自定義函數(shù)）來(lái)加工得到，偽SQL代碼如下：

insert into target table select log表中的字段，udf(歸因處理輸入字段) as 原因行為 from 分組排序后的log表

歸因處理輸入字段選取了部分通用環(huán)境字段和業(yè)務(wù)字段，通用環(huán)境字段用來(lái)判斷當(dāng)前行數(shù)據(jù)中的環(huán)境參數(shù)是否發(fā)生變化（例如是否換了一個(gè)設(shè)備），業(yè)務(wù)字段主要用于udf的輸出結(jié)果。具體數(shù)據(jù)處理流程如下：

1. 對(duì)日志進(jìn)行分組排序，使用distribute by按照通用環(huán)境字段進(jìn)行分組，使用sort by按照時(shí)間戳順序排序，這樣保證了相同分組的數(shù)據(jù)分配到同一個(gè)reducer當(dāng)中進(jìn)行處理，并且是按照時(shí)間戳排序之后進(jìn)行有序處理；

2. 在日志分組排序之后，進(jìn)行鏈路信息字段加工，使用hive udf來(lái)實(shí)現(xiàn)。在udf中，通過(guò)棧來(lái)存儲(chǔ)鏈路信息，一次udf執(zhí)行過(guò)程簡(jiǎn)述如下圖所示：udf輸入?yún)?shù)的通用環(huán)境字段用來(lái)判斷是否更換了設(shè)備或app，如果通用參數(shù)發(fā)生變化，說(shuō)明上一個(gè)分組內(nèi)的數(shù)據(jù)全部處理完，清空棧內(nèi)的數(shù)據(jù)，把當(dāng)前行為入棧。如果通用參數(shù)沒(méi)有發(fā)生變化，說(shuō)明仍然在處理相同組內(nèi)的數(shù)據(jù)。需要判斷當(dāng)前行為的加入是否發(fā)生頁(yè)面回退，如果發(fā)生頁(yè)面回退，則需按將相同頁(yè)面之間的行為出棧，最終將當(dāng)前行為入棧。

3. 結(jié)果數(shù)據(jù)輸出過(guò)程中，會(huì)首先進(jìn)行行為標(biāo)記，比如將每個(gè)頁(yè)面的最后一次點(diǎn)擊行為進(jìn)行特殊標(biāo)記，然后再將棧中所有的元素放入數(shù)組中，作為最終的鏈路信息字段。

鏈路信息字段加工之后，我們要使用這個(gè)字段來(lái)解決流量歸因統(tǒng)計(jì)需求。我們回過(guò)頭來(lái)看一下之前提到的流量數(shù)據(jù)歸因建設(shè)兩個(gè)難點(diǎn)。其實(shí)，把問(wèn)題標(biāo)準(zhǔn)化成統(tǒng)計(jì)經(jīng)過(guò)A行為的B行為的次（人）數(shù)，并且加工出鏈路信息字段，就已經(jīng)解決了上述的兩個(gè)難點(diǎn)問(wèn)題：鏈路信息字段是經(jīng)過(guò)分組排序加工出來(lái)的，等同于提前做好了日志關(guān)聯(lián)；對(duì)所有的用戶點(diǎn)擊行為和用戶進(jìn)入某一頁(yè)面行為都加工了鏈路信息字段，實(shí)現(xiàn)了全鏈路歸因。鏈路信息字段加工過(guò)程是與業(yè)務(wù)需求解耦的，即不根據(jù)業(yè)務(wù)需求定制化開(kāi)發(fā)，這就使得我們的方案具有很強(qiáng)的靈活性和拓展性。在IDL層可以根據(jù)主題的需要取出任何主題所需要的歸因數(shù)據(jù)。

其中，鏈路信息包含某行為需要通過(guò)udf來(lái)實(shí)現(xiàn)，因此我們開(kāi)發(fā)了一系列的udf、udtf來(lái)使用鏈路信息字段。

前面介紹了在歸因建設(shè)中我們使用的鏈路信息追加的方案，可能在業(yè)界其他團(tuán)隊(duì)使用的是其它的方案，比如掛單，這里給出不同方案的簡(jiǎn)單對(duì)比：

• 鏈路信息追加：典型空間換時(shí)間的方案，特點(diǎn)是存儲(chǔ)冗余，同時(shí)需要寫(xiě)UDF實(shí)現(xiàn)，有一定使用成本，但是它比較靈活，可以支持任意的原因行為、目標(biāo)行為分析

• 指定目標(biāo)事件歸因：這種方案是針對(duì)固定場(chǎng)景的，適合在需求比較固定的業(yè)務(wù)場(chǎng)景。比如在當(dāng)前階段，我們只對(duì)訂單這個(gè)事件做歸因分析，那就可以在每條日志后面加一個(gè)字段記錄訂單id。相對(duì)鏈路信息追加這種方案的特點(diǎn)是存儲(chǔ)不冗余、使用成本低，適用于需求固定的場(chǎng)景

仔細(xì)對(duì)比我們會(huì)發(fā)現(xiàn)這兩種方案是對(duì)稱的，鏈路信息追加存儲(chǔ)的是當(dāng)前行為之前發(fā)生的行為，掛單存儲(chǔ)的是當(dāng)前行為之后發(fā)生的行為。

勾稽關(guān)系：

接下來(lái)介紹一個(gè)流量數(shù)據(jù)校驗(yàn)方案，勾稽關(guān)系校驗(yàn)。勾稽關(guān)系在流量數(shù)據(jù)加工過(guò)程中可以很方便的做監(jiān)控、校驗(yàn)。比如一個(gè)簡(jiǎn)單場(chǎng)景就是落地頁(yè)流量要等于來(lái)源流量，搜索點(diǎn)擊的人數(shù)一定是跟搜索頁(yè)面瀏覽人數(shù)相差不大的。這里將勾稽關(guān)系單獨(dú)列出，也是希望大家在做流量數(shù)倉(cāng)過(guò)程中可以靈活使用它。

5. 埋點(diǎn)治理

介紹完數(shù)據(jù)加工內(nèi)容之后，我們講解下數(shù)據(jù)治理方案，整個(gè)的數(shù)據(jù)治理或者數(shù)據(jù)資產(chǎn)管理包含很多工作，細(xì)節(jié)可以參考《美團(tuán)外賣(mài)離線數(shù)倉(cāng)建設(shè)實(shí)踐》，這里簡(jiǎn)單介紹下埋點(diǎn)治理方案。埋點(diǎn)數(shù)據(jù)的特點(diǎn)是數(shù)據(jù)量級(jí)很大，因此在做埋點(diǎn)治理時(shí)一定要做 ROI 評(píng)估，目前的辦法就是做血緣追溯，追溯埋點(diǎn)在ETL任務(wù)中的使用情況。

我們將埋點(diǎn)使用情況分成了三類：

• 在數(shù)倉(cāng)內(nèi)建設(shè)的表，IDL層的表會(huì)屬于唯一一個(gè)主題，且該表內(nèi)使用的埋點(diǎn)就是主題維表中的所有埋點(diǎn)；CDL層會(huì)依賴于IDL層的一個(gè)或多個(gè)主題表，可以通過(guò)CDL中主題維度代理鍵使用情況標(biāo)記出該表使用的所有埋點(diǎn)；MDL層如果依賴于IDL、CDL、MDL的主題表，同樣可以通過(guò)主題維度代理鍵使用情況來(lái)標(biāo)記；

• ADL層的表比較靈活，如果直接依賴于IDL層的明細(xì)數(shù)據(jù)表和主題維表，可以通過(guò)主題維表的使用情況來(lái)標(biāo)記使用的埋點(diǎn)；

• ADL層的數(shù)據(jù)直接依賴于IDL明細(xì)數(shù)據(jù)，并且直接使用了埋點(diǎn)唯一標(biāo)識(shí)，那就可以直接標(biāo)記出所用的埋點(diǎn)了。

將全部使用流量數(shù)據(jù)的ETL任務(wù)標(biāo)記完之后，我們就可以給每個(gè)埋點(diǎn)進(jìn)行評(píng)分，分?jǐn)?shù)較低的埋點(diǎn)會(huì)進(jìn)行有計(jì)劃的刪減和治理，對(duì)于分?jǐn)?shù)較高的埋點(diǎn)會(huì)進(jìn)行更好的監(jiān)控及跟蹤。

最后簡(jiǎn)單說(shuō)下外賣(mài)流量數(shù)據(jù)的應(yīng)用，目前主要有三類：

• OLAP 分析：事件分析、頁(yè)面分析、資源位分析、AB 實(shí)驗(yàn)分析

• 用戶行為分析：漏斗分析、路徑分析、留存分析、用戶細(xì)查、用戶分群分析；目前主要使用的技術(shù)是 Doris

• 標(biāo)簽數(shù)據(jù)層：流量數(shù)據(jù)很大部分場(chǎng)景都是在標(biāo)簽應(yīng)用，比如：算法策略、營(yíng)銷都會(huì)用到標(biāo)簽

在 OLAP 引擎方面，大家都很了解，不做過(guò)多介紹，美團(tuán)外賣(mài)對(duì)Doris、Kylin、Druid 都有使用，對(duì)幾種 OLAP 引擎對(duì)比以及在美團(tuán)外賣(mài)的使用場(chǎng)景如下圖所示：

經(jīng)過(guò)幾年的建設(shè)實(shí)踐，美團(tuán)外賣(mài)流量數(shù)據(jù)倉(cāng)庫(kù)已經(jīng)提供了完善、準(zhǔn)確的離線數(shù)據(jù)服務(wù)，未來(lái)我們將更加關(guān)注實(shí)時(shí)流量數(shù)倉(cāng)的建設(shè)，特別是實(shí)時(shí)數(shù)據(jù)全鏈路歸因建設(shè)依然面臨著一些挑戰(zhàn)。

• 在數(shù)據(jù)治理方面，我們將持續(xù)完善數(shù)據(jù)監(jiān)控、完善埋點(diǎn)血緣檢測(cè)，并將預(yù)測(cè)算法、根因分析等應(yīng)用于數(shù)據(jù)監(jiān)控和問(wèn)題分析，進(jìn)一步的降低運(yùn)維成本

• 在數(shù)據(jù)產(chǎn)品方面，我們將繼續(xù)打造一站式分析平臺(tái)，讓用戶更加自助、靈活、即時(shí)的進(jìn)行行為數(shù)據(jù)分析