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

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

• 治理背景
• 治理策略
• 治理經(jīng)驗回顧
• 規(guī)劃與展望

一、治理背景?

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

在字節(jié)的數(shù)據(jù)處理鏈路中：

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

第二，日志采集服務則將收集到的埋點數(shù)據(jù)統(tǒng)一匯集到實時的 topic 中。

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

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

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

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

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

字節(jié)的埋點治理機制在公司內(nèi)取得的效果與收益也是比較大的：

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

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

二、治理策略

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

1、 先控增量，再治存量

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

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

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

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

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

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

目前這一套機制，已經(jīng)在在字節(jié) 1 億+/秒流量及 50+萬條元數(shù)據(jù)情況下正常運轉。

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

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

2、降低無用埋點上報

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

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

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

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

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

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

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

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

3、按重要性區(qū)分埋點等級

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

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

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

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

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

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

4、支持采樣上報

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

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

三、治理經(jīng)驗回顧

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

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

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

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

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

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

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

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

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

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

由此，指標監(jiān)控和治理策略就形成了一個循環(huán)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

四、規(guī)劃與展望

后續(xù)，我們將以下三個方向推動治理優(yōu)化。

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

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

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

以上介紹的埋點成本治理是數(shù)據(jù)治理的重要組成部分，主要在字節(jié)跳動內(nèi)部應用。

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

五、問答環(huán)節(jié)

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

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

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

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

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

相關的成本計算即是由數(shù)據(jù)條數(shù)*單價。

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

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

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