DataLeap是火山引擎數(shù)智平臺VeDI旗下的大數(shù)據(jù)研發(fā)治理套件產(chǎn)品，幫助用戶快速完成數(shù)據(jù)集成、開發(fā)、運維、治理、資產(chǎn)、安全等全套數(shù)據(jù)中臺建設，降低工作成本和數(shù)據(jù)維護成本、挖掘數(shù)據(jù)價值、為企業(yè)決策提供數(shù)據(jù)支撐。

數(shù)據(jù)血緣是幫助用戶找數(shù)據(jù)、理解數(shù)據(jù)以及使數(shù)據(jù)發(fā)揮價值的基礎能力。本文將聚焦數(shù)據(jù)血緣存儲和血緣導出，分享在存儲和導出數(shù)據(jù)血緣的模型設計以及優(yōu)化，并介紹字節(jié)跳動在數(shù)據(jù)血緣建設過程中所遇到的挑戰(zhàn)和技術(shù)實現(xiàn)以及數(shù)據(jù)血緣的具體用例，具體包括數(shù)據(jù)血緣模型、數(shù)據(jù)血緣優(yōu)化、數(shù)據(jù)血緣用例、未來展望四個部分。本文介紹的數(shù)據(jù)血緣能力和實踐，目前大部分已通過火山引擎DataLeap對外提供服務。

一、數(shù)據(jù)血緣模型

1、數(shù)據(jù)血緣模型 – 挑戰(zhàn)

首先介紹一下字節(jié)內(nèi)部數(shù)據(jù)血緣遇到的挑戰(zhàn)。

隨著公司業(yè)務擴張、用戶數(shù)量持續(xù)增長以及數(shù)倉建設不斷完善，元數(shù)據(jù)種類和數(shù)量也經(jīng)歷了非線性增長，并在此期間涌現(xiàn)出一些問題。

第一，擴展性。好的擴展性可以在面對新型元數(shù)據(jù)血緣時保證快速接入和迭代，而擴展性不佳則會導致在業(yè)務變化時需要不停地重構(gòu)來適應業(yè)務，對業(yè)務造成很多影響。

第二，性能。一個模型本身的插入和更新效率會直接影響數(shù)據(jù)的導入導出的流程，這些都會帶來更直觀的業(yè)務上的感受，所以需要考慮如何保證環(huán)節(jié)高效性。

第三，時效性。很多應用場景對正確率格外敏感，如果血緣數(shù)據(jù)有延遲，其實就等于血緣的不準確，會對業(yè)務造成影響。

最后，賦能業(yè)務。技術(shù)服務于業(yè)務，業(yè)務增長會幫助技術(shù)升級迭代，技術(shù)創(chuàng)新也會促進業(yè)務發(fā)展。在字節(jié)內(nèi)部，我們會根據(jù)業(yè)務特點，考慮業(yè)務需要，將技術(shù)成本與業(yè)務收益做平衡，最終做出數(shù)據(jù)模型決策?？偠灾?，數(shù)據(jù)模型沒有完美的方案，只有最適合企業(yè)自身業(yè)務、適合當前階段的數(shù)據(jù)血緣方案。

2、 數(shù)據(jù)血緣模型 – 展示層

字節(jié)內(nèi)部有很多種元數(shù)據(jù)類型，包括線上傳統(tǒng)的離線數(shù)倉Hive、OLAP分析引擎ClickHouse，以及實時側(cè)元數(shù)據(jù)，如Kafka和ES以及Redis。這些元數(shù)據(jù)所對應的表/Topic都統(tǒng)一維護在元數(shù)據(jù)平臺上，目前血緣展示層是以這些數(shù)據(jù)資產(chǎn)作為主視角。

如下圖所示，中心數(shù)據(jù)資產(chǎn)包含普通字段和分區(qū)字段等信息，還可以從圖中看到中心資產(chǎn)上下游資產(chǎn)信息，上游有哪些相關(guān)的表，下游有哪些相關(guān)的topic或者表。圖中資產(chǎn)和資產(chǎn)之間連接的邊，代表的是生產(chǎn)關(guān)系：1個任務讀取了上游的資產(chǎn)，產(chǎn)生了下游的資產(chǎn)。

