一文讀懂位元組跳動“埋點驗證平臺”

来源:https://www.cnblogs.com/bytedata/archive/2022/08/08/16561790.html
-Advertisement-
Play Games

更多技術交流、求職機會、試用福利，歡迎關註位元組跳動數據平臺微信公眾號，回覆【1】進入官方交流群 序言 埋點數據作為推薦、搜索、產品優化的基石，其數據質量的重要性不言而喻，而要保障埋點數據的質量，埋點驗證則首當其衝。工欲善其事必先利其器，要做好埋點驗證會面臨很多技術挑戰：易用性、準確性、實時性、穩定性 ...


更多技術交流、求職機會、試用福利，歡迎關註位元組跳動數據平臺微信公眾號，回覆【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 服務目標

  1. 基於 WebSocket 實現一套通用長連接通訊協議，能實現同一個客戶端上的不同業務共用同一個長連接通道，並實現可靠的心跳機制。

  2. 客戶端和服務端基於通用長連接通訊協議實現一個穩定可靠的全雙工通道。

  3. 客戶端實現一個通用的 SDK，服務端實現一個通用接入層。

  4. 客戶端 SDK，服務端接入層，都要很方便後續 service 接入。

  5. Push 服務定期做打點監控，同時開放 http 的 Admin 介面，方便系統的監控和查看服務狀態

Push 服務優勢

  1. 連接穩定性：Push 服務分為兩個組件 Push 和 Backone，實現了業務和推送解耦。push 面向客戶端連接，設計儘可能簡單，需保持大量客戶端活躍連接，避免了業務服務更新時不影響客戶端連接

  2. 服務隔離性：不同的業務服務接入 push 服務，會根據接入信息做集群隔離，避免業務之間互相影響

  3. 橫向擴展性：當業務服務不斷增多時，只需對 push 服務做橫向擴容即可支持

Push 服務流程

圖片

穩定性

埋點數據可靠不丟失

SLA

  1. 定義：服務級別協議 (service-level agreement，即 SLA) 是服務提供方與客戶之間的正式承諾，用來量化服務水平(質量、可用性、責任)

  2. 埋點驗證服務：服務的特征是實時，所以衡量埋點驗證不可用的手段是“數據延遲”，即埋點從“上報”->“驗證平臺”的 p99 超過 3s 即視為不可用，日常 p99 在 1s

措施

  • 為了保證“SLA”，我們做了一系列的保護措施

  • 日誌轉換器：客戶端、服務端、web 端上報的是原始日誌格式，需要轉換為埋點驗證日誌格式後進行驗證

 

 

圖片

擴展性

快速接入新的埋點數據格式

  • 提供可插拔的“日誌轉換器插件”，服務高內聚，可支持各種日誌格式快速接入、驗證

圖片

展望

埋點驗證是保障埋點質量的有效方式，此方式屬於事前驗證，適用於埋點頻繁變化的業務場景，需要一定程度的人工介入，能夠解決基本的埋點質量問題。但是對於核心埋點場景來說，這種方式的驗證成本較高，需要重覆的人力投入，為瞭解決核心埋點驗證成本高的問題，我們正在探索落地其他方式：

  • 回歸驗證(自動化驗證)：伴隨每次發版，核心埋點都需要進行回歸驗證，目前我們通過內部其他團隊的合作實現了自動化驗證功能來支撐回歸驗證，當前已有一部分業務正在使用，極大地降低了驗證核心埋點的成本

  • 事後驗證：經過事前驗證、回歸驗證，埋點質量基本能得到很好的保障。但為了更好的保障我們也在探索事後驗證的場景和落地：

    質量大盤：通過“規則引擎”，結合“質量模型”對埋點數據進行質量評估，得出各個維度的“質量評分”，然後針對質量問題進行專項修複，進一步提高埋點質量。

    質量工具：提供監控計劃，業務可以針對自己關註的埋點配置監控報警，當線上出現質量問題，會發送質量報告給業務，及時止損。

  • 全鏈路埋點質量保障：事前驗證、回歸驗證、事後驗證貫穿埋點的生命周期，打通這三個流程，從而形成埋點質量保障全鏈路，徹底解決埋點質量問題。

 

