導讀：隨著業務的發展，業務上報的埋點數據會越來越多，雜亂的埋點數據不僅會消耗計算和存儲成本，造成巨大的成本浪費，也無法有效的應用于業務，給業務帶去數據價值，因此埋點數據的治理就很有必要。

今天分享的主題是在字節跳動應用的埋點成本治理實踐，本次分享從如下幾個方面來介紹：

• 治理背景
• 治理策略
• 治理經驗回顧
• 規劃與展望

一、治理背景?

埋點數據是用戶在使用產品過程中產生的一系列行為日志，比如用戶使用抖音過程中點擊、滑動等操作。對了解用戶、優化業務來說，用戶行為日志是非常重要的數據來源。

在字節的數據處理鏈路中：

第一，埋點從各端的 SDK 上報數據到日志采集服務。

第二，日志采集服務則將收集到的埋點數據統一匯集到實時的 topic 中。

第三，在實時 topic 中進行統一實時 ETL 處理，包括數據清洗、數據分發、標準化等。數據在進行處理之后會分發到各個下游應用，包括實時消費、離線數倉、UBA（即用戶行為分析）、推薦系統、A/B 測試等。

埋點在字節跳動廣泛應用，因此數據規模也非常龐大，峰值流量達到1億+/秒，增量數據達到10萬億/天。為處理這些數據，HDFS的存儲增量達到10+PB/天。

龐大的數據量會給日常運維造成很多問題，如機器資源問題、成本問題、運維問題、SLA 保障問題。

• 以機器資源問題為例。去年，團隊遇到了 HDFS 無法及時交付的情況，埋點數據治理機制及時刪除了無用埋點和低優埋點。如果當時沒有這套機制，全部數據產出可能受到影響。
• 以運維問題為例。日常運維中最常遇到的 case 就是異常數據上報導致流量的突增。在有埋點治理機制的情況下，我們可以及時處理異常流量，否則束手無策。

埋點治理的核心思想是把有限資源投入到有效數據上報中，而不是浪費在無效的數據上報上。

字節的埋點治理機制在公司內取得的效果與收益也是比較大的：

• 目前埋點治理已經應用到抖音、頭條等多個業務，并且可以覆蓋內部 85% 的業務線。
• 通過無用埋點下線機制，2021 年節省了近億元的成本。
• 通過埋點分級機制，節省了 100+ PB 的 HDFS 存儲。
• 通過埋點采樣機制，2022 年截止目前已經節省了 3000 萬+的成本。

接下來會進一步推廣埋點治理機制，節省更多成本。

二、治理策略

在從 0 到 1 建設埋點成本治理的過程中，我們針對各種不同的場景采取不同的策略。

1、 先控增量，再治存量

如果在業務發展過程中引入的治理，那么首先面臨的問題是，業務側既有存量埋點數據上報，同時也在不斷設計和增加新的埋點數據上報。

假設要治理的數據是一個大水池（且進水口在不斷的往里進水），目標是凈化大水池，則需要先在進水口加裝凈化器，避免邊治理邊污染。

該道理應用于埋點治理，則需要先把新增埋點控制起來，再逐步治理存量數據。

?為了控制新增，我們增加埋點上報管控的機制。在過去，業務上報埋點是自由的；增加了埋點上報管控后，則需要先將上報信息登記到“允許上報”列表中，只有該列表中的埋點才能夠正常上報。

為了讓上報管控機制生效， 我們在數據鏈路中的 SDK 上報、實時 ETL 兩個環節分別增加了對應的處理。這兩個環節可以形成互補作用：?

• 在 SDK 側實現上報管控，讓管控生效時機更加接近源頭，節省更多網絡帶寬和計算資源。
• 依賴 SDK 側進行管控存在一定限制因素：需要業務將SDK升級到“支持上報管控”的版本。
• 如果要推動全產品線升級 SDK，耗時較長，也很難避免一些老舊版本遲遲無法升級。
• 通過實時 ETL 進行上報管控處理，則可以很好彌補這一缺陷：它可以管控所有的上下游， 也能快速推廣到全產品線。

目前這一套機制，已經在在字節 1 億+/秒流量及 50+萬條元數據情況下正常運轉。

為了讓業務能動態地維護和管理“允許上報”列表，我們提供了平臺化的功能：業務在字節內部可以通過流量平臺 ByteIO 做埋點的錄入、登記、狀態管理。

