01
流量數據采集
1.美團外賣流量數據采集歷史
先介紹下我們團隊做流量數據的歷史演變過程，我們是從2015年開始做流量數據建設，初期的需求比較簡單，主要是剖析一些用戶行為的PV/UV。對此我們定義了一些code埋點，它是一種顧客端和服務端聯合的日志，同時在顧客端實現了鏈路追蹤，整體實現還是比較簡單的。
2016年開始，我們業務整體發展迅速，須要深入剖析用戶行為，所以我們在服務端定義了一套完整的日志采集規范，定義了page（頁面）、block（模塊）、item（元素）、（來源）、（目標）等采集內容，但是在數倉層面完成了歸因統計的數據建設。
到了2017年，我們的數據采集使用集團的流量體系，這套體系是顧客端日志，主要有下列三個部份：
下邊簡單介紹下埋點在技術上的分類，通常埋點分為后端埋點和前端埋點兩種。
后端埋點：
將采集的SDK集成在終端上，主要有三種：代碼埋點；可視化埋點；無埋點。美團使用的是代碼埋點，它比較顯著的優點是：
可視化埋點和無埋點原理差不多，PM和營運朋友可以在管理平臺配置須要的埋點，之后SDK定時檢查辨識埋點的的控件，獲取埋點數據。相比而言可視化埋點施行成本很低，而且埋點質量上我們認為代碼埋點遠低于可視化埋點，假如場景簡單或則業務處在早期階段，建議使用可視化埋點或則無埋點這些成本較低的方案；假如業務比較復雜，公司研制規模比較大，但是對數據建設有比較高的要求，代碼埋點是最好的選擇。目前業界內，神策數據這幾種方案都支持，主要是支持無埋點。
前端埋點：
如今極少單獨使用，基本是和后端埋點搭配使用。它的優點是外網傳輸，即時性強，遺失風險小。
2.埋點信息與風波介紹
埋點采集的信息可以分為環境信息和業務信息兩大類。
埋點風波分類主要分為三大類：
如上圖中左下角是個實例：
在APP頁面的底部，我們用紅色框圈中的部份是一個，上報這個日志的時侯會攜帶，和首頁pv日志的值相同，上報爆光、點擊日志的時侯就會有一個自己的惟一標示。中間是頻道區，同前面的一樣上報時就會攜帶，每次點擊就會上報模塊惟一標示，這15個頻道會分別上報15條爆光日志，它們的、相同，通過位置數組（從0位到14位）來分辨。再下邊這個的位置日志上報規則同底部相同。
在這樣的風波分類下，我們把一個用戶行為依照時間排序得到圖中右下角所示的序列：用戶首先步入一個頁面上報PV日志，會看見好多模塊上報MV日志，之后點擊某個模塊上報MC日志，接著發生跳轉跳到新的頁面，之后接著瀏覽、點擊、跳轉、瀏覽......
從這樣一個序列中可以看出在整個上報日志中，數據量最大就是MV風波。
3.埋點規范與協作流程
接出來介紹埋點規范與協作流程以及一些問題點。埋點這個事情是一個多團隊協作的事情，須要你們一起協同，所以流程、規范很重要，不然會發生何必要的分歧。
協作流程：我們的流程是這樣的，先由需求方提出需求交給業務PM，業務PM在埋點平臺做埋點配置，埋點平臺依照配置生成代碼給到顧客端RD，顧客端RD使用埋點SDK做埋點施行，施行以后由顧客端QA來測試校準之后上線，接著數據組RD使用日志數據表加工數據將數據結果交付給數據組PM，最后將結果交付給需求方。這兒簡單說下埋點配置環節，在美團外賣是由業務PM來統一負責，同時數據團隊做規范的指導、定期出席一些埋點評審。
埋點規范：主要是約束一些數組的上報方式，包括數組名稱、上報時機等。
問題排查：在問題排查方面，我們有一套比較完整埋點問題追蹤流程，也是便捷后續做埋點問題的復盤。
埋點SLA：我們專門擬定了一套埋點SLA(Level-服務級別合同)機制，目前這塊主要由顧客端RD和QA來保證SLA，業務PM按照埋點重要性提供須要保證的SLA列表，數據組提供監控工具。
數據生產鏈路主要有以下幾個階段：需求、配置、埋點、驗證、上報、日志表。
流程是：在需求確定以后會做埋點的配置，顧客端進行測試上線。以后顧客端會依據用戶行為將日志上報（這兒分為實時上報和延后上報兩種）到nginx服務器，通過flume將日志搜集傳輸到kafka里，之后做實時處理，包括數據校準、過濾、字段分拆等比較簡單的數據處理，然后將數據落地到離線的log表，在離線階段的會進行比較重的數據處理操作，例如去重、關聯、標記等，最后產出公司級別數據表，提供公司各個業務部門使用。
4.埋點注意事項
后面介紹了埋點的基本信息與規范流程，這兒給你們介紹一些埋點的注意事項。個人認為做埋點還是十分須要經驗的，甚至是須要更多的試錯，這兒給你們列了一些注意事項以供參考：
同質參數的名稱和類型保持一致：主要就是彰顯在通用參數、業務參數、行為標示的統一，盡量做到事前整治，給整個的數據加工、數倉建設減少工作量，其實在數倉加工過程中也一定要做一些容錯；
通用復用：盡量少的創建新的風波，而是想辦法復用原先的風波，便捷后續的埋點管理；例如某彈窗在好多頁面都出現過，彈窗模塊爆光標示須要是惟一的，當它出現在不同的頁面的時侯，我們可以通過頁面標示來分辨，而不是每出現一個新的頁面就重新定義一個模塊標示；
最小細度：埋點定義到模塊內的最小元素，可以防止重復上報；
合并上報：相同模塊的MV風波可以合并上報；某一頁面中一定出現的元素可以不用上報(這兒是指MV爆光風波)，或則和PV時間合并上報，在PV中加一個數組標示即可；
歷史兼容：不能改變已有風波標示的含意，不能改變屬性標示的含意，不能改變參數值的含意；通常只做新增，不做更改，可以廢棄；
追蹤回溯：埋點設計文檔可以回挪到歷史版本，以便排查問題。
02
流量數據加工
介紹完了埋點信息，接出來重點講解流量數倉建設和歸因建設，首先介紹流量數倉構架。
1.流量數倉模型構架
在整個流量數倉建設過程中還是面對好多挑戰的，例如：
整個流量數倉構架如圖中所示，與之前惠明老師介紹的基本相同，具體細節可參考原文，這兒稍為講下：
ODL：DataLayer，操作型數據層，這一層主要對采集到的數據進行無損著陸、基礎數組清洗加工。ODL是原始日志明細寬表，完成了日志數據清洗過濾、歸因建設、公共維度建設等。全鏈路歸因建設在這一層實現。公共維度建設諸如地理位置維度生成、常用維度代理鍵生成等，下沉到ODL來進行，減少了運維和下游使用成本，須要依賴于DIM層的環境維度表。
IDL：DataLayer外賣app開發，集成數據層，這一層在ODL之上，主要完成領域數據建模，描述業務對象屬性、業務對象間的關系、業務行為屬性、業務行為與業務對象的關系等。IDL層是明細寬表層，按照數據域和業務過程進行主題界定，在主題內描述業務對象和業務行為，非常是對主題內常用的擴充維度數組進行提取，而且進一步使用維度退化手段，增強明細寬表的易用性、降低使用成本。比如搜索主題篩選了用戶搜索行為相關的日志，并將描述搜索業務的擴充字段進行提取。
CDL：DataLayer，器件數據層，這一層在IDL之上，主要完成剖析實體辨識，在主題界定基礎上，產生剖析實體/實體關系特點模型，對模型的指標進行加工，分為明細數據視圖和聚合數據表兩類。
MDL：MartDataLayer，集市數據層，這一層在CDL之上，構建在主題界定基礎上，通過維度層級匯總產生匯總表，通過維度字段關聯產生寬表，給數據應用提供便利應用的半成品數據集，比如，常見的店家流量寬表（店家的點擊、曝光、進店統計）。
ADL：AppDataLayer，應用數據層，不屬于內統一建設，這一層在MDL之上，直接面對數據應用，優先使用MDL的數據，當MDL不滿足時，可以向上使用CDL、IDL的數據。ADL作為數據應用的個性化數據通常不對外提供數據服務。
DIM：公共維度層，包括了流量數倉建設過程中使用的流量維表，分成主題維度表和環境維度表。其中主題維度表將埋點標示（用戶行為標示）映射成主題維度，是IDL、CDL進行主題界定的核心維度表。環境維度表包括了流量靜態屬性中常見的維度，比如app名稱、啟動渠道、設備類型等，主要應用于ODL層的公共維度建設。
2.流量數倉建設原則
在數倉建設中有好多原則，這兒掏出其中三個在流量數倉中比較重要的原則跟你們分享下：
①高內聚和低耦合
將業務相仿或相關、粒度相同、高機率同時訪問的數據放到一起。具體在流量數倉建設過程中，合理的主題界定顯然就是遵照高內聚低耦合的原則。不合理的主題界定會造成數據使用成本、運維成本減小。主題界定是和業務強相關的事情，須要你們定期自己的主題界定是否合理，一定要緊隨業務需求。
②公共處理邏輯下沉且單一
越是底層公用的處理邏輯，越要置于數據底層封裝與實現，不要讓公共邏輯多處存在且曝露給下層的表。流量底層數據的公共處理邏輯主要是環境維度建設和歸因建設。
③成本與性能平衡
適當的進行數據冗余來換取查詢和刷新性能，但不要過度冗余與數據復制。這是最淺顯易懂的原則，但在流量數倉建設過程中，須要綜合考慮各類使用場景，實踐上去很難。美團外賣每晚的數據量幾百億條，這樣一份數據，假如在多處出現復制，對儲存資源就是很大的浪費。成本與性能平衡確實須要多思索，在做數倉規劃時就須要把這個事情考慮到。具體實踐如下：
3.維度建設
為何常說流量數據在做數倉建設時比業務數據困難，個人認為是由于流量數據的數據源本身是一些半結構化的數據，沒有剖析維度的概念，所以在數倉的建設時我們要做好多的維度建設工作。因而維度建設是整個流量數倉工作中最核心工作，同時也是最大的難點。
我們維度建設分為兩種，環境維度和主題維度。
環境維度：
環境維度是指用戶行為所處的環境描述，比如用戶的定位城市、用戶的設備類型、用戶使用的app名稱等，這種維度是在主題界定基礎上，剖析實體維度模型中最主要的維度，即用戶在選取業務過程后最主要的剖析視角。環境維度建設主要遵循公共處理邏輯下沉且單一這個原則，在ODL完成建設。環境維度建設過程中，假如剖析的維度在日志中早已存在明晰數組，且該數組具有業務含意并是自然字段，這么都會直接使用這個自然鍵和相對應的維度屬性表。假如剖析的維度須要日志中的多個數組聯合，這時我們會對這多個數組生成一個代理鍵，并建立以這個代理鍵為字段的維度屬性表。
舉例來說，終端維度須要由日志中的操作系統類型、app名稱、啟動渠道這三個數組聯合生成。如下表所示，我們使用這三個數組生成了一個代理鍵終端id。非常說明的是，終端id的映射維表并不是簡單的可以通過操作系統、app名稱、啟動渠道這三個數組關聯得到。例如，終端id=3的這一行，操作系統數組可以為任意值（對上報日志不做要求）。這就要求我們在生成代理鍵的時侯須要采取一種愈發靈活的形式，以應對上游數據的不確定性沖擊。所以我們使用了UDF來實現：
UDF(操作系統，app名稱，啟動渠道)=終端id
主題維度：
原始日志在采集上來以后，是不具備業務過程分類的，僅僅能通過埋點標示來做分辨。所以我們須要對日志進行主題界定，也就是業務過程界定。舉例來說，我們想曉得一個用戶在外賣搜索頁的全部行為，我們就須要先找到外賣搜索頁的全部埋點標示，之后從原始日志中過濾下來。主題界定就是，將原始日志進行根據埋點標示界定到不同的主題表中。
我們將外賣整體的業務過程根據實體加行為進行具象。外賣業務中，常見的實體包括用戶、商家、菜品、訂單。實體和實體之間通過行為來聯接。例如，用戶和店家之間的行為可以有搜索、使用智能助手、使用購物車、點擊店家資源位等。
我們將這個埋點標示與主題表中的業務標示建立成主題維度表，用于管理埋點標示與業務標示的關系。在主題維表中，業務標示使用代理鍵，并在IDL中通過主題維表關聯出代理鍵。主題界定過程中，我們還須要將主題內常用的擴充維度數組進行提取，對于不同的埋點提取這種數組的形式不太一樣，我們也將埋點標示與主題擴充維度提取方法的對應關系維護在主題維度表中。
以資源位主題為例講解一下建設的過程：
業務過程描述：在做主題建設時我們首先要確定業務過程，這兒的業務過程就是從外賣的資源位點擊開始，用戶在點擊以后會步入店家頁，之后步入水單頁遞交訂單，最后下單。
業務過程提取：描述清楚業務過程以后，要對業務過程進行提取，即從ODL日志中找出所有瀏覽和點擊的日志，具體做法是：
維度管理：
在維度建設那邊，最后再聊下維度管理的事情，從昨晚的內容你們應當也可以感遭到，在流量數倉中維度建設是最核心的內容，它決定流量數倉的剖析視角以及流量數倉的運維成本，在做流量數倉建設時建議認真做下維度管理。
我們是專門做了一個工具來做維度管理。所有維度信息在管理平臺統一錄入、校驗、更新，最后同步到數倉的DIM層，給數倉的生產使用。這樣增加了數倉的運維成本。
4.歸因建設
歸因需求介紹：
后面內容我們講了數倉整體構架以及維度建設方面內容細節，接出來我們介紹流量數據最核心的、也是你們會時常遇見的歸因建設。在流量數據剖析場景中，有一類需求是基于單一埋點或埋點集合的且不須要進行日志關聯的剖析，例如某種用戶行為的人數、次數等；另一類需求是須要將日志進行關聯而且對日志的先后次序有要求的剖析，例如常見的統計經過外賣首頁店家列表點擊后的成單行為人數、次數。第二類需求似乎就是我們說的流量數據歸因。
流量數據歸因建設在外賣業務場景下是十分難的，難點有二：數據量大，在幾百億條的日志中，將須要的日志進行關聯是十分歷時、耗資源的；需求不固定，一般我們難以預知需求方想將什么日志做歸因剖析。
為此，流量數據歸因建設要重點解決這兩個難點問題，非常是難點二，因為需求的不固定，我們要實現全鏈路的歸因建設，而不是只針對個別行為的日志做歸因建設。
首先，我們要將需求簡化而且標準化，我們將所有的歸因統計具象成如下問題描述：
統計經過A行為的B行為的次(人)數
應對這樣的問題，給出的偽SQL：
select count(1) from 日志 where 行為 = B and 鏈路信息 包含 A經過這樣具象后，我們發覺問題顯得清晰一些，這個偽SQL就是所有歸因剖析場景的標準化查詢。問題聚焦在"鏈路信息"的建設。我們要為每一個用戶行為構建一個鏈路信息數組。
哪些是鏈路信息呢？在外賣業務場景下，鏈路信息是：某一行為的時間前序行為集合，集合中不包含相同頁面之間的行為。
鏈路信息建設：
在目標表中，為每一行數據新增一列鏈路信息，使用鏈表格式來儲存當前行的行為的鏈路信息。鏈表中每一個元素即代表一個時間前序行為（排除了MV風波），其中包含的數組會選定一些業務奇特的、與當前行為不同的數組（不包括通用環境數組），這是因為一個行為的時間前序行為中，通用環境數組通常是相同的（例如設備號、操作系統等），且通用環境數組早已作為了分組排序的條件。這樣設計表結構的用處是：目標表的行數沒有變多；對所有的用戶點擊行為和用戶步入某一頁面行為加工了鏈路信息數組。
可能會有朋友指責這個數組會不會非常長，非常是當用戶行為鏈路非常長的時侯，旁邊的行為日志這個數組值會很長。這些場景下我們就須要考慮究竟什么行為應當置于這個數組里，這兒我們使用因果關系來判定那個行為是這行日志的誘因行為。
我們將因果關系定義為為與相同頁面之間的事情無關。如上圖中風波序列記錄某用戶從P1點擊步入P2再點擊步入P3，之后又回到P2接著回到了P1又點擊了其它模塊。在這段用戶行為中P3的鏈路信息如圖中所示彩色部份只包含第一次抵達P3時經過的路徑；M5模塊的鏈路信息如圖中彩色模塊所示，我們覺得圖中所示的兩個P2之間的鏈路與M5鏈路信息無關；M7的鏈路信息同理。
這樣我們屏蔽掉用戶操作過程中的回退操作，最終記錄的鏈路信息數組值不會很大，其實這些因果關系一定要契合業務情況。
定義好鏈路信息和目標表結構以后，我們進行數據加工，鏈路信息數組使用udf（自定義函數）來加工得到，偽SQL代碼如下：
insert into target table select log表中的字段，udf(歸因處理輸入字段) as 原因行為 from 分組排序后的log表歸因處理輸入數組選定了部份通用環境數組和業務主鍵，通用環境數組拿來判定當前行數據中的環境參數是否發生變化（比如是否換了一個設備），業務主鍵主要用于udf的輸出結果。具體數據處理流程如下：
1.對日志進行分組排序，使用by根據通用環境數組進行分組，使用sortby根據時間戳次序排序，這樣保證了相同分組的數據分配到同一個當中進行處理，但是是根據時間戳排序然后進行有序處理；
2.在日志分組排序然后，進行鏈路信息數組加工，使用hiveudf來實現。在udf中，通過棧來儲存鏈路信息，一次udf執行過程闡述如右圖所示：udf輸入參數的通用環境數組拿來判定是否更換了設備或app，假如通用參數發生變化，說明上一個分組內的數據全部處理完，清空棧內的數據，把當前行為入棧。假如通用參數沒有發生變化，說明一直在處理相同組內的數據。須要判定當前行為的加入是否發生頁面回退，倘若發生頁面回退，則需按將相同頁面之間的行為出棧，最終將當前行為入棧。
3.結果數據輸出過程中，會首先進行行為標記，例如將每位頁面的最后一次點擊行為進行特殊標記，之后再將棧中所有的元素裝入鏈表中，作為最終的鏈路信息數組。
鏈路信息數組加工過后，我們要使用這個數組來解決流量歸因統計需求。我們回過頭來看一下之前提到的流量數據歸因建設兩個難點。雖然，把問題標準化成統計經過A行為的B行為的次（人）數，而且加工出鏈路信息數組，就早已解決了上述的兩個難點問題：鏈路信息數組是經過分組排序加工下來的，等同于提早做好了日志關聯；對所有的用戶點擊行為和用戶步入某一頁面行為都加工了鏈路信息數組，實現了全鏈路歸因。鏈路信息數組加工過程是與業務需求前饋的，即不依照業務需求多樣化開發，這就促使我們的方案具有很強的靈活性和拓展性。在IDL層可以依照主題的須要取出任何主題所須要的歸因數據。
其中，鏈路信息包含某行為須要通過udf來實現，因而我們開發了一系列的udf、udtf來使用鏈路信息主鍵。
后面介紹了在歸因建設中我們使用的鏈路信息追加的方案，可能在業界其他團隊使用的是其它的方案，例如撤單，這兒給出不同方案的簡單對比：
仔細對比我們會發覺這兩種方案是對稱的，鏈路信息追加儲存的是當前行為之前發生的行為，撤單儲存的是當前行為以后發生的行為。
勾稽關系：
接出來介紹一個流量數據校準方案，勾稽關系校準。勾稽關系在流量數據加工過程中可以很便捷的做監控、校驗。例如一個簡單場景就是落地頁流量要等于來源流量，搜索點擊的人數一定是跟搜索頁面瀏覽人數相差不大的。這兒將勾稽關系單獨列舉，也是希望你們在做流量數倉過程中可以靈活使用它。
5.埋點整治
介紹完數據加工內容以后，我們講解下數據整治方案，整個的數據整治或則數據資產管理包含好多工作，細節可以參考，這兒簡單介紹下埋點整治方案。埋點數據的特征是數據量級很大，因而在做埋點整治時一定要做ROI評估，目前的辦法就是做血緣溯源，溯源埋點在ETL任務中的使用情況。
我們將埋點使用情況分成了三類：
將全部使用流量數據的ETL任務標記完以后，我們就可以給每位埋點進行評分，分數較低的埋點會進行有計劃的刪節和整治，對于分數較高的埋點會進行更好的監控及跟蹤。
03
流量數據應用
最后簡單說下外賣流量數據的應用，目前主要有三類：
在OLAP引擎方面外賣app開發，你們都很了解，不做過多介紹，美團外賣對Doris、Kylin、Druid都有使用，對幾種OLAP引擎對比以及在美團外賣的使用場景如右圖所示：
04
總結與展望
經過幾年的建設實踐，美團外賣流量數據庫房早已提供了建立、準確的離線數據服務，未來我們將愈加關注實時流量數倉的建設，非常是實時數據全鏈路歸因建設仍然面臨著一些挑戰。
免責聲明：部分文章信息來源于網絡以及網友投稿，本站只負責對文章進行整理、排版、編輯，出于傳遞更多信息之目的，并不意味著贊同其觀點或證實其內容的真實性，如本站文章和轉稿涉及版權等問題，請作者在及時聯系本站，我們會盡快為您處理。
