元數據管理系統這個名詞,從事非數據倉庫工作的人，很少會接觸到這個零碎，即便是正在從事這方面工作的敵人，可能依然對它不是很理解，那么明天我來聊一聊元數據管理系統。

元數據的定義
依照傳統的定義，元數據（Metadata）是對于數據的數據。在數據倉庫零碎中，元數據能夠幫忙數據倉庫管理員和數據倉庫的開發人員十分不便地找到他們所關懷的數據；元數據是形容數據倉庫內數據的構造和建設辦法的數據，可將其按用處的不同分為兩類：技術元數據（Technical Metadata）和業務元數據（Business Metadata）。

技術元數據是存儲對于數據倉庫零碎技術細節的數據，是用于開發和治理數據倉庫應用的數據，它次要包含以下信息：

數據倉庫構造的形容，包含倉庫模式、視圖、維、層次結構和導出數據的定義，以及數據集市的地位和內容；
業務零碎、數據倉庫和數據集市的體系結構和模式
匯總用的算法，包含度量和維定義算法，數據粒度、主題畛域、匯集、匯總、預約義的查問與報告；
由操作環境到數據倉庫環境的映射，包含源數據和它們的內容、數據宰割、數據提取、清理、轉換規則和數據刷新規定、平安（用戶受權和存取控制）。


業務元數據從業務角度形容了數據倉庫中的數據，它提供了介于使用者和理論零碎之間的語義層，使得不懂計算機技術的業務人員也可能“讀懂”數據倉庫中的數據。業務元數據次要包含以下信息：使用者的業務術語所表白的數據模型、對象名和屬性名；拜訪數據的準則和數據的起源。

零碎所提供的分析方法以及公式和報表的信息；具體包含以下信息：

企業概念模型：這是業務元數據所應提供的重要的信息，它示意企業數據模型的高層信息、整個企業的業務概念和互相關系。以這個企業模型為根底，不懂數據庫技術和SQL語句的業務人員對數據倉庫中的數據也能做到成竹在胸。
多維數據模型：這是企業概念模型的重要組成部分，它通知業務剖析人員在數據集市當中有哪些維、維的類別、數據立方體以及數據集市中的聚合規定。這里的數據立方體示意某主題畛域業務事實表和維表的多維組織模式。
業務概念模型和物理數據之間的依賴：以上提到的業務元數據只是示意出了數據的業務視圖，這些業務視圖與理論的數據倉庫或數據庫、多維數據庫中的表、字段、維、檔次等之間的對應關系也應該在元數據知識庫中有所體現。

元數據的作用
與其說數據倉庫是軟件開發我的項目，還不如說是系統集成我的項目，因為它的次要工作是把所需的數據倉庫工具集成在一起，實現數據的抽取、轉換和加載，OLAP剖析和數據挖掘等。如下圖所示，它的典型構造由操作環境層、數據倉庫層和業務層等組成。

其中，第一層（操作環境層）是指整個企業內無關業務的OLTP零碎和一些內部數據源；第二層是通過把第一層的相干數據抽取到一個中心區而組成的數據倉庫層；第三層是為了實現對業務數據的剖析而由各種工具組成的業務層。圖中右邊的局部是元數據管理，它起到了承前啟后的作用，具體體現在以下幾個方面：

1、元數據是進行數據集成所必須的
數據倉庫最大的特點就是它的集成性。這一特點不僅體現在它所蘊含的數據上，還體現在施行數據倉庫我的項目的過程當中。一方面，從各個數據源中抽取的數據要依照肯定的模式存入數據倉庫中，這些數據源與數據倉庫中數據的對應關系及轉換規則都要存儲在元數據知識庫中；另一方面，在數據倉庫我的項目施行過程中，間接建設數據倉庫往往費時、費勁，因而在實際當中，人們可能會依照對立的數據模型，首先建設數據集市，而后在各個數據集市的根底上再建設數據倉庫。

不過，當數據集市數量增多時很容易造成“蜘蛛網”景象，而元數據管理是解決“蜘蛛網”的要害。如果在建設數據集市的過程中，留神了元數據管理，在集成到數據倉庫中時就會比較順利；相同，如果在建設數據集市的過程中漠視了元數據管理，那么最初的集成過程就會很艱難，甚至不可能實現。

2、元數據定義的語義層能夠幫忙用戶了解數據倉庫中的數據
最終用戶不可能象數據倉庫系統管理員或開發人員那樣相熟數據庫技術，因而迫切需要有一個“翻譯”，可能使他們清晰地了解數據倉庫中數據的含意。元數據能夠實現業務模型與數據模型之間的映射，因此能夠把數據以用戶須要的形式“翻譯”進去，從而幫忙最終用戶了解和應用數據。

