本文簡單介紹了“抖音集團數據資產管理平臺”全貌，數據資產管理平臺是抖音集團在復雜業務場景中思考的新方向，啟發大家對于元數據以及數據資的全新思考。文章重點展開介紹了“抖音集團大數據血緣的演進和應用”部分，讓大家以更宏觀視角認識血緣，并在如何建設好數據血緣給出建設性的思路。

首先整體介紹下抖音集團的一站式數據資產門戶平臺。在大數據領域，各大公司通常會開展元數據采集以及數據地圖的建設工作，行業內的普遍認知聚焦于“元數據”。而在抖音集團，我們的認知核心在于“數據資產”。其核心點在于，我們發現若要真正服務好用戶，單純依靠原始元數據，難以滿足更精準化的找數需求。因此，我們經過全方位的思考，構建了更具系統化的“管、找、用”數據資產平臺。以下為抖音集團數據資產管理平臺。

我們的資產平臺支持豐富的數據源類型，借助于強大的元數據采集能力，將所有數據源元數據采集至元數據中心，形成統一元數據湖，其中就包括全鏈路血緣。基于采集后的原始元數據，數據 BP 會通過資產管理進行二次上下架、分級分類等管理操作，平臺會借助主動元數據手段（Gartner 提出）等，持豐富資產元數據。我們會建立資產評估體系評估資產的完善度，牽引資產不斷做好。在消費場景上，我們基于數據資產元數據構建搜索、門戶以及推薦等產品化能力，同時結合大模型構建AI搜索，通過多樣化產品矩陣滿足數據資產元數據消費需求。以上是數據資產平臺整體簡單介紹。

一、抖音集團血緣整體介紹

1. 整體概覽

在抖音集團內，對于數據血緣建設的目標是：構建全覆蓋、實時、準確的大數據血緣，基于血緣數據打造全場景血緣應用賦能提效。這里我們的認知是：數據血緣是元數據的核心基礎能力，如果想致力于打造更高效的數據平臺，可提高對于數據血緣的建設重視程度。

2. 建設背景

血緣，即元數據實體之間的關系，也可以簡單理解為大數據任務 ETL 的結構化信息。抖音集團內部數據血緣建設背景，可以分為四個方面：

• 看鏈路：整個大數據是一個超大的數據鏈路，集團內有百萬級別的任務，需要結合血緣看清楚這些業務之間的關系。
• 保質量：生產任務每天都在線上迭代，每天有萬級別的線上任務變更，該如何評估好這些迭代對線上是否會產生影響，需要結合血緣鏈路去評估，以保障整個生產的質量。
• 保安全：安全是企業數據數據的生命線，如何高效發現企業中的敏感數據，需要依賴血緣數據傳播能力。
• 降成本：超大規模集群規模背后是大量的計算、存儲資源，如何合理利用資源，并精準發現低價值資源，并驅動治理，也需要依賴血緣實現。

因此，建設好大數據血緣對我們來說迫在眉睫。

3. 血緣整體鏈路

那么如何建設好一套大數據血緣呢？

簡化來看大數據鏈路：從埋點到消息隊列（或者上游的業務 DB），構建離線數倉、實時數倉，數倉加工完后寫入到高速存儲，提供線上服務或者產品化能力。基于大數據鏈路，我們需覆蓋血緣包括以下三類。粒度上覆蓋表級血緣和字段級血緣，其中字段級我們更多提細粒度字段級血緣，包括行級血緣和算子血緣。

• 數據源或數據采集的血緣：埋點血緣
• 數據生產鏈路的血緣：實時數倉血緣、離線數倉血緣
• 應用端的血緣：服務/產品應用的血緣

4. 血緣模型抽象

在建設血緣時，該如何抽象模型呢？