3、數(shù)據(jù)血緣模型 – 抽象層

再來介紹，火山引擎DataLeap如何設計抽象層。

抽象層是整個數(shù)據(jù)血緣的數(shù)據(jù)模型，主要包含兩種節(jié)點，一種是資產(chǎn)節(jié)點，另外一種是任務節(jié)點。

在圖中，資產(chǎn)節(jié)點用圓形表示，任務節(jié)點用菱形表示。具體舉個例子：

（1）一個 FlinkSQL 任務消費了 Kafka 的 topic，然后寫入到一個 Hive 的表里，那么 Kafka 的 topic 和 hive 表就是表資產(chǎn)節(jié)點，而 FlinkSQL 消費任務就是中間的任務節(jié)點。

（2）一個 Kafka 的 topic 里面可能會定義自己的 schema，包括多個字段，例如schema里包含字段 a、b、c，通過 FlinkSQL 任務，比如一個 SQL：insert into hiveTable select a，b，c from kafkaTopic，通過進行這樣的處理，字段 a、b、c 和這個 hive 的字段 d 就產(chǎn)生了血緣關(guān)系。

（3）創(chuàng)建子任務的節(jié)點，把幾個字段節(jié)點連接起來，每個子任務節(jié)點會和子任務節(jié)點通過從屬關(guān)系的邊來進行連接，字段節(jié)點和每一個表資產(chǎn)節(jié)點也會通過從屬關(guān)系的邊進行連接。本身這個任務和資產(chǎn)之間會有消費生產(chǎn)關(guān)系的邊連接。

以上就是整個血緣數(shù)據(jù)模型在抽象層的展現(xiàn)。

這樣設計是有以下好處：

首先，任務資產(chǎn)的抽象是對生產(chǎn)平臺上和在各種任務平臺上廣泛直接的任務關(guān)系的抽象，當再去接入新元數(shù)據(jù)或新任務類型時，我們只需要擴展當前抽象的資產(chǎn)節(jié)點和任務節(jié)點，即可把新加入進來的任務鏈路所對應的血緣接入到存儲中。這種數(shù)據(jù)模型也能方便地更新和刪除血緣鏈路，維持時效性。

其次，在字節(jié)內(nèi)部的血緣建設中，還存在接入各種血緣鏈路的難點。基于目前設計可以減少開發(fā)成本，在更新血緣的時只需要更新中心任務節(jié)點，并且把中心任務節(jié)點所對應的子任務節(jié)點的邊也做相應的更新和刪除，就完成了血緣信息的插入和更新。

4、數(shù)據(jù)血緣模型 – 實現(xiàn)層

在實現(xiàn)層，火山引擎 DataLeap 主要基于 Apache Atlas 來實現(xiàn)。Apache Atlas 本身也是一個數(shù)據(jù)治理的產(chǎn)品，它預定義了一些元數(shù)據(jù)的類型，整個類型系統(tǒng)有比較好的擴展性。在 Atlas 本身的 DataSet 和 Process 元數(shù)據(jù)定義上，我們引入了字節(jié)內(nèi)部獨有的業(yè)務元數(shù)據(jù)的屬性和子任務定義，最終把任務相關(guān)的元數(shù)據(jù)存儲起來。

Atlas 本身也支持血緣的查詢能力，通過 Apache Atlas 暴露的接口來轉(zhuǎn)換成圖上查找某個節(jié)點對應血緣關(guān)系的邊，以此實現(xiàn)血緣查詢。

5、數(shù)據(jù)血緣模型 – 存儲層

在存儲層，目前主要基于 Apache Atlas 原生圖數(shù)據(jù)庫——JanusGraph。JanusGraph 底層支持 HBase。我們將每條邊的關(guān)系作為兩邊的資產(chǎn)節(jié)點的屬性，存入到對應 RowKey 的獨立 cell 中。

另外，我們也對存儲做了相關(guān)的改造，如字節(jié)內(nèi)部自研的存算分離 key-value 存儲。我們也在獨立環(huán)境中會做輕量級部署，同時基于性能或成本，以及部署復雜度，把存儲切換為 OLTP 數(shù)據(jù)庫，比如 MYSQL 數(shù)據(jù)庫。