立即跳轉火山引擎大數據研發治理套件產品官網瞭解詳情！
您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • C#《原CSharp》第四回 人常見歲月更替 卻難知人文相繼
    紀芾顯然此時並不是很能理解紀老爺子口中是也不是這句話的意思，不過他依然將這個要點記在了心裡，方便以後悟出其最終門道的時候進行比對。 “今天，我在璃月港北邊的一戶人家，遇到了一個挺有意思的後生，他是今天才覺醒的元素力，但對於簡單的元素力操作已經掌握了些許了。”紀存初還沒等紀芾好好揣摩他剛纔那句話的深意 ...
  • react環境搭建及文件配置
    webpack簡介 構建工具（基於Nodejs）node(v16)前端工程化。 環境搭建 創建一個空的package.json npm init webpack核心包（提供了API,插件） npm i webpack -g npm i webpack -D cnpm i webpack -g cnp ...
  • 在docker中編譯安裝apache
    在docker中拉取centos8鏡像，創建一個為centos8的容器，併在容器中編譯安裝apache，然後使用編製安裝完成的容器創建一個鏡像。測試是否能通過此鏡像部署一個web站點併成功訪問 ...
  • 探秘：TriCore處理器中斷機制
    1. TriCore與中斷的簡介 TriCore是德國英飛凌科技公司旗下的第一個為實時嵌入式系統而優化的統一的、32位的微控制器-DSP（Digital Signal Processing）處理器架構。TriCore的ISA（Instruction Set Architecture），即指令集體繫結 ...
  • 博德之門:黑暗聯盟2 for mac(迷宮探索游戲)原生版
    博德之門:黑暗聯盟2是一款原始畫風奇幻探索動作冒險游戲，商隊遇難，僅剩的守衛也已受傷，邪惡力量再次回到了傳說中的博德之門，玩家需要狡猾的戰士和大膽的法師從威脅所有人的黑魔法中奪回博德之門，快拿起你的武器參加戰鬥吧！ 詳情：博德之門:黑暗聯盟2 for mac(迷宮探索游戲) 簡單介紹 在這個地牢爬行 ...
  • PreviewMarkdown for Mac(Markdown編輯預覽軟體)
    PreviewMarkdown Mac版是一款功能強大的Markdown編輯預覽軟體，為使用流行的 Markdown 標記格式創建的文檔提供 QuickLook 文件預覽和文件圖標縮略圖。 詳情：PreviewMarkdown for Mac(Markdown編輯預覽軟體) 簡單介紹 Preview ...
  • MySql 刪除數據表
    定義： 刪除數據表就是將資料庫中已經存在的表從資料庫中刪除。註意，在刪除表的同時，表的定義和表中所有的數據均會被刪除。因此，在進行刪除操作前，最好對錶中的數據做一個備份，以免造成無法輓回的後果。本節將詳細講解資料庫表的刪除方法。 1 刪除一個或多個沒有被其他表關聯的數據表 如果一個數據表沒有和其它表 ...
  • 【DB運營管理/開發解決方案】上海道寧為您提供提高工作便利性的集成開發工具——Orange
    Orange是提高工作便利性的 集成開發工具 可以極大方便資料庫管理和 用戶的數據訪問進程 Orange是 DB運營管理和開發解決方案 通過方便而又強大的功能 快速可視化編程前端 以便瀏覽數據分析和可視化 開發商介紹 Ware Valley成立於2001年，是一家全球性的軟體公司，也是南韓唯一一個為 ...
