?在復雜的社會分工協作體系中，我們需要明確個人定位，才能更好的發揮價值，數據也是一樣，于是，數據血緣應運而生。

圖：數據血緣實例一、數據血緣是什么

數據血緣是在數據的加工、流轉過程產生的數據與數據之間的關系。

提供一種探查數據關系的手段，用于跟蹤數據流經路徑。

二、數據血緣的組成

1、數據節點

數據血緣中的節點，可以理解為數據流轉中的一個個實體，用于承載數據功能業務。例如數據庫、數據表、數據字段都是數據節點；從廣義上來說，與數據業務相關的實體都可以作為節點納入血緣圖中，例如指標、報表、業務系統等。

按照血緣關系劃分節點，主要有以下三類：流出節點->中間節點->流入節點

流出節點： 數據提供方，血緣關系的源端節點。中間節點： 血緣關系中類型最多的節點，既承接流入數據，又對外流出數據。流入節點： 血緣關系的終端節點，一般為應用層，例如可視化報表、儀表板或業務系統。

2、節點屬性

當前節點的屬性信息，例如表名，字段名，注釋，說明等。

3、流轉路徑

數據流轉路徑通過表現數據流動方向、數據更新量級、數據更新頻率三個維度的信息，標明了數據的流入流出信息：

數據流動方向： 通過箭頭的方式表明數據流動方向數據更新量級： 數據更新的量級越大，血緣線條越粗，說明數據的重要性越高。數據更新頻率： 數據更新的頻率越高，血緣線條越短，變化越頻繁，重要性越高。

4、流轉規則-屬性

流轉規則體現了數據流轉過程中發生的變化，屬性則記錄了當前路徑對數據的操作內容，用戶可通過流轉路徑查看該路徑規則與屬性，規則可以是直接映射關系，也可以是復雜的規則，例如：

數據映射： 不對數據做任何變動，直接抽取。數據清洗： 表現數據流轉過程中的篩選標準。例如要求數據不能為空值、符合特定格式等。數據轉換： 數據流轉過程中，流出實體的數據需要進行特殊處理才能接入到數據需求方。數據調度： 體現當前數據的調度依賴關系。數據應用： 為報表與應用提供數據。

三、我們為什么需要數據血緣

1、日益龐大的數據開發導致表間關系混亂，管理成本與使用成本激增

數據血緣產生最本質的需求。大數據開發作為數據匯集與數據服務提供方，龐大的數據與混亂的數據依賴導致管理成本與使用成本飆升。

2、數據價值評估，數據質量難以推進

表的優先級劃分，計算資源的傾斜，表級數據質量監控，如何制定一個明確且科學的標準。

3、什么表該刪，什么表不能刪，下架無依據

業務庫，數倉庫，中間庫，開發庫，測試庫等眾多庫表，是否存在數據冗余（一定存在）。以及存儲資源如何釋放？

4、動了一張表，錯了一堆表

你改了一張表的字段，第二天醒來發現郵件里一堆任務異常告警。

5、ETL任務異常時的歸因分析、影響分析、恢復

承接上個問題，如果存在任務異常或者ETL故障，我們如何定位異常原因，并且進行影響分析，以及下游受影響節點的快速恢復。

6、調度依賴混亂

數據依賴混亂必然會帶來調度任務的依賴混亂，如何構建一個健壯的調度依賴。

7、數據安全審計難以開展

針對銀行、保險、政府等對安全關注度較高的行業，數據安全-數據泄露-數據合規性需要重點關注。由于數據存在ETL鏈路操作，下游表的數據來源于上游表，所以需要基于數據全鏈路來進行安全審計，否則可能會出現下游數據安全等級較低，導致上游部分核心數據泄露。

四、數據血緣可以做什么

1、流程定位，追蹤溯源

通過可視化方式，將目標表的上下游依賴進行展示，一目了然。

2、確定影響范圍

通過當前節點的下游節點數量以及類型可以確定其影響范圍，可避免出現上游表的修改導致下游表的報錯。

3、評估數據價值、推動數據質量

通過對所有表節點的下游節點進行匯總，排序，作為數據評估依據，可重點關注輸出數量較多的數據節點，并添加數據質量監控。

4、提供數據下架依據

例如以下數據節點，無任何下游輸出節點，且并無任何存檔需求，則可以考慮將其下架刪除。

5、歸因分析，快速恢復

當某個任務出現問題時，通過查看血緣上游的節點，排查出造成問題的根因是什么。同時根據當前任務節點的下游節點進行任務的快速恢復。

6、梳理調度依賴

可以將血緣節點與調度節點綁定，通過血緣依賴進行ETL調度。