以上就是整個數(shù)據(jù)血緣模型的設計部分。通過這樣的數(shù)據(jù)血緣模型，我們可以減少新的數(shù)據(jù)血緣鏈路接入開發(fā)成本，同時也很方便更新和刪除血緣。

二、數(shù)據(jù)血緣優(yōu)化

第二部分將主要介紹在火山引擎 DataLeap 中典型的數(shù)據(jù)血緣優(yōu)化，包括實時數(shù)據(jù)血緣更新優(yōu)化、血緣查詢優(yōu)化和血緣數(shù)據(jù)開放式導出。

1、實時數(shù)據(jù)血緣優(yōu)化

首先，實時數(shù)據(jù)血緣的更新。字節(jié)內(nèi)部現(xiàn)在數(shù)據(jù)血緣的更新方式是通過 T+1 的鏈路和實時鏈路來更新。由于內(nèi)部有很多場景對時效性的要求特別高，如果數(shù)據(jù)血緣更新不太及時，就是影響血緣準確率，甚至影響業(yè)務使用。

在數(shù)據(jù)血緣的架構(gòu)設計之初就已經(jīng)支持了 T+1 的導入，但是時效性始終是天級別的。

（1）數(shù)據(jù)血緣任務周期性的拉取所有在運行任務的配置信息，調(diào)用平臺的 API 拉取對應任務相關(guān)的配置或者 SQL；

（2）對于 SQL 類型的任務會調(diào)用另外一個解析引擎服務提供的解析能力來去解析數(shù)據(jù)血緣的信息；

（3）再和元數(shù)據(jù)平臺登記的資產(chǎn)信息相匹配，最后構(gòu)建出一個任務資產(chǎn)節(jié)點的上下游，把這個任務資產(chǎn)節(jié)點和表資產(chǎn)節(jié)點之間的邊更新到圖數(shù)據(jù)庫中去。

在實時更新的時候，我們有兩種方案：

方案一：是在引擎?zhèn)?，即在任務運行時，通過任務執(zhí)行引擎把該任務在構(gòu)建 DAG 后生成的血緣信息通過 Hook 送入。

（1）優(yōu)點：在引擎?zhèn)鹊难壊杉窍鄬Κ毩⒌?，每個引擎在采集血緣的時候不會互相影響。

（2）缺點：

① 每個引擎都需要適配一個血緣采集的 Hook，一些中小企業(yè)在引擎?zhèn)榷伎赡苊媾R的一個問題是同一個引擎可能在線上運行會有多個版本，那么適配的成本就會比較高，需要每個版本都適配一次。

② Hook 還有一定的侵入性，會對本身的作業(yè)有一定的負擔。

方案二：在任務開發(fā)的平臺上把這個任務變更的消息送出，當任務的生命周期變化的時候，通過 Hook 消息把任務狀態(tài)變更消息通過調(diào)用 API 進行登記或者發(fā)送到 MQ 進行解耦，血緣服務收到這份通知之后，再主動調(diào)用解析服務來更新這個任務血緣。

（1）優(yōu)點：擴展性好，不會受到引擎?zhèn)认拗?，未來要接入新的引擎時，只需要在這個任務平臺上去創(chuàng)建對應的任務，把這個任務變更的消息送出，就可以得到這個血緣更新的通知，然后去更新血緣。

（2）缺點：對血緣解析服務平臺會有一定的改造成本，任務間的消息可能會互相影響。

綜合比較，我們采用了第二種方案，并且引入了MQ進一步的降低任務平臺和血緣平臺的耦合，這種做法可能犧牲了部分的延遲，但是會讓整個鏈路變得更加可靠，最終減低了血緣這邊整體的延遲，從天級別減低到了分鐘級別。

以上就是我們在血緣時效性上的優(yōu)化。

2、數(shù)據(jù)查詢優(yōu)化

第二個優(yōu)化點是查詢。目前字節(jié)數(shù)據(jù)血緣查詢依賴 Apache Atlas。在使用該血緣查詢服務時，有一個很普遍的場景，就是多節(jié)點查詢的場景。在影響分析的過程中，我們經(jīng)常會查詢一張表的全部字段血緣，會轉(zhuǎn)化成查詢多個節(jié)點的血緣上下游關(guān)系，需要解決查詢效率的問題。

