數據血緣描述了數據的來源和去向，以及數據在多個處理過程中的轉換。數據血緣是組織內使數據發揮價值的重要基礎能力。本文從字節的數據鏈路概況開始，介紹了數據血緣在字節的應用場景，總體設計，數據模型以及衡量指標。

DataLeap

字節跳動數據鏈路介紹

為了明確問題的討論范圍，我們首先介紹一下字節的數據鏈路。

字節的數據的來源分為兩種：

端數據：APP和Web端通過埋點SDK發送的，經過LogService，最終落入MQ；

業務數據：APP，Web和第三方服務所進行的業務操作，通過各種應用的服務，最終落入RDS，RDS中的數據，經過Binlog的方式，匯入MQ；

MQ中的數據，在MQ之間有分流的過程，做轉換格式，流量拆分等。

離線數倉的核心是Hive，數據通過各種手段最終匯入其中，使用主流的HiveSQL或SparkJob做業務處理，流入下游Clickhouse等其他存儲。

實時數倉的核心是MQ，使用主流的FlinkSQL或通用FlinkJob做處理，期間與各種存儲做SideJoin豐富數據，最終寫入各種存儲。

典型的數據出口有三類：

指標系統：業務屬性強烈的一組數據，比如“抖音日活”

報表系統：以可視化的形式，各種維度展示加工前或加工后的數據

數據服務：以API調用的形式進一步加工和獲取數據

在字節，數據血緣的系統邊界是：從RDS和MQ開始，一路途徑各種計算和存儲，最終匯入指標、報表和數據服務系統。

DataLeap

血緣的應用場景

在討論技術細節之前，需要先講清楚血緣的應用場景與業務價值，進一步明確數據血緣需要解決的問題。不同的應用場景，對于血緣數據的消費方式，血緣的覆蓋范圍，血緣的質量訴求，都會有所差別。

領域	場景舉例	場景描述	場景特點
數據資產	引用熱度計算	資產被頻繁消費和廣泛引用，是對自身權威性的有利佐證，類似網頁引用中的PageRank值，我們根據資產的下游血緣情況，定義了資產定義引用熱度值。熱度高的資產，更值得被信任。	離線方式批量消費血緣數據； 覆蓋范圍越廣越好； 少量錯誤不會造成惡劣影響
	理解數據上下文	在找數據時，通過查看一份數據資產的血緣，來更多的了解它的“前世今生”，可以更好的判定當前資產是不是自己需要的，或者是不是值得信賴的。就像了解一個人，可以從他周圍的朋友中得到很多信息一樣，是對這個人“生平”很好的補充。	實時方式獲取血緣數據； 覆蓋范圍越廣越好； 少量錯誤不會造成惡劣影響
數據開發	影響分析	當處于血緣上游的研發同學修改任務前，通過查看自己的下游，通知對應資產或任務的負責人，進行相應的修改，否則會造成嚴重的生產事故	實時方式獲取血緣數據； 覆蓋范圍越廣越好； 血緣錯誤可能會造成嚴重事故
	歸因分析	當某個任務出現問題時，通過查看血緣上游的任務或資產，排查出造成問題的根因是什么	實時方式獲取血緣數據； 覆蓋范圍越廣越好； 血緣錯誤會影響效率
數據治理	鏈路狀態追蹤	事先挑選已知的核心任務，通過血緣關系，自動化的梳理出其所在的核心鏈路，并做重點的治理與保障	離線方式批量消費血緣數據； 覆蓋核心鏈路； 血緣錯誤可能會造成嚴重事故
	數倉治理	數倉規范化治理，包括但不限于：數倉分層中不合理的逆向引用；數倉分層不合理；冗余的表與鏈路等	離線方式批量消費血緣數據； 覆蓋離線和實時數倉； 少量錯誤不會造成惡劣影響
數據安全	安全合規檢查	資產本身具有安全等級，資產的安全等級不應該低于上游資產的安全等級，否則會有權限泄露風險。基于血緣，通過掃描高安全等級資產的下游，來排除安全合規風險	離線方式批量消費血緣數據； 覆蓋離線和實時數倉； 錯誤可能會造成安全風險
	標簽傳播	首先根據規則自動識別（或人工）部分資產的安全標簽，基于血緣，將標簽自動傳播到下游更廣泛的資產	離線方式批量消費血緣數據； 覆蓋離線和實時數倉； 少量不準確不會造成惡劣影響

DataLeap

數據血緣系統的整體設計

01 - 概覽

通過對字節血緣鏈路和應用場景的討論，可以總結出血緣整體設計時需要考慮的兩個關鍵點：

可擴展性：在字節，業務復雜而龐大，整條數據鏈路中，使用到的各種存儲有幾十種，細分的任務類型也是幾十種，血緣系統需要可以靈活的支持各種存儲和任務類型

