DataLeap 是火山引擎數智平台 VeDI 旗下的大資料研發治理套件産品，幫助使用者快速完成資料內建、開發、運維、治理、資産、安全等全套資料中台建設，降低工作成本和資料維護成本、挖掘資料價值、為企業決策提供資料支撐。資料血緣是幫助使用者找資料、了解資料以及使資料發揮價值的基礎能力。基于位元組跳動内部沉澱的資料治理經驗，火山引擎 DataLeap 具備完備的資料血緣能力，本文将從資料血緣應用背景、發展概況、架構演講以及未來展望四部分，為大家介紹資料血緣在位元組跳動進化史。
背景介紹
1. 資料血緣是資料資産平台的重要能力之一
在火山引擎 DataLeap 中，資料資産平台主要提供中繼資料搜尋、展示、資産管理以及知識發現能力。在資料資産平台中，資料血緣是幫助使用者找資料、了解資料以及使資料發揮價值的重要基礎能力。
2. 位元組跳動的資料鍊路情況
資料來源
在位元組跳動，資料主要來源于以下兩部分：
埋點資料：
主要來自 APP 端和 Web 端。經過日志采集後，這類資料最終進入到消息隊列中。
業務資料：
該類資料一般以線上形式存儲，如 RDS 等。
中間部分是以 Hive 為代表的離線數倉：
該類資料主要來自消息隊列或者線上存儲，經過資料內建服務把資料導入離線數倉。經過離線數倉的資料加工邏輯，流轉到以 ClickHouse 為代表的 OLAP 引擎。
另外，在消息隊列部分，還會通過 Flink 任務或者其他任務對Topic 分流，是以上圖也展現了一個回指的箭頭。
資料去向
主要以名額系統和報表系統為代表。名額系統包含重要且常用的業務名額，如抖音的日活等。報表系統是把名額以可視化形式展現出來。
資料服務
主要通過 API 提供資料，具體而言，從消息隊列、線上存儲、下遊消費以及上圖右側所示的資料流轉，都涵蓋在資料血緣範圍内。
血緣發展概況
接下來介紹血緣在位元組跳動的三個發展階段。
第一階段：2019 年左右開始
第一階段主要提供資料血緣基礎能力，以 Hive 和 ClickHouse 為代表，支援表級血緣、字段血緣，涉及10+中繼資料。
第二階段：從 2020 年初開始
第二階段引入了任務血緣，同時支援的中繼資料類型進行擴充，達到15+。
第三階段：從 2021 年上半年至今
在這一階段，我們對整個中繼資料系統（即前文提到的資産平台）進行了 GMA 改造，同步對血緣架構進行全面更新，由此支援了更豐富的功能，具體包括：
首先， 中繼資料種類擴充到近 30 種且時效性提升。之前以離線方式更新血緣資料，導緻資料加工邏輯變化的第二天，血緣才會産生變化。目前，基于近實時的更新方式，資料加工邏輯在 1 分鐘内即在血緣中展現。
其次，新增血緣消費方式的變更通知。由于該版本支援實時血緣，業務方産生及時了解血緣變化的需求，變動通知功能就是把血緣變化情況以消息隊列的形式告知業務方。
再次，支援評估血緣品質。新增一條鍊路，專門服務于血緣資料品質。
最後，引入标準化接入方式。為了減少重複工作、降低血緣接入成本，我們制定了詳細的血緣接入标準，業務方資料均以标準化方式接入。
以上就是整體的發展情況，目前處于第三個版本當中。
資料血緣架構的演進
1. 第一版血緣架構：建立血緣基本能力，初探使用場景
血緣架構
- 在資料來源方面，目前血緣主要包括兩個資料來源（見上圖左上角）：
- 第一，資料開發平台： 使用者在開發平台寫任務，并對資料加工，由此産生血緣資料。
- 第二，追蹤資料： 第三方平台（即任務平台）對使用者埋點等資料進行計算，也會産生血緣資訊。
- 在血緣加工任務方面（見上圖中間部分）：
這部分會對任務進行血緣解析，産生血緣快照檔案。由于第一版采用離線方式運作，每天該血緣任務均會生成對應的血緣快照檔案。我們通過對比前後兩天的血緣快照檔案，來擷取血緣的變更情況，然後把這些變更加載到圖中。
除此之外，血緣中涉及的中繼資料會備援一份，并存儲到圖裡。
- 在血緣存儲方面（見上圖右邊部分），除了應用于圖資料庫之外，血緣本身也會依賴中繼資料的存儲，如 Mysql 以及索引類存儲。4. 在血緣消費層面，第一版隻支援通過API 進行消費。
最後總結該版本的三個關鍵點：
- 血緣資料每天以離線方式全量更新。
- 通過對比圖來判斷血緣更新操作，後面将為大家詳細解答為什麼要通過對比的方式。
- 備援一份中繼資料存儲到圖資料庫中。
存儲模型
圖中上半部分為表級血緣，隻包括一種類型節點，即表節點，如說 Hive 表、 ClickHouse 表以及其他表。
圖中下半部分為字段血緣圖，第一版主要是提供建構血緣的基本能力，是以用彼此分離的兩張圖來實作。由于血緣中中繼資料進行了備援，每個圖裡面的每個節點裡面都存儲表相關的中繼資料，包括業務資訊以及其他資訊。
除此之外，我們會預先計算一些統計資訊，儲存到圖的節點中，如目前節點下遊總節點數量、下遊層級數量等。
采用預先計算的目的是為了“用空間換時間”，在産品對外展示的功能上可能要露出資料資訊，如果從圖裡實時查詢可能影響性能，是以采用空間換時間的方式來支援産品的展示。
2. 第二版血緣架構：血緣價值逐漸展現，使用場景拓寬
血緣架構
經過1年的使用，血緣在資料資産中的價值逐漸展現，且不斷有應用場景落地，由此我們進行了第二版本更新。更新點具體包括：
第一，去除第一版本中中繼資料備援。中繼資料備援在圖提升了性能，但是可能導緻 Metadata Store 的中繼資料不一緻，給使用者帶來困擾。
第二，去掉了預計算的統計資訊。随着血緣的資料量增多，預計算的資訊透出不能給很好輔助使用者完成業務判斷，且導緻任務負擔重。比如，即使知道某一節點的下遊資料量，還是要拉出所有節點才能進一步分析或決策。
第三，支援一條全新鍊路，在新增鍊路上，我們把血緣快照檔案導入離線數倉，主要應用于兩個場景：
- 離線分析場景或全量分析場景。
- 基于離線數倉的血緣資料實作資料監控，盡早發現血緣異常情況。
是以，從第二版開始，資料血緣新增了很多離線消費方式。
存儲模型
第二個版本引入了全新血緣存儲模型（如上圖所示），并将第一個版本兩張圖融合成一張圖，解決了無法通過表周遊字段血緣的問題。
除此之外，第二個版本還引入了任務類型節點，服務于以下三種周遊場景：
- 單純周遊資料血緣，即從資料節點到資料節點。
- 資料血緣和任務血緣混合方式。
- 單純任務之間血緣關系。
3. 第三版血緣架構：血緣成為資料發揮價值的重要基礎能力
血緣架構
2021年初，火山引擎DataLeap資料血緣疊代到第三版，也成為公司内部資料發揮價值的重要基礎能力。
服務于業務方對資料高品質要求，第三版更新點如下：
血緣資料來源： 除了支援兩個平台之外，還支援包括報表、第三方使用者畫像等其他平台 。
血緣任務： 之前版本隻支援每天定時運作的離線排程方式，第三版引入實時消費方式，支援實時解析血緣，并提取通用邏輯，複用離線血緣任務和實時血緣任務。
血緣解析：不同類型任務需要使用不同解析邏輯。在之前版本中，Hive SQL 任務和Flink SQL任務的解析邏輯是內建到血緣任務中。從第三版開始，我們把解析服務拆解成可配置的插件，實作了插件化。當某一種任務類型的血緣解析邏輯需要調整的時候，隻用改動其中一個解析服務，其他解析服務不受影響，同時也讓血緣任務更好維護。
中繼資料存儲統一：隻依賴圖資料庫和索引存儲，同時支援從系統中把所有相關的資料導出離線數倉。
實時消費： 血緣發生變更的資訊會被同步到消息隊列。
血緣的驗證子產品：使用方對血緣資料品質有高要求，是以第三版引入新的血緣的驗證子產品。
- 驗證的前提是要有引擎埋點資料，該埋點資料能清楚知道某一個任務具體讀取資料情況、寫入資料情況
- 在離線數倉中，通過埋點資料與血緣資料中對比，生成血緣資料品質報表。
- 資料品質報表對血緣消費者開放，消費者能夠清晰了解每個血緣鍊路準确性和覆寫情況。
- 血緣标準化接入：即讓使用者快速接入資料，不用每一種血緣接入都重複寫邏輯。
存儲模型
第三版血緣存儲模型相對于前兩版的更新點如下：
- 以任務為中心。黃色圓圈為任務節點，資料加工邏輯産生血緣，是以我們把資料加工邏輯抽象為任務節點，血緣的建立則以任務為媒介，任務成為血緣中心。也就是說，表1、表2、表3之間的血緣，是通過任務 a 完成建構。假設沒有任務 a ，則三個表之間的血緣也不存在。
- 表血緣和字段血緣模型統一，在字段血緣之間沒有具體任務的情況下，我們會抽象出虛拟的任務來統一模型。由此，任務和任務之間的血緣采用新的邊來表示依賴關系。
重要特性
增量更新
在實時血緣基礎上，我們還支援增量更新能力，即當某一個任務的加工邏輯發生變化時，隻需要更新圖中一小部分。
血緣建立： 資料加工邏輯上線或開始生效，将被抽象為圖資料庫的操作，即建立一個任務節點和對應的資料節點，并建立兩者之間的邊。上圖例子為表1、表2和任務的邊，以及任務和表3之間的邊。
血緣删除：資料的加工邏輯發生了下線、删除或不生效。**** 先在圖裡面查詢該任務節點，把任務節點以及關聯血緣相關的邊删除。血緣存儲模型以任務為中心，是以表1、表2和表3之間的血緣關系也同步消失，這部分血緣即被删除。
血緣更新：任務本身沒有發生上線或下線，但計算邏輯發生變化。 例如，原本血緣關系是表1、表2生成表3，現在變成了表2、表4生成表3。我們需要做的如下：
- 解析出最新血緣狀态，即表2、表4到表3的血緣關系，與目前血緣狀态做對比（主要對比該任務 a 相關的邊），上圖例子是入邊發生變化，那麼删除其中一條邊，建構另外一條邊，即可完成該任務節點的血緣更新。
- 如果面臨以上血緣關系變化，但是沒有該任務節點，應該執行哪些操作來更新血緣？由于隻有血緣最新狀态和目前狀态，沒有任務節點去擷取最小機關的血緣關系，是以隻能進行全量血緣或全圖對比，才能得出邊的變化情況，再更新到圖資料庫中。如果不進行全量血緣或全圖對比，無法知曉如何删除條和建立條，導緻血緣無法更新。這也是前兩個版本需要進行血緣快照對比的原因。
血緣标準化
在火山引擎DataLeap中，通常把血緣資料接入抽象成一個 ETL 。
首先，血緣資料來源，即第三方平台血緣相關的資料，通常是一個資料加工邏輯或者稱為任務。接着，對這些任務完成 KeyBy 操作，并與資料資産平台的任務資訊做對比，确定如何進行任何建立、删除和更新。
在再完成過濾操作之後， 由Lineage Parser 對建立、更新等任務進行血緣解析，得出血緣結果之後會生成表示圖相關操作的Event，最終通過Sink 把資料寫入到資料資産平台中。
上圖綠色和藍色分别表示：
- 藍色：對不同血緣接入過程的邏輯一緻，可抽象出來并複用。
- 綠色：不同血緣的實作情況不一樣。例如，某一個平台為拉取資料，另外一個平台通過其他方式擷取資料，導緻三個部分不一樣，是以我們抽取特殊部分，複用共同部分。除此之外，我們還提供通用 SDK，串聯整個血緣接入流程，使得接入新的血緣時，隻需要實作綠色元件。
目前，位元組跳動内部業務已經可以使用 SDK 輕松接入血緣。
資料血緣品質-覆寫率
當血緣發展到一定階段，業務方不止關心血緣覆寫情況、支援情況，還關心血緣資料品質情況。是以，第三版本透出血緣品質相關名額——覆寫率和準确率。
覆寫率：血緣覆寫的資料資産數占關注的資産數量占比。
關注的資料資産一般指，有生産任務或有生産行為的資産。上圖虛線圓圈，如 Table 9，使用者建立該表後沒有生産行為，是以也不會産生血緣，在計算中将被剔除掉。上圖實線圓圈，表示有生産行為或有任務讀取，則被認為是關注的資産。關注的資料資産被血緣覆寫的占比，即覆寫率。
以上圖為例，在10張表中，由于有任務與Table 1 ~ 8關聯，是以判定有血緣。Table 10，它與Task-D之間的連線是虛線，表示本來它應該有血緣，但是實際上血緣任務沒把這個血緣關系解析出來，那麼我們就認為這個 Table 10是沒有被血緣覆寫的。整體上被血緣覆寫的資産就是表1 ~ 8。除了Table 9之外，其他的都是關注的資産，那麼血緣覆寫的資産占比就是8/9。也就是圖上藍色的這第8個除以藍色的8個加上 Table 10，就是9個，是以這個覆寫率就是88%。
資料血緣品質-準确率
覆寫血緣不一定是正确的，是以我們還定義了準确率名額，即血緣準确的任務數/同類型的任務數。
舉個例子，假設任務 c 的血緣應該是 Table 5、Table6生成 Table 7，但實際上被遺漏，沒有被解析（虛線表示），導緻任務 c 的血緣不準确。也存在其他情況缺失或多餘情況，導緻血緣不準确。
在上圖中，同類型任務包含4個，即 a、b、c、d。那麼，準确的血緣解析隻有 a、b，是以準确率占比為2/4 = 50%。
在火山引擎DataLeap中，由于血緣來源是任務，是以我們以任務的視角來看待血緣準确率。
血緣品質-位元組現狀
在覆寫率部分，目前 Hive 和 ClickHouse 中繼資料覆寫度較高，分别達到98%、96%。對于實時中繼資料，如Kafka ，相關 Topic 覆寫70%，其他中繼資料則稍低。
在準确率部分，我們區分任務類型做準确性解析。如 DTS 資料內建任務達到99%以上，Hive SQL 任務、 Flink SQL 任務是 97%、81% 左右。
血緣架構對比
上圖為三個版本對比情況：
- 血緣的消費方式：第一版隻支援 API 的方式，使用者需要在資料資産平台上檢視血緣資訊；第二版支援離線數倉，讓使用者可以全量分析血緣；第三版支援消息隊列，使使用者可以擷取血緣增量的變化。
- 增量更新： 第三版開始支援增量更新。
- 血緣任務： 第二個版本開始支援任務血緣，第三個版本支援資料品質。
- 中繼資料存儲統一： 第三版進行了中繼資料架構更新，使得中繼資料和血緣存儲在同一個地方。
- 新血緣接入耗時： 前兩個版本大概需要花費 7-10 天左右。第三版本引入标準化，外部業務方或位元組内部用标準化流程，實作 3、4 天左右完成開發、測試、上線。
未來展望
第一，持續對架構和流程進行精簡。目前，血緣任務分為離線和實時兩部分，但沒有完全統一。在插件化、橫向擴充等方面也需要加強。
第二，生态化支援。目前支援公司内部的中繼資料，未來計劃拓展對開源或外部中繼資料的支援。在血緣标準化方面，提供一站式資料血緣能力，作為基礎能力平台為業務方提供服務。
第三，提升資料品質。除了血緣數量，還需要持續提升品質。同時由于資料鍊路複雜，導緻鍊路問題排查異常困難，未來我們也會支援快速診斷。
最後，支援智能化場景。結合元數倉等資料，提供包含關鍵鍊路梳理在内的智能化能力。目前，當業務方發現資料有問題之後，主要通過按照血緣資料一個一個排查方式解決，導緻效率低下。未來，我們将考慮透出血緣關鍵鍊路，提升排查效率。