3、元數據是保證數據品質的要害
數據倉庫或數據集市建設好當前，使用者在應用的時候，經常會產生對數據的狐疑。這些狐疑往往是因為底層的數據對于用戶來說是不“通明”的，使用者很天然地對后果產生狐疑。而借助元數據管理系統，最終的使用者對各個數據的前因后果以及數據抽取和轉換的規定都會很不便地失去，這樣他們天然會對數據具備信念；當然也可便捷地發現數據所存在的品質問題。甚至國外有學者還在元數據模型的根底上引入品質維，從更高的角度上來解決這一問題。

4、元數據能夠反對需要變動
隨著信息技術的倒退和企業職能的變動，企業的需要也在一直地扭轉。如何結構一個隨著需要扭轉而平滑變動的軟件系統，是軟件工程畛域中的一個重要問題。傳統的信息系統往往是通過文檔來適應需要變動，然而僅僅依附文檔還是遠遠不夠的。勝利的元數據管理系統能夠把整個業務的工作流、數據流和信息流無效地治理起來，使得零碎不依賴特定的開發人員，從而進步零碎的可擴展性 。

元數據管理現狀
由以上幾節咱們理解到元數據簡直能夠被稱為是數據倉庫乃至商業智能（BI）零碎的“靈魂”，正是因為元數據在整個數據倉庫生命周期中有著重要的位置，各個廠商的數據倉庫解決方案都提到了對于對元數據的治理。但遺憾的是對于元數據的治理，各個解決方案都沒有明確提出一個殘缺的管理模式；它們提供的僅僅是對特定的部分元數據的治理。與元數據相干的數據倉庫工具大抵可分為四類：

1、數據抽取工具
把業務零碎中的數據抽取、轉換、集成到數據倉庫中，如Ardent的DataStage、Pentaho的開源ETL產品Kettle、ETI的Extract等。這些工具僅提供了技術元數據，簡直沒有提供對業務元數據的反對。

2、前端展示工具
包含OLAP剖析、報表和商業智能工具等，如Cognos的PowerPlay、Business Objects的BO，以及國內廠商帆軟的FineBI／FineReport等。它們通過把關系表映射成與業務相干的事實和維來反對多維業務視圖，進而對數據倉庫中的數據進行多維分析。這些工具都提供了業務元數據與技術元數據絕對應的語義層。

3、建模工具
為非技術人員籌備的業務建模工具，這些工具能夠提供更高層的與特定業務相干的語義。如CA的ERwin、Sysbase的PowerDesigner以及Rational的Rose等。

4、元數據存儲工具
元數據通常存儲在專用的數據庫中，該數據庫就如同一個“黑盒子”，內部無奈曉得這些工具所用到和產生的元數據是如何存儲的。還有一類被稱為元數據知識庫（Metadata Repository）的工具，它們獨立于其它工具，為元數據提供一個集中的存儲空間。這些工具包含微軟的Repository，Ardent的MetaStage和Sybase的WCC等。

5、元數據管理工具
目前國內的元數據管理工具大略有三類。一是像IBM、CA等公司都提供的專門工具，比方IBM收買Ascential失去的MetaStage，CA的DecisionBase都是如此；二是像DAG的MetaCenter，開源產品Pentaho Metadata，它們不依靠于某項BI產品，是一種第三方的元數據管理工具；三是像普元、石竹這樣的集成商也有本人的元數據管理工具：普元MetaCube、新炬網絡元數據管理系統、石竹MetaOne等。

專門的元數據管理工具，對自家產品兼容較好，一旦波及跨系統管理，就不盡如人意了。從國內的理論利用來看，DAG的MetaCenter這一工具應用最多，目前所看到的在電信、金融畛域建設的元數據管理我的項目基本上都是利用了這一產品。

我從互聯網上搜尋了簡直所有的元數據廠家：Pentaho開源的MetaData產品，反對源碼下載試用，能夠進行集成開發；普元MetaCube下載后，配置麻煩，目前為止還沒有調通；其余公司產品均不提供下載試用。

元數據管理規范
沒有規矩不成方圓。元數據管理之所以艱難，一個很重要的起因就是不足對立的規范。在這種狀況下，各公司的元數據管理解決方案各不相同。近幾年，隨著元數據聯盟MDC（Meta Data Coalition）的凋謝信息模型OIM（Open Information Model）和OMG組織的公共倉庫模型CWM（Common Warehouse Model）規范的逐步欠缺，以及MDC和OMG組織的合并，為數據倉庫廠商提供了對立的規范，從而為元數據管理鋪平了路線。

從元數據的倒退歷史不難看出，元數據管理次要有兩種辦法：

對于絕對簡略的環境，依照通用的元數據管理規范建設一個集中式的元數據知識庫。
對于比較復雜的環境，別離建設各局部的元數據管理系統，造成分布式元數據知識庫，而后，通過建設規范的元數據交換格局，實現元數據的集成治理。

目前OMG家的CWM（Common Warehouse MetaModel）規范已成為元數據管理界的統一標準：OMG是一個領有500多會員的國際標準化組織，馳名的CORBA規范即出自該組織。公共倉庫元模型（Common Warehouse Metamodel）的次要目標是在異構環境下，幫忙不同的數據倉庫工具、平臺和元數據知識庫進行元數據交換。2001年3月，OMG頒布了CWM 1.0規范。CWM模型既包含元數據存儲，也包含元數據交換，它是基于以下三個工業規范制訂的：