開放的集成方式：消費血緣時，有實時查詢的場景，也有離線消費的場景，還有可能下游系統會基于當前數據做擴展

字節數據血緣系統的整體架構可以分為三部分：

任務接入：以某種方式，從任務管理系統中獲取任務信息

血緣解析：通過解析任務中的信息，獲取到血緣數據

數據導出：負責將血緣數據存儲到Data Catalog系統中，并供下游系統消費

02?-?任務接入

有兩個關鍵的設計考慮：

提供兩種可選的鏈路，以應對不同下游系統對于數據實時性的不同要求：

近實時鏈路：任務管理系統將任務的修改的消息寫入MQ，供血緣模塊消費

離線鏈路：血緣模塊周期性的調用任務管理系統的API接口，拉取全量（或增量）任務信息，進行處理

定義統一的Task模型，并通過TaskType來區分不同類型任務，確保后續處理的可擴展性：

不同任務管理系統，可能管理相同類型的任務，比如都支持FlinkSQL類型的任務；同一任務管理系統，有時會支持不同類型的任務，比如同時支持編寫FlinkSQL和HiveSQL

新增任務管理系統或者任務類型，可以添加TaskType

03?- 血緣解析

有兩個關鍵的設計考慮： 定義統一的血緣數據模型LineageInfo 針對不同的TaskType，靈活定制不同的解析實現，也支持不同TaskType可服用的兜底解析策略。比如： SQL類任務：比如HiveSQL與FlinkSQL，會調用SQL類的解析服務 Data Transfer Service（DTS）類：解析任務中的配置，建立源與目標之間的血緣關系 其他類任務：比如一些通用任務會登記依賴和產出，報表類系統的控制面會提供報表來源的庫表信息等

04?- 數據導出

血緣解析所產出的LineageInfo，會首先送入DataCatalog系統，支持三種集成方式： 對于Data Catalog中血緣相關API調用，實時拉取需要的血緣數據 消費MQ中的血緣修改增量消息，以近實時能力構造其他周邊系統 消費數倉中的離線血緣導出數據，做分析梳理等業務

DataLeap

血緣的數據模型

血緣數據模型的定義，是確保系統可擴展性和方便下游消費集成的關鍵設計之一。

01 -概覽

我們以圖的數據模型來建模整套血緣系統。圖中包含兩類節點和兩類邊：

數據節點：對于存儲數據的介質的抽象，比如一張Hive表，或者是Hive表的一列

任務節點：對于任務（或鏈路）的抽象，比如一個HiveSQL腳本

從數據節點指向任務節點的邊：代表一種消費關系，任務讀取了這個數據節點的數據

從任務節點指向數據節點的邊：代表一種生產關系，任務生產了這個數據節點的數據

將任務節點和數據節點統一到一張圖上的2點優勢：

將血緣的生命周期與任務的生命周期統一，通過更新任務關聯的邊來更新血緣關系

可以靈活的支持從任務切入和從數據節點切入的不同場景。比如數據資產領域從數據節點切入的居多，而數據開發領域從任務切入的場景居多，不同的應用場景可以在一張大圖上靈活遍歷

02?- 字段（Column）級血緣

字段血緣是血緣模型中的邊界情況，單獨拿出來簡單討論。在實現時，有兩種可供選擇的思路：

方案	優勢	劣勢	備注
1：復用任務節點，為字段之間的關系添加特殊定義的邊	直觀上更容易理解	邊類型數量可能爆炸，寫入與遍歷復雜	上下游的Column之間映射關系多時，劣勢明顯
2：在字段之間添加冗余的任務節點，復用邊的語義	統一了數據模型與遍歷過程。	冗余了任務節點	通常字段之間的任務節點沒有實際意義，如果想知道由什么任務引入的關聯關系，可以多查詢一次虛擬節點與任務節點之間的邊。

我們最終采用了第2種方案。

DataLeap

血緣衡量指標

實際推廣血緣時，最常被用戶問到的問題就是，血緣質量怎么樣，他們的場景能不能用。面對這種靈魂拷問，每個用戶都單獨評估一遍的開銷過大，所以我們花了很多精力討論探索出了最常用的三個技術指標，以佐證血緣質量。用戶可以根據這些指標，判斷自己的場景是否適用。

01 - 準確率

定義：假設一個任務實際的輸入和產出與血緣中該任務的上游和下游相符，既不缺失也不多余，則認為這個任務的血緣是準確的，血緣準確的任務占全量任務的比例即為血緣準確率。

準確率是用戶最關注的指標，像數據開發的影響分析場景，血緣的缺失有可能會造成重要任務沒有被通知，造成線上事故。

不同類型的任務，血緣解析的邏輯不同，計算準確率的邏輯也有區別：

