滴滴在流量鏈路檢測架構設計及實踐

**桔妹導讀：**流量數據作爲整個數據體系構建的基石之一，爲公司的用戶增長、產品優化、智能運營及科學決策等方面，提供了可靠的業務分析及決策依據。業務層面對於流量數據也有較高的要求，比如全面性、準確性、及時性。經過幾年時間的打磨，我們沉澱了一套覆蓋全鏈路的檢測體系，能夠有效輔助鏈路同學看清數據現狀、定位數據問題。本文分享了流量鏈路檢測在滴滴多業務線場景下的實踐。 

**1. **

背景

Omega 是公司內部提供移動端用戶行爲採集、加工、存儲、呈現和應用的全流程數據服務平臺。整個平臺以前端數據採集爲源頭，通過實時或者離線 ETL 加工出具有業務需求的指標結果，爲滴滴的用戶增長、產品優化、智能運營及科學決策等提供可靠的流量數據支持。目前支持了公司內外部近 1500 + 應用，覆蓋公司大部分業務線。

業務層面對埋點提出了全面、準確、及時的高要求，而這也是整個數據體系構建的基石。經過過往幾年的持續打磨，我們沉澱了一套覆蓋全鏈路的檢測體系，能夠有效的輔助鏈路同學看清數據現狀，定位數據問題。下面我將與大家分享技術側的架構設計。

**2. **

數據鏈路

首先，先簡單介紹一下整個數據鏈路的架構，一共包含如下六個核心模塊。

• 採集 SDK：用於收集、組裝、發送埋點數據，通過相關緩存策略，降低丟包率、重複率。同時接收服務端策略下發，定向採集。

• 數據接收：用於接收來自端上的埋點數據及配置下發，高吞吐輕量級 web 服務。

• 實時 ETL：下游實時、離線數據的同源出口，負責比較重的數據處理邏輯，如格式轉換、地理信息填充、白名單過濾等。

• 離線數倉：kafka 數據到 hive 的清洗過程，包含通用 ODS 及面向 Session、設備等主題的數倉建設。

• 實時分流：面向實時數倉及算法策略場景的分流服務。

• 行爲分析：kafka2olap 子鏈路，服務上層行爲分析能力，如埋點細分、漏斗、路徑分析等分析產品。

整個鏈路相對較長，涉及各個大數據組件，鏈路的穩定性保障存在着難點，主要體現在以下幾點：

• 1. 數據源種類多，需要多種採集 SDK，且採集邏輯需要適配不同的生態。
• 2. 採集數據量大，強關聯業務的使用場景，對數據的準確、及時性要求高。
• 3. 採集 SDK 宿主及各個採集組件在不斷迭代，可能會出現問題。

如何有效的評估並提供給下游一份可用的數據？這就是貫穿全流程的鏈路檢測服務需要解決的問題，數據鏈路檢測模塊主要承擔鏈路的接收率、重複率、丟包率的度量及預警等職責。 

**3. **

數據鏈路檢測

**********▍******3.1 ****設計思路

對採集數據實現完整性度量：採集的數據質量我們從兩個方面進行度量：1）採集的精確度 2）採集的準確度。

精確是指每一次獨立測量和真實值之間的差距（與理論值相符合的程度）；

準確則是要求實驗有高度再現（多次實驗或計算的結果一致），一個完整的度量必須符合精確和準確兩個條件，才能算是精準，減少誤判。

我們在度量的精準和準確兩個方面進行了如下方面的努力。採集完整性度量方案不同於公司實時採集系統 dquality 採用的三方校驗，Omega 採用基於離線的小時級 pv、uv 聯合校驗保證度量採集完整性的精確度和準確度。

在採集精確度方面：

• 1）端上 sdk 層面，前端設備會以進程（android/ios，h5 以頁面）爲基本單位，維護一個計數器，在 app 存活期間記錄當前的埋點上報數據量，並且會記錄後續的每次上報數據量。

