經(jīng)驗一：數(shù)據(jù)血緣模型的分層架構(gòu)

1. 挑戰(zhàn)

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

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

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

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

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

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

2. 數(shù)據(jù)血緣模型 - 展示層

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

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

3. 數(shù)據(jù)血緣模型 - 抽象層

接下來介紹，火山引擎 DataLeap 如何設(shè)計抽象層。

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

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

• 一個 FlinkSQL 任務(wù)消費(fèi)了 Kafka 的 topic，然后寫入到一個 Hive 的表里，那么 Kafka 的 topic 和 hive 表就是表資產(chǎn)節(jié)點(diǎn)，而 FlinkSQL 消費(fèi)任務(wù)就是中間的任務(wù)節(jié)點(diǎn)。
• 一個 Kafka 的 topic 里面可能會定義自己的 schema，包括多個字段，例如 schema 里包含字段 a、b、c，通過 FlinkSQL 任務(wù)，比如一個 SQL：insert into hiveTable select a，b，c from kafka Topic，通過進(jìn)行這樣的處理，字段 a、b、c 和這個 hive 的字段 d 就產(chǎn)生了血緣關(guān)系。
• 創(chuàng)建子任務(wù)的節(jié)點(diǎn)，把幾個字段節(jié)點(diǎn)連接起來，每個子任務(wù)節(jié)點(diǎn)會和子任務(wù)節(jié)點(diǎn)通過從屬關(guān)系的邊來進(jìn)行連接，字段節(jié)點(diǎn)和每一個表資產(chǎn)節(jié)點(diǎn)也會通過從屬關(guān)系的邊進(jìn)行連接。本身這個任務(wù)和資產(chǎn)之間會有消費(fèi)生產(chǎn)關(guān)系的邊連接。

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

這樣設(shè)計有以下好處：

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

其次，在字節(jié)內(nèi)部的血緣建設(shè)中，還存在接入各種血緣鏈路的難點(diǎn)?；谀壳霸O(shè)計可以減少開發(fā)成本，在更新血緣的時只需要更新中心任務(wù)節(jié)點(diǎn)，并且把中心任務(wù)節(jié)點(diǎn)所對應(yīng)的子任務(wù)節(jié)點(diǎn)的邊也做相應(yīng)的更新和刪除，就完成了血緣信息的插入和更新。

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

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

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

5. 數(shù)據(jù)血緣模型 - 存儲層

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

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

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

經(jīng)驗二：三個數(shù)據(jù)血緣優(yōu)化方向

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

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

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

在數(shù)據(jù)血緣的架構(gòu)設(shè)計之初就已經(jīng)支持了 T+1 的導(dǎo)入，不過時效性始終是按天為周期的。

• 數(shù)據(jù)血緣任務(wù)周期性的拉取所有在運(yùn)行任務(wù)的配置信息，調(diào)用平臺的API拉取對應(yīng)任務(wù)相關(guān)的配置或者 SQL
• 對于 SQL 類型的任務(wù)會調(diào)用另外一個解析引擎服務(wù)提供的解析能力來去解析數(shù)據(jù)血緣的信息
• 再和元數(shù)據(jù)平臺登記的資產(chǎn)信息相匹配，最后構(gòu)建出一個任務(wù)資產(chǎn)節(jié)點(diǎn)的上下游，把這個任務(wù)資產(chǎn)節(jié)點(diǎn)和表資產(chǎn)節(jié)點(diǎn)之間的邊更新到圖數(shù)據(jù)庫中去。

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

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

• 優(yōu)點(diǎn)：在引擎?zhèn)鹊难壊杉窍鄬Κ?dú)立的，每個引擎在采集血緣的時候不會互相影響。
• 缺點(diǎn)：

• 每個引擎都需要適配一個血緣采集的 Hook，一些中小企業(yè)在引擎?zhèn)榷伎赡苊媾R的一個問題是同一個引擎可能在線上運(yùn)行會有多個版本，那么適配的成本就會比較高，需要每個版本都適配一次。
• Hook 還有一定的侵入性，會對本身的作業(yè)有一定的負(fù)擔(dān)。

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

• 優(yōu)點(diǎn)：擴(kuò)展性好，不會受到引擎?zhèn)认拗?，未來要接入新的引擎時，只需要在這個任務(wù)平臺上去創(chuàng)建對應(yīng)的任務(wù)，把這個任務(wù)變更的消息送出，就可以得到這個血緣更新的通知，然后去更新血緣。
• 缺點(diǎn)：對血緣解析服務(wù)平臺會有一定的改造成本，任務(wù)間的消息可能會互相影響

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

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

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

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

有兩種基本的解決方案：

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

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

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

3.血緣數(shù)據(jù)開放式導(dǎo)出

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

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

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

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

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

影響分析應(yīng)用

影響分析即事前分析，指當(dāng)表資產(chǎn)產(chǎn)生變更時，能夠事前感知影響。血緣上游的資產(chǎn)負(fù)責(zé)人在修改對應(yīng)的生產(chǎn)任務(wù)時，需要通過血緣查看資產(chǎn)下游，由此判斷資產(chǎn)修改產(chǎn)生的影響，從而針對修改的兼容性或者某條鏈路的重要性，完成通知等操作，否則會因為缺少通知而造成嚴(yán)重的生產(chǎn)事故。

歸因分析應(yīng)用

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

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

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

鏈路狀態(tài)追蹤

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

數(shù)倉治理

數(shù)據(jù)血緣也會用來輔助數(shù)倉建設(shè)，如規(guī)范化治理。數(shù)倉規(guī)范化治理包括清理數(shù)倉分層不合理的引用、數(shù)倉分層不規(guī)范、冗余表等。例如，來自同一個上游表，但屬于不同層級的兩個表，屬于冗余，將通過數(shù)據(jù)血緣輔助清理。

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

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

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

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

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

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

未來展望

1.數(shù)據(jù)血緣技術(shù)趨勢

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

通用的血緣解析能力

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

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

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

時序血緣

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

2.數(shù)據(jù)血緣的應(yīng)用趨勢

標(biāo)準(zhǔn)化

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

端到端的血緣打通

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

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

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

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

本文介紹的數(shù)據(jù)血緣能力和實踐，目前大部分已通過火山引擎 DataLeap 對外提供服務(wù)，歡迎大家點(diǎn)擊閱讀原文體驗。