導(dǎo)讀：隨著業(yè)務(wù)的發(fā)展，業(yè)務(wù)上報(bào)的埋點(diǎn)數(shù)據(jù)會(huì)越來(lái)越多，雜亂的埋點(diǎn)數(shù)據(jù)不僅會(huì)消耗計(jì)算和存儲(chǔ)成本，造成巨大的成本浪費(fèi)，也無(wú)法有效的應(yīng)用于業(yè)務(wù)，給業(yè)務(wù)帶去數(shù)據(jù)價(jià)值，因此埋點(diǎn)數(shù)據(jù)的治理就很有必要。

今天分享的主題是在字節(jié)跳動(dòng)應(yīng)用的埋點(diǎn)成本治理實(shí)踐，本次分享從如下幾個(gè)方面來(lái)介紹：

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

一、治理背景?

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

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

第一，埋點(diǎn)從各端的 SDK 上報(bào)數(shù)據(jù)到日志采集服務(wù)。

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

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

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

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

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

埋點(diǎn)治理的核心思想是把有限資源投入到有效數(shù)據(jù)上報(bào)中，而不是浪費(fèi)在無(wú)效的數(shù)據(jù)上報(bào)上。

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

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

接下來(lái)會(huì)進(jìn)一步推廣埋點(diǎn)治理機(jī)制，節(jié)省更多成本。

二、治理策略

在從 0 到 1 建設(shè)埋點(diǎn)成本治理的過(guò)程中，我們針對(duì)各種不同的場(chǎng)景采取不同的策略。

1、 先控增量，再治存量

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

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

該道理應(yīng)用于埋點(diǎn)治理，則需要先把新增埋點(diǎn)控制起來(lái)，再逐步治理存量數(shù)據(jù)。

?為了控制新增，我們?cè)黾勇顸c(diǎn)上報(bào)管控的機(jī)制。在過(guò)去，業(yè)務(wù)上報(bào)埋點(diǎn)是自由的；增加了埋點(diǎn)上報(bào)管控后，則需要先將上報(bào)信息登記到“允許上報(bào)”列表中，只有該列表中的埋點(diǎn)才能夠正常上報(bào)。

為了讓上報(bào)管控機(jī)制生效， 我們?cè)跀?shù)據(jù)鏈路中的 SDK 上報(bào)、實(shí)時(shí) ETL 兩個(gè)環(huán)節(jié)分別增加了對(duì)應(yīng)的處理。這兩個(gè)環(huán)節(jié)可以形成互補(bǔ)作用：?

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

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

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

上報(bào)管控的機(jī)制可以實(shí)現(xiàn)直接管控流量上報(bào)，這也是后續(xù)開(kāi)展治理的基礎(chǔ)。

2、降低無(wú)用埋點(diǎn)上報(bào)

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

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

① 埋點(diǎn)的成本直接與上報(bào)量相關(guān)：如果埋點(diǎn)的上報(bào)量越高，對(duì)它投入的計(jì)算和存儲(chǔ)成本就越高。

② 埋點(diǎn)的價(jià)值則從三個(gè)維度進(jìn)行分析：

• 離線查詢(xún)，例如在 Hive 表中是否用到這個(gè)埋點(diǎn)；
• 實(shí)時(shí)分流，例如這個(gè)埋點(diǎn)是否通過(guò)特定的實(shí)時(shí)分流規(guī)則，分流到了其他的 topic 中進(jìn)行消費(fèi)；
• 是否有UBA的查詢(xún)。

如果在這三個(gè)維度上某個(gè)埋點(diǎn)的使用非常少，那么我們認(rèn)為它的價(jià)值就是略低的。

為了降低無(wú)用埋點(diǎn)的上報(bào)，我們支持業(yè)務(wù)通過(guò) ByteIO 平臺(tái)篩選無(wú)用埋點(diǎn)，并且發(fā)起治理；最終確認(rèn)下線的埋點(diǎn)將不再允許上報(bào)。

通過(guò)無(wú)用埋點(diǎn)下線這一機(jī)制，在 2021 年節(jié)省了近億元成本。

3、按重要性區(qū)分埋點(diǎn)等級(jí)

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

為了應(yīng)對(duì)這個(gè)問(wèn)題，我們提出了埋點(diǎn)分級(jí)的方案，即通過(guò)區(qū)分埋點(diǎn)的重要性給埋點(diǎn)標(biāo)注等級(jí)，對(duì)不同的埋點(diǎn)等級(jí)提供不同的運(yùn)維保障，達(dá)到平衡計(jì)算資源和存儲(chǔ)資源的目的。

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

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

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

業(yè)務(wù)可以通過(guò) ByteIO 平臺(tái)的功能直接對(duì)埋點(diǎn)分級(jí)信息進(jìn)行管理。而通過(guò)埋點(diǎn)分級(jí)這套機(jī)制，我們節(jié)省了 100+PB 的 HDFS 存儲(chǔ)。

4、支持采樣上報(bào)

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

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

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

