更多技術交流、求職機會、試用福利，歡迎關注位元組跳動資料平臺微信公眾號，回復【1】進入官方交流群
序言
埋點資料作為推薦、搜索、產品優化的基石，其資料質量的重要性不言而喻，而要保障埋點資料的質量，埋點驗證則首當其沖，工欲善其事必先利其器，要做好埋點驗證會面臨很多技術挑戰：易用性、準確性、實時性、穩定性、擴展性，如何攻克這些挑戰呢，其實還是技術，這也是本文的主旨所在，
目前埋點驗證已在位元組內部得到廣泛使用，通過一鍵掃碼開啟驗證、實時上報驗證、自動生成驗證報告，解決了埋點資料驗證難、埋點質量保障難的問題，
埋點驗證流程
-
埋點生命周期：4+6
4 個角色：PM、DA、RD、QA
6 個節點：提出需求、設計埋點、開發埋點、測驗埋點、上報埋點、分析埋點
-
埋點驗證流程：3+3+3
3 個角色：DA、RD、QA
3 個節點：設計埋點、測驗埋點、驗收埋點
3 個物料：埋點驗證方案、埋點驗證工具、埋點驗證報告
技術架構
產品流程
先簡單介紹一下產品，以便大家能對平臺有整體認識，方便大家更加輕松地理解技術，平臺主要包括三部分：埋點驗證方案、埋點驗證工具、埋點驗證報告，三者相輔相成，極大的降低了用戶的埋點驗證成本，
-
附埋點驗證工具圖
技術架構圖
埋點驗證的鏈路很長，可以簡單概括為三個環節：埋點上報、埋點接收、埋點驗證，每個環節都有一定的復雜性，此處先介紹整體流程，讓大家可以快速對全流程有所認識，其次將主要聚焦于“埋點驗證”環節，此環節的重中之重是埋點驗證引擎，它包括 4 個部分：規則生成器、規則選擇器、埋點驗證器和埋點推送器，通過對埋點驗證引擎的詳解讓大家對“埋點如何驗證”有更深的理解，
-
埋點上報環節重點是豐富的 SDK(客戶端、服務端、JS、Chrome 插件)，要做到簡單易用并且保證埋點實時上報，
-
埋點接識訓節重點是資料接收服務(客戶端-applog、Web 端-mcs、服務端-databus)、資料保存服務(訊息佇列)，要保證服務穩定并且保證埋點不丟失，
-
埋點驗證環節重點是埋點驗證引擎，要確保服務高性能并且保證埋點驗證結果的準確性，
規則生成器
規則生成器將“埋點驗證方案”轉換為“驗證規則”，埋點驗證方案是驗證規則的邏輯視圖，方便用戶操作，降低驗證規則的撰寫和維護成本，通過邏輯視圖和物理視圖兩層邏輯，確保了埋點驗證引擎底層不受業務變化的影響，
埋點方案
埋點驗證方案支持 2 種：
-
按需求驗證：即新建需求計劃，針對某次需求驗證、
-
按元資料驗證：即按元資料驗證，元資料是指所有需求的并集
按元資料驗證：
-
埋點名稱：video_play
-
引數資訊
(名稱、型別、是否必填、值校驗、是否是場景條件)
enter_from,string,必傳,固定值(login),是
duration,integer,必傳,值無限制,否
type,integer,必傳,列舉(1,2,3),否
埋點資料：
{
"app_id":100,
"event":"click",
"params":{
"enter_from":"login",
"duration":1,
"type":3
}
}
埋點規則
{
"app_id":100,
"event_name":"video_play",
"logical_filter":{
"enter_from":"login"
},
"meta":{
"required_field":[
"duration",
"enter_from",
"type"
],
"scene":{
"condition":"enter_from=login",
"name":"登錄頁"
},
"validate_field":[
"duration",
"enter_from",
"type"
]
},
"physical_validation":"{\"$schema\":\"https://json-schema.org/draft/2019-09/schema\",\"type\":\"object\",\"properties\":{\"params\":{\"type\":\"object\",\"properties\":{\"duration\":{\"type\":\"integer\"},\"enter_from\":{\"type\":\"string\",\"enum\":[\"login\"]},\"type\":{\"type\":\"integer\",\"enum\":[1,2,3]}},\"required\":[\"duration\",\"enter_from\",\"type\"]}},\"required\":[\"params\"]}",
"source":"schema_scene"
}
埋點規則欄位說明
-
app_id：應用 id
-
event_name：埋點名稱
-
logical_filter：用于“規則選擇器”
-
physical_validation：用于“埋點驗證器”
-
source：區分規則來源：按需求驗證、按元資料驗證
規則選擇器
規則選擇器將依據“埋點”中的關鍵資訊，從“驗證規則池”中選擇出對應的“埋點驗證規則”，
-
選擇邏輯：具體資料參考“規則生成器”
根據“埋點資料”中 app_id 和 event 從“驗證規則池”中篩選出“匹配的規則”
將“埋點資料”的 parms 欄位和“匹配的規則”的 login_filter 規欄位進行匹配，選擇出最終的“埋點驗證規則”
埋點驗證器
埋點驗證器將依據“基礎驗證規則”以及“規則選擇器”產出的“埋點驗證規則”，對“埋點資料”進行驗證并產出“驗證結果”，
-
基礎驗證規則：埋點是否登記；埋點是否禁用；是否是 debug 埋點；
-
埋點驗證規則：引數是否丟失；引數型別是否正確；引數取值是否符合預期:列舉、范圍、正則；
-
埋點驗證結果：驗證結果提供雙語格式，用戶可自行選擇中文或者英文；
埋點推送器
埋點推送器將“埋點驗證結果”推送到前端，推送的程序存在資料互動頻繁、資料體積大、資料傳輸穩定性的要求，這里我們自建 Push 服務進行資料傳輸，保證資料實時可達，
技術挑戰
-
易用性：快速接入埋點驗證，快速開始埋點驗證
-
準確性：埋點驗證結果準確、用戶可信
-
實時性：埋點資料實時可見
-
穩定性：埋點資料可靠不丟失
-
擴展性：快速接入新的埋點資料格式
易用性
快速接入埋點驗證，快速開始埋點驗證
SDK
-
快速接入埋點驗證
-
SDK 提供“埋點驗證開關”，客戶端集成 SDK 的時候，可根據不同環境來配置是否開啟“埋點驗證開關”
-
SDK 層判斷如果開啟“埋點驗證開關”，埋點資料會雙發，此程序對業務是透明的
雙發的原因或者為什么不從“線上埋點通道”取數？這里主要考慮兩個原因：
“線上埋點通道”資料量太大
SDK 層線上上報邏輯是采用微批的形式，默認 1 分鐘從客戶端上報一次，而埋點驗證要求實時性，所以采用單獨的通道
掃碼連接
-
快速開始埋點驗證
-
連接流程
建立 WS 連接：服務端和驗證平臺建立長連接，用于通信
ws_id：驗證平臺根據 ws_id 生成二維碼
掃碼：客戶端掃描二維碼
獲取并打開驗證開關：客戶端獲取設備資訊并且打開埋點驗證開關
上報 device_id：客戶端將長連接資訊和設備資訊上報至服務端
下發 device_id：服務端將設備資訊推送到驗證平臺
開始驗證：埋點驗證平臺進入驗證階段
上報埋點：客戶端開始上報埋點
推送埋點：服務端將埋點推送到驗證平臺
-
下發原理
客戶端上報的埋點資料中含有設備資訊
用戶通過掃碼在驗證平臺回填設備資訊
服務端接收到埋點資料后，將埋點資料中的設備資訊和驗證平臺的設備資訊進行匹配，如果匹配則將埋點資料進行下發
準確性
埋點驗證結果準確、用戶可信
埋點驗證引擎必須保證埋點驗證結果的準確性，才能降低驗證成本，針對埋點資料本身的格式驗證，我們采用了 JsonSchema 作為驗證手段，以支持完善的驗證規則、可信的驗證結果，上文中的“規則生成器”、“規則選擇器”、“埋點驗證器”也都在一定程度上保證了埋點驗證結果的準確性，
埋點方案
event:video_play
-
埋點名稱：video_play
-
引數資訊
(名稱、型別、是否必填、值校驗、是否是場景條件)
enter_from,string,必傳,固定值(login),是
duration,integer,必傳,值無限制,否
type,integer,必傳,列舉(1,2,3),否
埋點規則
jsonSchema
{
"$schema":"https://json-schema.org/draft/2019-09/schema",
"type":"object",
"properties":{
"params":{
"type":"object",
"properties":{
"duration":{
"type":"integer"
},
"enter_from":{
"type":"string",
"enum":[
"login"
]
},
"type":{
"type":"integer",
"enum":[
1,
2,
3
]
}
},
"required":[
"duration",
"enter_from",
"type"
]
}
},
"required":[
"params"
]
}
埋點資料
event:video_play
{
"app_id":100,
"event":"click",
"params":{
"enter_from":"login",
"duration":1,
"type":3
}
}
驗證結果
event:video_play
-
測驗地址：https://www.jsonschemavalidator.net/
實時性
埋點資料實時可見
埋點驗證場景下，服務端和驗證平臺需要頻繁地進行資料互動，所以我們自建了 Push 服務(基于 WebSocket 的封裝)，能夠保證資料的實時暢通性
Push 服務目標
-
基于 WebSocket 實作一套通用長連接通訊協議，能實作同一個客戶端上的不同業務共享同一個長連接通道，并實作可靠的心跳機制，
-
客戶端和服務端基于通用長連接通訊協議實作一個穩定可靠的全雙工通道，
-
客戶端實作一個通用的 SDK，服務端實作一個通用接入層，
-
客戶端 SDK，服務端接入層，都要很方便后續 service 接入，
-
Push 服務定期做打點監控，同時開放 http 的 Admin 介面，方便系統的監控和查看服務狀態
Push 服務優勢
-
連接穩定性：Push 服務分為兩個組件 Push 和 Backone，實作了業務和推送解耦，push 面向客戶端連接，設計盡可能簡單，需保持大量客戶端活躍連接，避免了業務服務更新時不影響客戶端連接
-
服務隔離性：不同的業務服務接入 push 服務，會根據接入資訊做集群隔離，避免業務之間互相影響
-
橫向擴展性：當業務服務不斷增多時，只需對 push 服務做橫向擴容即可支持
Push 服務流程
穩定性
埋點資料可靠不丟失
SLA
-
定義：服務級別協議 (service-level agreement，即 SLA) 是服務提供方與客戶之間的正式承諾，用來量化服務水平(質量、可用性、責任)
-
埋點驗證服務：服務的特征是實時，所以衡量埋點驗證不可用的手段是“資料延遲”，即埋點從“上報”->“驗證平臺”的 p99 超過 3s 即視為不可用，日常 p99 在 1s
措施
-
為了保證“SLA”，我們做了一系列的保護措施
-
日志轉換器：客戶端、服務端、web 端上報的是原始日志格式，需要轉換為埋點驗證日志格式后進行驗證
擴展性
快速接入新的埋點資料格式
-
提供可插拔的“日志轉換器插件”，服務高內聚，可支持各種日志格式快速接入、驗證
展望
埋點驗證是保障埋點質量的有效方式，此方式屬于事前驗證，適用于埋點頻繁變化的業務場景，需要一定程度的人工介入，能夠解決基本的埋點質量問題，但是對于核心埋點場景來說，這種方式的驗證成本較高，需要重復的人力投入，為了解決核心埋點驗證成本高的問題，我們正在探索落地其他方式：
-
回歸驗證(自動化驗證)：伴隨每次發版，核心埋點都需要進行回歸驗證，目前我們通過內部其他團隊的合作實作了自動化驗證功能來支撐回歸驗證，當前已有一部分業務正在使用，極大地降低了驗證核心埋點的成本
-
事后驗證：經過事前驗證、回歸驗證，埋點質量基本能得到很好的保障，但為了更好的保障我們也在探索事后驗證的場景和落地：
質量大盤：通過“規則引擎”，結合“質量模型”對埋點資料進行質量評估，得出各個維度的“質量評分”，然后針對質量問題進行專項修復，進一步提高埋點質量，
質量工具：提供監控計劃，業務可以針對自己關注的埋點配置監控報警，當線上出現質量問題，會發送質量報告給業務，及時止損，
-
全鏈路埋點質量保障：事前驗證、回歸驗證、事后驗證貫穿埋點的生命周期，打通這三個流程，從而形成埋點質量保障全鏈路，徹底解決埋點質量問題，
立即跳轉火山引擎大資料研發治理套件產品官網了解詳情！
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/501280.html
標籤：大數據