有兩種基本的解決方案：

一種是直接在應用層進行封裝，對 Apache Atlas 血緣服務的暴露層新增一個接口，比如通過循環(huán)遍歷去執(zhí)行單個查詢，這樣改造的內(nèi)容是很少的，但是其實性能并沒有提升，而且實現(xiàn)比較暴力。

另外一種方式是改造 Apache Atlas 血緣服務對圖庫查詢的調(diào)用。因為 Atlas 使用 JanusGraph 作為底層的實現(xiàn)，提供了一部分的抽象，但是只暴露了單節(jié)點的查詢，而沒有批量查詢的方法，我們只需要適配 JanusGraph 這邊批量查詢的接口，就可以達到提速的效果。

所以我們在圖數(shù)據(jù)庫的操作入口增加了一個新的批量查詢的方法，通過這種方式對血緣節(jié)點進行批量查詢，來進一步提升性能。同時 Atlas 在查詢血緣節(jié)點回來之后，需要進行一個映射，映射到具體的實體上去拿回它的一些屬性，在這個過程中我們也加入了異步批量的操作方式來進一步的提升性能。經(jīng)過優(yōu)化之后，我們在對一些引用熱度比較高的表資產(chǎn)節(jié)點或者查詢表資產(chǎn)或者對應列的時候，效率都可以得到明顯提升。

3、血緣數(shù)據(jù)開放式導出

第三個優(yōu)化點是在血緣的導出上提供了多種方式，除了在頁面上可視化的查詢血緣的能力之上，我們也陸續(xù)提供了很多使用血緣的方式，包括下載到 Excel,或者查詢這個血緣數(shù)據(jù)導出的數(shù)倉表，或者直接使用服務平臺側(cè)開放的 API，還可以訂閱血緣變更的 topic，來直接監(jiān)聽血緣的變更，下游的用戶可以根據(jù)自己的開發(fā)場景，以及業(yè)務對準確率、覆蓋率的要求，來決定到底使用哪種方式來消費血緣數(shù)據(jù)。

三、數(shù)據(jù)血緣用例

接下來第三部分主要介紹數(shù)據(jù)血緣的具體用例，介紹字節(jié)內(nèi)部是如何使用數(shù)據(jù)血緣的。在字節(jié)內(nèi)部數(shù)據(jù)血緣用例的典型使用領(lǐng)域主要包括：資產(chǎn)領(lǐng)域、開發(fā)領(lǐng)域、治理領(lǐng)域和安全領(lǐng)域。

1、數(shù)據(jù)血緣用例 – 資產(chǎn)領(lǐng)域

首先在資產(chǎn)領(lǐng)域，數(shù)據(jù)血緣主要應用在資產(chǎn)熱度的計算。在資產(chǎn)熱度計算時，有些資產(chǎn)會被頻繁消費和廣泛引用。某個資產(chǎn)被眾多下游引用，是自身權(quán)威性的證明，而這種權(quán)威性的證明需要一種定量的度量，因此需要引入了“資產(chǎn)熱度”的概念。資產(chǎn)熱度本身是參考網(wǎng)頁排名算法PageRank算法實現(xiàn)的，同時我們也提供了資產(chǎn)熱度值，根據(jù)資產(chǎn)的下游血緣依賴的情況，定義了資產(chǎn)引用的熱度值，如果某個資產(chǎn)引用熱度值越高，就代表了這個資產(chǎn)更應該被信任，數(shù)據(jù)更可靠。

另外，血緣也可以幫助我們理解數(shù)據(jù)。比如用戶在元數(shù)據(jù)平臺或者血緣平臺上查詢數(shù)據(jù)資產(chǎn)節(jié)點的時候，可能是想要進行下一步的作業(yè)開發(fā)或者是排查一些問題，那么他就需要首先找到這個數(shù)據(jù)資產(chǎn)。用戶不了解數(shù)據(jù)產(chǎn)生的過程，就無法了解數(shù)據(jù)的過去和未來。也就是哲學上經(jīng)典的問題：這個表到底是怎么來的？它具體有哪些含義？我們就可以通過數(shù)據(jù)血緣來找到具體表的上下游信息。