在推動(dòng)埋點(diǎn)成本治理的過(guò)程中，我們遇到了一些問(wèn)題：

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

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

第三，隨著治理程度的加深，場(chǎng)景和方案需要逐步細(xì)化。在“無(wú)用埋點(diǎn)下線->埋點(diǎn)分級(jí)->采樣上報(bào)”的過(guò)程中可以體現(xiàn)這一點(diǎn)。

針對(duì)問(wèn)題二，具體分享一些心得。

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

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

為了證明這一點(diǎn)（WHY&WHEN），我們向業(yè)務(wù)提供了一組明確的觀測(cè)指標(biāo)。

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

以上指標(biāo)為業(yè)務(wù)判斷是否需要治理的標(biāo)準(zhǔn)。當(dāng)業(yè)務(wù)通過(guò)上述指標(biāo)確認(rèn)需要治理后，則直接串聯(lián)使用“治理策略”中的策略和平臺(tái)功能，對(duì)埋點(diǎn)進(jìn)行治理，以達(dá)到治理優(yōu)化的目的。

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

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

自動(dòng)治理的主要思想是由系統(tǒng)自動(dòng)監(jiān)測(cè)指標(biāo)變化，并且自動(dòng)篩選可能需要治理的埋點(diǎn)，之后推送給業(yè)務(wù)，再由各個(gè)埋點(diǎn)的負(fù)責(zé)人來(lái)確認(rèn)對(duì)應(yīng)埋點(diǎn)是否需要治理。

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

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

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

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

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

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

在“治理策略”部分提到，為了讓業(yè)務(wù)降低無(wú)用埋點(diǎn)的上報(bào)，我們需要對(duì)埋點(diǎn)的使用情況進(jìn)行分析。其中，UBA 查詢(xún)因?yàn)榭梢灾苯訉?duì)接特定系統(tǒng)，相對(duì)來(lái)說(shuō)比較容易獲取。而離線和實(shí)時(shí)的使用分析，則需要通過(guò)一些分析手段，去獲取對(duì)應(yīng)的使用情況、并進(jìn)行血緣建設(shè)。

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

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

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

綜上，為了達(dá)成完整的使用情況分析，需要達(dá)到：能夠解析出各個(gè)層級(jí) hive 表和 topic 里包含的埋點(diǎn)，以及各個(gè)層級(jí) hive 表和 topic 被查詢(xún)消費(fèi)的埋點(diǎn)。

為了達(dá)到上述目標(biāo)，實(shí)施方法里需要包含兩個(gè)要素：第一，能夠解析 ETL/查詢(xún)/消費(fèi)里和埋點(diǎn)相關(guān)的邏輯；第二，能夠結(jié)合 hive 表/topic 的上下游關(guān)系，將解析做逐層的傳播，得到最終各個(gè)層級(jí)的結(jié)果。

目前我們初步具備了這一能力，在當(dāng)前的基礎(chǔ)上接下來(lái)會(huì)做進(jìn)一步的細(xì)化。

四、規(guī)劃與展望

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

第一，打通成本與資源。針對(duì)各個(gè)業(yè)務(wù)治理情況，評(píng)估結(jié)果是否會(huì)影響業(yè)務(wù)后續(xù)資源申請(qǐng)。例如某業(yè)務(wù)的數(shù)據(jù)治理評(píng)分不太樂(lè)觀，后續(xù)則不再允許業(yè)務(wù)新增埋點(diǎn)上報(bào)，反向推動(dòng)業(yè)務(wù)進(jìn)行主動(dòng)治理。

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

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

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

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

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

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

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

血緣準(zhǔn)確性驗(yàn)證方面，目前來(lái)說(shuō)確實(shí)有一定難度。比如我想確定一個(gè)準(zhǔn)確率指標(biāo)的話，量化視角比較難，更多依賴(lài)于人工經(jīng)驗(yàn)做判斷。目前我們也沒(méi)有特別好的指標(biāo)，主要也是在依賴(lài)人工經(jīng)驗(yàn)。

Q2：埋點(diǎn)的成本是如何計(jì)算的？

A2：我們的成本體系會(huì)將成本分?jǐn)偟铰顸c(diǎn)的條數(shù)上。目前無(wú)論是離線的還是實(shí)時(shí)的處理，我們都會(huì)將投入的相關(guān)成本，如 CPU、存儲(chǔ)等資源的消耗折算后，和直接處理的數(shù)據(jù)量掛鉤，將總體的成本平攤到每條數(shù)據(jù)上，計(jì)算得一個(gè)單價(jià)。

相關(guān)的成本計(jì)算即是由數(shù)據(jù)條數(shù)*單價(jià)。

Q3：埋點(diǎn)等級(jí)治理中，埋點(diǎn)與指標(biāo)的關(guān)系如何建立和維護(hù)？

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

但如果埋點(diǎn)等級(jí)治理這部分我有誤解的話，可以再提出，我們?cè)偕钊胩接憽?/span>