一周排行
    -Advertisement-
    Play Games
  • UOS 開啟 VisualStudio 遠程調試 .NET 應用之旅
    前言 在我們開發過程中基本上不可或缺的用到一些敏感機密數據，比如SQL伺服器的連接串或者是OAuth2的Secret等，這些敏感數據在代碼中是不太安全的，我們不應該在源代碼中存儲密碼和其他的敏感數據，一種推薦的方式是通過Asp.Net Core的機密管理器。 機密管理器 在 ASP.NET Core ...
  • C# - 能否讓 SortedSet.RemoveWhere 內傳入的委托非同步執行
    新改進提供的Taurus Rpc 功能，可以簡化微服務間的調用，同時可以不用再手動輸出模塊名稱，或調用路徑，包括負載均衡，這一切，由框架實現並提供了。新的Taurus Rpc 功能，將使得服務間的調用，更加輕鬆、簡約、高效。 ...
  • 順序棧的介面程式
    順序棧的介面程式 目錄順序棧的介面程式頭文件創建順序棧入棧出棧利用棧將10進位轉16進位數驗證 頭文件 #include <stdio.h> #include <stdbool.h> #include <stdlib.h> 創建順序棧 // 指的是順序棧中的元素的數據類型，用戶可以根據需要進行修改 ...
  • mORMot2 獲取數據集1
    前言 整理這個官方翻譯的系列，原因是網上大部分的 tomcat 版本比較舊，此版本為 v11 最新的版本。 開源項目 從零手寫實現 tomcat minicat 別稱【嗅虎】心有猛虎，輕嗅薔薇。 系列文章 web server apache tomcat11-01-官方文檔入門介紹 web serv ...
  • 萬字長文總結與剖析C語言關鍵字 -- <<C語言深度解剖>>
    C總結與剖析:關鍵字篇 -- <<C語言深度解剖>> 目錄C總結與剖析:關鍵字篇 -- <<C語言深度解剖>>程式的本質:二進位文件變數1.變數:記憶體上的某個位置開闢的空間2.變數的初始化3.為什麼要有變數4.局部變數與全局變數5.變數的大小由類型決定6.任何一個變數,記憶體賦值都是從低地址開始往高地 ...
  • 【Flink入門修煉】2-3 Flink Checkpoint 原理機制
    如果讓你來做一個有狀態流式應用的故障恢復，你會如何來做呢？ 單機和多機會遇到什麼不同的問題？ Flink Checkpoint 是做什麼用的？原理是什麼？ ...
  • C++ 多級繼承與多重繼承：代碼組織與靈活性的平衡
    C++ 多級繼承 多級繼承是一種面向對象編程（OOP）特性，允許一個類從多個基類繼承屬性和方法。它使代碼更易於組織和維護，並促進代碼重用。 多級繼承的語法 在 C++ 中，使用 : 符號來指定繼承關係。多級繼承的語法如下： class DerivedClass : public BaseClass1 ...
  • 圖文結合手把手教你創建SpringCloud項目
    前言 什麼是SpringCloud？ Spring Cloud 是一系列框架的有序集合，它利用 Spring Boot 的開發便利性簡化了分散式系統的開發，比如服務註冊、服務發現、網關、路由、鏈路追蹤等。Spring Cloud 並不是重覆造輪子，而是將市面上開發得比較好的模塊集成進去，進行封裝，從 ...
  • 類模板的常見用法
    class_template 類模板和函數模板的定義和使用類似，我們已經進行了介紹。有時，有兩個或多個類，其功能是相同的，僅僅是數據類型不同。類模板用於實現類所需數據的類型參數化 template<class NameType, class AgeType> class Person { publi ...
  • system-v IPC共用記憶體通信
    目錄system v IPC簡介共用記憶體需要用到的函數介面shmget函數--獲取對象IDshmat函數--獲得映射空間shmctl函數--釋放資源共用記憶體實現思路註意 system v IPC簡介 消息隊列、共用記憶體和信號量統稱為system v IPC(進程間通信機制)，V是羅馬數字5，是UNI ...
所有分類