2、數(shù)據(jù)血緣用例 – 開發(fā)領(lǐng)域

數(shù)據(jù)血緣的第二個用例是開發(fā)領(lǐng)域。在開發(fā)領(lǐng)域中會有兩個應用：影響分析和歸因分析。

（1）影響分析應用

影響分析應用是事前分析。也就是當我們對表資產(chǎn)做一些變更的時候，在事前需要感知這個變更的影響，處于血緣上游的資產(chǎn)負責人在修改對應的生產(chǎn)任務的時候s，就需要通過血緣來查看自己資產(chǎn)的下游，來判斷這個資產(chǎn)修改的影響，針對修改的兼容性或者某條鏈路的重要性，來對應的做一些通知的操作，否則會因為缺少通知而造成嚴重的生產(chǎn)事故。

（2）歸因分析應用

歸因分析應用是事后分析。比如當某個任務所產(chǎn)生的表出現(xiàn)了問題，我們就可以通過查詢血緣的上游，逐級尋找到血緣上游改動的任務節(jié)點或者資產(chǎn)節(jié)點來排查出造成問題的根因是什么。在發(fā)現(xiàn)和定位出了問題之后，我們會去修復數(shù)據(jù)，在修復數(shù)據(jù)的時候，我們可以通過血緣來查找任務或者表的依賴關(guān)系，對于離線數(shù)倉可能就需要重跑某個分區(qū)的輸出數(shù)據(jù)，我們需要根據(jù)血緣來劃定范圍，只需要回溯對應受影響的下游任務就可以了，減少一些不必要的資源浪費。

3、數(shù)據(jù)血緣用例 – 治理領(lǐng)域

在治理領(lǐng)域應用中，血緣關(guān)系在字節(jié)內(nèi)部也有典型的使用場景：鏈路狀態(tài)追蹤和數(shù)倉治理。

（1）鏈路狀態(tài)追蹤

比如在重要的節(jié)日或者活動的時候，我們需要事先挑選一些需要重要保障的任務，這時就需要通過血緣關(guān)系來梳理出鏈路的主干，即核心鏈路。然后去對應的做重點的治理和保障，比如簽署 SLA。

（2）數(shù)倉治理

在數(shù)倉建設方面，也會使用血緣來輔助一些日常的工作，比如規(guī)范化治理。數(shù)倉規(guī)范化治理包括清理數(shù)倉中分層不合理的引用，或者是數(shù)倉分層整體不規(guī)范，存在一些冗余的表。比如，兩個表來自同一個上游表，但是它們在不同層級，這些冗余的表就需要被清理掉的，這種場景就是使用血緣來輔助治理的一個典型用例。

4、數(shù)據(jù)血緣用例 – 安全領(lǐng)域

安全相關(guān)問題在一些跨國或國際化產(chǎn)品企業(yè)會比較常見，每個國家地區(qū)的安全政策是不一樣的。我們在做安全合規(guī)檢查時，每個資產(chǎn)都有對應的資產(chǎn)安全等級，這個資產(chǎn)安全等級會有一定的規(guī)則，比如我們規(guī)定下游資產(chǎn)的安全等級一定高于上游的安全資產(chǎn)等級，否則就會有權(quán)限泄露問題或者是其他的安全問題?；谘墸覀兛梢話呙璧竭@些規(guī)則涉及的資產(chǎn)下游，來配置相應掃描規(guī)則，然后進行安全合規(guī)排查，以便做出對應的治理。

另外，血緣在標簽傳播方面也有所應用，可以通過血緣的傳播鏈路來進行自動化工作，比如對資產(chǎn)進行安全標簽打標的時候，人工的打標方式會相對比較繁瑣而且需要關(guān)注鏈路的信息，那么就可以借助血緣信息來完成自動的打標，比如配置一些規(guī)則讓安全標簽明確場景、節(jié)點和終止規(guī)則。

以上這些都是數(shù)據(jù)血緣在字節(jié)內(nèi)部的一些典型用例，我們也在探索更多的使用場景。