7、數據安全審計

數據本身具有權限與安全等級，下游數據的安全等級不應該低于上游的安全等級，否則會有權限泄露風險。

可以基于血緣，通過掃描高安全等級節點的下游，查看下游節點是否與上游節點權限保持一致，來排除權限泄露、數據泄露等安全合規風險。

五、數據血緣落地方案

目前業內常見的落地數據血緣系統以及應用，主要有以下三種方式：

1、采用開源系統：

Atlas、Metacat、Datahub等

采用開源系統最大的優點是投入成本較低，但是缺點主要包括

1、適配性較差，開源方案無法完全匹配公司現有痛點。

2、二開成本高，需要根據開源版本進行定制化開發。

2、廠商收費平臺：

億信華辰，網易數帆等

此類數據平臺中會內置數據血緣管理系統，功能較為全面，使用方便。但是同樣也有以下缺點：

1、貴

2、需要ALL IN平臺，為保障數據血緣的使用，數據業務需要全部遷移到廠商平臺中。

3、自建

通過圖數據庫、后端、前端自建數據血緣管理系統，此方案開發投入較大，但是有以下優點

1、因地制宜，可根據核心痛點定制化開發元數據及數據血緣系統。

2、技術積累，對于開發人員來說，從0-1開發數據血緣系統，可以更深刻的理解數據業務。

3、平臺解耦，獨立于數據平臺之外，數據血緣的開發不會對正常業務造成影響。

接下來我們講講如何自建數據血緣系統

六、如何構建數據血緣系統 1、明確需求，確定邊界

在進行血緣系統構建之前，需要進行需求調研，明確血緣系統的主要功能，從而確定血緣系統的最細節點粒度，實體邊界范圍。

例如節點粒度是否需要精確到字段級，或是表級。一般來說，表級粒度血緣可以解決75%左右的痛點需求， 字段級血緣復雜度較表級血緣高出許多，如果部門人數較少，可以考慮只精確到表級粒度血緣。

常見的實體節點包括：任務節點、庫節點、表節點、字段節點、指標節點、報表節點、部門節點等。血緣系統可以擴展數據相關的實體節點，可以從不同的場景查看數據走向，例如表與指標，指標與報表的血緣關系。但是實體節點的范圍需要明確，不可無限制的擴展下去。

明確需求，確定節點粒度與范圍之后，才可根據痛點問題給出準確的解決方案，不至于血緣系統越建越臃腫，提高ROI（投入產出比）。

2、構建元數據管理系統

目前市面上所有的血緣系統都需要依賴于元數據管理系統而存在。

元數據作為血緣的基礎，一是用于構建節點間的關聯關系，二是用于填充節點的屬性，三是血緣系統的應用需要基于元數據才能發揮出最大的價值。所以構建血緣系統的前提一定是有一個較全面的元數據。

元數據管理系統將會在下周發布的《元數據管理系統落地實施》文章中進行詳細講解

3、技術選型：圖數據庫

目前業內通常采用圖數據庫進行血緣關系的存儲。

對于血緣關系這種層級較深，嵌套次數較多的應用場景，關系型數據庫必須進行表連接的操作，表連接次數隨著查詢的深度增大而增多，會極大影響查詢的響應速度。

而在圖數據庫中，應用程序不必使用外鍵約束實現表間的相互引用，而是利用關系作為連接跳板進行查詢，在查詢關系時性能極佳，而且利用圖的方式來表達血緣關系更為直接。

下圖為圖數據庫與關系型數據庫在查詢人脈時的邏輯對比：

4、血緣關系錄入：自動解析and手動登記

自動解析：

獲取到元數據之后，首先可以根據元數據表中的SQL抽取語句，通過SQL解析器可自動化獲取到當前表的來源表【SQL解析器推薦jsqlparse】，并進行血緣關系錄入。

手動登記：

如果當前表無SQL抽取語句，數據來源為手動導入、代碼寫入、SparkRDD方式等無法通過自動化方式確定來源表的時候，我們需要對來源表進行手動登記，然后進行血緣關系的錄入。

血緣關系錄入需要基于圖數據庫進行，圖數據庫的建模、語句與關系型數據庫截然不同，如有疑問可以加入社區交流群進行解答。

5、血緣可視化

血緣系統構建完成后，為了能夠更好的體現血緣價值，量化產出，需要進行血緣可視化的開發，分為兩步：

（1）鏈路-屬性展示：

根據具體節點，通過點擊操作，逐級展示血緣節點間的鏈路走向與涉及到的節點屬性信息。

（2）節點操作：

