《數據資產管理核心技術與應用》讀書筆記-第三章：數據血緣

《數據資產管理核心技術與應用》是清華大學出版社出版的一本圖書，全書共分10章，第1章主要讓讀者認識數據資產，瞭解數據資產相關的基礎概念，以及數據資產的發展情況。第2～8章主要介紹大數據時代數據資產管理所涉及的核心技術，內容包括元數據的採集與存儲、數據血緣、數據質量、數據監控與告警、數據服務、數據許可權與安全、數據資產管理架構等。第9～10章主要從實戰的角度介紹數據資產管理技術的應用實踐，包括如何對元數據進行管理以發揮出數據資產的更大潛力，以及如何對數據進行建模以挖掘出數據中更大的價值。

圖書介紹：數據資產管理核心技術與應用

今天主要是給大家分享一下第三章的內容：

第三章的標題為數據血緣

內容思維導圖如下：

 1、獲取數據血緣的技術實現

1.1、如何從Hive中獲取數據血緣

Hive 是典型的數據倉庫的代表，也是大數據中離線數據分層模型設計的代表，並且支持HQL的數據處理和計算，所以Hive為了方便用戶做數據跟蹤，在底層設計時，其實就考慮到了數據血緣跟蹤這個問題。Hive 自身的血緣在其源碼中主要通過org.apache.hadoop.hive.ql.hooks.LineageLogger.java 來輸出，org.apache.hadoop.hive.ql.hooks.LineageLogger.java代碼中主要處理的過程如下圖所示，血緣主要通過edges（DAG圖的流向）和vertices（DAG圖的節點）來進行輸出。《數據資產管理核心技術與應用》讀書筆記

在org.apache.hadoop.hive.ql.hooks.LineageLogger.java的源碼中定義了其支持的4種SQL操作類型，分別為QUERY（查詢）、CREATETABLE_AS_SELECT（將Select 查詢創建為一張表）、ALTERVIEW_AS（修改視圖）、CREATEVIEW（創建視圖）。

org.apache.hadoop.hive.ql.hooks.LineageLogger.java在解析和生成edges（DAG圖的流向）和vertices（DAG圖的節點）信息時，會判斷QueryPlan（查詢計劃）的類型是否是支持的4種SQL操作類型中的一種，如果不是的話，就不會解析和生成edges和vertices。

org.apache.hadoop.hive.ql.hooks.Hook.java是Hive提供的Hook（鉤子）功能，用於在Hive 任務執行前或者執行後，註入自定義的的操作代碼。

具體的代碼實現，可以直接參考紙質書，這裡不再贅述。

1.2、 從Spark 執行計劃中獲取數據血緣

Spark底層生成執行計劃以及處理執行計劃的過程如下圖所示。

從圖中可以看到，

1、 執行SQL語句或者Data Frame時，會先生成一個Unresolved Logical Plan，就是沒有做過任何處理和分析的邏輯執行計劃，僅僅會從SQL語法的角度做一些基礎性的校驗。

2、 之後通過獲取Catalog的數據，對需要執行的SQL語句做表名、列名的進一步分析校驗，從而生成一個可以直接運行的邏輯執行計劃。

3、 但是Spark底層會有個優化器來生成一個最優的執行操作方式，從而生成一個優化後的最佳邏輯執行計劃。

4、 將最終確定下來的邏輯執行計劃轉換為物理執行計劃，轉換為最終的代碼進行執行。

Spark的執行計劃其實就是數據處理的過程計劃，會將SQL語句或者DataFrame 做解析，並且結合Catalog一起，生成最終數據轉換和處理的代碼。所以可以從Spark的執行計劃中，獲取到數據的轉換邏輯，從而解析到數據的血緣。但是spark的執行計劃都是在spark底層內部自動處理的，如何獲取到每次Spark任務的執行計劃的信息呢？其實在Spark底層有一套Listener的架構設計，可以通過Spark Listener 來獲取到spark 底層很多執行的數據信息。

在spark的源碼中，以Scala的形式提供了一個org.apache.spark.sql.util.QueryExecutionListener  trait （類似Java 語言的介面），來作為Spark SQL等任務執行的監聽器。在org.apache.spark.sql.util.QueryExecutionListener  中提供瞭如下表所示的兩個方法。《數據資產管理核心技術與應用》讀書筆記

因此可以借用QueryExecutionListener  來主動讓Spark在執行任務時，將執行計劃信息推送到自己的系統或者資料庫中，然後再做進一步的解析，如下圖

具體的代碼實現，由於代碼較多，請參考紙質書。

1.3、 從Spark  SQL語句中獲取數據血緣

