美團外賣流量數(shù)倉建設(shè)和分析應(yīng)用

點擊上方“數(shù)據(jù)管道”，選擇“置頂星標(biāo)”公眾號

干貨福利，第一時間送達

1. 美團外賣流量數(shù)據(jù)采集歷史

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

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

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

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

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

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

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

前端埋點：

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

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

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

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

后端埋點：?

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

2. 埋點信息與事件介紹

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

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

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

埋點事件分類主要分為三大類：

• PV：頁面事件或者叫做頁面曝光事件，就是當(dāng)用戶打開美團 APP，每次進入一個頁面的時候，就會立即上報一條頁面的 PV 日志，每個頁面都有自己的唯一標(biāo)識 page_id

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

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

如上圖中左下角是個實例：

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

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

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

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

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

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

埋點規(guī)范：主要是約束一些字段的上報方法，包括字段名稱、上報時機等。

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

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

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

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

4. 埋點注意事項

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

③ 成本與性能平衡

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

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

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

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

3. 維度建設(shè)

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

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

環(huán)境維度：

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

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

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

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

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

主題維度：

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

我們將外賣整體的業(yè)務(wù)過程按照實體加行為進行抽象。外賣業(yè)務(wù)中，常見的實體包括用戶、商家、菜品、訂單。實體和實體之間通過行為來連接。比如，用戶和商家之間的行為可以有搜索、使用智能助手、使用購物車、點擊商家資源位等。

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

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

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

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

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

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

• 同時我們在描述資源位這個業(yè)務(wù)活動的時候需要看資源位位置，這個位置就是描述用戶點擊的商家在商家列表的第幾位，資源位位置在各個埋點里上報的值可能不一樣，所以需要在資源位主題維度表里記錄埋點標(biāo)識，記錄好之后在加工 IDL 表時就可以根據(jù)埋點標(biāo)識將資源位位置加工出來。

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

維度管理：

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

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

4. 歸因建設(shè)

歸因需求介紹：

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

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

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

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

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

應(yīng)對這樣的問題，給出的偽SQL：

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

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

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

鏈路信息建設(shè)：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

勾稽關(guān)系：

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

5. 埋點治理

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

我們將埋點使用情況分成了三類：

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

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

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

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

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

• OLAP 分析：事件分析、頁面分析、資源位分析、AB 實驗分析

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

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

在 OLAP 引擎方面，大家都很了解，不做過多介紹，美團外賣對Doris、Kylin、Druid 都有使用，對幾種 OLAP 引擎對比以及在美團外賣的使用場景如下圖所示：

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

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

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

今天的分享就到這里，謝謝大家。

馬驤

美團外賣 |?技術(shù)專家