• 2）通道數據加工層面，在端上實現類似 trace 系統的 traceId，埋點每次上傳會在端上生成唯一的請求 Id，保證每次請求的唯一性，請求 Id 會在數據流動各個節點進行記錄。在數據傳輸節點保證 at last once 語義的情況下，實現每一個埋點的唯一性校驗。

• 3）在小時級粒度下，以服務器接收時間解決接入層請求日誌和埋點日誌切割的時間漂移問題。

在採集準確度方面：

檢測需要的數據源以小時級離線表 ods 形式產出，在離線數據的基礎上構建檢測指標，保證數據源多次重新計算結果一致。

**********▍******3.2 ****方案設計

對於全鏈路的六大模塊，我們進行了環環相比的檢測方案，通過數據前後流動兩個節點 pv 比率 (uv 比率輔助校驗是否存在重複消費情況) 判斷每個節點生產消費是否正常，簡化後的鏈路如下圖五個節點：

鏈路檢測有兩個核心指標：丟失率和入庫率，分別用來度量端上 sdk、內部通道的採集質量。

丟失率是邏輯上度量端上 sdk 採集質量，丟失率分子爲實際在接入層收集到請求數，丟失率的分母是通過計數器實現預期的請求數，丟失率通過對埋點請求接收情況量化進而度量端上 sdk 的採集質量。

入庫率是用來度量內部通道的採集質量，通過埋點數據流動過的 4 個節點的請求 pv 及埋點 pv【一個請求包含多條埋點數據】比率實現，入庫率通過對埋點請求 pv 及埋點 pv 實際流入到下游情況量化進而度量內部通道的採集情況。

基於上面思考和設計，實現了小時級及天級的鏈路檢測服務，具體如下：

現平臺 native 埋點的丟失率控制在 0.5%，web 埋點的丟失率控制在 2%，業內對於 web 埋點上報丟失率一般在 5% 左右。

**4. **

方案應用

**********▍**************4.1 ****完整性判定

離線數倉 ODS 層完整性 tag 利用 flink Checkpoint 編號嚴格單調遞增實現。採用 Flink 以 SequenceFile 格式進行 HDFS 寫入，Checkpoint 失敗時 PartFile 永遠處於 in-progress 或 pendiing 狀態，可以不被下游離線 ETL 任務讀取。

基於離線數據實現鏈路全局角度檢測採集包、及包內部埋點的丟失，重複情況

**********▍**************4.2 ****應用檢測

即檢測一個具體端的指標、丟失率、重複率等數據，以及關鍵埋點和屬性的上報、填充情況。

**********▍**************4.3 ****未註冊大盤

針對已經在端上進行上報，但是未在埋點管理平臺註冊的埋點，或者已註冊埋點但未註冊屬性的情況，提供查看及註冊使用，方便流量鏈路相關同學進行埋點治理。

**********▍**************4.4 ****埋點監控

除了業務自定義信息外，埋點也會包含較多通用屬性，如 uid、城市 id、渠道等信息，平臺會提供系統屬性填充率、Android/IOS 比值、枚舉值等監控能力，用戶也可以在平臺進行自定義配置。

之後可以在平臺上查看埋點的質量數據，並且可以以推送的方式告知用戶。

**5. **

方案應用

Omega 採集鏈路起源滴滴對流量採集的訴求，並且跟隨對流量數據使用的不斷迭代升級，逐漸演進，和業務共同成長。隨着 “0188 戰略落地”，業務增長方面持續發力，對實時數據訴求日漸增多，提升數據時效性和實時化服務也是 Omega 後續採集方案演進的重點，致力於進一步提升更好的數據埋點採集、實時服務、基礎數倉等服務。

內容編輯 | Teeo

聯繫我們 | DiDiTech@didiglobal.com

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/D_bClw_WnIFglyx1Yv6GBw