元數據管理是隨著數據倉庫的建設逐漸完善起來的，這也決定了元數據管理主要集中在數據領域。例如數據結構、數據加工轉換關系等。而隨著我們對元數據理解的不斷深入，其實元數據廣泛存在于企業架構的方方面面，而不僅僅局限于數據領域里。

元數據是什么？

數據中臺的構建，需要確保全局指標的業務口徑一致，要把原先口徑不一致的、重復的指標進行梳理，整合成一個統一的指標字典，我們稱之為元數據。而這項工作的前提，是要搞清楚這些指標的業務口徑、數據來源和計算邏輯。 要理解元數據首先要知道“元”是什么。元數據意思是“與數據有關的數據”。元數據可以為數據說明其元素或屬性（名稱、大小、數據類型等），或結構（長度、字段、數據列），或其相關數據（位于何處、如何聯系、擁有者）。元數據起源于圖書館管理系統，我們便從圖書中去解釋元數據的概念吧。

一本書，書的封面和內頁都向我們展示了這樣的元數據信息：標題、作者姓名、出版商和版權細節、背面的描述、目錄、頁碼。這個栗子可以看出，我們日常生活中，都會有相應的元數據信息保留下來。在數據治理中，元數據便是對于數據的描述，存儲著關于數據的數據信息。我們可以通過這些元數據去管理和檢索我們想要的“這本書”。有了元模型，就能根據元模型來采集元數據信息。這樣一來，就能通過層層關鍵信息將重要目標展現出來。

元數據主要分３種類型，分別是（數據字典＼數據血緣＼數據特征）。

數據字典：描述的是數據的結構信息。主要包括表名＼注釋信息＼表的產出任務＼每個表都有哪些字段＼這些字典分別代表什么含義＼字段的類型。 數據血緣：一個表是直接通過哪些表加工而來。一般用于做影響分析和故障溯源。 數據特征：主要指數據的屬性信息，比如存儲空間大小＼訪問熱度＼主題域＼分層＼表關聯的指標。 元數據可以用5個緯度來評判 其一，多業務線、多租戶支持。 其二，多數據源支持（比如mysql、Hive、Kudu等，半結構化的KV管理【kafka、redis、hbase】），同時還要支持相同數據源的多個集群。 其三，數據血緣，元數據中心需要支持數據血緣的實時采集和高性能的查詢，同時還要支持字段級別的血緣。 其四，與大數據平臺集成。元數據中心需要與ranger集成，實現基于tag的權限管理方式。 其五，數據標簽。必須支持對表和表中的字段打標簽，通過豐富的不同類型的標簽，可以完善數據中臺數據的特征，比如指標可以作為一種類型的標簽打在表上，主題域、分層信息都可以作為不同類型的標簽關聯到表。 其中比較難的是找到數據血緣，一般可以通過3種方式 通過靜態解析SQL，獲得輸入表和輸出表 通過實時抓取正在執行的SQL，解析執行計劃，獲取輸入表和輸出表 通過任務日志解析的方式，獲取執行后的SQL輸入表和輸出表 對產品經理而言，元數據管理平臺通過對業務指標、業務術語、業務規則、業務含義等業務信息進行管控，協助業務人員了解業務含義、行業術語和規則、業務指標取數據口徑和影響范圍等。

元數據管理是隨著數據倉庫的建設逐漸完善起來的，這也決定了元數據管理主要集中在數據領域。例如數據結構、數據加工轉換關系等。

而隨著我們對元數據理解的不斷深入，其實元數據廣泛存在于企業架構的方方面面，而不僅僅局限于數據領域里。

因此，元數據管理的范圍也在不斷擴大，從簡單的庫表，到整個數據平臺，再到服務管理，不斷地突破傳統管理的范疇，形成了廣義元數據管理。

在這個過程中，對元數據的技術架構也有了新的要求，穩定可擴展的架構才是實現廣義元數據管理的基礎。

元數據管理的架構

要實現元數據管理有三個方面：

1、采集：指從各種工具中，把各種類型的元數據采集進來，采集是元數據管理第一步。

2、存儲：采集之后需要相應的存儲策略來對元數據進行存儲，這需要在不改變存儲架構的情況下擴展元數據存儲的類型;

3、管理和應用：在采集和存儲完成后，對已經存儲的元數據進行管理和應用。

隨著元數據管理范疇的不斷擴大，如何保證元數據從采集、存儲到應用等關鍵環節的穩定和擴展，成為元數據管理架構設計的關鍵問題。

OMG的模型體系規范為元數據管理提供了基礎，所以整個元數據管理設計的關鍵應該以模型體系規范為指導。

OMG提出的CWM(Common Warehouse Metamodel)規范對數據倉庫相關的所有模型進行了描述，在初期我們也遵照此規范設計元數據管理的架構，但是規范里也有坑，我們很快就發現了問題。

我們發現CWM規范本質上是針對數據倉庫領域的規范，按照OMG的模型體系來看，模型的抽象層次還是太低。

如果繼續提高抽象層級，MOF規范位于模型體系最底層，所有模型體系規范的基礎都應該是MOF(Meta Object Facility)規范，UML，CWM都是由MOF擴展而來。

基于MOF的還有模型交換的規范XMI，為不同元數據交換提供了很好的模型基礎。

那么若整個元數據圍繞MOF設計和擴展，不用修改元數據管理核心部分，就可以適應元數據種類的不斷擴展。

下面我們來看看如何設計元數據的存儲：

元模型對元數據屬性及關系進行了定義，一般來講，元模型存儲有兩種方式。

1、第一種方式是將元模型轉換成系統數據庫表和屬性，實現一對一管理存儲。例如可以將主鍵元模型存儲在主鍵記錄表中、將存儲過程元模型存儲在存儲過程記錄表中等。

