本文整理自火山引擎開發者社區 Meetup 第四期演講，主要介紹了字節跳動流量平臺的埋點內容解決方案和埋點鏈路解決方案，揭秘了流量平臺如何支撐起字節跳動萬億+的實時數據處理。

首先我們定義一下埋點是什么?埋點主要是描述用戶在 APP 內觸發的一系列行為，包括點擊、側滑等?；谶@些行為，我們可以進行行為分析、個性化推薦、精準營銷等很多事情。埋點主要描述的是哪些數據?

• Who：誰操作的數據
• When：什么時候操作的數據
• Where：在哪些頁面、模塊的數據
• How：用戶如何操作的
• What：有哪些附加信息

因為本文介紹的是埋點治理，所以這里再介紹一下什么是數據治理。數據治理是指在數據的生命周期內，對其進行管理的原則性方法，其目標是為了確保數據的安全、及時、準確、可用和易用。數據總是會變得無效甚至無用，因此就涉及到對存量數據的治理。但這里要強調一下，數據治理不只針對存量數據，更重要的是對增量數據的治理，通過一系列手段，能保證數據從源頭開始就是正確的。此外，所有的治理都有具體的落地內容，一個穩定的治理鏈路是所有數據治理的基石。

下面就為大家介紹字節跳動是如何治理埋點數據的。

字節跳動流量平臺

流量平臺是字節跳動內部統一的埋點平臺，覆蓋埋點數據定義、采集、生產、應用、治理等埋點全生命周期。當前，流量平臺已經覆蓋了 2000 多個應用，管理埋點(事件)數 20 萬，每天產生的埋點數據量超過萬億，每年能給公司節省的成本超億元。

上圖是字節跳動流量平臺的產品概念圖，可以看到流量平臺主要分為幾塊：

• 埋點內容：這是用戶接觸最多的一塊，包括埋點生命周期的設計、開發、驗證、上線、使用、乃至下線。
• 埋點治理：指的是狹義的對存量數據的治理。涉及成本、SLA 等的治理。
• 鏈路側：包含埋點的收集、處理和訂閱的全鏈路，平臺目前支持對 iOS、Android 等全端數據的收集。平臺已經跟下游使用流量數據的應用進行打通，用戶可以訂閱數據。
• 鏈路根基：即自研的動態實時計算平臺，也是整個平臺的核心技術，它能夠支撐起字節跳動萬億+的實時數據的處理。

埋點內容解決方案

埋點內容主要管理埋點生命周期，這里要著重強調一下上圖中心位置的埋點模型其實非常重要，因為埋點模型設計的好壞直接影響到埋點的設計、開發、測試甚至使用。

埋點內容用戶痛點

埋點內容的用戶主要是有兩大類：埋點消費者和埋點生產者。對于埋點消費者來說，存在如下痛點：

• 查找難度大：埋點數量非常多，找不到自己想要的埋點。
• 使用難度高：找到埋點之后，用戶也很可能不清楚指標埋點口徑。
• 埋點難信任：當數據不符合預期時，不確定埋點數據是否可用。

對于埋點生產者來說，也有一些痛點：

• 生產鏈路長：各方信息對齊、流程推動難度大;
• 模型落地難：不知如何設計、不知是否符合規范;
• 缺乏工具支持：設計、開發、測試純白手起家。

那怎么去解決用戶的這些痛點呢?首先我們要弄清楚埋點的第一站是什么。很多公司都有埋點系統，對于大部分公司而言，埋點的第一站是埋點錄入。但是大家會發現，埋點錄入并不是一切的源頭，埋點設計才是。埋點設計是第一手的資料，根據埋點的設計文稿可以將用戶的需求梳理得非常細致。而埋點錄入是第二手甚至是第 N 手資料，錄入的信息肯定會有丟失，并且只能進行一些基本的校驗，滿足基本的準確性。

