Vol . 22
數說
數據血緣構建及應用
2023第8期
總第22期
數據血緣專題
北京市朝陽區朝外大街甲6號萬通中心D座25層 數據部
風向
一線
熱點
什么是數據血緣，如何做好數據血緣分析？
字節跳動數據血緣技術實現與具體用例
數據治理：數據血緣關系
目錄/contents
一、前言
數據血緣是元數據管理、數據治理、數據質量的重要一環，追蹤數據的來源、處理、出處，對數據價值評估提供依據，描述源數據流程、表、報表、即席查詢之間的流向關系，表與表的依賴關系、表與離線ETL任務，調度平臺，計算引擎之間的依賴關系。數據倉庫是構建在Hive之上，而Hive的原始數據往往來自于生產DB，也會把計算結果導出到外部存儲，異構數據源的表之間是有血緣關系的。
數據血緣用途：
- 追蹤數據溯源：當數據發生異常，幫助追蹤到異常發生的原因；影響面分析，追蹤數據的來源，追蹤數據處理過程。
- 評估數據價值：從數據受眾、更新量級、更新頻次等幾個方面給數據價值的評估提供依據。
- 生命周期：直觀地得到數據整個生命周期，為數據治理提供依據。
- 安全管控：對源頭打上敏感等級標簽后，傳遞敏感等級標簽到下游。
本文介紹攜程數據血緣如何構建及應用場景。第一版T+1構建Hive引擎的表級別的血緣關系，第二版近實時構建Hive，Spark，Presto多個查詢引擎和DataX傳輸工具的字段級別血緣關系。
二、構建血緣的方案
2.1 收集方式
方案一：只收集SQL，事后分析。
當SQL執行結束，收集SQL到DB或者Kafka。
- 優點：當計算引擎和工具不多的時候，語法相對兼容的時候，用Hive自帶的LineageLogger重新解析SQL可以獲得表和字段級別的關系。
- 缺點：重放SQL的時候可能元數據發生改變，比如臨時表可能被Drop，沒有臨時自定義函數UDF，或者SQL解析失敗。
數據血緣構建及應用
轉自數據倉庫與Python公眾號 作者cxzl25
原文鏈接：
//mp.weixin.qq.com/s/cz9I09ouo-h4Qj2WAlOkEg
方案二：運行時分析SQL并收集。
當SQL執行結束后立即分析Lineage，異步發送到Kafka。
- 優點：運行時的狀態和信息是最準確的，不會有SQL解析語法錯誤。
- 缺點：需要針對各個引擎和工具開發解析模塊，解析速度需要足夠快。
2.2 開源方案? ?
Apache Atlas
Apache Atlas是Hadoop社區為解決Hadoop生態系統的元數據治理問題而產生的開源項目，它為Hadoop集群提供了包括數據分類、集中策略引擎、數據血緣、安全和生命周期管理在內的元數據治理核心能力。官方插件支持HBase、Hive、Sqoop、Storm、Storm、Kafka、Falcon組件。
Hook在運行時采集血緣數據，發送到Kafka。Atlas消費Kafka數據，將關系寫到圖數據庫JanusGraph，并提供REST API。
其中Hive Hook支持表和列級別血緣，Spark需要使用GitHub的hortonworks-spark/spark-atlas-connector，不支持列級別，Presto則不支持。
Linkedin DataHub
WhereHows項目已于2018年重新被LinkedIn公司設計為DataHub項目。它從不同的源系統中采集元數據，并進行標準化和建模，從而作為元數據倉庫完成血緣分析。
社區提供了一個Demo，演示地址：
//demo.datahubproject.io/
與Airflow集成較好，支持數據集級別血緣，字段級別在2021Q3的Roadmap。
驅動力
數說
三、攜程方案
攜程采用了方案二，運行時分析SQL并收集分析結果到Kafka。由于開源方案在現階段不滿足需求，則自行開發。
由于當時缺少血緣關系，對數據治理難度較大，表級別的血緣解析難度較低，表的數量遠小于字段的數量，早期先快速實現了表級別版本。
在16-17年實現和上線了第一個版本，收集常用的工具和引擎的表級別的血緣關系，T+1構建關系。
在19年迭代了第二個版本，支持解析Hive，Spark，Presto多個查詢引擎和DataX傳輸工具的字段級別血緣關系，近實時構建關系。
四、第一個版本-表級別血緣關系
4.1 處理流程
針對Hive引擎開發了一個Hook，實現ExecuteWithHookContext接口，從HookContext可以獲得執行計劃，輸入表，輸出表等豐富信息，異步發送到Kafka，部署的時候在hive.exec.post.hooks添加插件即可。
在17年引入Spark2后，大部分Hive作業遷移到Spark引擎上，這時候針對Spark SQL CLI快速開發一個類似Hive Hook機制，收集表級別的血緣關系。
傳輸工具DataX作為一個異構數據源同步的工具，單獨對其開發了收集插件。
在經過解析處理后，將數據寫到圖數據庫Neo4j，提供元數據系統展示和REST API服務，落地成Hive關系表，供用戶查詢和治理使用。
4.3 痛點
- 隨著計算引擎的增加，業務的增長，表級別的血緣關系已經不滿足需求。
- 覆蓋面不足，缺少Spark ThriftServer , Presto引擎，缺少即席查詢平臺，報表平臺等。
- 關系不夠實時，期望寫入表后可以快速查詢到關系，用戶可以直觀查看輸入和輸出，數據質量系統，調度系統可以根據任務ID查詢到輸出表，對表執行質量校驗任務。
- 圖數據庫Neo4j社區版為單機版本，存儲數量有限，穩定性欠佳，當時使用的版本較低，對邊不能使用索引(3.5支持)，這使得想從關系搜索到關聯的上下游較為麻煩。
驅動力
數說
五、第二版本-字段級別血緣關系
之前實現的第一個版本，對于細粒度的治理和追蹤還不夠，不僅缺少對字段級別的血緣關系，也不支持采集各個系統的埋點信息和自定義擴展屬性，難以追蹤完整鏈路來源，并且關系是T+1，不夠實時。
針對各個計算引擎和傳輸工具DataX開發不同的解析插件，將解析好的血緣數據發送到Kafka，實時消費Kafka，把關系數據寫到分布式圖數據JanusGraph。
4.2 效果
在元數據系統上，可以查看一張表多層級的上下游血緣關系，在關系邊上會有任務ID等一些屬性。
5.1 傳輸工具DataX
阿里開源的Druid是一個 JDBC 組件庫，包含數據庫連接池、SQL Parser 等組件。通過重寫MySqlASTVisitor、SQLServerASTVisitor來解析MySQL / SQLServer的查詢SQL，獲得列級別的關系。
5.2 計算引擎
計算引擎統一格式，收集輸入表、輸出表，輸入字段、輸出字段，流轉的表達式等一些信息。
Hive
參考 org.apache.hadoop.hive.ql.hooks.LineageLogger 實現，異步發送血緣數據到 Kafka。
Atlas的HiveHook也是實現ExecuteWithHookContext接口，從HookContext獲得LineageInfo，也可以參考HIVE-19288 引入的org.apache.hadoop.hive.ql.hooks.HiveProtoLoggingHook，采集更多引擎相關的信息。
其中遇到幾個問題：
- 通過HiveServer2執行獲取的start time不正確
HIVE-10957 QueryPlan's start time is incorrect in certain cases
- 獲取執行計劃空指針，導致收集失敗
SparkHIVE-12709 further improve user level explain獲取執行計劃有可能出現卡住，可以加個調用超時。
前置條件：引入 SPARK-19558 Add config key to register QueryExecutionListeners automatically，實現自動注冊QueryExecutionListener。
實現方式：通過實現QueryExecutionListener接口，在onSuccess回調函數拿到當前執行的QueryExecution，通過LogicalPlan的output方法，獲得所有Attribute，利用NamedExpression的exprId映射關系，對其進行遍歷和解析，構建列級別關系。
覆蓋范圍：Spark SQL CLI、Thrift Server、使用Dataset/DataFrame API（如spark-submit、spark-shell、pyspark）
遇到問題：
- 使用analyzedPlan而不是optimizedPlan，optimizer的執行計劃可能會丟失一些信息，可以在analyzedPlan的基礎上apply一些有助于分析的Rule，如CombineUnions。
- 傳遞的初始化用的hiveconf/hivevar變量被Thrift Server忽略，導致初始化Connection沒有辦法埋點。
驅動力
數說
打上Patch SPARK-13983 ，可以實現第一步，傳遞變量，但是這個變量在每次執行新的statement都重新初始化，導致用戶set的變量不可更新。后續給社區提交PR SPARK-26598，修復變量不可更新的問題。SPARK-13983 Fix HiveThriftServer2 can not get "--hiveconf" and "--hivevar" variables since 2.0SPARK-26598 Fix HiveThriftServer2 cannot be modified hiveconf/hivevar variables
- Drop Table 的限制，DropTableCommand執行成功的時候，該表不一定在之前存在過，如果在Drop之前存在過，元數據也已經被刪除了，無從考證。
在DropTableCommand增加了一個標志位，真正在有執行Drop操作的話再置為True，保證收集的血緣數據是對的。
- 使用Transform用戶自定義腳本的限制
PrestoTransform不像java UDF，只輸入需要用到的字段即可，而是需要將所有后續用到的字段都輸入到自定義腳本，腳本再決定輸出哪些字段，這其中列與列之間的映射關系無法通過執行計劃獲得，只能簡單的記錄輸出列的表達式，如transform(c1,c2,c3) script xxx.py to c4。
開發Presto EventListener Plugin，實現EventListener接口，從queryCompleted回調函數的QueryCompletedEvent解析得到相應的信息。
上線的時候遇到一個無法加載Kafka加載StringSerializer的問題（StringSerializer could not be found）。
Kafka客戶端使用 Class.forName(trimmed, true, Utils.getContextOrKafkaClassLoader()) 來加載Class，優先從當前線程的ContextClassLoader加載，與Presto的ThreadContextClassLoader有沖突，需要初化始KafkaProducer的時候，將ContextClassLoader暫時置為NULL。//stackoverflow.com/a/50981469/1673775
5.3 圖數據庫JanusGraph
JanusGraph是一個開源的分布式圖數據庫。具有很好的擴展性，通過多機集群可支持存儲和查詢數百億的頂點和邊的圖數據。JanusGraph是一個事務數據庫，支持大量用戶高并發地執行復雜的實時圖遍歷。
生產上，存儲我們使用Cassandra，索引使用Elasticsearch，使用Gremlin查詢/遍歷語言來讀寫JanusGraph，有上手難度，熟悉Neo4j的Cypher語法可以使用cypher-for-gremlin plugin。
驅動力
數說
以下是數據血緣寫入圖數據庫的模型，Hive字段單獨為一個Lable，關系型DB字段為一個Label，關系分兩種，LABELWRITE，LABELWRITE_TTL。
只有輸入沒有輸出（Query查詢操作），只有輸出沒有輸入（建表等DDL操作）也會強制綁定一個來源系統的ID及擴展屬性。
在生產上使用JanusGraph，存儲億級的血緣關系，但是在開發過程中也遇到了一些性能問題。
- 寫入速度優化
以DB名+表名+字段名作為唯一key，實現getOrCreateVertex，并對vertex id緩存，加速頂點的加載速度。
- 關系批量刪除
關系LABELWRITETTL表示寫入的關系有存活時間（TTL-Time to live），這是因為在批量刪除關系的時候，JanusGraph速度相當慢，而且很容易OOM。比如要一次性刪除，Label為WRITE，x=y，寫入時間小于等于某個時間的邊，這時候Vertex和Edge load到內存中，容易OOM。g.E().hasLabel("WRITE").has("x",eq("y")).has("publishedDate",P.lte(new Date(1610640000))).drop().iterate()嘗試使用多線程+分批次的方式，即N個線程，每個線程刪除1000條，速度也不太可接受。這時候采用了折中的方案，需要刪除關系用另外一種Label來表示，并在創建Label指定了TTL，由于Cassandra支持cell level TTL，所以邊的數據會自動被刪除。但是ES不支持TTL，實現一個定時刪除ES過期數據即可。
GPU平臺 （PySpark）
通過ETL任務ID，查詢任務ID，報表ID，都可以獲取到輸入，輸出的表和字段的關系。
5.5 局限
使用MapReduce、Spark RDD讀寫HDFS的血緣暫時沒有實現。
思路可以在JobClient.submitJob的時候采集輸入和輸出路徑，又或者通過HDFS的AuditLog、CallerContext來關聯。
5.6 效果
在第一版使用圖的方式展示血緣關系，在上下游關系較多的時候，顯示較為混亂，第二版改成樹狀表格的方式展示。
字段operator在調度系統Zeus被轉換成hive_account，最后輸出是ArtNova報表系統的一張報表。
驅動力
數說
5.4 覆蓋范圍
Zeus調度平臺 （ETL操作INSERT、CTAS，QUERY）
Ad-Hoc即席查詢平臺 （CTAS，QUERY）
報表平臺 （QUERY）
元數據平臺 （DDL操作）
六、實際應用場景
6.1 數據治理
- 通過血緣關系篩選，每天清理數千張未使用的臨時表，節約空間。
- 作為數據資產評估的依據，統計表、字段讀寫次數，生成的表無下游訪問，包括有沒有調度任務，報表任務，即席查詢。
6.2 元數據管理
- 統計一張表的生成時間，而不是統計整個任務的完成時間。
- 數據異常，或者下線一張表、一個字段的時候，可以找到相關的ETL任務或者報表任務，及時通知下游。
- 統計表的使用熱度，顯示趨勢。
6.4 敏感等級標簽
當源頭的數據來自生產DB時，生產DB有些列的標簽已打上了敏感等級，通過血緣關系，下游的表可以繼承敏感等級，自動打上敏感標簽。
七、總結
以上描述了攜程如何構建表和字段級別的血緣關系，及在實際應用的場景。
隨著業務需求和數據的增長，數據的加工流程越來越復雜，構建一套數據血緣，可以輕松查詢到數據之間的關系，進行表和字段級的血緣追溯，在元數據管理，數據治理，數據質量上承擔重要一環。
驅動力
數說
6.3 調度系統
得益于在圖數據庫JanusGraph可以使用關系邊的key作為索引，可以根據任務ID可以輕松獲得該任務輸入和輸出表。
- 當配置一個任務A的依賴任務列表的時候，可以使用推薦依賴，檢查依賴功能，獲得任務A的所有輸入表，再通過輸入的表獲得寫入任務ID列表，即為任務A所需依賴的任務列表。
- 在任務結束后，獲取該任務所有輸出的表，進行預配的規則進行數據質量校驗。
驅動力
風向
大數據時代，數據的來源極其廣泛，各種類型的數據在快速產生，也在爆發性增長，這導致了數據之間的關系也變得越發復雜。
因此對數據工程師來說，如何管理表之間、代碼之間的復雜關系，從而更好地認識和理解業務系統與底層表的關系、底層表的表間關系，理清當前數據（字段、關鍵指標或者數據標簽）從哪里來？到哪里去？搞清楚哪些下游系統在使用這些數據等成為一件很重要的事。
什么是數據血緣，如何做好數據血緣分析？
轉自億信華辰微信公眾號
原文鏈接：
//mp.weixin.qq.com/s/Pzl2ALkZQfcknzbGxpdZUg
而要解決這個事，我們就不得不提到元數據管理中的數據血緣。數據血緣描述了數據的來源和去向，以及數據在多個ETL處理過程中的轉換，因此，數據血緣是組織內使數據發揮價值的重要基礎能力。今天小億就來為大家分享下什么是數據血緣，以及如何做好血緣分析？
驅動力
風向
一、什么是數據血緣
數據血緣，又稱數據血統、數據起源、數據譜系，是指數據的全生命周期中，數據從產生、處理、加工、融合、流轉到最終消亡，數據之間自然形成一種關系。其記錄了數據產生的鏈路關系，這些關系與人類的血緣關系比較相似，所以被成為數據血緣關系。
比如，數據A經過ETL處理生成了數據B，那么我們就說數據A與B有著血緣關系，且數據A是數據B的上游數據，同時數據B是數據A的下游數據。按血緣對象來分，可分為系統級血緣、表級血緣、字段（列）級血緣。不管是結構化數據還是非結構化數據，都必定存在數據血緣關系。
（4）層次性：數據的血緣關系是具備層級關系的，就如同傳統關系型數據庫中，用戶是級別最高的，之后依次是數據庫、表、字段，他們自上而下，一個用戶擁有多個數據庫，一個數據庫中存儲著多張表，而一張表中有多個字段。他們有機結合在一起，形成完整的數據血緣關系。
三、數據血緣分析主要應用在哪方面？
而數據血緣分析是元數據管理的重要應用之一，其梳理系統、表、視圖、存儲過程、ETL、程序代碼、字段等之間的關系，并采用圖數據庫進行可視化展示。簡單地說就是通過可視化展示數據是怎么來的，經過了哪些過程、階段及計算邏輯。
二、數據血緣關系的4個特征
與人類社會中的血緣關系不同，數據的血緣關系包含4個特有的特征：
（1）歸屬性：數據是被特定組織或個人擁有所有權的，擁有數據的組織或個人具備數據的使用權，實現營銷、風險控制等目的。
（2）多源性：這個特性與人類的血緣關系有本質的差異，同一個數據可以有多個來源。來源包括，數據是由多個數據加工生成的，或者由多種加工方式或加工步驟生成的。
（3）可追溯：數據的血緣關系體現了數據的全生命周期，從數據生成到廢棄的整個過程，均可追溯。
驅動力
風向
場景和真實的業務價值。而數據血緣則提供了一種基于數據實際應用的價值評估方法：使用者越多（需求方）、使用量級越大、更新越頻繁的數據往往更有價值。
（1）數據受眾：在血緣關系圖上，右邊的數據流出節點表示受眾，亦即數據需求方，數據需求方越多表示數據價值越大；
（2）數據更新量級：數據血緣關系圖中，數據流轉線路的線條越粗，表示數據更新的量級越大，從一定程度上反映了數據價值的大小；
（3）數據更新頻次：數據更新越頻繁，表示數據越鮮活，價值越高。在血緣關系圖上，數據流轉線路的線段越短，更新越頻繁。
3.數據質量評估
數據血緣清晰的記錄了數據來源以及數據流轉過程中的處理方式和處理規則，能實現對各個數據節點的分析和數據質量評估。
4.數據歸檔參考
數據血緣中記錄了數據的去向，可清晰的掌握數據被消費的情況，一旦數據沒有消費者，那也就意味著數據已經失去價值。此時，可以對數據進行進一步評估，考慮進行歸檔或銷毀處理。
四、如何做好數據血緣關系分析？
數據血緣分析作為數據血緣的應用方式，不是單純的一種技術手段或一個工具，而是一個貫穿數據生命周期的過程，涉及流程、技術、產品等多維度的內容。在此，我們將數據血緣分析分為三大模塊：數據血緣建設，數據血緣分析，數據血緣可視化。
1.數據血緣建設
數據血緣建設并不是去建設數據血緣關系，因為數據血緣關系是數據流轉過程中自動產生的是生而有之的。數據血緣建設的目標是當這些生而有之的數據血緣關系產生時，能被及時、準確的記錄和存儲下來。因此，數據血緣建設并不是一個指定的動作，而是一種管理流程和數據意識，需要延伸到數據產生之前，從數據存儲的設計開始。
數據血緣建設是數據血緣分析的前提條件，準確、完整、及時記錄信息才能帶來有效的血緣分析效果，考慮到部分數據源本身的數據血緣建設準備較差，在某些業務場景中需要人工介入進行梳理。
1.數據溯源
溯源，指的是探尋事物的根本、源頭。我們分析處理的數據，可能來源很廣泛，不同來源的數據，其數據質量參差不齊，對分析處理的結果影響也不盡相同。當數據發生異常，我們需要能追蹤到異常發生的原因，把風險控制在適當的水平。
換句話說，依托于數據血緣的可塑性特點，根據血緣中的數據鏈路關系，可實現指定數據的來源、去向的追溯，可幫助用戶理解數據含義、在全流程上定位數據問題、進行數據關聯影響分析等，解決多層復雜邏輯處理后的數據難以理解、難以應用、出現問題難以定位的問題。
2.數據價值評估
數據價值是數據管理的核心標準，不管是數據交易中的數據定價還是數據安全的保護等級，數據價值都是一個重要的參考因素。因此，如何準確地評估數據價值成為了企業面臨的一大難題。
傳統的數據價值評估，往往完全依靠相關法規要求和業務經驗，缺少在具體應用場景中的評估依據，數據價值評估脫離了數據的應用
驅動力
風向
業務需求的差異將決定血緣分析層次和血緣層級的差異，進而體現在數據血緣圖譜上，因此數據血緣圖譜也許要基于數據血緣層級進行分層展現，直觀的從應用層級、數據層級、字段層級呈現數據的血緣關系。
在具體的應用中，首先業務需求差異和可采集分析的血緣信息的影響，數據血緣圖譜的呈現方式可能存在差異，但其整體形態基本一致：以某個數據為核心節點，體現該節點的數據來源、數據去向、流轉路徑以及路徑中的處理方式和處理。因此，數據血緣可視化視圖中應該當至少包含以下元素：
（1）數據節點
標記數據的具體信息，如所有者、層次信息、終端信息等，根據不同的血緣層次和業務需求，數據節點的信息有所有差異。根據數據類型的不同，數據節點有可以分為：主節點，數據流入節點、數據流出節點。
①主節點：主節點是數據血緣圖譜的核心，是我們當前需要觀察的數據，它只有一個，整個圖譜呈現的就是它的血緣關系；主節點應該是可以且方便切換的。
②數據流入節點：數據流入節點標記主節點的數據來源，是主節點的父節點，它可能有多個甚至多層。
③數據流出節點：數據流出節點標記主節點的數據去向，是主節點的子節點，同樣可能有多個或多層；在數據流出節點中有一種特殊的終端節點，數據到達終端節點后，將不再向別處流轉。
（2）流轉線路
標記數據的流轉路徑，通常從流入節點匯聚到主節點，再主節點擴散到流出節點。在流轉線路中，不僅可標記出數據的流向和流轉關系，還可以通過線路的粗細、長短等標記數據量級和更新頻次。
（3）處理節點
標記數據流轉過程中的處理方式和處理規則，通常用于數據節點之間的流轉線路中。通過處理節點，可以直觀地了解到數據在兩個節點之間流轉時，通過什么樣的規則進行了怎樣的處理。
2.數據血緣分析
數據血緣分析針對數據流轉過程中產生并記錄的各種信息進行采集、處理和分析，對數據之間的血緣關系進行系統性梳理、關聯、并將梳理完成信息進行存儲。考慮到企業的數據龐雜問題，數據血緣分析往往需要借助工具或系統展開，實現血緣信息數據的自動采集、自動分析。
數據血緣分析通常會按數據血緣的層級進行，層級基于業務需求和某些數據特性可能有差別，常見的分析層級為應用（業務系統）級、數據（表/文件）級和字段級。數據血緣分析的目標是實現數據來源的精確追蹤、流轉過程的準確還原、數據去向的精準定位。
3.數據血緣可視化
血緣分析完成后，需要依靠可視化技術將分析結果清晰、直觀地傳遞給用戶，幫助客戶進行二次分析和具體應用。數據血緣圖譜是血緣分析中最常用可視化方案。
驅動力
風向
億信華辰元數據管理平臺EsPowerMeta是基于B/S架構的軟件平臺，架構分為5層，數據源層、采集層、數據層、功能層和訪問層，其不僅適配各種數據庫、各類ETL、各類數據倉庫和報表產品，還適配各類結構化或半結構化數據源。
五、數據血緣分析時的注意事項
數據血緣分析時，需要考慮以下幾個方面：
1.全面性
數據處理過程實際上是程序對數據進行傳遞、運算演繹和歸檔的過程，數據的流動性和數據間的復雜關系，將導致某一數據的細微變動引起多個系統的數據發生變化。為了確保數據血緣的完整性，必須將整個系統能夠作為數據血緣的分析對象，真正做到追源頭溯尾。
2.及時性
據和數據之間的關系可能是隨時變動的 ，為了保證數據血緣的準確性和可用性，血緣分析必須與數據保持同步更新，確保數據血緣的分析結果面向最新的數據和數據關系。
3.適用性
血緣分析技術和實現有多種，分析的廣度、深度、維度也有不同，但所有的技術都是為需求服務的，血緣分析需要在實現需求目標的前提下展開。
六、小結
隨著數據的爆發式增長，數據之間的關系也變得越發復雜。在這樣的背景下，具備可塑性、歸屬性等特征的數據血緣將數據治理過程中發揮越來越大的作用。數據的血緣對于分析數據、跟蹤數據的動態演化、衡量數據的可信度、保證數據的質量具有重要的意義。
但數據血緣應用需要依賴豐富的可分析數據、強大的數據采集和血緣分析能力、清晰直觀的血緣圖譜，是一個貫穿數據生命周期的持續性工程。這里億信華辰元數據管理平臺EsPowerMeta就可以幫助你。
另外，元數據管理模塊還提供了豐富的元數據分析功能，包括血緣分析、影響分析、全鏈分析、關聯度分析、屬性值差異分析等，分析出元數據的來龍去脈，快速識別元數據的價值，掌握元數據變更可能造成的影響，以便更有效的評估變化帶來的風險，從而幫助用戶高效準確的對數據資產進行清理、維護與使用！
血緣分析可以滿足許多行業(包括醫療、金融、銀行和制造業等)對所呈現數據的特殊監管及合規性要求。
最后，影響度分析，也是較為血緣關系應用的一部分，其用來分析數據的下游流向。當系統進行升級改造時，能動態數據結構變更、刪除及時告知下游系統。通過依賴數據的影響性分析，可以快速定位出元數據修改會影響到哪些下游系統，哪些表和哪些字段。從而減少系統升級改造帶來的風險。
驅動力
一線
分享嘉賓｜彭洪劍 字節跳動 DataLeap 研發工程師
編輯整理｜黃如飛 迅雷網心科技
出品社區｜DataFun
導讀：DataLeap是火山引擎數智平臺VeDI旗下的大數據研發治理套件產品，幫助用戶快速完成數據集成、開發、運維、治理、資產、安全等全套數據中臺建設，降低工作成本和數據維護成本、挖掘數據價值、為企業決策提供數據支撐。
數據血緣是幫助用戶找數據、理解數據以及使數據發揮價值的基礎能力。本文將聚焦數據血緣存儲和血緣導出，分享在存儲和導出數據血緣的模型設計以及優化，并介紹字節跳動在數據血緣建設過程中所遇到的挑戰和技術實現以及數據血緣的具體用例，具體包括數據血緣模型、數據血緣優化、數據血緣用例、未來展望四個部分。本文介紹的數據血緣能力和實踐，目前大部分已通過火山引擎DataLeap對外提供服務，歡迎大家點擊閱讀原文體驗。
字節跳動數據血緣技術實現與具體用例
轉自知乎DataFunTalk賬號
原文鏈接：
//zhuanlan.zhihu.com/p/609364769
01/數據血緣模型
首先介紹一下字節內部數據血緣遇到的挑戰。
隨著公司業務擴張、用戶數量持續增長以及數倉建設不斷完善，元數據種類和數量也經歷了非線性增長，并在此期間涌現出一些問題。
第一，擴展性。好的擴展性可以在面對新型元數據血緣時保證快速接入和迭代，而擴展性不佳則會導致在業務變化時需要不停地重構來適應業務，對業務造成很多影響。
第二，性能。一個模型本身的插入和更新效率會直接影響數據的導入導出的流程，這些都會帶來更直觀的業務上的感受，所以需要考慮如何保證環節高效性。
驅動力
一線
第三，時效性。很多應用場景對正確率格外敏感，如果血緣數據有延遲，其實就等于血緣的不準確，會對業務造成影響。
最后，賦能業務。技術服務于業務，業務增長會幫助技術升級迭代，技術創新也會促進業務發展。在字節內部，我們會根據業務特點，考慮業務需要，將技術成本與業務收益做平衡，最終做出數據模型決策。總而言之，數據模型沒有完美的方案，只有最適合企業自身業務、適合當前階段的數據血緣方案。
2. 數據血緣模型 – 展示層
字節內部有很多種元數據類型，包括線上傳統的離線數倉Hive、OLAP分析引擎ClickHouse，以及實時側元數據，如Kafka和ES以及Redis。這些元數據所對應的表/Topic都統一維護在元數據平臺上，目前血緣展示層是以這些數據資產作為主視角。
如下圖所示，中心數據資產包含普通字段和分區字段等信息，還可以從圖中看到中心資產上下游資產信息，上游有哪些相關的表，下游有哪些相關的topic或者表。圖中資產和資產之間連接的邊，代表的是生產關系：1個任務讀取了上游的資產，產生了下游的資產。
在圖中，資產節點用圓形表示，任務節點用菱形表示。具體舉個例子：
（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）創建子任務的節點，把幾個字段節點連接起來，每個子任務節點會和子任務節點通過從屬關系的邊來進行連接，字段節點和每一個表資產節點也會通過從屬關系的邊進行連接。本身這個任務和資產之間會有消費生產關系的邊連接。
以上就是整個血緣數據模型在抽象層的展現。
這樣設計是有以下好處：
首先，任務資產的抽象是對生產平臺上和在各種任務平臺上廣泛直接的任務關系的抽象，當再去接入新元數據或新任務類型時，我們只需要擴展當前抽象的資產節點和任務節點，即可把新加入進來的任務鏈路所對應的血緣接入到存儲中。這種數據模型也能方便地更新和刪除血緣鏈路，維持時效性。
其次，在字節內部的血緣建設中，還存在接入各種血緣鏈路的難點。基于目前設計可以減少開發成本，在更新血緣的時只需要更新中心任務節點，并且把中心任務節點所對應的子任務節點的邊也做相應的更新和刪除，就完成了血緣信息的插入和更新。
3. 數據血緣模型 – 抽象層
再來介紹，火山引擎DataLeap如何設計抽象層。
抽象層是整個數據血緣的數據模型，主要包含兩種節點，一種是資產節點，另外一種是任務節點。
驅動力
一線
4. 數據血緣模型 – 實現層
在實現層，火山引擎 DataLeap 主要基于 Apache Atlas 來實現。Apache Atlas 本身也是一個數據治理的產品，它預定義了一些元數據的類型，整個類型系統有比較好的擴展性。在 Atlas 本身的 DataSet 和 Process 元數據定義上，我們引入了字節內部獨有的業務元數據的屬性和子任務定義，最終把任務相關的元數據存儲起來。
Atlas 本身也支持血緣的查詢能力，通過 Apache Atlas 暴露的接口來轉換成圖上查找某個節點對應血緣關系的邊，以此實現血緣查詢。
以上就是整個數據血緣模型的設計部分。通過這樣的數據血緣模型，我們可以減少新的數據血緣鏈路接入開發成本，同時也很方便更新和刪除血緣。
02/數據血緣優化
第二部分將主要介紹在火山引擎 DataLeap 中典型的數據血緣優化，包括實時數據血緣更新優化、血緣查詢優化和血緣數據開放式導出。
5. 數據血緣模型 – 存儲層
在存儲層，目前主要基于 Apache Atlas 原生圖數據庫——JanusGraph。JanusGraph 底層支持 HBase。我們將每條邊的關系作為兩邊的資產節點的屬性，存入到對應 RowKey 的獨立 cell 中。
另外，我們也對存儲做了相關的改造，如字節內部自研的存算分離 key-value 存儲。我們也在獨立環境中會做輕量級部署，同時基于性能或成本，以及部署復雜度，把存儲切換為 OLTP 數據庫，比如 MYSQL 數據庫。
驅動力
一線
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 在查詢血緣節點回來之后，需要進行一個映射，映射到具體的實體上去拿回它的一些屬性，在這個過程中我們也加入了異步批量的操作方式來進一步的提升性能。經過優化之后，我們在對一些引用熱度比較高的表資產節點或者查詢表資產或者對應列的時候，效率都可以得到明顯提升。
03/數據血緣用例
接下來第三部分主要介紹數據血緣的具體用例，介紹字節內部是如何使用數據血緣的。在字節內部數據血緣用例的典型使用領域主要包括：資產領域、開發領域、治理領域和安全領域。
1. 數據血緣用例 – 資產領域
首先在資產領域，數據血緣主要應用在資產熱度的計算。在資產熱度計算時，有些資產會被頻繁消費和廣泛引用。某個資產被眾多下游引用，是自身權威性的證明，而這種權威性的證明需要一種定量的度量，因此需要引入了“資產熱度”的概念。資產熱度本身是參考網頁排名算法PageRank算法實現的，同時我們也提供了資產熱度值，根據資產的下游血緣依賴的情況，定義了資產引用的熱度值，如果某個資產引用熱度值越高，就代表了這個資產更應該被信任，數據更可靠。
另外，血緣也可以幫助我們理解數據。比如用戶在元數據平臺或者血緣平臺上查詢數據資產節點的時候，可能是想要進行下一步的作業開發或者是排查一些問題，那么他就需要首先找到這個數據資產。用戶不了解數據產生的過程，就無法了解數據的過去和未來。也就是哲學上經典的問題：這個表到底是怎么來的？它具體有哪些含義？我們就可以通過數據血緣來找到具體表的上下游信息。
3. 血緣數據開放式導出
第三個優化點是在血緣的導出上提供了多種方式，除了在頁面上可視化的查詢血緣的能力之上，我們也陸續提供了很多使用血緣的方式，包括下載到 Excel,或者查詢這個血緣數據導出的數倉表，或者直接使用服務平臺側開放的 API，還可以訂閱血緣變更的 topic，來直接監聽血緣的變更，下游的用戶可以根據自己的開發場景，以及業務對準確率、覆蓋率的要求，來決定到底使用哪種方式來消費血緣數據。
驅動力
一線
2. 數據血緣用例 – 開發領域
數據血緣的第二個用例是開發領域。在開發領域中會有兩個應用：影響分析和歸因分析。
（1）影響分析應用
影響分析應用是事前分析。也就是當我們對表資產做一些變更的時候，在事前需要感知這個變更的影響，處于血緣上游的資產負責人在修改對應的生產任務的時候s，就需要通過血緣來查看自己資產的下游，來判斷這個資產修改的影響，針對修改的兼容性或者某條鏈路的重要性，來對應的做一些通知的操作，否則會因為缺少通知而造成嚴重的生產事故。
（2）歸因分析應用
歸因分析應用是事后分析。比如當某個任務所產生的表出現了問題，我們就可以通過查詢血緣的上游，逐級尋找到血緣上游改動的任務節點或者資產節點來排查出造成問題的根因是什么。在發現和定位出了問題之后，我們會去修復數據，在修復數據的時候，我們可以通過血緣來查找任務或者表的依賴關系，對于離線數倉可能就需要重跑某個分區的輸出數據，我們需要根據血緣來劃定范圍，只需要回溯對應受影響的下游任務就可以了，減少一些不必要的資源浪費。
3. 數據血緣用例 – 治理領域
在治理領域應用中，血緣關系在字節內部也有典型的使用場景：鏈路狀態追蹤和數倉治理。
（1）鏈路狀態追蹤
比如在重要的節日或者活動的時候，我們需要事先挑選一些需要重要保障的任務，這時就需要通過血緣關系來梳理出鏈路的主干，即核心鏈路。然后去對應的做重點的治理和保障，比如簽署 SLA。
（2）數倉治理
在數倉建設方面，也會使用血緣來輔助一些日常的工作，比如規范化治理。數倉規范化治理包括清理數倉中分層不合理的引用，或者是數倉分層整體不規范，存在一些冗余的表。比如，兩個表來自同一個上游表，但是它們在不同層級，這些冗余的表就需要被清理掉的，這種場景就是使用血緣來輔助治理的一個典型用例。
驅動力
一線
4. 數據血緣用例 – 安全領域
安全相關問題在一些跨國或國際化產品企業會比較常見，每個國家地區的安全政策是不一樣的。我們在做安全合規檢查時，每個資產都有對應的資產安全等級，這個資產安全等級會有一定的規則，比如我們規定下游資產的安全等級一定高于上游的安全資產等級，否則就會有權限泄露問題或者是其他的安全問題。基于血緣，我們可以掃描到這些規則涉及的資產下游，來配置相應掃描規則，然后進行安全合規排查，以便做出對應的治理。
另外，血緣在標簽傳播方面也有所應用，可以通過血緣的傳播鏈路來進行自動化工作，比如對資產進行安全標簽打標的時候，人工的打標方式會相對比較繁瑣而且需要關注鏈路的信息，那么就可以借助血緣信息來完成自動的打標，比如配置一些規則讓安全標簽明確場景、節點和終止規則。
04/未來展望
1. 血緣技術趨勢
在業界，血緣的發展趨勢主要關注以下幾點：
（1）通用的血緣解析能力
血緣是元數據平臺的核心能力，很多時候元數據平臺會接入多樣化元數據，這些業務元數據也會依賴血緣不同的血緣解析能力，現在的解析往往是依賴各個引擎團隊來支持的，但是其實在更加廣泛的場景，我們需要有一個兜底的方案來提供一個更通用的血緣解析能力，所以未來我們會提供標準 SQL 解析引擎，以達到通用解析的目的。
（2）非侵入式的非 SQL 類型血緣采集
除了可解析的 SQL 或可配置的任務，日常還會涉及到代碼類型的任務，如 JAR 任務。JAR 任務現在的解析方式是根據一些埋點信息或者用戶錄入的上下游信息去完成血緣的收集，這部分未來會出現一種非侵入式的非 SQL 類型血緣采集的技術，比如 Flink 或者 Spark 的 JAR 任務，我們可以在任務運行時拿到這些血緣，來豐富平臺側血緣的數據。
（3）時序血緣
時序血緣也是字節內部的考慮點。目前血緣信息圖數據庫相當于是對當前血緣拓撲的一次快照，其實血緣是會變化的，比如用戶在修
以上這些都是數據血緣在字節內部的一些典型用例，我們也在探索更多的使用場景。
根據其對血緣質量的要求，這些場景被分成了幾個區域。根據血緣覆蓋率、血緣準確率的要求，可以分為四個象限，比如其中一類是需要覆蓋全鏈路且血緣準確率要求異常高的，例如開發項的兩個用例，因為在開發項的用例中，血緣的延遲會嚴重影響決策上的判斷，對血緣質量要求是最高的。
血緣建設過程也會劃分不同的建設時期，我們可以根據現在要支持的業務場景和業務優先級來輔助制定血緣建設規劃，決定血緣迭代的節奏和具體方向。
驅動力
一線
改一個任務的時候，上線任務變更或是修改表結構，然后對應的修改自己生產任務的時候，涉及到時序的概念，這個時序可以方便我們去追溯一些任務的變化，支持我們去做事前事后影響分析，所以時序血緣如何在圖數據庫中引入也是未來的一個趨勢。
2. 數據血緣的應用趨勢
（1）標準化
前文提到很多應用場景的底層能力都是通過接口來獲得，獲得接口的數據也涉及到應用的標準化，標準化的應用可以讓我們移植到更多的業務上，提供更好的血緣數據分析幫助。
（2）端到端的血緣打通
另一個應用趨勢是端到端的血緣能力，現在平臺主要接入資產節點，端到端則會涉及到更上游，如 App 端和 Web 端采集的數據，或者是下游報表，以及 API 之后最終的節點。在血緣收集中，這部分信息目前缺失，端到端血緣打通將是未來應用上的趨勢之一。
3. 云上的全鏈路血緣能力
在字節跳動內部，血緣能力會進行上云，云上涉及各類數據類型，因此血緣發展方向之一是把各類異構數據類型統一接入，并且支持云上用戶來自定義接入新類型血緣。
同時，當數據應用標準化之后，也可以把血緣應用提供給云上用戶，云上用戶也可以反向加入到血緣應用的開發中，最后把數據血緣模型作為一種標準來推廣，由此衍生出更好的血緣應用、血緣服務生態。
驅動力
熱點
數據血緣關系，從概念來講很好理解，即數據的全生命周期中，數據與數據之間會形成多種多樣的關系，這些關系與人類的血緣關系類似，所以被稱作數據的血緣關系。
數據治理：數據血緣關系
轉自與數據同行微信公眾號 作者歪老師
原文鏈接：
//mp.weixin.qq.com/s/RhdAkq3f04KIi8tktZ_y5A
從技術角度來講，數據a通過ETL處理生成了數據b，那么，我們會說，數據a與數據b具有血緣關系。不過與人類的血緣關系略有不同，數據血緣關系還具有一些個性化的特征。
歸屬性
數據是被特定組織或個人擁有所有權的，擁有數據的組織或個人具備數據的使用權，實現營銷、風險控制等目的。
多源性
這個特性與人類的血緣關系有本質上的差異，同一個數據可以有多個來源（即多個父親），來源包括，數據是由多個數據加工生成，或者由多種加工方式或加工步驟生成。
可追溯
數據的血緣關系體現了數據的全生命周期，從數據生成到廢棄的整個過程，均可追溯。
層次性
數據的血緣關系是具備層級關系的，就如同傳統關系型數據庫中，用戶是級別最高的，之后依次是數據庫、表、字段，他們自上而下，一個用戶擁有多個數據庫，一個數據庫中存儲著多張表，而一張表中有多個字段。它們有機地結合在一起，形成完整的數據血緣關系。
如下圖中某學校學生管理系統后臺數據庫的ER圖示例，學生的學號、姓名、性別、出生日期、年級、班級等字段組成了學生信息表，學生信息表、教師信息表、選課表之間通過一個或多個關聯字段組成了整個學生管理系統后臺的數據庫。
驅動力
熱點
不管是結構化數據，還是非結構化數據，都具有數據血緣關系，他們的血緣關系或簡單直接，或錯綜復雜，都是可以通過科學的方法追溯的。
以某銀行財務指標為例，利息凈收入的計算公式為利息收入減去利息支出，而利息收入又可以拆分為對客業務利息收入、資本市場業務利息收入和其他業務利息收入，對客業務利息收入又可以細分為信貸業務利息收入和其他業務利息收入，信貸業務利息收入還可以細分為多個業務條線和業務板塊的利息收入。
如此細分下去，一直可以從財務指標追溯到原始業務數據，如，客戶加權平均貸款利率和新發放貸款余額。如果利息凈收入指標發現數據質量問題，其根因可以通過下圖一目了然發現。
數據血緣追溯不只體現在指標計算上，同樣可以應用到數據集的血緣分析上。不管是數據字段、數據表，還是數據庫，都有可能與其他數據集存在著血緣關系，分析血緣關系對數據質量提升有幫助的同時，對數據價值評估、數據質量評估以及后續對數據生命周期管理也有較大的幫助和提高。
從數據價值評估角度來看，通過對數據血緣關系的梳理，我們不難發現，數據的擁有者和使用者，簡單地來看，在數據擁有者較少且使用者（數據需求方）較多時，數據的價值較高。在數據流轉中，對最終目標數據影響較大的數據源價值相對較高。同樣，更新、變化頻率較高的數據源，一般情況下，也在目標數據的計算、匯總中發揮著更高的作用，那可以判斷為這部分數據源具有較高的價值。
從數據質量評估角度來看，清晰的數據源和加工處理方法，可以明確每個節點數據質量的好壞。
從數據生命周期管理角度來看，數據的血緣關系有助于我們判斷數據的生命周期，是數據的歸檔和銷毀操作的參考。
考慮到數據血緣的重要性和特性，以一般來講，我們在血緣分析時，會關注應用（系統）級、程序級、字段級三個層次間數據間的關系。比較常見的是，數據通過系統間的接口進行交換和傳輸。
例如下圖，銀行業務系統中的數據，由統一數據交換平臺進行流轉分發給傳統關系型數據庫和非關系型大數據平臺，數據倉庫和大數據平臺匯總后，交流各個應用集市分析使用。其中涉及大量的數據處理和數據交換工作：
驅動力
熱點
在分析其中的血緣關系時，主要考慮以下幾個方面：
1、全面性
如上圖所示，數據處理過程實際上是程序對數據進行傳遞、運算演繹和歸檔的過程，即使歸檔的數據也有可能通過其他方式影響系統的結果或流轉到其他系統中。為了確保數據流跟蹤的連貫性，必須將整個系統集作為分析的對象。
2、靜態分析法
本方法的優勢是，避免受人為因素的影響，精度不受文檔描述的詳細程度、測試案例和抽樣數據的影響，本方法基于編譯原理，通過對源代碼進行掃描和語法分析，以及對程序邏輯涉及的路徑進行靜態分析和羅列，實現對數據流轉的客觀反映。
3、接觸感染式分析法
通過對數據傳輸和映射相關的程序命令進行篩選，獲取關鍵信息，進行深度分析。
4、邏輯時序性分析法
為避免冗余信息的干擾，根據程序處理流程，將與數據庫、文件、通信接口數據字段沒有直接關系的傳遞和映射的間接過程和程序中間變量，轉換為數據庫、文件、通信接口數據字段之間的直接傳遞和映射。
5、及時性
為了確保數據字段關聯關系信息的可用性和及時性，必須確保查詢版本更新與數據字段關聯信息的同步，在整個系統范圍內做到“所見即所得”。
一般來說，數據血緣的用途主要體現以下幾個方面：
1、合規需求，這是監管部門的需求，為了監管合規，數據流動的各點和來源，都是重點需要監管的。
2、影響分析和質量問題分析，這個數據開發部們的核心需求，隨著數據應用越來越多，數據的流動鏈越來越長，一個源頭的核心業務的改動，下游各分析應用必須保持同步，沒有影響分析，就會各個數據服務造成異常訪問的情況。
3、數據安全和隱私，這個是數據合規部門的需求，哪些數據是需要脫敏的，這個要保持全流通所有域的管控。
4、遷移項目，這個出現在特定老項目終止需要新項目接管的情況下，沒有數據流動映射表，就會大量花時間去整理，也很難保證遷移的完整性和正確性。
5、自服務分析，數據分析團隊為了確定數據可信程度，那么數據的來源是數據可信的重要依據。
數據血緣系統的構建和維護是一個較重的系統工程，筆者認為其是數據治理工作中的流沙之地，不小心會陷入這個坑之中，尤其是技術完美人格類型的負責人，這是因為數據血緣的工作需要考慮的因素很多。
為了最大程度降低項目失敗的風險，我們需要考慮數據血緣的服務用戶對象，確定業務方面和技術方面的血緣優先，需要考慮到細節程度，覆蓋率，變化頻率，同時還要考慮人員流動，組織部門，技術架構等情況，制定最適合我們自己的策略。
數據血緣的收集方法主要有以下幾種：
1、自動解析
自動解析當前主要的收集方法，具體就是解析SQL語句，存儲過程，ETL過程等文件。因為復雜代碼和應用環境等原因，根據國際廠商的經驗，自動解析可以覆蓋到企業數據的70-95%，目前無法做到100%，因此患有技術潔癖的負責人容易犯下這個錯誤，即追求極高的覆蓋率。
驅動力
熱點
2、系統跟蹤
這個方法就是通過數據加工流動過程中，加工主體工具負責發送數據映射，這樣做的極大好處是收集精準，及時，細粒度可支持，不過限制就是不是每個工具都可以集成。這種方法一般鑒于統一的加工平臺，比如Informatica可以管理自己的全數據血緣周期。
3、機器學習方法
這個方法是基于數據集之間的依賴關系，計算數據的相似度。這個方法的好處是對工具和業務沒有依賴，缺點準確率需要人工確認，一般可以做到3-8的數據可以分析發現。
4、手工的收集
在整個項目中，一般有5%是需要手工來做的。
目前的數據血緣大多是基于技術的梳理，一般服務技術人員的需求。隨著數據服務走向前臺，服務業務分析和CDO的業務數據血緣，目前已經有相關產品，通過數據的語義分析，將技術元數據映射到業務元數據上，將血緣以業務流程方式發布共享出來，輔助商務決策，這是未來的發展方向之一。
--END--
北京市朝陽區朝外大街甲6號萬通中心D座25層
聯系電話：15801365057
投稿地址：kai.zhao@yeepay.com
--數據驅動變革--
增值電信業務經營許可證：陜B2-20210327 |