上報管控的機制可以實現直接管控流量上報，這也是后續開展治理的基礎。

2、降低無用埋點上報

控制好新增的埋點數據以后，接下來要對存量的數據進行治理。存量數據治理里廣泛存在的現象是：某些埋點已經不再使用了，但它仍在持續上報，造成資源的浪費。針對這種情況，我們希望提供給業務一項能力：將無用埋點篩選出來，將其從“允許上報”的列表中移除出去，不再上報。

為了定義無用埋點，我們會分析對比各個埋點的價值、成本，如果某個埋點的成本很高，而價值很低，那么它就是需要優先被治理的。

① 埋點的成本直接與上報量相關：如果埋點的上報量越高，對它投入的計算和存儲成本就越高。

② 埋點的價值則從三個維度進行分析：

• 離線查詢，例如在 Hive 表中是否用到這個埋點；
• 實時分流，例如這個埋點是否通過特定的實時分流規則，分流到了其他的 topic 中進行消費；
• 是否有UBA的查詢。

如果在這三個維度上某個埋點的使用非常少，那么我們認為它的價值就是略低的。

為了降低無用埋點的上報，我們支持業務通過 ByteIO 平臺篩選無用埋點，并且發起治理；最終確認下線的埋點將不再允許上報。

通過無用埋點下線這一機制，在 2021 年節省了近億元成本。

3、按重要性區分埋點等級

無用埋點治理下線之后，留下的埋點業務仍需使用，但它們的重要性不同。比如核心指標要用到的埋點數據和 RD 排查問題要用到的埋點數據，在重要性和優先級上有明顯區別，因此在 TTL 和 SLA 上要求是不一樣的。而在過去的設計中，計算資源和存儲資源沒辦法優先向高優的埋點進行傾斜。當計算或存儲資源短缺或遇到問題時，會導致所有數據一起出問題，并沒有哪些埋點數據會優先得到保障。

為了應對這個問題，我們提出了埋點分級的方案，即通過區分埋點的重要性給埋點標注等級，對不同的埋點等級提供不同的運維保障，達到平衡計算資源和存儲資源的目的。

為了讓埋點分級機制生效，首先需要把埋點分級信息發送給實時 ETL，實時 ETL 會根據該元數據信息對收集到的埋點數據增加等級標注，之后數據再整體流向下游。當下游拿到打上等級標注的數據后，會根據等級標注的信息再區分 TTL 和 SLA 的保障。

以下圖數倉中的處理為例，可以看到實時 topic 里的數據已經帶上等級標注信息了（priority 參數），數倉要做的是根據不同的分級結果將 topic 中的數據分發到對應的 dump 目錄，再由不同的任務產出、加載到對應的分區中。

通過這一套埋點分級的處理，我們可以針對優先級不同的埋點數據提供不同的 SLA 和 TTL 保障，同時可以達到平衡計算和存儲資源的目的。以任務為例，P0 的任務可以用高優的隊列、專線的資源，在 dump 產出的時候就進行產出；而 P2 的任務可能就用低優的隊列、混部的資源， 在錯峰的時間產出。通過這樣的方式，計算資源就實現了向 P0 任務傾斜。再以分區為例，P0 分區可能保持更長的 TTL，比如說保存一年以上，而 P2 可能只保存 90 天左右。通過對 P2 分區進行更頻繁的刪除，有限的存儲資源也是向 P0 的分區傾斜的。

業務可以通過 ByteIO 平臺的功能直接對埋點分級信息進行管理。而通過埋點分級這套機制，我們節省了 100+PB 的 HDFS 存儲。

4、支持采樣上報

除了重要性不同外，還有一些埋點需要使用、但不需要全量上報。對于這一類埋點，我們提供埋點采樣化的配置，來支持埋點采樣上報。和前邊的上報管控類似，采樣上報也是在 SDK 和實時 ETL 兩個環節生效，在這里就不再額外贅述。

業務可以在 ByteIO 平臺配置埋點是否需要采樣及采樣比例。通過埋點采樣的機制，在 2022 年已經節省了 3000+萬的成本。

三、治理經驗回顧

在推動埋點成本治理的過程中，我們遇到了一些問題：

第一，在業務發展過程中開始的治理，需要先控新增再治存量。