其次，如果沒有資產的輔助設計，每一個埋點錄入都要從 0 到 1 去實現一遍。但是埋點設計通過資產輔助設計可以變得很簡單。因此，我們認為埋點設計才是 the single source of truth，這是我們整體設計的核心。下面來看看用戶如何在我們的系統設計埋點。

字節跳動流量平臺的產品輔助設計基于靈活的模型支持、設計資產積累、設計輔助，可以方便每一個用戶定義高質量數據，讓用戶愿意在系統進行設計和評審。

設計完埋點，我們在埋點開發上也有對應的工具來服務來發。下面是我們的一段演示：

當用戶要設計埋點時，可以通過 ID 找到要開發的埋點，通過點擊即可插入代碼。同時，系統支持 VSCode 等主流編輯器，針對不同語言和代碼風格自定義代碼模版，還有類型校驗、編輯切換等。

埋點測試

埋點測試比 QA 要難很多，看的是一串數字、類型的值等。在字節跳動流量平臺系統中，可以依托埋點設計中的規則輔助測試，針對類型、取值、必填等自動驗證，并且可以一鍵生成報告。

我們是怎么去做好測試這件事的呢?重點還是前面提到的做好埋點設計。只有設計周全，才能積攢足夠的規則進行自動化測試，因此埋點設計方案非常重要。

埋點設計者會在方案設計時制定一系列的約束規則，我們會依托這些約束規則生成一系列相匹配的測試用例，并在測試過程中進行自動匹配、測試。

埋點測試時，測試者手機掃碼即可將服務器和瀏覽器建立連接，在 App 上操作后，流量平臺可以實時接收到對應的埋點數據。因為已經有測試用例，規則執行引擎便可以自動匹配執行并得到結果，再通過驗證結果推送服務實時推送至瀏覽器。

埋點測試后，用戶可以通過報告生成器可以一鍵生成報告，發送給 RD 進行修改或者 DA 進行驗收。這樣就完成了整個測試流程。

埋點存量治理

在生成了大量的埋點之后，我們需要進行存量埋點數據的治理，具體涉及 SLA、成本、合規以及數據質量等方面。為什么還要進行存量埋點數據的治理呢?我們有這樣一些觀點：

• 數據不一定都是重要的。因為業務都不一定總是重要的。
• 數據并不總是有用的。比如活動下線了，埋點就要下線，否則付出了成本卻沒有收益。
• 數據不一定總是合規的。隨著數據隱私的重要性越來越高，合規要求也在不斷更新變動。

對于存量埋點數據的治理，也有一些痛點。對于治理負責方來說，數據越來越多，而對數據的實時性要求卻越來越高；隨著數據量暴增，成本也急劇增加，SLA 等級越來越慢；用戶隱私也越來越重要。對于治理實施方來說，他們可能不敢治理，不愿治理，也不懂治理。

我們梳理了用戶的需求，發現是這樣幾層：

• 用戶層：自動化識別埋點是否有用，流程化引導埋點的分級和下線。
• 統計層：做到數字化、貨幣化，治理大盤清晰可知，埋點成本準確無誤。
• 甄別層：通過的血緣圖譜，對實時統計、離線報表、行為分析、推薦系統等做實時決策。
• 執行層：從 APP 端到數倉全流程，強兜底。
• 鏈路層：需要高效、穩定、完整的鏈路方案解決治理難題。

針對這些需求，我們是怎么做的呢?

埋點分級/無用埋點甄別

埋點血緣和離線血緣抽取不太一樣。離線血緣是點與點之間的血緣，但埋點血緣關注的是內容與點的血緣，它需要知道一張表的哪些行的信息有用。這是完全不同的一個領域，沒有任何前人的經驗可以借鑒，我們在埋點血緣做了幾個方面的事情：

• 離線處理：通過 SQL 解析，計算埋點與離線表的血緣;
• 實時處理：利用埋點鏈路優勢，掌握實時分流血緣關系;
• 即時分析：與行為分析、SQL 臨時查詢系統打通;
• 推薦系統：利用數據清洗鏈路優勢，解耦推薦血緣。