基于可視化的血緣節點與當前節點附帶的元數據屬性，我們可以設想一些自動化操作例如：

節點調度：直接基于血緣開啟當前表節點的調度任務

屬性修改：通過前端修改當前節點的元數據屬性并保存

還有更多可視化操作可以加入社區交流群進行討論

6、血緣統計分析

數據血緣構建完成后，我們可以做一些統計分析的操作，從不同層面查看數據的分布與使用情況，從而支撐業務更好更快更清晰。

以我們團隊舉例，在工作過程中，我們需要以下血緣統計用于支撐數據業務，例如：

數據節點下游節點數量排序，用于評估數據價值及其影響范圍

查詢當前節點的所有上游節點，用于業務追蹤溯源

數據節點輸出報表信息詳情統計，用于報表的上架與更新

查詢孤島節點，即無上下游節點的節點，用于數據刪除的依據

7、血緣驅動業務開展

數據血緣構建完成，統計分析結果也有了，業務痛點也明確了，接下來我們即可利用數據血緣驅動業務更好更快開展。

我們團隊目前落地的血緣相關業務有以下幾點：

（1）影響范圍告警：

將血緣關系與調度任務打通，監測當前血緣節點的調度任務，如果當前節點調度出現異常，則對當前節點的所有下游節點進行告警。

（2）異常原因探查：

還是將血緣關系與調度任務打通，監測當前血緣節點的調度任務，如果當前節點調度出現異常，則會給出當前節點的直接上游節點，用于探查異常原因。

（3）異常鏈路一鍵恢復：

基于上一應用，異常原因定位并且修復完成之后，可以通過血緣系統，一鍵恢復當前數據節點的所有下游節點調度任務，真正實現一鍵操作。

團隊目前已經基于血緣系統構建出一整套的異常調度影響范圍告警->異常原因探查->異常鏈路一鍵恢復的故障響應修復機制。

（4）支撐數據下架：

目前團隊已經根據探查孤島節點即無上下游節點的節點，累計歸檔數據表628張，節省了13%的存儲空間。

（5）數據質量監控：

對當前血緣中所有節點輸出的下有節點數量進行排序，可以精確的判斷某張表的影響范圍大小，從而可以根據此對高排序表進行數據質量的監控。

（6）數據標準化監控：

如果當前公司制定了基于庫、表、字段的命名規范，我們可以通過探查血緣中的所有數據節點，并命名規范進行匹配，得到不符合規范的庫、表、字段進行整改。

當然了，此業務僅基于元數據也可實現，放在此處屬于博主強行升華了。

（7）數據安全審計：

團隊基于用戶職級、部門、操作行為等權重對目前的庫表進行了數據權限等級劃分，權限等級越高，當前表的安全級別越高。

團隊基于血緣進行數據全鏈路的安全等級監測，如果發現下游節點安全等級低于上游節點，則會進行告警并提示整改。確保因為安全等級混亂導致數據泄露。

八、血緣系統評價標準

在推動數據血緣落地過程中，經常會有用戶詢問：血緣質量如何？覆蓋場景是否全面？能否解決他們的痛點？做出來好用嗎？

于是我也在思考，市面上血緣系統方案那么多，我們自建系統的核心優勢在哪里，血緣系統的優劣從哪些層次進行評價，于是我們團隊量化出了以下三個技術指標：

1、準確率

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

準確率是數據血緣中最核心的指標，例如影響范圍告警，血緣的缺失有可能會造成重要任務沒有被通知，造成線上事故。

我們在實踐中通過兩種途徑，盡早發現有問題的血緣節點：

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

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

2、覆蓋率

定義： 當有數據資產錄入血緣系統時，則代表數據血緣覆蓋了當前數據資產。被血緣覆蓋到的數據資產占所有數據資產的比例即為血緣覆蓋率。

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

在內部，我們定義覆蓋率指標的目的有兩個，一是我方比較關注的數據資產集合，二是尋找當前業務流程中尚未覆蓋的數據資產集合，以便于后續血緣優化。

當血緣覆蓋率低時，血緣系統的應用范圍一定是不全面的，通過關注血緣覆蓋率，我們可以知曉血緣的落地進度，推進數據血緣的有序落地。

3、時效性

定義： 從數據資產新增和任務發生修改的時間節點，到最終新增或變更的血緣關系錄入到血緣系統的端到端延時。

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

例如：故障影響范圍告警以及恢復，是對血緣實時性要求很高的場景之一。如果血緣系統只能定時更新T-1的狀態，可能會導致嚴重業務事故。

提升時效性的瓶頸，需要業務系統可以近實時的將任務相關的修改，以通知形式發送出來，并由血緣系統進行更新。