SQL類任務：比如HiveSQL和FlinkSQL任務，血緣來源于SQL的解析，當SQL解析服務給出的質量保證是，成功解析的SQL任務，產生的血緣關系就一定是準確的，那么這類任務的血緣準確率，就可以轉化成SQL解析的成功率。

數據集成（DTS）類任務：比如MySQL->Hive這類通道任務，血緣來源于對用戶登記上下游映射關系的配置，這類血緣的準確率，可以轉化成對于任務配置解析的成功率。

腳本類任務：比如shell，python任務等，這些血緣來源于用戶登記的任務產出，這類血緣的準確率，可以轉化成登記產出中正確的比例。

注意一個問題，上面所講的準確率計算，轉化的時候都有一個前提假設，是程序按照我們假定的方式運行，實際情況并不一定總是這樣。其實這件事情沒必要特別糾結，血緣就像我們在運行的其他程序一樣，都可能因程序bug，環境配置，邊界輸入等，產生不符合預期的結果。

作為準確率的補充，我們在實踐中通過三種途徑，盡早發現有問題的血緣：

人工校驗：通過構造測試用例來驗證其他系統一樣，血緣的準確性問題也可以通過構造用例來驗證。實際操作時，我們會從線上運行的任務中采樣出一部分，人工校驗解析結果是否正確，有必要的時候，會mock掉輸出，持續運行校驗。

埋點數據驗證：字節中的部分存儲會產生訪問埋點數據，通過清洗這些埋點數據，可以分析出部分場景的血緣鏈路，以此來校驗程序中血緣產出的正確性。比如，HDFS的埋點數據可以用來校驗很多Hive相關鏈路的血緣產出。

用戶反饋：全量血緣集合的準確性驗證是個浩瀚的過程，但是具體到某個用戶的某個業務場景，問題就簡化多了。實際操作中，我們會與一些業務方深入的合作，一起校驗血緣準確性，并修復問題。

02?- 覆蓋率

定義：當至少有一條血緣鏈路與資產相關時，稱為資產被血緣覆蓋到了。被血緣覆蓋到的資產占關注資產的比例即為血緣覆蓋率。

血緣覆蓋率是比較粗粒度的指標。作為準確率的補充，用戶通過覆蓋率可以知道當前已經支持的資產類型和任務類型，以及每種覆蓋的范圍。

在內部，我們定義覆蓋率指標的目的有兩個，一是圈定出我們比較關注的資產集合，二是尋找系統中缺失的整塊的任務類型。

以Hive表為例，字節生產環境的Hive表已經達到了幾十萬級別，其中有很大一部分，是不會被長期使用與關注的。計算血緣覆蓋率時，我們會根據規則圈選出其中的部分，比如，過去7天有數據寫入的，作為分母，在這之上，看血緣覆蓋率是多少。

當血緣覆蓋率低時，通常說明我們漏掉了某種任務類型或者圈選的資產范圍不合理。舉個例子，在初期時，我們發現MQ的血緣覆蓋率只有個位數，分析后發現，我們漏掉了以另外一種格式定義的流式數據集成任務。

03?- 時效性

定義：從任務發生修改，到最終反應到血緣存儲系統的端到端延時。

對于一些用戶場景來說，血緣的時效性并沒有特別重要，屬于加分項，但是有一些場景是強依賴。不同任務類型的時效性會有差異。

數據開發領域的影響分析場景，是對血緣實時性要求很高的場景之一。用戶在圈定修改的影響范圍時，如果只能拉取到昨天為止的狀態，是會產生嚴重業務事故的。

提升時效性的瓶頸，通常不在血緣服務方，而是任務管理系統是否可以近實時的將任務相關的修改，以通知形式發送出來。

DataLeap

未來

文中闡述的部分數據血緣技術已經通過大數據研發治理套件DataLeap（回復數字“2”了解產品信息）對外開放。

接下來，字節跳動數據平臺在數據血緣方面的工作，會主要集中在三個方向：

首先，是持續提升血緣的準確性。當前我們的血緣準確性已經提升到了可用的狀態，但是依然需要人工的校驗與修復。如何持續穩定的提升準確性，是探索的重要方向。

其次，是血緣的標準化建設。除了數據血緣之外，應用級別的血緣其實也很重要，在解決方案上，我們希望做到通用與標準。當前業務方會基于數據血緣拼接一些自己業務領域的鏈路，完成標準化后，這部分用例可以復用整套基礎設施，定制產品層面的展現就好了。

最后，是加強對外部生態的支持。細分下來有兩個方向，一是探索通用的SQL類血緣解析引擎，當前，新接入一種SQL類的引擎血緣，成本是比較高的；二是支持開源或公有云上產品的端到端血緣。