根據(jù)其對血緣質(zhì)量的要求，這些場景被分成了幾個區(qū)域。根據(jù)血緣覆蓋率、血緣準確率的要求，可以分為四個象限，比如其中一類是需要覆蓋全鏈路且血緣準確率要求異常高的，例如開發(fā)項的兩個用例，因為在開發(fā)項的用例中，血緣的延遲會嚴重影響決策上的判斷，對血緣質(zhì)量要求是最高的。

血緣建設過程也會劃分不同的建設時期，我們可以根據(jù)現(xiàn)在要支持的業(yè)務場景和業(yè)務優(yōu)先級來輔助制定血緣建設規(guī)劃，決定血緣迭代的節(jié)奏和具體方向。

四、未來展望

1、血緣技術(shù)趨勢  

在業(yè)界，血緣的發(fā)展趨勢主要關(guān)注以下幾點：

（1）通用的血緣解析能力

血緣是元數(shù)據(jù)平臺的核心能力，很多時候元數(shù)據(jù)平臺會接入多樣化元數(shù)據(jù)，這些業(yè)務元數(shù)據(jù)也會依賴血緣不同的血緣解析能力，現(xiàn)在的解析往往是依賴各個引擎團隊來支持的，但是其實在更加廣泛的場景，我們需要有一個兜底的方案來提供一個更通用的血緣解析能力，所以未來我們會提供標準 SQL 解析引擎，以達到通用解析的目的。

（2）非侵入式的非 SQL 類型血緣采集

除了可解析的 SQL 或可配置的任務，日常還會涉及到代碼類型的任務，如 JAR 任務。JAR 任務現(xiàn)在的解析方式是根據(jù)一些埋點信息或者用戶錄入的上下游信息去完成血緣的收集，這部分未來會出現(xiàn)一種非侵入式的非 SQL 類型血緣采集的技術(shù)，比如 Flink 或者 Spark 的 JAR 任務，我們可以在任務運行時拿到這些血緣，來豐富平臺側(cè)血緣的數(shù)據(jù)。

（3）時序血緣

時序血緣也是字節(jié)內(nèi)部的考慮點。目前血緣信息圖數(shù)據(jù)庫相當于是對當前血緣拓撲的一次快照，其實血緣是會變化的，比如用戶在修改一個任務的時候，上線任務變更或是修改表結(jié)構(gòu)，然后對應的修改自己生產(chǎn)任務的時候，涉及到時序的概念，這個時序可以方便我們?nèi)プ匪菀恍┤蝿盏淖兓?，支持我們?nèi)プ鍪虑笆潞笥绊懛治?，所以時序血緣如何在圖數(shù)據(jù)庫中引入也是未來的一個趨勢。

2、數(shù)據(jù)血緣的應用趨勢

（1）標準化

前文提到很多應用場景的底層能力都是通過接口來獲得，獲得接口的數(shù)據(jù)也涉及到應用的標準化，標準化的應用可以讓我們移植到更多的業(yè)務上，提供更好的血緣數(shù)據(jù)分析幫助。

（2）端到端的血緣打通

另一個應用趨勢是端到端的血緣能力，現(xiàn)在平臺主要接入資產(chǎn)節(jié)點，端到端則會涉及到更上游，如 App 端和 Web 端采集的數(shù)據(jù)，或者是下游報表，以及 API 之后最終的節(jié)點。在血緣收集中，這部分信息目前缺失，端到端血緣打通將是未來應用上的趨勢之一。

3、云上的全鏈路血緣能力

在字節(jié)跳動內(nèi)部，血緣能力會進行上云，云上涉及各類數(shù)據(jù)類型，因此血緣發(fā)展方向之一是把各類異構(gòu)數(shù)據(jù)類型統(tǒng)一接入，并且支持云上用戶來自定義接入新類型血緣。

同時，當數(shù)據(jù)應用標準化之后，也可以把血緣應用提供給云上用戶，云上用戶也可以反向加入到血緣應用的開發(fā)中，最后把數(shù)據(jù)血緣模型作為一種標準來推廣，由此衍生出更好的血緣應用、血緣服務生態(tài)。