前面介紹到，血緣可以簡單理解為關系，那是否把血緣抽象為點和邊就能解決血緣的問題呢？如上圖示例，表 tb 包含兩列，列都來自于表 ta，ta 和 tb 通過任務產生的關系，同時兩個表的列也都產生了關系，這是最直接的模型。另外，會發現是這個任務讓兩個實體產生了關系，所以另外一種模型方式是把任務節點也抽象出來。我們可以通過這兩種模型來表達血緣關系，但實際兩個模型其實存在差異。

第一個模型：表現更新時會非常慢，一旦任務變更，需要去更新所有任務相關實體節點，但讀取會非常高效，因為關系被直接被固化存儲；第二個模型：更新非常快，更新任務時只需更新任務相關的關系，但讀會非常慢，需推導最終血緣關系。

基于該案例推演，我們設計了更泛化的血緣模型，在模型中抽象三類實體。第一個 DataStore 實體，與通常的 Hive Table 對應；第二個抽象是 Column，由于實體和實體之間存在從屬的關系，所以再往下抽象一層即 column，column 可以從屬于 DataStore；第三個抽象是 Process，實體與實體通過 task 產生關系，所以抽象出 Process 來表達 task。

通過三類實體產生六類關系：實體和實體的關系（如表和表的血緣關系），列與列的關系（即字段血緣），任務和任務之間的關系等。通過實踐驗證，該模型能夠覆蓋到所有血緣關系，在實際存儲過程中又考慮到以上兩個特點，我們存儲了兩類模型，寫入時使用第二個模型，查詢時使用第一個模型，從而滿足大數據場景下高效的存儲和讀取。

5. 血緣衡量指標

我們定義了“血緣質量分”指標來衡量血緣質量，包括三個一級指標，加權后為血緣質量分。抖音集團內部當前血緣質量分處于較好水平，但仍然也需要持續提升。

• 血緣覆蓋率：考慮任務成功解析的數量，覆蓋多少任務；
• 血緣準確率：成功解析并不代表完全正確，會在覆蓋基礎上近一步排除異常解析的情況。
• 血緣完整率：成功解析也不一定完整，最終通過完整率來看清楚血緣是否完全覆蓋。

6. 血緣整體生態體系

血緣數據重點依賴依賴上游生產任務邏輯或者日志，通過多種接入模式采集，然后通過血緣處理（其中重點是解析）形成統一血緣數據。對外提供血緣分析服務以及血緣應用，包括血緣圖譜、口徑探查、血緣分析以及基于血緣的各種工具箱，幫助用戶方便快捷地使用血緣。借助于血緣開放生態，希望人人能夠貢獻血緣，人人能夠用好血緣。

整套血緣體系有幾個特點：覆蓋全鏈路、精細化血緣、準確度非常高、應用場景廣泛。

二、抖音集團血緣系統架構

1. 血緣系統建設挑戰

血緣系統建設主要面臨如下一些挑戰：

• 首先，如何精準化解析細粒度血緣；
• 其次，如何覆蓋非結構化數據源，比如實時鏈路中會有 Redis、Kafka 等；
• 然后，如何覆蓋跨 region 的機房血緣；
• 最后，如何覆蓋調用較大的應用端調用血緣。

2. 血緣系統解決方案架構

基于以上四個挑戰，我們設計了整套血緣架構。

• 數據源：覆蓋各種上游數據源的有價值信息，包括任務代碼、配置信息、離線表以及人工補錄的數據。
• 采集：元數據鏈路和血緣鏈路，元數據鏈路重點關注元信息采集到元數據的體系里面；血緣鏈路，重點結合解析服務和 Catalog，提取血緣數據；
• 存儲：通過圖庫存儲血緣數據，開源圖庫有JanusGraph、Neo4j、NebulaGraph 等。離線鏈路通過圖庫 Dump 任務到 hdfs，并構建數倉；
• 分析：通過實時數據和離線數據，以通用的血緣分析服務，支持實時以及離線的分析場景。

3. 統一解析服務