在埋點分級上，我們以性能埋點為突破口，給予匹配的 SLA 和 TTL 配置。

埋點鏈路解決方案

下面著重介紹一下我們的埋點鏈路解決方案。首先我們還是來看下埋點鏈路用戶的需求是什么。對于非技術的運營、分析師同學，他們需要清楚自己：

• 需要什么樣的數據：是埋點數據還是展現數據?
• 需要哪些數據：最好能對不同來源不同時效性的數據進行可視化過濾、清洗。
• 需要在哪里用這些數據：是實時報表，還是行為分析，還是推薦?

埋點鏈路的挑戰

在埋點鏈路設計上我們也遇到了一些挑戰：

• 大數據量下的穩定性：埋點數據在字節跳動是核心數據，其穩定性非常重要。
• 低延遲實時處理：尤其對于推薦，實時性要求非常高。

分級構建+下線。這里分幾塊內容：

• 數據接入：我們提供全棧 SDK 接入，還在 SDK 內置了管控的機制，利用各個 APP 內終端計算的能力，大大節省成本;而且根據合規要求不能上報的埋點就可以直接在 SDK 端丟棄掉;
• 數據收集：數據收集一般是提供 HTTP 接口，將上報的數據存到消息隊列。而埋點數據量特別大，于是我們進行了埋點聚合，將埋點的 Event 數據聚合成 Applog 數據一起上報。數據進入到 Applog 后通過自研的實時數據處理平臺來解析。

實時動態處理引擎

上圖是我們自研的實時數據平臺架構，該平臺主要解決兩方面的問題：

• 實時處理：快速處理大量數據;
• 動態化：字節跳動服務規模巨大，重啟時間過長會導致下游斷流，因此我們的實時領域里不接受重啟。此外，邏輯有任何修改都要重啟，在大量的業務和邏輯下這是不可能實現的。所以該平臺一定要做到動態化。

動態實時處理引擎在收到實時數據的 Applog 后將其解析成真正的埋點數據。再通過數據加工，可以轉換為其他的(甚至自定義的)數據格式，最后通過數據訂閱推送到各應用。

第二種模式是分級。在埋點數據被解析以后，我們會打上標記，然后 dump 到 hdfs 不同的路徑下。后續 Hive 進行構建的時候可以區分優先級，優先級高的進入高優隊列。Hive 的數據也是分區的，分區的數據可以制定不同的 TTL。這樣，數據的 TTL 和 SLA 就都能分級了。

第三是強保證。在埋點數據下線前，先將要下線的數據分流到 pre-discard Hive 表中暫存 30 天。如果在這段時間里沒有問題，30 天之后就可以直接下線。

現在，該引擎的處理邏輯、拓撲、函數以及 RPC 都可以做到動態化。用戶對于上游而言，一般是寫 SQL 或者進行界面化操作。因為用戶不懂如何處理，我們就需要特定的模型讓用戶進行適配。于是我們用聲明式表達建立統一的邏輯模型讓用戶直接適配。在引擎上我們還能以插件化的形式支持 Flink、Pyjstorm、TCE 等多種運行時平臺，業務方基于視圖表達可以定制化支持業務場景。

Map 計算模型

下面介紹下該引擎的邏輯動態性。我們使用的是簡單的 map 模型。

數據進來后判斷是否是需要的，過濾清洗之后需要的數據進入下游，不需要的數據就丟棄掉。基于 Groovy 語言的熱加載，將語言轉換成可執行的邏輯。

拓撲重構

字節跳動的業務新增速度很快，我們希望新增業務下游后也不需要重啟。對于業務方來說，用戶只關心業務邏輯，運維關心底層穩定性和 Job 執行效率。但是在實際處理中，一個大的困境在數據源。我們以 Kafka 為例，每多一個消費者就多一份網絡消耗和數據反序列化的計算成本，對 Kafka 的壓力就越大。我們應對的方法原理其實很簡單，即基于源數據集來進行重構。

