需要進行對比學習，弄清楚是hive元數據還是數倉元數據，兩者有很大的區別，存儲位置也是不一樣的

Hive元數據

• 元數據包括：表名、表所屬的數據庫（默認是default）、表的擁有者、列/分區字段、表的類型（是否是外部表）、表的數據所在目錄、表的映射關系等；
• 默認存儲在自帶的derby數據庫中，推薦使用MySQL存儲Metastore；

數倉元數據

好好的體會一下數倉元數據的內容，注意和hive元數據進行對比學習
元數據概念

• 狹義的解釋是用來描述數據的數據；
• 廣義的來看，除了業務邏輯直接讀寫處理的那些業務數據，所有其它用來維持整個系統運轉所需的信息、數據都可以叫作元數據；

元數據定義

• 按照傳統的定義，元數據（Metadata）是關于數據的數據。在數據倉庫系統中，元數據可以幫助數據倉庫管理員和數據倉庫的開發人員非常方便地找到他們所關心的數據；元數據是描述數據倉庫內數據的結構和建立方法的數據，可將其按用途的不同分為兩類：技術元數據（Technical Metadata）和業務元數據（Business Metadata）。

技術元數據

存儲關于數據倉庫系統技術細節的數據，是用于開發和管理數據倉庫使用的數據

• 數據倉庫結構的描述，包括倉庫模式、視圖、維、層次結構和導出數據的定義，以及數據集市的位置和內容；
• 業務系統、數據倉庫和數據集市的體系結構和模式；
• 匯總用的算法，包括度量和維定義算法，數據粒度、主題領域、聚集、匯總、預定義的查詢與報告；
• 由操作環境到數據倉庫環境的映射，包括源數據和它們的內容、數據分割、數據提取、清理、轉換規則和數據刷新規則、安全（用戶授權和存取控制）。

業務元數據

從業務角度描述了數據倉庫中的數據，它提供了介于使用者和實際系統之間的語義層，使得不懂計算機技術的業務人員也能夠“讀懂”數據倉庫中的數據。

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

總結

• 搭建數據倉庫中最容易缺失的就是對元數據的管理，很少有數據倉庫團隊具備完整的元數據，當然搭建數據倉庫的工程師本身就是活的元數據，但無論是為了用數據的人還是數據倉庫自身的團隊著想，元數據都不可或缺。一方面元數據為數據需求方提供了完整的數據倉庫使用文檔，幫助他們能自主地快速獲取數據，另一方面數據倉庫團隊成員可以從日常的數據解釋中解脫出來，無論是對后期的不斷迭代更新和維護還是培訓新的員工，都非常有好處，元數據可以讓數據倉庫的應用和維護更加高效。

元數據作用

• 與其說數據倉庫是軟件開發項目，還不如說是系統集成項目，因為它的主要工作是把所需的數據倉庫工具集成在一起，完成數據的抽取、轉換和加載，OLAP分析和數據挖掘等；元數據在數據倉庫中起到了承上啟下得作用。

具體表現如下：

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文件流的方式進行交換。

五、元數據管理功能

1. 數據地圖

數據地圖展現是以拓撲圖的形式對數據系統的各類數據實體、數據處理過程元數據進行分層次的圖形化展現，并通過不同層次的圖形展現粒度控制，滿足開發、運維或者業務上不同應用場景的圖形查詢和輔助分析需要。

2. 元數據分析

血緣分析

• 血緣分析（也稱血統分析）是指從某一實體出發，往回追溯其處理過程，直到數據系統的數據源接口。對于不同類型的實體，其涉及的轉換過程可能有不同類型，如：對于底層倉庫實體，涉及的是ETL處理過程；而對于倉庫匯總表，可能既涉及ETL處理過程，又涉及倉庫匯總處理過程；而對于指標，則除了上面的處理過程，還涉及指標生成的處理過程。數據源接口實體由源系統提供，作為數據系統的數據輸入，其它的數據實體都經過了一個或多個不同類型的處理過程。血緣分析正是提供了這樣一種功能，可以讓使用者根據需要了解不同的處理過程，每個處理過程具體做什么，需要什么樣的輸入，又產生什么樣的輸出。

影響分析

• 影響分析是指從某一實體出發，尋找依賴該實體的處理過程實體或其他實體。如果需要可以采用遞歸方式尋找所有的依賴過程實體或其他實體。該功能支持當某些實體發生變化或者需要修改時，評估實體影響范圍。

實體關聯分析

• 實體關聯分析是從某一實體關聯的其它實體和其參與的處理過程兩個角度來查看具體數據的使用情況，形成一張實體和所參與處理過程的網絡，從而進一步了解該實體的重要程度。本功能可以用來支撐需求變更影響評估的應用。

實體差異分析

• 實體差異分析是對元數據的不同實體進行檢查，用圖形和表格的形式展現它們之間的差異，包括名字、屬性及數據血緣和對系統其他部分影響的差異等,在數據系統中存在許多類似的實體。這些實體（如數據表）可能只有名字上或者是在屬性中存在微小的差異，甚至有部分屬性名字都相同，但處于不同的應用中。由于各種原因，這些微小的差異直接影響了數據統計結果，數據系統需要清楚了解這些差異。本功能有助于進一步統一統計口徑，評估近似實體的差異

指標一致性分析

• 指標一致性分析是指用圖形化的方式來分析比較兩個指標的數據流圖是否一致，從而了解指標計算過程是否一致。該功能是指標血緣分析的一種具體應用。指標一致性分析可以幫助用戶清楚地了解到將要比較的兩個指標在經營分析數據流圖中各階段所涉及的數據對象和轉換關系是否一致，幫助用戶更好地了解指標的來龍去脈，清楚理解分布在不同部門且名稱相同的指標之間的差異，從而提高用戶對指標值的信任。

3. 輔助應用優化

元數據對數據系統的數據、數據加工過程以及數據間的關系提供了準確的描述，利用血緣分析、影響分析和實體關聯分析等元數據分析功能，可以識別與系統應用相關的技術資源，結合應用生命周期管理過程，輔助進行數據系統的應用優化.

4. 輔助安全管理

• 企業數據平臺所存儲的數據和提供的各類分析應用，涉及到公司經營方面的各類敏感信息。因此在數據系統建設過程中，須采用全面的安全管理機制和措施來保障系統的數據安全。
• 數據系統安全管理模塊負責數據系統的數據敏感度、客戶隱私信息和各環節審計日志記錄管理，對數據系統的數據訪問和功能使用進行有效監控。為實現數據系統對敏感數據和客戶隱私信息的訪問控制，進一步實現權限細化，安全管理模塊應以元數據為依據，由元數據管理模塊提供敏感數據定義和客戶隱私信息定義，輔助安全管理模塊完成相關安全管控操作。

5. 基于元數據的開發管理

數據系統項目開發的主要環節包括：需求分析、設計、開發、測試和上線。開發管理應用可以提供相應的功能，對以上各環節的工作流程、相關資源、規則約束、輸入輸出信息等提供管理和支持。

推薦學習文章：https://tech.youzan.com/youzan-metadata/ 有贊數據倉庫元數據系統實踐

參考博客 ： 聊一聊數據倉庫中的元數據管理系統
元數據及數據倉庫相關概念