Java 體系中有兩個比較出名的解析器：Antlr 和 Calcite。Antlr 是一個詞法和語法解析器，能夠方便地幫我們解析各種各樣語言，變成抽象語法樹。Calcite 對 SQL 領域適配較好，SQL 方面定義了 RelNode，和對 SQL 相關的優化規則。

解析是血緣領域非常核心的組件，需要關注支持多種方言，因為生產任務是多樣化的，有實時、離線、OLAP、非結構化數據以及更復雜的任務腳本。

這里我們提出的比較理想解析方案是：基于 Antlr+Calcite 的統一解析器，既能覆蓋多方言，又能處理復雜腳本，充分利用兩個解析器的優勢。我們只要定義詞法文件和語法文件，通過 Antlr 生成語法樹，然后把語法樹通過 SQLNode 轉換器轉換為 Calcite 的 SQLNode，在 SQLNode 和 RelNode 中提取出血緣信息。

4. 血緣接入服務 -生產血緣

上圖中是數據生產血緣示例，一張商品表寫到下游的一張表。解析器將任務邏輯解析，獲取到表與表的依賴關系，比如商品的 detail 表依賴商品表，商品 detail 表里商品的 number 依賴下面表的商品 number。我們會存儲幾個關鍵的信息，字段與字段的裁剪掉代碼片段，還會將計算算子存儲下來，比如先做 aggregate -> select -> where,存到字段的血緣里面，這就是算子級別血緣。

對于 no schema 的任務，需要去查詢 catalog 構建血緣信息，catalog 中已提前管理 MQ/Redis 的 meta 信息。對于算子血緣，希望能夠盡量全的存儲計算信息，會在一些場景使用。

5. 血緣接入服務 -跨 Region 血緣

在集團內部有很多 region，region 之間的數據可能會涉及到一些關聯計算，因此需要跨 region 血緣去處理。例如 A、B、C 三個區域的血緣，我們會先在本區域獲取 local 血緣，然后發到總線上去構建跨 region 血緣。如果某個區域是一個 global 表，我們會借助某個區域訪問 catalog，將 global 表展開到具體 region。

6. 血緣接入服務 -應用血緣

應用端血緣在業界并不常見，是抖音集團血緣的一大特色。我們有非常多的應用端服務和產品，因此希望能夠覆蓋端到端的血緣關系，實現真正的全鏈路血緣。所以，我們構建了應用端的血緣。

應用產品大體可以分成兩類，第一類就是搭建類，可以通過低代碼平臺去搭建應用產品，第二類就是定制開發的一些應用產品。這兩類都會通過 HTTP 或者 RPC，去調用后端服務。后端服務會調用大數據 oservice（統一數據服務），one service 服務會調用到物理表。另外一種可能是服務會直接調用物理表。

應用產品頁面跟后端服務的血緣關系打通幾個方案：對于搭建類的產品，借助于低代碼的 meta 信息去構建血緣；通過 spider 爬取頁面信息，通過頁面信息提取出頁面和接口的信息；通過 trace 日志，基于一套日志規范，讓業務去按照規范打日志，血緣系統中提取日志獲取血緣數據。

服務和服務之間的血緣，主要依賴 trace 日志去構建血緣關系。服務和 one service，基于 one service 元信息構建血緣關系。

應用血緣采集過程中面臨的關鍵問題：埋點日志量可能會非常大，我們采取日志聚合或采樣來縮小量級；埋點日志不準確，業務方把關系打在日志中，我們稱之為染色。

三、抖音集團血緣應用場景

以上介紹了數據血緣系統的建設思路，接下來介紹血緣在內部具體的應用場景。

1. 血緣應用整體介紹

我們希望能夠發揮數據血緣在數據全鏈路的價值，助力公司降本提效。這里列舉了四大應用場景，分別為數據開發、數據治理、數據資產和數據安全，其中一些已經覆蓋，還有一些正在建設中。接下來將詳細介紹各個場景的應用。

2. 數據開發場景的應用

數據開發場景中的應用主要包括：