在Spark任務處理中，通過SQL語句來實現離線的ETL 數據處理是其在大數據中最常見的應用方式，如下圖所示針對這種應用場景，可以直接通過獲取Spark 中運行的SQL語句，然後通過解析SQL語句，並且結合Catalog，來分析出SQL 語句中包含的輸入表和輸出表的數據血緣關係。《數據資產管理核心技術與應用》讀書筆記

有了通過SQL語句來解析血緣的思路後，需要解決的問題就是怎麼自動抓取到Spark中運行的SQL語句。在上面的敘述中，有提到過Spark 有Listener的機制，org.apache.spark.sql.util.QueryExecutionListener只是Listener中的一種，可以通過Listener的方式自動獲取到Spark的相關執行信息。在Spark中提供了org.apache.spark.scheduler.SparkListener這個底層抽象類來供上層代碼監聽Spark在整個生命執行周期中的相關事件消息，如下圖所示。

獲取Spark 執行的SQL 語句的整體流程總結如下圖

具體的代碼實現，由於代碼較多，請參考紙質書。

1.4、 從Flink中獲取數據血緣

FlinkSQL 在底層執行時，大概包含瞭如下的5個步驟，其底層執行過程和SparkSQL非常的類似。

• 第一步：對即將執行的SQL語句做語法分析，此時會通過Apache Calcite 將SQL語句直接轉換為AST (Abstract Syntax Tree的簡寫，翻譯過來就是抽象語法樹），也就是Calcite 中的SqlNode節點樹。Calcite是一個開源的SQL解析工具，Flink在底層技術實現時，集成了Calcite作為其底層的SQL語句解析器， Calcite的Github 地址為https://github.com/apache/calcite/，相關的更多介紹可以參考官方文檔網址：https://calcite.apache.org/docs/。
• 第二步：根據查詢到的元數據對SQL語句中的語法進行校驗，通過第一步中獲取到的SqlNode節點樹中的信息來獲取SQL語句中包含的表、欄位、函數等信息，然後通過和元數據進行比對來判斷SQL語句中包含的表、欄位等信息在元數據中是否存在。
• 第三步：通過結合元數據信息對SqlNode節點樹的進一步解析得到關係表達式樹，生成初步的邏輯執行計劃。
• 第四步：對第三步生成的邏輯執行計划進行進一步優化得到最優的邏輯執行計劃，這一步得到結果還是關係表達式樹。
• 第五步：將邏輯執行計劃轉變為物理執行計劃，提交給Flink 集群進行執行。《數據資產管理核心技術與應用》讀書筆記

具體的代碼實現，由於代碼較多，請參考紙質書。

1.5、   從數據任務的編排系統中獲取數據血緣

        數據任務的編排系統通常是對不同的數據節點類型的任務進行前後運行順序以及依賴關係的編排，如下圖所示。

具體的代碼實現，由於代碼較多，請參考紙質書。

2、數據血緣的存儲模型與展示設計

從架構設計的角度來看，血緣數據存儲需要註意如下幾點:《數據資產管理核心技術與應用》讀書筆記

• 可擴展性：支持對數據血緣的源端進行擴展，比如當前只需要支持 Hive、Spark執行計劃、Spark SQL等，但是未來可能會新增其他數據血緣來源。如果出現新的數據血緣來源時，要做到對現有的設計不做改動便可支持。
• 可跟蹤性：需要記錄數據血緣的變更記錄，方便將來做追蹤，比如數據血緣出現變更時，需要將其變更的過程記錄下來，而不是在數據血緣發生變化後，直接替換現有的已經採集入庫的數據血緣關係。
• 可維護性：支持手動維護，比如支持人工維護數據血緣或者數據血緣採集錯誤時，支持人工修改。

數據血緣的採集和處理的過程通常如下圖所示，實時獲取原始數據，然後發送到類似Kafka這樣的消息隊列中，然後對原始數據進行解析，生成血緣數據，然後入庫保存。

在血緣數據解析入庫後，就可以對數據血緣做展示了，關於數據血緣的展示設計參考如下圖所示，一般需要註意如下幾點：

• 支持表級血緣，預設展示表級血緣關係，選擇單個表時，還可以點擊查看該表的上游血緣或者下游血緣。
• 詳情中支持欄位級血緣展示，點擊圖中表的欄位詳情時，可以繼續展開顯示欄位級的血緣關係。
• 血緣關係中，支持點擊查看血緣的解析來源，比如SparkSQL語句、Spark執行計劃等。

從下圖可以看到表與表之間以及欄位與欄位之間的血緣關係展示。當某一張表發生變更時，很容易的就知道對下游或者上游的哪些表和欄位產生影響，從而可以加快很多問題的處理和定位。在使用某張表的數據時，也能追溯到該表的原始數據表以及經過了哪些中間表的處理，數據的鏈路變得非常清晰，對數據的使用者來說，產生了極大的幫助。《數據資產管理核心技術與應用》讀書筆記