第二，如何推動業務完成治理。我們需要向業務側提供明確的 3W1H：即我為什么要治理（WHY）、我要治理什么（WHAT）、我怎么治理（HOW）以及我什么時候應該去治理（WHEN）。

第三，隨著治理程度的加深，場景和方案需要逐步細化。在“無用埋點下線->埋點分級->采樣上報”的過程中可以體現這一點。

針對問題二，具體分享一些心得。

作為中臺，我們需要向業務側提供明確的 3W1H，而 3W1H 中的治理什么（WHAT）、怎么治理（HOW），從前面的“治理策略”部分可以大致總結出：治理的對象是無用的、不重要的、可采樣的埋點，治理的方式是采用上述的策略和工具。

• 為什么要治理（WHY）：業務存在不合理的資源浪費，并且通過治理可以降低成本。
• 什么時間應該治理（WHEN）：在業務資源浪費超過預期、成本超過預期的時候。

為了證明這一點（WHY&WHEN），我們向業務提供了一組明確的觀測指標。

• 埋點上報總量：平均每天業務會上報多少條數的埋點數據。
• 埋點成本：為了處理這部分數據，對應業務每天會花多少錢。
• 無用埋點占比：在當前的埋點數據上報總量中，無用埋點所占的比例是多少。
• 埋點密度：通過對比計算埋點上報總量與用戶活躍總時長，來衡量業務數據量級的增長與業務規模的增長是否成正比。比如現在產品處在快速增長期，埋點數據上報量大增長則符合預期。但如果用戶活躍總時長一直沒變化，只有上報總量一直在飛速增長，則數據上報存在一定問題。

以上指標為業務判斷是否需要治理的標準。當業務通過上述指標確認需要治理后，則直接串聯使用“治理策略”中的策略和平臺功能，對埋點進行治理，以達到治理優化的目的。

由此，指標監控和治理策略就形成了一個循環。

?在推動治理的過程中也發現，雖然提供了指標，也提供了策略，但業務很難定期的、主動的去觀測相關指標，并發起治理。經過了解后發現這主要和工作模式有關系，如果把依賴業務主動的指標觀測變成由系統自動的監測并發起治理，業務也可以接受。因此我們就逐步建設和推廣了自動治理的機制。

自動治理的主要思想是由系統自動監測指標變化，并且自動篩選可能需要治理的埋點，之后推送給業務，再由各個埋點的負責人來確認對應埋點是否需要治理。

基于這個機制，我們可以逐步邁向治理常態化的目標。

在自動治理機制中，面向不同的業務場景，又分出了兩種模式：監督式和無監督式。?

監督式的自動治理適合規模比較大一點的業務，這類業務有成本上的考慮，對治理的成果也比較關注。所以我們允許業務自定義監測規則，并且可以指派明確的治理監督人監督治理的進度和成果。監督人在這個過程中可以進行一些拉群、催辦、成果 review 等等操作。

監督式治理目前在字節內部主要應用于抖音、頭條等業務，平均每兩個月會進行一次治理，在 2022 年已經節省了 4000 萬元的成本。

無監督式自動治理適合廣泛存在的小業務，這類業務結構較簡單，可以完全托管給系統、使用統一規范進行治理。無監督式自動治理目前在字節內部主要落地應用于一些小的業務，它實現的一個效果是將這部分業務的平均無用埋點占比從 60% 降到了 20%，并且維持在一個比較穩定的狀態。

另外，分享一些在埋點使用情況分析上的思考。

在“治理策略”部分提到，為了讓業務降低無用埋點的上報，我們需要對埋點的使用情況進行分析。其中，UBA 查詢因為可以直接對接特定系統，相對來說比較容易獲取。而離線和實時的使用分析，則需要通過一些分析手段，去獲取對應的使用情況、并進行血緣建設。

在字節的埋點數據使用過程中，離線和實時數據的傳播有一定的相似性。如下圖，其中每一個節點可以認為是一個離線 hive 表或實時 topic，節點之間存在明確的上下游關系。數據從根節點開始，一層層的向下傳遞，最終傳遞到各層級的節點中。除了節點間的傳播外，數據也可以從節點中取出直接進行消費，比如對 hive 表的直接查詢、對 topic 的直接消費等。節點間的傳遞、對節點的直接查詢/消費，構成了整體的數據傳播鏈路。