• 數據變更影響面評估：提供全鏈路任務、表、列的血緣關系查詢、篩選和展示，支持切換 select 血緣及 non-select 血緣，幫助用戶看清數據之間的關系。
• 快速查看字段或者指標加工口徑：通過血緣能力計算數據開發鏈路，并根據指定字段進行代碼裁剪， 只展示該字段相關邏輯，大幅減少無關代碼，提高閱讀效率。
• 實時開發任務提效：基于指定任務，使用血緣能力為下游任務鏈路創建影子鏈路，提供測試鏈路數據預覽功能及線上數據比對功能，預覽最終產品的變動。
• 精準選擇待回溯鏈路：基于列級別的回溯范圍計算，同時支持用戶指定首尾節點、根據特征進行二次篩選等，提升回溯的整體效率和準確性。
• 上游數據變化及時感知：監聽元數據埋點變更，根據血緣關系判斷影響范圍，并實時發送通知，幫助開發人員及時感知上游變更。
• 數據模型重構高校切換：基于用戶配置好待切換模型后，根據血緣計算出待切換任務列表，自動生成切換代碼，自動完成數據比對。

3. 數據治理場景的應用

下面重點看數據治理鏈路應用，數據治理的核心目標是質量、成本、安全。

• 低價值/風險資產識別：通過血緣發現耗費大量資源、下游使用很少的，低 ROI 的資產，以及一些高風險資產。
• 成本計算：基于鏈路級別血緣計算全鏈路成本。
• 及時性保障：構建鏈路級別的時效性保障能力。
• 準確性保障：檢測高風險、高優先級價值的資產質量是否符合預期，是否存在風險。
• 安全保障：高效發現高密數據，檢測安全風險。

對于及時性保障場景。通常大家做及時性保障，可能會做單點保障，比如監控某個任務的完成時間。我們可以充分利用血緣傳播能力，當我們發現 6 這個任務是一個非常核心任務時，我們可以優先級傳播到整個鏈路，進而可以提升鏈路優先級。當要求任務 6 需要 6 點完成，在任務 1 執行時可以預判，任務 6 在 6 點完成是否有風險，進而實現鏈路預測告警。另外，還可以做跨部門 SLA 簽署，比如要保某個任務，需要上游一起保障，就可以通過血緣發現相關資產，然后聯合相關部門簽署 SA，從而保障整個資產及時性。

對于成本計算場景。在大數據鏈路里面，我們希望看到每個節點實際的資源成本消耗。例如任務 6 本身消耗資源并不大，但是為了計算 6，需要 12345 這五個任務來輔助計算，那這 5 個任務的成本也要算在 6 的成本上，這時就可以基于血緣關系將成本分攤下去。計算成本是為了能夠看清楚資產的計算成本，同時也可以用于評估資產的 ROI，結合治理規則，找到低 ROI 的資產做治理。

四、未來展望

最后簡單介紹一下對未來的設想。

1. 數據血緣未來規劃

對于血緣的未來規劃：全覆蓋 和 血緣價值。

首先，會將血緣能力做得更加標準化，簡化血緣的理解和接入；其次，基于標準化，做更高維度的能力開放，讓人人都可以貢獻血緣；最后，進一步構建更細顆粒的精細化的血緣，比如行級血緣。

近一步挖掘數據血緣在質量、效率、安全方面的價值。

2. 數據資產平臺未來展望

火山引擎數智平臺 VeDI 旗下 DataLeap 一直致力于打造一套領先的數據資產全鏈路能力，解決數據資產“管、找、用”的問題，未來期望在集團內部產生更大價值。

我們會構建更完善的元數據，行業里面有主動元數據、大模型等新的理念，結合算法能力挖掘更多元數據，形成統一的元數據知識圖譜。持續借助平臺能力把數據用好，例如數據資產門戶。我們還會基于元數據構建豐富的應用，幫助用戶用好這些元數據。

同時也通過火山引擎在 ToB 市場持續輸出到行業，能夠幫助到有需要的公司，為行業大數據賦能。