本文介紹的數據血緣能力和實踐，目前大部分已通過火山引擎DataLeap對外提供服務。
DataLeap是火山引擎數智平臺VeDI旗下的大數據研發治理套件產品，幫助用戶快速完成數據集成、開發、運維、治理、資產、安全等全套數據中臺建設，降低工作成本和數據維護成本、挖掘數據價值、為企業決策提供數據支撐。
數據血緣是幫助用戶找數據、理解數據以及使數據發揮價值的基礎能力。本文將聚焦數據血緣存儲和血緣導出，分享在存儲和導出數據血緣的模型設計以及優化，并介紹字節跳動在數據血緣建設過程中所遇到的挑戰和技術實現以及數據血緣的具體用例，具體包括數據血緣模型、數據血緣優化、數據血緣用例、未來展望四個部分。本文介紹的數據血緣能力和實踐，目前大部分已通過火山引擎DataLeap對外提供服務。
一、數據血緣模型
1、數據血緣模型 – 挑戰
首先介紹一下字節內部數據血緣遇到的挑戰。
隨著公司業務擴張、用戶數量持續增長以及數倉建設不斷完善，元數據種類和數量也經歷了非線性增長，并在此期間涌現出一些問題。
第一，擴展性。好的擴展性可以在面對新型元數據血緣時保證快速接入和迭代，而擴展性不佳則會導致在業務變化時需要不停地重構來適應業務，對業務造成很多影響。
第二，性能。一個模型本身的插入和更新效率會直接影響數據的導入導出的流程，這些都會帶來更直觀的業務上的感受，所以需要考慮如何保證環節高效性。
第三，時效性。很多應用場景對正確率格外敏感，如果血緣數據有延遲，其實就等于血緣的不準確，會對業務造成影響。
最后，賦能業務。技術服務于業務，業務增長會幫助技術升級迭代，技術創新也會促進業務發展。在字節內部，我們會根據業務特點，考慮業務需要，將技術成本與業務收益做平衡，最終做出數據模型決策。總而言之，數據模型沒有完美的方案，只有最適合企業自身業務、適合當前階段的數據血緣方案。
2、 數據血緣模型 – 展示層
字節內部有很多種元數據類型，包括線上傳統的離線數倉Hive、OLAP分析引擎ClickHouse，以及實時側元數據，如Kafka和ES以及redis。這些元數據所對應的表/Topic都統一維護在元數據平臺上，目前血緣展示層是以這些數據資產作為主視角。
如下圖所示，中心數據資產包含普通字段和分區字段等信息，還可以從圖中看到中心資產上下游資產信息，上游有哪些相關的表，下游有哪些相關的topic或者表。圖中資產和資產之間連接的邊，代表的是生產關系：1個任務讀取了上游的資產，產生了下游的資產。
3、數據血緣模型 – 抽象層
再來介紹，火山引擎DataLeap如何設計抽象層。
抽象層是整個數據血緣的數據模型，主要包含兩種節點，一種是資產節點，另外一種是任務節點。
在圖中，資產節點用圓形表示，任務節點用菱形表示。具體舉個例子：
（1）一個 FlinkSQL 任務消費了 Kafka 的 topic，然后寫入到一個 Hive 的表里，那么 Kafka 的 topic 和 hive 表就是表資產節點，而 FlinkSQL 消費任務就是中間的任務節點。
（2）一個 Kafka 的 topic 里面可能會定義自己的 schema，包括多個字段，例如schema里包含字段 a、b、c，通過 FlinkSQL 任務，比如一個 SQL：insert into hiveTable select a，b，c from kafkaTopic，通過進行這樣的處理，字段 a、b、c 和這個 hive 的字段 d 就產生了血緣關系。
（3）創建子任務的節點，把幾個字段節點連接起來，每個子任務節點會和子任務節點通過從屬關系的邊來進行連接，字段節點和每一個表資產節點也會通過從屬關系的邊進行連接。本身這個任務和資產之間會有消費生產關系的邊連接。
以上就是整個血緣數據模型在抽象層的展現。
這樣設計是有以下好處：
首先，任務資產的抽象是對生產平臺上和在各種任務平臺上廣泛直接的任務關系的抽象，當再去接入新元數據或新任務類型時，我們只需要擴展當前抽象的資產節點和任務節點，即可把新加入進來的任務鏈路所對應的血緣接入到存儲中。這種數據模型也能方便地更新和刪除血緣鏈路，維持時效性。
其次，在字節內部的血緣建設中，還存在接入各種血緣鏈路的難點。基于目前設計可以減少開發成本，在更新血緣的時只需要更新中心任務節點，并且把中心任務節點所對應的子任務節點的邊也做相應的更新和刪除，就完成了血緣信息的插入和更新。
4、數據血緣模型 – 實現層
在實現層，火山引擎 DataLeap 主要基于 Apache Atlas 來實現。Apache Atlas 本身也是一個數據治理的產品，它預定義了一些元數據的類型，整個類型系統有比較好的擴展性。在 Atlas 本身的 DataSet 和 Process 元數據定義上，我們引入了字節內部獨有的業務元數據的屬性和子任務定義，最終把任務相關的元數據存儲起來。
Atlas 本身也支持血緣的查詢能力，通過 Apache Atlas 暴露的接口來轉換成圖上查找某個節點對應血緣關系的邊，以此實現血緣查詢。
5、數據血緣模型 – 存儲層
在存儲層，目前主要基于 Apache Atlas 原生圖數據庫——JanusGraph。JanusGraph 底層支持 HBase。我們將每條邊的關系作為兩邊的資產節點的屬性，存入到對應 RowKey 的獨立 cell 中。
另外，我們也對存儲做了相關的改造，如字節內部自研的存算分離 key-value 存儲。我們也在獨立環境中會做輕量級部署，同時基于性能或成本，以及部署復雜度，把存儲切換為 OLTP 數據庫，比如 MySQL 數據庫。
以上就是整個數據血緣模型的設計部分。通過這樣的數據血緣模型，我們可以減少新的數據血緣鏈路接入開發成本，同時也很方便更新和刪除血緣。
二、數據血緣優化
第二部分將主要介紹在火山引擎 DataLeap 中典型的數據血緣優化，包括實時數據血緣更新優化、血緣查詢優化和血緣數據開放式導出。
1、實時數據血緣優化
首先，實時數據血緣的更新。字節內部現在數據血緣的更新方式是通過 T+1 的鏈路和實時鏈路來更新。由于內部有很多場景對時效性的要求特別高，如果數據血緣更新不太及時，就是影響血緣準確率，甚至影響業務使用。
在數據血緣的架構設計之初就已經支持了 T+1 的導入，但是時效性始終是天級別的。
（1）數據血緣任務周期性的拉取所有在運行任務的配置信息，調用平臺的 API 拉取對應任務相關的配置或者 SQL；
（2）對于 SQL 類型的任務會調用另外一個解析引擎服務提供的解析能力來去解析數據血緣的信息；
（3）再和元數據平臺登記的資產信息相匹配，最后構建出一個任務資產節點的上下游，把這個任務資產節點和表資產節點之間的邊更新到圖數據庫中去。
在實時更新的時候，我們有兩種方案：
方案一：是在引擎側，即在任務運行時，通過任務執行引擎把該任務在構建 DAG 后生成的血緣信息通過 Hook 送入。
（1）優點：在引擎側的血緣采集是相對獨立的，每個引擎在采集血緣的時候不會互相影響。
（2）缺點：
① 每個引擎都需要適配一個血緣采集的 Hook，一些中小企業在引擎側都可能面臨的一個問題是同一個引擎可能在線上運行會有多個版本，那么適配的成本就會比較高，需要每個版本都適配一次。
② Hook 還有一定的侵入性，會對本身的作業有一定的負擔。
方案二：在任務開發的平臺上把這個任務變更的消息送出，當任務的生命周期變化的時候，通過 Hook 消息把任務狀態變更消息通過調用 API 進行登記或者發送到 MQ 進行解耦，血緣服務收到這份通知之后，再主動調用解析服務來更新這個任務血緣。
（1）優點：擴展性好，不會受到引擎側限制，未來要接入新的引擎時，只需要在這個任務平臺上去創建對應的任務，把這個任務變更的消息送出，就可以得到這個血緣更新的通知，然后去更新血緣。
（2）缺點：對血緣解析服務平臺會有一定的改造成本，任務間的消息可能會互相影響。
綜合比較，我們采用了第二種方案，并且引入了MQ進一步的降低任務平臺和血緣平臺的耦合，這種做法可能犧牲了部分的延遲，但是會讓整個鏈路變得更加可靠，最終減低了血緣這邊整體的延遲，從天級別減低到了分鐘級別。
以上就是我們在血緣時效性上的優化。
2、數據查詢優化
第二個優化點是查詢。目前字節數據血緣查詢依賴 Apache Atlas。在使用該血緣查詢服務時，有一個很普遍的場景，就是多節點查詢的場景。在影響分析的過程中，我們經常會查詢一張表的全部字段血緣，會轉化成查詢多個節點的血緣上下游關系，需要解決查詢效率的問題。
有兩種基本的解決方案：
一種是直接在應用層進行封裝，對 Apache Atlas 血緣服務的暴露層新增一個接口，比如通過循環遍歷去執行單個查詢，這樣改造的內容是很少的，但是其實性能并沒有提升，而且實現比較暴力。
另外一種方式是改造 Apache Atlas 血緣服務對圖庫查詢的調用。因為 Atlas 使用 JanusGraph 作為底層的實現，提供了一部分的抽象，但是只暴露了單節點的查詢，而沒有批量查詢的方法，我們只需要適配 JanusGraph 這邊批量查詢的接口，就可以達到提速的效果。
所以我們在圖數據庫的操作入口增加了一個新的批量查詢的方法，通過這種方式對血緣節點進行批量查詢，來進一步提升性能。同時 Atlas 在查詢血緣節點回來之后，需要進行一個映射，映射到具體的實體上去拿回它的一些屬性，在這個過程中我們也加入了異步批量的操作方式來進一步的提升性能。經過優化之后，我們在對一些引用熱度比較高的表資產節點或者查詢表資產或者對應列的時候，效率都可以得到明顯提升。
3、血緣數據開放式導出
第三個優化點是在血緣的導出上提供了多種方式，除了在頁面上可視化的查詢血緣的能力之上，我們也陸續提供了很多使用血緣的方式，包括下載到 Excel,或者查詢這個血緣數據導出的數倉表，或者直接使用服務平臺側開放的 API，還可以訂閱血緣變更的 topic，來直接監聽血緣的變更，下游的用戶可以根據自己的開發場景，以及業務對準確率、覆蓋率的要求，來決定到底使用哪種方式來消費血緣數據。
三、數據血緣用例
接下來第三部分主要介紹數據血緣的具體用例，介紹字節內部是如何使用數據血緣的。在字節內部數據血緣用例的典型使用領域主要包括：資產領域、開發領域、治理領域和安全領域。
1、數據血緣用例 – 資產領域
首先在資產領域，數據血緣主要應用在資產熱度的計算。在資產熱度計算時，有些資產會被頻繁消費和廣泛引用。某個資產被眾多下游引用，是自身權威性的證明，而這種權威性的證明需要一種定量的度量，因此需要引入了“資產熱度”的概念。資產熱度本身是參考網頁排名算法PageRank算法實現的，同時我們也提供了資產熱度值，根據資產的下游血緣依賴的情況，定義了資產引用的熱度值，如果某個資產引用熱度值越高，就代表了這個資產更應該被信任，數據更可靠。
另外，血緣也可以幫助我們理解數據。比如用戶在元數據平臺或者血緣平臺上查詢數據資產節點的時候，可能是想要進行下一步的作業開發或者是排查一些問題，那么他就需要首先找到這個數據資產。用戶不了解數據產生的過程，就無法了解數據的過去和未來。也就是哲學上經典的問題：這個表到底是怎么來的？它具體有哪些含義？我們就可以通過數據血緣來找到具體表的上下游信息。
2、數據血緣用例 – 開發領域
數據血緣的第二個用例是開發領域。在開發領域中會有兩個應用：影響分析和歸因分析。
（1）影響分析應用
影響分析應用是事前分析。也就是當我們對表資產做一些變更的時候，在事前需要感知這個變更的影響，處于血緣上游的資產負責人在修改對應的生產任務的時候s，就需要通過血緣來查看自己資產的下游，來判斷這個資產修改的影響，針對修改的兼容性或者某條鏈路的重要性，來對應的做一些通知的操作，否則會因為缺少通知而造成嚴重的生產事故。
（2）歸因分析應用
歸因分析應用是事后分析。比如當某個任務所產生的表出現了問題，我們就可以通過查詢血緣的上游，逐級尋找到血緣上游改動的任務節點或者資產節點來排查出造成問題的根因是什么。在發現和定位出了問題之后，我們會去修復數據，在修復數據的時候，我們可以通過血緣來查找任務或者表的依賴關系，對于離線數倉可能就需要重跑某個分區的輸出數據，我們需要根據血緣來劃定范圍，只需要回溯對應受影響的下游任務就可以了，減少一些不必要的資源浪費。
3、數據血緣用例 – 治理領域
在治理領域應用中，血緣關系在字節內部也有典型的使用場景：鏈路狀態追蹤和數倉治理。
（1）鏈路狀態追蹤
比如在重要的節日或者活動的時候，我們需要事先挑選一些需要重要保障的任務，這時就需要通過血緣關系來梳理出鏈路的主干，即核心鏈路。然后去對應的做重點的治理和保障，比如簽署 SLA。
（2）數倉治理
在數倉建設方面，也會使用血緣來輔助一些日常的工作，比如規范化治理。數倉規范化治理包括清理數倉中分層不合理的引用，或者是數倉分層整體不規范，存在一些冗余的表。比如，兩個表來自同一個上游表，但是它們在不同層級，這些冗余的表就需要被清理掉的，這種場景就是使用血緣來輔助治理的一個典型用例。
4、數據血緣用例 – 安全領域
安全相關問題在一些跨國或國際化產品企業會比較常見，每個國家地區的安全政策是不一樣的。我們在做安全合規檢查時，每個資產都有對應的資產安全等級，這個資產安全等級會有一定的規則，比如我們規定下游資產的安全等級一定高于上游的安全資產等級，否則就會有權限泄露問題或者是其他的安全問題。基于血緣，我們可以掃描到這些規則涉及的資產下游，來配置相應掃描規則，然后進行安全合規排查，以便做出對應的治理。
另外，血緣在標簽傳播方面也有所應用，可以通過血緣的傳播鏈路來進行自動化工作，比如對資產進行安全標簽打標的時候，人工的打標方式會相對比較繁瑣而且需要關注鏈路的信息，那么就可以借助血緣信息來完成自動的打標，比如配置一些規則讓安全標簽明確場景、節點和終止規則。
以上這些都是數據血緣在字節內部的一些典型用例，我們也在探索更多的使用場景。
根據其對血緣質量的要求，這些場景被分成了幾個區域。根據血緣覆蓋率、血緣準確率的要求，可以分為四個象限，比如其中一類是需要覆蓋全鏈路且血緣準確率要求異常高的，例如開發項的兩個用例，因為在開發項的用例中，血緣的延遲會嚴重影響決策上的判斷，對血緣質量要求是最高的。
血緣建設過程也會劃分不同的建設時期，我們可以根據現在要支持的業務場景和業務優先級來輔助制定血緣建設規劃，決定血緣迭代的節奏和具體方向。
四、未來展望
1、血緣技術趨勢
在業界，血緣的發展趨勢主要關注以下幾點：
（1）通用的血緣解析能力
血緣是元數據平臺的核心能力，很多時候元數據平臺會接入多樣化元數據，這些業務元數據也會依賴血緣不同的血緣解析能力，現在的解析往往是依賴各個引擎團隊來支持的，但是其實在更加廣泛的場景，我們需要有一個兜底的方案來提供一個更通用的血緣解析能力，所以未來我們會提供標準 SQL 解析引擎，以達到通用解析的目的。
（2）非侵入式的非 SQL 類型血緣采集
除了可解析的 SQL 或可配置的任務，日常還會涉及到代碼類型的任務，如 JAR 任務。JAR 任務現在的解析方式是根據一些埋點信息或者用戶錄入的上下游信息去完成血緣的收集，這部分未來會出現一種非侵入式的非 SQL 類型血緣采集的技術，比如 Flink 或者 Spark 的 JAR 任務，我們可以在任務運行時拿到這些血緣，來豐富平臺側血緣的數據。
（3）時序血緣
時序血緣也是字節內部的考慮點。目前血緣信息圖數據庫相當于是對當前血緣拓撲的一次快照，其實血緣是會變化的，比如用戶在修改一個任務的時候，上線任務變更或是修改表結構，然后對應的修改自己生產任務的時候，涉及到時序的概念，這個時序可以方便我們去追溯一些任務的變化，支持我們去做事前事后影響分析，所以時序血緣如何在圖數據庫中引入也是未來的一個趨勢。
2、數據血緣的應用趨勢
（1）標準化
前文提到很多應用場景的底層能力都是通過接口來獲得，獲得接口的數據也涉及到應用的標準化，標準化的應用可以讓我們移植到更多的業務上，提供更好的血緣數據分析幫助。
（2）端到端的血緣打通
另一個應用趨勢是端到端的血緣能力，現在平臺主要接入資產節點，端到端則會涉及到更上游，如 App 端和 Web 端采集的數據，或者是下游報表，以及 API 之后最終的節點。在血緣收集中，這部分信息目前缺失，端到端血緣打通將是未來應用上的趨勢之一。
3、云上的全鏈路血緣能力
在字節跳動內部，血緣能力會進行上云，云上涉及各類數據類型，因此血緣發展方向之一是把各類異構數據類型統一接入，并且支持云上用戶來自定義接入新類型血緣。
同時，當數據應用標準化之后，也可以把血緣應用提供給云上用戶，云上用戶也可以反向加入到血緣應用的開發中，最后把數據血緣模型作為一種標準來推廣，由此衍生出更好的血緣應用、血緣服務生態。