相同 SLA 下的業務線，只要用了相同的 source，就可以把拓撲重構為新的模型。拓撲重構之后，用戶側無感知，SLA 也沒有打破，但是效率確實成倍提升，而且對于上游 Kafka 的壓力小了許多。

實時動態處理引擎整體架構

我們希望這個引擎是一個會變形的引擎。上游用戶可以通過 SQL、圖形化/界面化配置，我們可以根據 schema 產生的 catalog 生成一個通用的自定義邏輯規則。之后用戶還會對邏輯規則進行修改，比如進行校驗或函數重構，我們再會轉換成用戶的物理規則(physical rule)，我們現在是使用 Groovy 進行轉換。轉換成物理規則之后，還有其他一些問題要處理。

首先是動態化，包括：

• UDF 動態化：我們期望 UDF 改變也不用重啟，所以 UDF 需要進行動態化編譯。
• 拓撲重構動態化：重構之后拓撲改變，需要新的拓撲結構。
• RPC 動態化：可以加載動態的函數。

這些配置更新以后，經過 Planbuilder 生成 JobGraph，引擎再拉取配置。

這時也有一個問題：我們的規則非常多，不能因為一條規則的更改就更新所有規則。所以我們做的是增量更新，只對有需要的規則進行更新。

引擎拉取之后，會加載新的資源(RPC、Schema)，并進行拓撲重構以及編譯。因為之前給到的是一些 Groovy 的代碼片段，用戶可以將其熱編譯為物理規則。

此外我們還做了很多細致的工作，例如 Object catch。舉個例子：大部分埋點上報的是 String 格式的 Json 數據，用戶在進行數據清洗時就需要將 String 反序列化為 Json object，如果用戶在規則中多次用到該 Json object 就會導致多次反序列化計算。因此，我們將反序列化后的 object 進行緩存，這樣再次使用時就可以直接使用，避免重復反序列化成本。

Q&A

Q：新增埋點之后不用重啟，那多久會生效，如何保證生效?

A：我們對用戶承諾的 SLA 是 2 分鐘生效。因為實時動態引擎是動態獲取數據的過程，可以更高頻地感知變化。在變化完成之后，我們是增量修改，修改的頻率也更低。

如何能保證新增埋點生效?前面提到了重視 SLA。SLA 不一樣，資源的利用率也就不一樣。此外埋點也不可能無限加，當資源利用率達到一定的閾值之后，就需要擴容。資源不足的問題沒有辦法解決，只能重啟。

Q：資源是先申請到位再重啟嗎?

A：在我們這邊是的，資源申請到位后才會進行對應的重啟。同時我們的開發套件會進行增量重啟，也就是不會一次把所有服務節點全部重啟，一次只會對有問題的部分(比如 10% 的服務節點)進行重啟，把限度降到最低。但是在大數據量下，重啟執行的運維成本依然很高。

Q：平臺上的埋點開發代碼模版可以復用嗎?

A：一般不會復用。不同語言的模版肯定不同，不同產品的工程團隊風格要求也不一樣，也需要定制，所以模版幾乎不會被復用。

Q：埋點的丟失和重復上報的問題是怎么處理的?

A：對于丟失數據的處理分兩個方面：

端上日志：上報數據失敗后會進行重試，并且端上有監控，可以了解當前客戶端上報的情況。

服務端的丟失，我們也有對應的監控，這時候丟失有幾種情況：

• 臟數據：沒有通過判斷校驗邏輯的數據不會直接丟棄，而是分到一個 dirty 流，可以重新找回。
• 特殊邏輯：比如風控邏輯。

重復上報的問題很少遇到，更多的是重啟之后重新消費 Kafka 的 offset 不是那么精準。但我們的引擎是動態的，不需要重啟，就避免了這個問題。