元數據管理
一、元數據的定義
按照傳統的定義，元數據（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文件流的方式進行交換。
OMG元數據知識庫體系結構如下圖所示。
CWM爲數據倉庫和商業智能（BI）工具之間共享元數據，制定了一整套關於語法和語義的規範。它主要包含以下四個方面的規範：
- CWM元模型（Metamodel）：描述數據倉庫系統的模型；
- CWM XML：CWM元模型的XML表示；
- CWM DTD：DW/BI共享元數據的交換格式；
- CWM IDL：DW/BI共享元數據的應用程序訪問接口（API）。
五、元數據管理功能
1. 數據地圖
數據地圖展現是以拓撲圖的形式對數據系統的各類數據實體、數據處理過程元數據進行分層次的圖形化展現，並通過不同層次的圖形展現粒度控制，滿足開發、運維或者業務上不同應用場景的圖形查詢和輔助分析需要。
2. 元數據分析
血緣分析
血緣分析（也稱血統分析）是指從某一實體出發，往回追溯其處理過程，直到數據系統的數據源接口。對於不同類型的實體，其涉及的轉換過程可能有不同類型，如：對於底層倉庫實體，涉及的是ETL處理過程；而對於倉庫彙總表，可能既涉及ETL處理過程，又涉及倉庫彙總處理過程；而對於指標，則除了上面的處理過程，還涉及指標生成的處理過程。數據源接口實體由源系統提供，作爲數據系統的數據輸入，其它的數據實體都經過了一個或多個不同類型的處理過程。血緣分析正是提供了這樣一種功能，可以讓使用者根據需要了解不同的處理過程，每個處理過程具體做什麼，需要什麼樣的輸入，又產生什麼樣的輸出。
影響分析
影響分析是指從某一實體出發，尋找依賴該實體的處理過程實體或其他實體。如果需要可以採用遞歸方式尋找所有的依賴過程實體或其他實體。該功能支持當某些實體發生變化或者需要修改時，評估實體影響範圍。
實體關聯分析
實體關聯分析是從某一實體關聯的其它實體和其參與的處理過程兩個角度來查看具體數據的使用情況，形成一張實體和所參與處理過程的網絡，從而進一步瞭解該實體的重要程度。本功能可以用來支撐需求變更影響評估的應用。
實體差異分析
實體差異分析是對元數據的不同實體進行檢查，用圖形和表格的形式展現它們之間的差異，包括名字、屬性及數據血緣和對系統其他部分影響的差異等,在數據系統中存在許多類似的實體。這些實體（如數據表）可能只有名字上或者是在屬性中存在微小的差異，甚至有部分屬性名字都相同，但處於不同的應用中。由於各種原因，這些微小的差異直接影響了數據統計結果，數據系統需要清楚瞭解這些差異。本功能有助於進一步統一統計口徑，評估近似實體的差異
指標一致性分析
指標一致性分析是指用圖形化的方式來分析比較兩個指標的數據流圖是否一致，從而瞭解指標計算過程是否一致。該功能是指標血緣分析的一種具體應用。指標一致性分析可以幫助用戶清楚地瞭解到將要比較的兩個指標在經營分析數據流圖中各階段所涉及的數據對象和轉換關係是否一致，幫助用戶更好地瞭解指標的來龍去脈，清楚理解分佈在不同部門且名稱相同的指標之間的差異，從而提高用戶對指標值的信任。
3. 輔助應用優化
元數據對數據系統的數據、數據加工過程以及數據間的關係提供了準確的描述，利用血緣分析、影響分析和實體關聯分析等元數據分析功能，可以識別與系統應用相關的技術資源，結合應用生命週期管理過程，輔助進行數據系統的應用優化.
4. 輔助安全管理
企業數據平臺所存儲的數據和提供的各類分析應用，涉及到公司經營方面的各類敏感信息。因此在數據系統建設過程中，須採用全面的安全管理機制和措施來保障系統的數據安全。
數據系統安全管理模塊負責數據系統的數據敏感度、客戶隱私信息和各環節審計日誌記錄管理，對數據系統的數據訪問和功能使用進行有效監控。爲實現數據系統對敏感數據和客戶隱私信息的訪問控制，進一步實現權限細化，安全管理模塊應以元數據爲依據，由元數據管理模塊提供敏感數據定義和客戶隱私信息定義，輔助安全管理模塊完成相關安全管控操作。
5. 基於元數據的開發管理
數據系統項目開發的主要環節包括：需求分析、設計、開發、測試和上線。開發管理應用可以提供相應的功能，對以上各環節的工作流程、相關資源、規則約束、輸入輸出信息等提供管理和支持。