UML：它對CWM模型進行建模。
MOF（元對象設施）：它是OMG元模型和元數據的存儲規范，提供在異構環境下對元數據知識庫的拜訪接口。
XMI（XML元數據交換）：它能夠使元數據以XML文件流的形式進行替換。
CWM為數據倉庫和商業智能（BI）工具之間共享元數據，制訂了一整套對于語法和語義的標準。它次要蘊含以下四個方面的標準：

CWM元模型（Metamodel）：形容數據倉庫零碎的模型；
CWM XML：CWM元模型的XML示意；
CWM DTD：DW/BI共享元數據的替換格局
CWM IDL：DW/BI共享元數據的應用程序拜訪接口（API）

元數據管理性能
1、數據地圖
數據地圖展示是以拓撲圖的模式對數據系統的各類數據實體、數據處理過程元數據進行分檔次的圖形化展示，并通過不同檔次的圖形展示粒度管制，滿足開發、運維或者業務上不同利用場景的圖形查問和輔助剖析須要。

2、元數據分析
血統剖析：血統剖析（也稱血統剖析）是指從某一實體登程，往回追溯其處理過程，直到數據系統的數據源接口。對于不同類型的實體，其波及的轉換過程可能有不同類型，如：對于底層倉庫實體，波及的是ETL處理過程；而對于倉庫匯總表，可能既波及ETL處理過程，又波及倉庫匯總處理過程；而對于指標，則除了下面的處理過程，還波及指標生成的處理過程。數據源接口實體由源零碎提供，作為數據系統的數據輸出，其它的數據實體都通過了一個或多個不同類型的處理過程。

血統剖析正是提供了這樣一種性能，能夠讓使用者依據須要理解不同的處理過程，每個處理過程具體做什么，須要什么樣的輸出，又產生什么樣的輸入。

影響剖析：響剖析是指從某一實體登程，尋找依賴該實體的處理過程實體或其余實體。如果須要能夠采納遞歸形式尋找所有的依賴過程實體或其余實體。該性能反對當某些實體發生變化或者須要批改時，評估實體影響范疇。

實體關聯剖析：體關聯剖析是從某一實體關聯的其它實體和其參加的處理過程兩個角度來查看具體數據的應用狀況，造成一張實體和所參加處理過程的網絡，從而進一步理解該實體的重要水平。

本性能能夠用來撐持需要變更影響評估的利用。

實體差別剖析：體差別剖析是對元數據的不同實體進行查看，用圖形和表格的模式展示它們之間的差別，包含名字、屬性及數據血統和對系統其余局部影響的差別等,在數據系統中存在許多相似的實體。這些實體（如數據表）可能只有名字上或者是在屬性中存在渺小的差別，甚至有局部屬性名字都雷同，但處于不同的利用中。

因為各種起因，這些渺小的差別間接影響了數據統計后果，數據系統須要分明理解這些差別。本性能有助于進一步對立統計口徑，評估近似實體的差別

指標一致性剖析：標一致性剖析是指用圖形化的形式來剖析比擬兩個指標的數據流圖是否統一，從而理解指標計算過程是否統一。該性能是指標血統剖析的一種具體利用。

指標一致性剖析能夠幫忙用戶分明地理解到將要比擬的兩個指標在經營剖析數據流圖中各階段所波及的數據對象和轉換關系是否統一，幫忙用戶更好地理解指標的前因后果，分明了解散布在不同部門且名稱雷同的指標之間的差別，從而進步用戶對指標值的信賴。

輔助利用優化
元數據對數據系統的數據、數據加工過程以及數據間的關系提供了精確的形容，利用血統剖析、影響剖析和實體關聯剖析等元數據分析性能，能夠辨認與零碎利用相干的技術資源，聯合利用生命周期治理過程，輔助進行數據系統的利用優化.
輔助平安治理
企業數據平臺所存儲的數據和提供的各類剖析利用，波及到公司經營方面的各類敏感信息。因而在數據系統建設過程中，須采納全面的平安管理機制和措施來保障系統的數據安全。
數據系統平安治理模塊負責數據系統的數據敏感度、客戶隱衷信息和各環節審計日志記錄治理，對數據系統的數據拜訪和性能應用進行無效監控。為實現數據系統對敏感數據和客戶隱衷信息的訪問控制，進一步實現權限細化，平安治理模塊應以元數據為根據，由元數據管理模塊提供敏感數據定義和客戶隱衷信息定義，輔助平安治理模塊實現相干平安管控操作。

基于元數據的開發治理
數據系統我的項目開發的次要環節包含：需要剖析、設計、開發、測試和上線。開發治理利用能夠提供相應的性能，對以上各環節的工作流程、相干資源、規定束縛、輸入輸出信息等提供治理和反對。