1、前言

大數據時代，數據的來源極其廣泛，各種類型的數據在快速產生，數據也是爆發性增長。從數據的產生，通過加工融合流轉產生新的數據，到最終消亡，數據之間的關聯關系可以稱之為數據血緣關系。在數據中臺的大背景下，數倉的開發者經常需要解決以下問題：

面對成百上千張的數據表，不知道該如何關聯，也不知道這些表具有什么業務價值

執行過長，慢的無法忍受的SQL腳本，卻不敢輕易進行整改

數據表是否包含機密數據需要被清理，以及這些機密數據是否被轉存導致權限放大

其實，以上的這些問題都可以統一歸類為數據發現問題。大部分企業會針對離線數倉任務進行SQL分析，構建表和字段的血緣關系，數據發現包括但不限于: 數據 表/列的業務分類分級和機密字段識別等。

2、數據血緣的基本概念

數據血緣(Data Lineage)，指的是數據從產生、ETL處理、加工、融合、流轉到最終消亡，數據之間自然形成一種關系。這些關系就是描述數據的數據（元數據）。掌握了這個元數據，就能最大程度的做好數據的應用和管理。

tips：有童鞋對元數據感興趣的，可以看這篇文章https://zhuanlan.zhihu.com/p/336504407

3、數據血緣的常見用途

業務域的劃分針對任務的表和字段，通過血緣關系可以確定表的上下游，以及對應這個表所涵蓋的業務范圍包括哪些

提升調度性能

通過收集調度任務的開始結束時間，了解任務ETL鏈路的時間瓶頸，在根據JOB的執行情況定位性能瓶頸，通過調整任務的基線、保證任務的資源提供，提升整條ETL鏈路的執行效率。

數據異常定位

若在某天的調度中，發現數據異常，想確認是什么造成，可根據DQC和血緣關系了解底層數據波動情況，快速定位原因。

數倉鏈路優化通過對表和字段的下游使用頻次，找到使用較多的，分析其是否有重復計算、浪費資源的情況。再判斷是否可以因此建設事實或維度表、或者把計算的指標或維度沉淀。

調度依賴的準確性判斷

在平時的開發過程中，很可能修改過SQL，但是忘記在調度平臺上配置相對應的依賴，這樣很可能會出現問題，其實通過調度平臺的調度關系的元數據，和收集到的血緣關系進行對比，可定時性的判斷調度任務依賴是否準確。

4、數據血緣的實現原理（表級別）

本文只闡述最基本的表級別的血緣關系的實現思路，真實的血緣實現，遠比文章中的場景復雜。

原理一  SQL解析之正則表達式

在最開始時，剛畢業的小白，如果讓你做好數倉的血緣元數據時，你會怎么做？

在初期的小白根本就不懂編譯器、語法分析、詞法分析以及AST這些概念時，想到的唯一辦法就是通過正則這個樸素的手段去解析SQL了，想法也非常直接，FROM或者JOIN后面就是源表，INSERT INTO/INSERT OVERWRITE TABLE后面就是目標表。

source_table_regex = re.compile(r"(?:from|join)\s+(\S*)(?:\s+|;)", re.IGNORECASE)
target_table_regex = re.compile(r"insert\s+(?:into|overwrite)\s+table\s+(\S*)\s+", re.IGNORECASE)

不過，若是我們的SQL是這樣的呢？

select * 
--from tableA
from tableB;

或者是這樣的：

select * from tableA
where description = "from Excel";

你會發現，這個思路有很多漏洞。事實上如果加上一些if-else的判斷，這個方案其實也滿足了大部分場景。但是！！！！身為開發人員一定要明白一個理念，當你在生產環境中只要有一個場景沒有滿足，那就是bug。

原理二 AST語法樹的解析

首先針對思路二，大家可以提前了解AST的概念，參考https://blog.csdn.net/u013212754/article/details/106981084

其次在了解思路二前提下，需要知道Hive SQL的執行過程（畢竟還是看的HQL的語法樹）以及一些名詞解釋。

• 名詞解釋

詞法分析器：詞法分析器的工作是分析量化那些本來毫無意義的字符流，將他們翻譯成離散的字符組（也就是一個一個的Token），供語法分析器使用。簡單說就是分析sql里每個單詞該怎么組成。

語法分析：語法分析器將把收到的Tokens組織起來，并轉換成語法規則定義的所允許的結構。簡單說就是研究這些單詞該以怎樣的結構組成一個SQL的。

Antlr：ANTLR (ANother Tool for Language Recognition ) 是一種語言識別工具，它提供了一個框架，可以通過包含 Java, C++, 或 C# 動作（action）的語法描述來構造語言識別器，編譯器和解釋器。

• Hive SQL的解析流程：

Hive根據Antlr定義的詞法、語法規則完成詞法、語法分析將HQL解析為AST Tree；

遍歷AST Tree，抽象出查詢的基本組成單元Query Block；

遍歷Query Block解析為操作樹Operator Tree(即，邏輯執行計劃)；

邏輯優化器進行操作樹變換，合并多余的ReduceSinkOperator，減少shuffle；

遍歷Operator Tree，將操作樹翻譯為對應的MapReduce任務；

物理優化器進行MapReduce任務變換，生成最終的執行計劃。

具體步驟：

• 對Hive SQL進行詞法分析和語法分析，獲取對應的AST 原始的抽象語法樹
• AST語法樹剪枝優化，減少遍歷次數，提高語義解析的效率，具體主要做兩方面的優化：

針對token中涉及到的無效解析節點進行刪除,如order by，distributedby,cluster by,sort by以及limit；

針對token中where/having的子查詢，在保證SQL語法正確性以及語義完整性的前提下，采用1=1 等價策略進行等價替換，降低了血緣關系解析的復雜性；通過以上兩種剪枝操作，既可以減少SQL語句的復雜性，又可以降低AST語法樹的層級，進一步減少了遍歷AST樹遞歸次數，降低血緣分析的復雜性，提高了語句解析效率。

遍歷AST獲取上游表名和下游表名，在SQL語句中存在大部分SQL語句片段即CTE。由于其在血緣關系解析中不起關鍵作用，且對SQL解析帶來很大困擾，因此血緣關系解析需對CTE類型進行識別，并進行替換與刪除。

5、總結

市面上其實針對數據血緣的產品有很多，像阿里DataWorks的數據地圖、字節的DataLeap以及非常火的開源產品Apache Atlas都是非常好用工具產品。但是本質上是想通過這篇文章，讓小伙伴們在使用這些產品的時候多去思考這些產品背后的實現原理。