聲明：本文歸屬一寸HUI所有。@一寸HUI
在上一篇文章數據中臺(架構篇)中瞭解到了數據中臺的架構，其中我們一個很重要的部分就是要構建數據資產，而數據資產中的元數據管理又是很重要的部分，接下來我們從幾個方面瞭解元數據：搞懂什麼是元數據？元數據和數據的區別是什麼？元數據有什麼作用？元數據可以用來做什麼？
什麼是元數據
元數據（metadata），就是描述數據的數據。看到這個估計比較抽象，比較難理解。
舉個例子：對於一個數據表，表的含義是什麼，由誰管理，每個字段的意思是什麼，都屬於這個數據表的元數據。一般來說，數據中臺不僅需要管理傳統的元數據，也需要管理數據應用的元數據。
元數據用來描述數據的數據，通過描述數據的產生、存儲、使用情況、業務含義等信息，以及數據管理人員相關信息。讓人們能夠清楚擁有什麼數據、代表什麼、源自何處、如何在系統中移動，以及哪些人可以使用源數據，如何使用。
元數據是一種數據。元數據反映了數據的交易、實踐、對象和關係。數據反映了真實世界的交易、實踐、對象和關係。兩者的關係就像數據和真實世界的關係。這一定義從數據和元數據區別與聯繫表述定義。元數據描述了數據本身（數據庫、數據元素、數據模型等）、數據表示的概念（如業務流程、應用程序系統、軟件代碼、技術架構等）以及數據和概念之間的關係。數據承載的是業務實體數據，而元數據是用於管理實體數據的。
元數據的分類
按照主要用途來劃分，元數據可以分成以下幾類。
- 業務元數據：與業務相關的數據信息，如數據項的語義、語法限制、與其他數據的關係。這類元數據可以幫助業務人員和應用使用數據，確認數據使用的正確性。
- 技術元數據：主要提供數據或應用的一些運維信息，例如存儲空間大小，數倉分層，訪問熱度，主題分類，關聯指標數據量、數據記錄數、數據集的物理位置、數據訪問記錄、數據裝載日誌、數據計算時間、質量稽覈記錄等。這類元數據是系統高效運維和審計所必需的信息。
- 管理元數據：用於機構管理的元數據，例如組織架構、人員權限等。這類元數據一般用來控制數據的訪問權限及數據用途審計和統計。
- 應用元數據：一般不屬於傳統元數據管理的範疇，包括數據中臺中運行的數據應用的信息，例如應用的開發部門、使用的數據源、產生的數據源、代碼的版本、運行的配置等。這類元數據可以用來回答數據如何產生、如何使用、使用多少資源等問題，可以提高數據能力共享和複用的效率。
在數據中臺中，業務數據的元數據往往能夠讓人更加實用。業務元數據包括如下內容：
- 數據定義：一般就是數據庫表的DDL，或者說是數據表的Schema。採集數據定義的目的是統一管理數據字段名稱、類型、說明，便於全局查詢及數據發現。
- 數據字典：一般是業務系統中所涉及概念的定義列表，描述的是數據的結構信息：表結構信息，主要包括像表名，字段名稱、類型和註釋，表的數 據產出任務，表和字段的權限等。數據字典的建設過程一般涉及業務系統的調研和從業務流程到實際數據映射關係的梳理，是元數據管理和數據中臺建設中很關鍵的一步。
- 數據血緣：數據之間的血緣依賴關係，對於一個指定的數據表、字段、記錄、域值，包括上游血緣（它們是如何計算出來的）和下游血緣（它們被用來計算哪些其他的數據表、字段、記錄、域值）。數據血緣在數據關係理解、數據驗證、運維排錯中都有很廣泛的應用，一般是元數據管理的必備功能之一，簡單理解爲一個表是直接通過哪些表加工而來。數據血緣一般會幫我們做影響分析和故障溯源。注意，支持不同級別的血緣帶來的額外管理負擔是逐漸增加的。目前大部分系統支持到表級血緣。
- 質量控制：數據必須滿足的一些質量規則，例如，每個字段必須滿足的條件、字段之間的關係、維度表中維度的限制。這些元數據一般屬於數據治理流程的一部分，在制定了質量規則之後，數據治理應用可以對指定對象檢查這些規則，並在需要的時候報錯。
- 統計數據：對於一些重要字段的統計數據，如最大值、最小值、中值、平均值、最常出現值等。有些統計數據的計算很耗資源，一般按需處理。例如，有的字段需要列出最常出現的前10個值，我們可以爲每個表提供一些基本的統計數據，然後提供可配置的統計數據計算功能。
- 數倉模型數據：對於數倉模型中的事實表、維度表，標註它們所屬的業務域（例如屬於銷售還是生產）和數倉模型層級（例如屬於貼源層還是匯聚層）。標記這些元數據可以讓用戶更方便地瀏覽數據資產。
- 聚合語義數據：一般是一些描述性數據，用來描述不同的數據表匯聚時必須滿足的條件，例如，用戶表和銷售表合併的時候應該過濾掉內部測試用戶和機器人賬號。這種語義元數據難以人工維護，可以採用與源代碼結合的方式來展示聚合的方式。
元數據的基礎功能和應用
我們可以通過元數據的管理，記錄和管理與數據相關的業務數據，便於人們理解數據，保證數據使用的一致性。從不同數據源採集並集成元數據，保證人們理解不同數據的相似性和差異保證元數據的質量、一致性和安全給元數據使用者提供標準的元數據訪問方法。
（1）數據地圖：數據地圖是基於所有元數據搭建起來的數據資產列表，可以將數據地圖看作將所有元數據進行可視化呈現的系統。它不僅能夠解決有什麼數據的問題，還能夠進行檢索，解決數據在哪裏的問題。通過可視化查詢、瀏覽、搜索，能夠根據類別、類型等信息展示各個數據實體的信息及其分佈情況，展示數據實體間的組合、依賴關係以及數據實體加工處理上下游的邏輯關係，也可以根據數據源庫、類型等搜索元數據信息。
（2）數據血緣和影響性分析
數據血緣和影響性分析主要解決“數據之間有什麼關係”的問題。因其重要價值，有的廠商會從元數據管理中將其單獨提取出來，作爲一個獨立的重要功能。但是考慮到數據血緣和影響性分析其實是來自於元數據信息，所以還是放在元數據管理中來描述。數據血緣分析是元數據管理的重要應用之一,血緣分析指的是獲取到數據的血緣關係，以歷史事實的方式記錄數據的來源、處理過程、梳理系統、表、視圖、存儲過程、ETL、程序代碼、字段等之間的關係，並採用圖數據庫進行可視化展現。總之就是通過可視化展示數據是怎麼來的，經過了哪些過程、階段及計算邏輯。
- 影響分析：在一個數據源或數據應用出現問題後，定位該問題的影響範圍，並根據管理元數據通知相關部門或人員。
- 指標溯源分析：通過血緣關係，對於一些關鍵指標，可以查看該指標的計算流程，並回溯到相關的數據源。這個方法在數據治理和數據質量管理中經常用到。
（3）元數據質量：主要做元數據治理用的，包含庫、表元數據治理功能，分多個維度統計元數據完成情況，並可以做相應通知等。在做好元數據質量的前提下，可以基於元數據做數據質量管理，在定義好數據質量元數據之後，由系統自動按照數據質量規則檢查數據，形成數據質量報告，並在數據質量出現問題時報警。
（4）元數據管理：元數據的管理包含元數據的增刪改查、變更管理、對比分析、統計分析等。
- 元數據的增刪改查。通過對不同的角色賦予相應的權限，實現元數據在組織範圍內的信息共享。值得注意的是，對元數據的修改、刪除、新增等操作，必須經過元數據管理員的審覈流程。
- 元數據變更管理。對元數據的變更歷史進行查詢，對變更前後的版本進行比對等。
- 元數據對比分析。對相似的元數據進行比對。比如，對近似的兩張表進行對比，發現它們之間的細微差異。
- 元數據統計分析。用於統計各類元數據的數量，如各類數據的種類、數量、數據量等，方便用戶掌握元數據的彙總信息。
（5）元數據中心：這是元數據核心功能之一，整個元數據的輸出就是數據地圖，用戶可以通過元數據中心查看錶的元數據信息（技術元數據、業務元數據）、任務信息、血緣關係（表級、字段級）血緣分析、使用信息等等（再多就看自己公司訴求了）
（6）元數據服務：統一元數據服務，主要提供查詢表、指標、維度基本信息的基礎元數據服務以及查詢表級血緣、字段級血緣的血緣服務。
（7）安全管理：通過元數據設置表及字段的安全等級，加密，脫敏，授權等，然後結合相應的規則對數據表及字段訪問進行控制，確保數據安全。
（8）數據冷熱度分析：冷熱度分析主要是對數據表的被使用情況進行統計，如表與ETL程序、表與分析應用、表與其他表的關係情況等，從訪問頻次和業務需求角度出發，進行數據冷熱度分析，用圖表展現表的重要性指數。
元數據管理架構
元數據管理架構功能：支持多業務線，支持多租戶，支持多種數據源，有數據血緣功能，數據標籤功能，與數據中臺集成等。
元數據中心統一對外提供了 API 訪問接口，數據傳輸、數據地圖、數據服務等其他的子系統都可以通過API 接口獲取元數據。另外 Ranger 可以基於元數據中心提供的 API 接口，獲取標籤對應的表，然後根據標籤更新表對應的權限，實現基於標籤的權限控制。
1.元數據採集和存儲
在數據處理的每一步中，我們必須獲取相應的元數據，並將這些元數據集中存儲在關係型數據庫中，便於後續查詢和管理。元數據是理解和使用數據的根據，它的完整性和正確性是整個大數據分析系統的基本條件。元數據採集必須能夠適應異構環境，支持從傳統關係型數據庫和大數據平臺中採集數據產生系統、數據加工處理系統和數據應用報表系統的全量元數據，包括過程中的數據實體（系統、庫、表、字段的描述）以及數據實體加工處理過程中的邏輯。同時，元數據管理系統必須支持人工輸入，允許人工的增、刪、改、查及發佈。
2.數據血緣
通過Spark/Hive/Flink本身提供的Listener/Hook機制，解析調度依賴中的FROM、CREATE、INSERT等語句，獲取輸入節點與輸出節點，生成血緣關係，就可以解析除SQL之外的其他語法。
在明確了實現方式後，就要考慮計劃執行時機了。執行時機主要有3個。
- （1）在運行前通過解析靜態的SQL，獲取依賴的輸入節點與輸出節點。
- （2）在運行中實時截取動態的SQL，獲取依賴的輸入節點與輸出節點。
- （3）在運行後通過解析任務日誌，獲取依賴的輸入節點與輸出節點。
在這3個時機中，時機（1）因爲沒有執行代碼，所以無法保證可以正常運行，時機（3）則比較後置，沒有時效性，所以最合適的是時機（2），在運行中解析SQL，能夠實時獲取輸入與輸出表，並且當依賴關係改變時也能實時變更。但是時機（2）也有一個缺點，那就是當數據表開發完成但還沒有被執行時，就無法獲取血緣關係，這時就需要通過解析靜態SQL的方式，建立跟其他表的依賴關係。
Apache Atlas就是採用（2）方式實現，其架構圖如下：
對於 Hive 計算引擎，Atlas 通過 Hook 方式，實時地捕捉任務執行計劃，獲取輸入表和輸出表，推送給Kafka，由一個 Ingest 模塊負責將血緣寫入 JanusGraph 圖數據庫中。然後通過 API 的方式，基於圖查詢引擎，獲取血緣關係。對於 Spark，Atlas 提供了 Listener 的實現方式。
對於數據血緣的實現，可以簡要概述爲：首先，通過Spark Listener/HiveHook/Flink Hook，解析調度依賴中的FROM、CREATE、INSERT等語句獲取輸入節點與輸出節點，生成血緣關係並推送給消息中間件（Kafka）；其次，消費端負責將血緣關係沉澱到圖形數據庫（Neo4j）中；最後，通過圖計算引擎在前端以圖形的方式將其展示出來。
3.數據字典
在實際的場景中，公司普遍存在大量多源異構的數據，其數據源包括Hive、MySQL、Oracle、Greenplum等。支持不同數據源，建立一個可擴展的、統一的元數據層非常重要的，否則公司的元數據是缺失的。所以構建數據字典是很重要的，開源的Metacat 擅長管理數據字典，可以參考Metacat的架構構建公司的數據字典。
Metacat最大的優勢：多數據源的可擴展架構:
從上面Metacat的架構圖中，可以看到：Metacat的設計非常巧妙，它並沒有單獨再保存一份元數據，而是採取直連數據源拉取的方式。一方面，它不存在保存兩份元數據一致性的問題；另一方面，這種架構設計很輕量化，每個數據源只要實現一個連接實現類即可，擴展成本很低。
4.數據地圖
數據地圖是基於所有元數據搭建起來的數據資產列表，可以將數據地圖看作將所有元數據進行可視化呈現的系統。數據地圖是基於元數據中心構建的一站式企業數據資產目錄，可以看作是元數據中心的界面。數據開發、分析師、數據運營、算法工程師可以在數據地圖上完成數據的檢索，解決了“不知道有哪些數據？”“到哪裏找數據？”“如何準確的理解數據”的難題。
數據地圖最核心的功能有兩個：元數據信息的展示、血緣關係。
數據地圖提供了多維度的檢索功能，使用者可以按照表名、列名、註釋、主題域、分層、指標進行檢索，結果按照匹配相關度進行排序。考慮到數據中臺中有一些表是數倉維護的表，有一些表數倉已經不再維護，因此在結果排序時，我們增加了數倉維護的表優先展示的規則。數據地圖還提供了按照主題域、業務過程導覽功能，可以幫助使用者快速瞭解當前有哪些表可以使用。
參考：
元數據管理系統
數據中臺學習筆記-元數據管理，指標管理，數據模型
聊聊數據中臺：元數據建設有哪些坑（一）
《雲原生數據中臺：架構、方法論與實踐》
《數據中臺：讓數據用起來》