2、另一種方式是基于MOF元元模型把所有屬性和關系打散，以此來實現元模型的通用存儲結構。

如圖所示，以CWM模型中關系型包為例進行說明，方式一是直接將元模型轉化為庫表，方式二按照元元模型的方式存儲元模型;

盡管第二種實現方式上復雜度會更高一些，但是在擴展性有絕對優勢，是元數據管理實現的優先選擇方式。

再來看看模型體系的層次結構：

和元數據有關的體系分三層，M1(元數據)、M2(元模型)、M3(元元模型)，其中MOF元元模型中描述了包、元素、屬性、命名空間和約束等對象及其關系，位于層次結構的最上層，也是最抽象的一層。

以MOF作為底層元元模型來支持元數據管理，在M2層中就可以對元模型進行定義和擴展(例如CWM模型)，將來還可以擴展到微服務模型、業務模型等。

選定了實現方式后，一般可以通過三步來實現元數據的管理：

第一步，以MOF規范設計元模型存儲結構，從而支持元模型的擴展。

第二步，基于MOF設計元模型，例如將CWM(公共倉庫元模型)規范中定義的元模型，存儲在元模型中。

第三步，按照擴展后的元模型，采集元數據，存儲到元數據系統中。

在元數據管理三層管理架構的支持下，通常只需要做元模型定義和元數據采集，就對不同元數據進行管理。

例如，要將表與字段元數據采集到元數據管理系統，只需要如下兩步：

首先，對元模型定義并描述元數據特征，包括類屬性描述、關系的描述等;

然后，將元數據采集進來，存儲到系統中;

元數據的應用價值

良好的元數據架構，能夠給元數據帶來更多的應用價值。我們再看看元數據的應用價值。

通過元數據管理我們能夠做到：

1、實現多樣、繁雜的元數據信息集中管理，為企業數據(服務)管理提供統一的視圖，實現企業級數據(服務)資產管理，方便數據(服務)交互共享，同時為后續規劃提供依據;

2、通過管理維護數據(服務)之間關系，實現數據(服務)自動關聯分析，為問題定位、影響分析、上線加速等提供支撐。

3、建立數據(服務)標準，統一交換、存儲、應用口徑，減少共享壁壘，降低應用出錯幾率，提升質量。

通過這些基本能力，元數據在數據管理、微服務管理、業務管理等方面都能發揮很大的作用。

通過元數據管理，在數據方面能做到：

1、數據標準化

2、數據開放

3、數據質量提升等

在微服務方面，能夠提供以下支撐：

1、服務開發、應用等標準化;

2、服務應用監控，優化服務應用等

將來在業務方面也能通過元數據實現業務流程分析、業務流程優化等能力。

大家常見的是元數據在數據倉庫中的應用，數據倉庫是一個典型的分層設計的數據架構，其分層設計反映了數據在數據倉庫中的加工處理過程。

元數據作為數據倉庫的核心組成部分，主要用于記錄和管理數據在數據倉庫中的整個流轉過程，實現對數據倉庫各層級數據進行統一管理。

（圖來源《一本書講透數據治理：戰略、方法、工具與實踐》）

元數據在數據倉庫中的應用如下： 描述數據源的庫表結構、數據關系以及每個數據項的定義； 描述數據源中每個數據項的值域范圍和更新頻率； 描述數據源與數據倉庫之間的數據映射關系； 描述數據倉庫中有哪些數據以及它們來自哪里； 描述數據在數據倉庫各層中的加工處理過程； 元數據管理工具為數據管理者和使用者提供了理解和查詢數據的一致語言； 利用元數據管理工具的元數據變更和版本管理功能，管理數據倉庫的數據模型，支持將元數據恢復到某一版本； 利用元數據管理工具的血緣分析、影響分析等功能，對數據倉庫中的數據問題快速定位、快速查找； 利用元數據管理工具的開放式元數據交換標準，實現數據倉庫中數據的交換和共享。

下面我們用幾個例子，舉例說明元數據的作用。

數據治理之中，元數據是整個治理體系落地的技術核心。

比如：在數據標準中將數據標準作為一類業務元數據存儲，將其和技術元數據一定程度的關聯，去看標準的落地效果。

在數據質量中，通過元數據追溯質量問題。在共享發布中，利用元數據自動形成數據服務等等。

元數據還能夠自動化的準確的管理應用的上線、變更， 通常企業系統建設會分為開發、測試與生產三個不同的環境，而在軟件開發過程中，無論是需求變更還是BUG修改都避免不了元數據的改動，這時候往往會出現開發庫、測試庫測試通過，而在上線過程中又出現問題的情況，這會讓運維部門非常頭疼。

此時若通過元數據對系統的上線變更進行管理，自動采集三個環境的庫表結構與存儲過程等信息，保證各個環境中的元數據都是最新的、最準確的，再將上線環境與測試環境的元數據進行對比，不一致的地方一目了然。如果把系統的開發庫、測試庫、生產庫的元數據都管理起來，上線時突然出現問題的概率就會大大降低。

通過擴展模型，元數據也能夠管理微服務，微服務的生命周期有多個階段，在前期需要與多個微服務協同考慮，上架后也會有多個使用者，在這種復雜的狀況下需要管理微服務的全生命周期。

在規劃階段提供標準元數據規范微服務，在設計階段提供連接其他微服務的元數據信息，在開發階段使用元數據協助開發測試。

上線后分析微服務的使用情況，并協助維護微服務的變更。最后微服務下架時將微服務的元數據存檔，并確保對目前體系不產生影響。

同時微服務的不同版本間的元數據的變化也可以做追溯和分析。

最后，未來元數據將是連接業務，數據與服務的企業核心基礎設施，可擴展的元數據架構也能夠產生更多更有價值的應用場景。