在這個傳播鏈路中，埋點數據最原始的形式是根節點的一行記錄。假使有一條下圖所示的 ETL，查詢范圍是「app in ('X','Y') and event in ('a','b')」，它就能夠明確的表示出這部分埋點會傳播到該下游節點。這個明確的范圍對埋點使用情況分析以及埋點治理來說是非常重要的信息，所以需要盡可能獲得。

然而實際上并不總有這么理想的 ETL 和節點，更多的是：明確范圍的 ETL 不在第一層，可能在第二層或第三層；或者不是直接出現這么完整的條件，而可能是多層組裝之后才出現，如在第一層 ETL 中指定了 app 限制而第二層 ETL 指定了 event 限制。針對這些復雜多樣的情況，理想的分析結果是：無論這個明確范圍出現在了哪一層的節點、以及它是如何出現的，我們都可以分析出對應信息。

綜上，為了達成完整的使用情況分析，需要達到：能夠解析出各個層級 hive 表和 topic 里包含的埋點，以及各個層級 hive 表和 topic 被查詢消費的埋點。

為了達到上述目標，實施方法里需要包含兩個要素：第一，能夠解析 ETL/查詢/消費里和埋點相關的邏輯；第二，能夠結合 hive 表/topic 的上下游關系，將解析做逐層的傳播，得到最終各個層級的結果。

目前我們初步具備了這一能力，在當前的基礎上接下來會做進一步的細化。

四、規劃與展望

后續，我們將以下三個方向推動治理優化。

第一，打通成本與資源。針對各個業務治理情況，評估結果是否會影響業務后續資源申請。例如某業務的數據治理評分不太樂觀，后續則不再允許業務新增埋點上報，反向推動業務進行主動治理。

第二，根據業務現狀推薦個性化的治理方案。不同的業務有各自獨特的業務特性，數據規模也不一致，導致的結果就是數據表現形式也不一樣。未來希望根據業務的數據表現情況，自動診斷業務當前面臨的最主要問題，基于此為其推薦個性化、高收益的治理方案。

第三，拓展治理范圍。當前的數據治理方案更多著眼于高成本數據的治理，后續會考慮對異常數據、低質量數據進行治理。例如：治理體積過大、流量增長不合理的異常數據，降低日常運維中遇到的問題；治理低質量數據，減少下游數據產出問題，整體提高數據的質量。

以上介紹的埋點成本治理是數據治理的重要組成部分，主要在字節跳動內部應用。

目前，字節跳動也將沉淀的數據治理經驗，通過火山引擎大數據研發治理套件 DataLeap 對外提供服務。作為一站式數據中臺套件，DataLeap 匯集了字節內部多年積累的數據集成、開發、運維、治理、資產、安全等全套數據中臺建設的經驗，助力 ToB 市場客戶提升數據研發治理效率、降低管理成本，歡迎大家來體驗。

五、問答環節

Q1：離線血緣和實時血緣是怎么實現的？血緣準確性是怎么驗證的？

A1：離線血緣和實時血緣實現方面，主要還是上述提到的兩個要素。第一是能夠解析ETL和查詢消費里和埋點相關的邏輯，第二是結合數據傳播鏈路的上下游結構，才能達到逐層傳播。不確定是否有更多想了解的問題，有機會的話可以再深入探討。

血緣準確性驗證方面，目前來說確實有一定難度。比如我想確定一個準確率指標的話，量化視角比較難，更多依賴于人工經驗做判斷。目前我們也沒有特別好的指標，主要也是在依賴人工經驗。

Q2：埋點的成本是如何計算的？

A2：我們的成本體系會將成本分攤到埋點的條數上。目前無論是離線的還是實時的處理，我們都會將投入的相關成本，如 CPU、存儲等資源的消耗折算后，和直接處理的數據量掛鉤，將總體的成本平攤到每條數據上，計算得一個單價。

相關的成本計算即是由數據條數*單價。

Q3：埋點等級治理中，埋點與指標的關系如何建立和維護？

A3：不太確定我是否有準確理解這個問題。如果忽略前半部分埋點等級治理的約束，只看埋點與指標的關系如何建立和維護，可能會更類似于前邊提到的如何做離線和實時血緣分析。比如怎樣把最初的 event 和各個產出的數據做關聯。具體的執行就是先做解析，再做數據傳播鏈路的上下游關聯。

但如果埋點等級治理這部分我有誤解的話，可以再提出，我們再深入探討。