數字化時代，企業需要知道它們擁有什么數據，數據在哪里、由誰負責，數據中的值意味著什么，數據的生命周期是什么，哪些數據安全性和隱私性需要保護，以及誰使用了數據，用于什么業務目的，數據的質量怎么樣，等等。這些問題都需要通過元數據管理解決，缺乏有效的元數據管理，企業的數據資產可能會變成拖累企業利潤的“包袱”。數據已經成為增強企業競爭力的核心要素，有效地管理和使用數據成為企業的剛需。越來越多的企業使用元數據管理工具來管理云計算、物聯網、數據湖中所產生的數據，以便更容易地理解、更快地查找和更有效地管理企業數據，實現數據的價值。本文介紹什么是元數據和元數據管理，以及常用的元數據管理策略、方法和技術。

01?元數據管理概述

沒有元數據，數據其實就沒有任何意義。元數據看起來只是一堆毫無意義的文字和數字，但本質上它為企業的各類數據提供了上下文環境，使企業能夠更好地了解、管理和使用數據。

1.1?什么是元數據

元數據是關于數據的組織、數據域及其關系的信息，簡言之，元數據就是描述數據的數據。

概念總是生澀的，對于沒有IT背景的人來說比較抽象，不容易理解，下面舉幾個例子。

示例1：歌詞中的元數據

有一首很多80后耳熟能詳的歌曲叫《小芳》，歌詞中有這么一句：“村里有個姑娘叫小芳，長得好看又善良。”我們對這句歌詞做一下分析。姓名，小芳；性別，姑娘（女）；長相，好看；性格，善良；住址，村里。“小芳”是被描述的對象，而“姓名”“性別”“長相”“性格”“住址”就是描述“小芳”的元數據。

示例2：戶口本中的元數據

戶口本中除了有姓名、身份證號、出生日期、住址、民族等信息外，還有家庭關系，如夫妻關系、父子關系、兄弟關系等。這些信息就是描述一個人的元數據，通過戶口本中的元數據，我們不僅能夠了解一個人的基本信息，還能夠了解其家庭關系。

示例3：圖書館中的元數據

圖書館都會用一個叫作“圖書目錄”的文件夾來管理藏書，圖書目錄包含圖書名稱、編號、作者、主題、簡介、擺放位置等信息，用來幫助圖書管理員管理和快速查找圖書。元數據就如同圖書館的圖書目錄一樣，能夠幫助數據管理員管理數據。

示例4：元數據好比字典

字典包含一個字的注音、含義、組詞、舉例等基本信息及其字體結構、相關引用、出處等。另外，我們可以通過拼音或偏旁部首查到這個字。所有這些信息都是對這個字的詳細描述，它們就是描述這個字的元數據。

示例5：元數據就像地圖

地圖是按一定比例運用線條、符號、顏色、文字注記等描繪顯示地球表面的自然地理、行政區域、社會經濟狀況的圖。通過地圖，您能夠找到自己所處的地理位置，了解您從哪里來，到哪里去，途中要路過哪些地方。元數據也具備這樣的特點，它能夠幫助企業了解自己有哪些數據，這些數據存放在哪里，數據的來源、去向及加工路徑等。

元數據與數據的不同之處在于：元數據描述的不是特定的實例或記錄，IT部門和業務部門都需要高質量的元數據來理解現有數據；元數據是比一般意義上的數據范疇更加廣泛的數據，不僅表示數據的類型、名稱、值等信息，還提供數據的上下文描述，比如數據的所屬業務域、取值范圍、數據間的關系、業務規則、數據來源等。

可以用5W1H模型來理解元數據，如表1所示。表1? 用5W1H模型理解元數據

1.2?元數據的3種類型

按照不同應用領域或功能，元數據一般大致可分為三類：業務元數據、技術元數據和操作元數據。

1.2.1?業務元數據

業務元數據描述數據的業務含義、業務規則等。明確業務元數據可以讓人們更容易理解和使用業務元數據。元數據消除了數據二義性，讓人們對數據有一致的認知，避免“自說自話”，進而為數據分析和應用提供支撐。

常見的業務元數據有：業務定義、業務術語解釋等；業務指標名稱、計算口徑、衍生指標等；業務引擎的規則、數據質量檢測規則、數據挖掘算法等；數據的安全或敏感級別等。

1.2.2?技術元數據

技術元數據是結構化處理后的數據，方便計算機或數據庫對數據進行識別、存儲、傳輸和交換。技術元數據可以服務于開發人員，讓開發人員更加明確數據的存儲、結構，從而為應用開發和系統集成奠定基礎。技術元數據也可服務于業務人員，通過元數據厘清數據關系，讓業務人員更快速地找到想要的數據，進而對數據的來源和去向進行分析，支持數據血緣追溯和影響分析。

常見的技術元數據有：物理數據庫表名稱、列名稱、字段長度、字段類型、約束信息、數據依賴關系等；數據存儲類型、位置、數據存儲文件格式或數據壓縮類型等；字段級血緣關系、SQL腳本信息、ETL信息、接口程序等；調度依賴關系、進度和數據更新頻率等。

1.2.3?操作元數據

操作元數據描述數據的操作屬性，包括管理部門、管理責任人等。明確管理屬性有利于將數據管理責任落實到部門和個人，是數據安全管理的基礎。

常見的操作元數據有：數據所有者、使用者等；數據的訪問方式、訪問時間、訪問限制等；數據訪問權限、組和角色等；數據處理作業的結果、系統執行日志等；數據備份、歸檔人、歸檔時間等。

元數據的分類及實例見表2。

表2? 元數據的分類（以“客戶”信息為例）

1.3?元數據的6個作用

在信息世界，元數據的主要作用是對數據對象進行描述、定位、檢索、管理、評估和交互。

描述：對數據對象的內容、屬性的描述，這是元數據的基本功能，是各組織、各部門之間達成共識的基礎。

定位：有關數據資源位置方面的信息描述，如數據存儲位置、URL等記錄，可以幫助用戶快速找到數據資源，有利于信息的發現和檢索。

檢索：在描述數據的過程中，將信息對象中的重要信息抽出標引并加以組織，建立它們之間的關系，為用戶提供多層次、多途徑的檢索體系，幫助用戶找到想要的信息。

管理：對數據對象的版本、管理和使用權限的描述，方面信息對象管理和使用。

評估：由于有元數據描述，用戶在不瀏覽具體數據對象的情況下也能對數據對象有個直觀的認識，方便用戶的使用。

交互：元數據對數據結構、數據關系的描述方便了數據對象在不同部門、不同系統之間進行流通和流轉，并確保流轉過程中數據標準的一致性。

元數據以數字化方式描述企業的數據、流程和應用程序，為企業數字資產的內容提供了上下文，使得數據更容易理解、查找、管理和使用。準確的元數據是必不可少的，也是迅速、有效地對數據去粗取精的關鍵。沒有元數據，數據就毫無意義，只不過是一堆數字或文字而已。因此，對于元數據的有效管理是企業數據治理的基礎。

1.4?什么是元數據管理

根據維基百科的定義，元數據管理是指與確保正確創建、存儲和控制元數據，以便在整個企業中一致地定義數據有關的活動。

元數據管理是對涉及的業務元數據、技術元數據、操作元數據進行盤點、集成和管理。采用科學有效的機制對元數據進行管理，并面向開發人員、業務用戶提供元數據服務，可以滿足用戶的業務需求，為企業業務系統和數據分析的開發、維護等過程提供支持。

可以從技術、業務和應用三個角度理解元數據管理。

技術角度：元數據管理著企業的數據源系統、數據平臺、數據倉庫、數據模型、數據庫、表、字段以及字段間的數據關系等技術元數據。

業務角度：元數據管理著企業的業務術語表、業務規則、質量規則、安全策略以及表的加工策略、表的生命周期信息等業務元數據。

應用角度：元數據管理為數據提供了完整的加工處理全鏈路跟蹤，方便數據的溯源和審計，這對于數據的合規使用越來越重要。通過數據血緣分析，追溯發生數據質量問題和其他錯誤的根本原因，并對更改后的元數據進行影響分析。

企業元數據管理的主要活動包括：創建并記錄主題領域的實體和屬性的數據定義；識別數據對象之間的業務規則和關系；證明數據內容的準確性、完整性和及時性；建立和記錄內容的上下文（數據血緣、數據影響的全鏈路跟蹤分析）；為多樣化的數據用戶提供一系列上下文理解，包括用于合規性、內部控制和更好決策的可信數據；為技術人員提供元數據信息，支持數據庫或應用的開發。

1.5?元數據管理的3個目標

企業元數據管理的本質是有效利用企業數據資產，讓數據發揮出盡可能大的價值。元數據管理可以幫助業務分析師、系統架構師、數據倉庫工程師和軟件開發工程師等相關干系人清楚地知道企業擁有什么數據，它們存儲在哪里，如何抽取、清理、維護這些數據并指導用戶使用。

以下元數據管理目標是企業的普遍訴求。

1.5.1?建立指標解釋體系

滿足用戶對業務和數據理解的需求，建立標準的企業內部知識傳承的信息承載平臺，建立業務分析知識庫，實現知識共享。能夠回答以下問題：

企業有哪些數據？什么是企業有效客戶？有效客戶和客戶有何區別？什么是產品的生命周期？這個數據還叫什么名字？數據倉庫中的存儲過程是誰寫的？它用來干什么？現在還在用嗎？典型應用有數據資源目錄和業務術語表。

1.5.2?提高數據溯源能力

讓用戶能夠清晰地了解數據倉庫中數據流的來龍去脈、業務處理規則、轉換情況等，提高數據的溯源能力，支持數據倉庫的成長需求，降低因員工換崗造成的影響。元數據有助于回答以下問題：

這張表是從哪個業務系統中抽取過來的？ETL過程是否對數據進行過加工處理？進行了哪些處理？指標數據是從哪些表匯總計算出來的？

典型應用有血緣分析、影響分析、全鏈路分析。

1.5.3?數據質量稽核體系

通過非冗余、非重復的元數據信息提高數據完整性、準確性。元數據管理解決的問題是如何將業務系統中的數據分門別類地進行管理，建立報警、監控機制，出現故障時能及時發現問題，為數據倉庫的數據質量監控提供基礎素材。能夠回答以下問題：

今天的在線用戶數為什么是0？為什么A報表中的本月收入值與B報表中的不同？典型應用有指標標準和數據質量規則。

1.6?元數據管理的4個挑戰

盡管企業越來越意識到元數據管理的重要性，但是在實際的數據治理中，元數據管理技術和方法仍面臨著很多挑戰。

1.6.1?局部的元數據管理

雖然很多企業已經意識到元數據管理能夠創建對數據的統一描述并確保數據的一致性，但是，目前國內企業的元數據管理多數是建立在新建系統或數據倉庫項目的局部治理上，而不是企業級的元數據管理，特別是對于企業采購的套裝軟件的治理顯得十分薄弱。主要原因是，要將中央元數據倉庫的元數據與套裝軟件產生的元數據進行匹配和映射，需要做大量工作。有的企業的元數據管理平臺成為擺設，或者只有部分IT人員在用，很少甚至完全沒有嘗試在整個企業中使用和推廣集中化的元數據。這在一定程度上限制了企業數據資產的共享或重用。因此，元數據管理需要全局、集中化的管理策略。

1.6.2?手動的元數據管理

在企業元數據管理項目的實施中，需要花費很長的時間來完成元數據的梳理和定義、元數據適配器的開發、元數據的采集、元數據的維護等任務。這些任務絕大多數是需要人工手動處理的，手動的元數據管理和維護十分煩瑣且容易出錯，這使得項目的成本提高，交付的周期變長。

因此，元數據管理需要更加有效的方法和自動化程度更高的工具。

1.6.3?日趨復雜的數據環境

大數據時代，隨著越來越多的非結構化、半結構化數據滲透到企業的數字環境中，采用傳統的元數據管理方式來采集、處理和檢索元數據變得越來越具有挑戰性。尤其是在處理復雜的數據關系時，雖然人們很容易根據認知關聯來判斷兩個或多個事物是否相關，但目前的元數據管理工具卻常常無法做到。

因此，元數據管理需要更智能化的技術。

1.6.4?數據的頻繁變化

企業的數據是在數據供應鏈中不斷移動的。這里所說的數據供應鏈，是指從數據創建到數據的加工處理、存儲使用的整個生命周期鏈條。隨著數據的不斷創建、抽取和轉換，有關數據來源、血緣、轉換過程、質量級別以及與其他數據的關系的元數據也會隨時變化。企業需要將自動化算法和規則應用于數據資產管理中，自動識別和生成元數據，減少手動維護的情況，從而確保元數據描述準確可靠。

1.7?元數據管理的4個階段

從元數據的發展歷史來看，元數據管理主要經歷了4個階段：分布式橋接階段、中央存儲庫階段、元數據倉庫階段、智能化管理階段（見圖1）。圖1? 元數據管理的4個階段

1.7.1?分布式橋接階段

分布式的元數據管理使用元數據橋實現不同工具間的元數據集成，這是一種點到點的元數據體系結構。分布式的橋接方式自然會導致分布式的元數據分發機制，這違背了數據倉庫“集中存儲，統一視圖”的處理原則，也是它的主要弱點。用這種方式集成元數據會大幅增加開發和維護費用，而且通常將一種格式的元數據轉換為另一種格式時，都會有一定的信息損失。分布式的元數據結構需要對互相共享元數據的數據庫進行同步，尤其是重復元數據的更新須被檢測并通告，以保持一致性。

1.7.2?中央存儲庫階段

建立具有特定目標和需求的元數據中央存儲庫，由它來統一采集、存儲、控制和分發元數據。例如，CRM、SCM等應用系統從中央存儲庫中檢索、使用元數據。

在這種模式下，元數據依然在局部產生和被獲取，但會集中到中央存儲庫進行存儲，業務元數據會手工錄入中央存儲庫中，技術元數據分散在文檔中的部分也通過手工錄入中央存儲庫中，而散落在各個中間件和業務系統中的技術元數據則通過數據集成的方式被讀取到中央存儲庫中。業務元數據和技術元數據之間全部或部分通過手工方式進行了關聯。

每個應用系統都必須實現它自己的數據庫訪問層（另一種形式的橋接），各大BI工具廠商通常都保證它們的工具本身就能夠支持元數據管理，例如Informatica的Metadata Manager、MetaStage。然而在具體實現中，它們的工具只是提供橋梁，從像Oracle這樣的RDBMS、Hyperion Essbase之類的MDDB、BusinessObjects之類的報表工具，甚至像ERWin這樣的數據建模工具中提取信息，然后將提取出的信息存儲到一個集中式的中央存儲庫中。

使用元數據中央存儲庫可以在一定程度上解決定義全局可用且被廣泛理解的元數據的需求，使元數據在整個企業層面可被感知和搜索，極大地方便企業獲取和查找元數據。但這并沒有完全根除問題：元數據仍然在各業務系統上維護，然后更新到中央存儲庫，各業務豎井之間仍然使用不同的命名法，經常會造成相同的名字代表不同意義的對象，而同一個對象則使用了多個不同的名字，有些沒有納入業務系統管理的元數據則容易缺失。中央存儲庫仍然需要使用元數據橋，無法根除受制于特定廠商的問題。

1.7.3?元數據倉庫階段

元數據倉庫遵循基于CWM（公共倉庫元模型）的元數據管理策略。CWM是用來輸入、輸出共享公共倉庫元數據的一個完全的語法和語義規范，提供了一個描述數據源、數據目標、轉換、分析和處理的元數據管理基礎框架，為不同工具和產品的元數據共享和交換提供了一個切實可行的標準。

通過構建基于CWM的元數據倉庫，數據源、ETL工具、各類報表和BI工具、各類數據庫系統的元數據有了一致的標準，各軟件工具只需要建立一個與元數據倉庫連接的CWM適配器就能實現相互之間的元數據交換或共享。

與中央存儲庫模式相比，基于CWM的元數據倉庫模式更新數據更加及時，并支持增量元數據的版本管理，而中央存儲庫的元數據更新周期通常在一天以上，并且需要將所有不同時期的元數據都存儲下來才能支持元數據版本管理。但本質上，元數據倉庫模式并沒有多大變化，業務元數據仍然需要手動補錄，業務元數據和技術元數據之間大多還是需要通過手工方式進行映射，因此管理成本無法降低很多。

當前，大部分企業的元數據管理處于中央存儲庫和元數據倉庫這兩個階段。

1.7.4?智能化管理階段

在這個階段，元數據管理的特點是自動化、智能化，通過與人工智能、機器學習等技術融合，實現元數據提取、整合、維護等多個過程的自動化和智能化。

（1）元數據提取

對于半結構化、非結構化的數據，例如文本文件、音視頻文件，采用文本識別、圖像識別、語音識別、自然語言處理等技術，自動發現和提取其元數據，形成有價值的數據資源池。

（2）元數據整合

在元數據的整合方面，通過語義模型，標簽體系自動采集相關的技術元數據和業務元數據，自動建立技術元數據與業務元數據的關系，并將其存儲進元數據存儲庫中。

（3）元數據維護

在人工智能技術的幫助下，元數據的管理和維護更加智能，例如：通過自定義規則探查元數據的一致性，并自動提醒更新和維護，確保元數據質量；通過語義分析為元數據自動打標簽，實現元數據的自動化編目等。

在這個階段，邏輯層次元數據的變更會被傳播到物理層次，同樣，物理層次變更時，邏輯層次將被更新。元數據中的任何變化都會觸發業務工作流，以便其他業務系統進行相應的修改。

02?元數據管理方法

從實施層面來看，元數據管理包括業務目標理解、元數據需求規劃、元數據設計、元數據管理體系的設計等。

2.1?業務目標理解

元數據管理是利用可視化的用戶體驗，基于靈活、健壯的元數據管理架構，實現企業數據資產的標準化、集中化管理。企業實施元數據管理需要首先從理解業務需求入手，只有理清了業務需求和目標，才能做出合理的元數據規劃。

通常企業實施元數據管理的主要業務訴求如下。（1）建立企業數據資產目錄

數據即資產的理念已經得到企業的廣泛認可。面對不斷增長、不斷變化、日益復雜的數據環境，企業需要數據資產的簡單發現和跟蹤能力。通過管理元數據，企業能夠快速發現數據資產的分布和關系，形成企業數據資產目錄。

（2）消除冗余，加強數據復用

通過元數據管理，建立基于CWM的元數據倉庫，實現企業元數據的統一管理，并將元數據倉庫作為“單一數據源”，為企業的應用開發提供可復用的數據模型和元數據標準，以實現元數據的重復利用，減少冗余或未使用數據，從而提高工作效率，降低軟件開發成本，縮短項目交付時間。

（3）降低因人員流動而導致知識流失的風險

企業重要的數據資產常常因關鍵員工的調離或離職而“消失”，這里所謂的“消失”通常并不是因為員工將數據惡意刪除或拿走，而是企業數據資產的存放方式、存儲位置等關鍵數據都只留在關鍵員工的大腦中，一旦該員工離開公司，數據資產也就隱沒在“茫茫數海”中了！而統一的元數據管理能夠降低企業這種數據“消失”的風險。

（4）提供數據血緣探查能力，提高數據分析的質量

數據來自什么地方以及如何產生、處理和交付數據，這為用戶提供了重要的背景知識。探查源系統中的數據可以暴露和解決數據的不準確、不一致問題，從而提升數據的質量。

此外，元數據的統一管理，提供變更管理、版本控制等能力為不斷變更的業務需求所帶來的影響提供了支撐，并加快了新應用開發項目和數據集成項目的開發速度。開發人員可以依賴統一、標準的元數據來輕松、準確地確定他們的項目所需的數據，從而節約項目開發成本，提升項目交付效率。

2.2?元數據需求規劃

在充分理解企業元數據管理訴求和目標之后，需要進行元數據規劃，設計元數據管理策略，以促進元數據目標的實現。元數據貫穿企業數據資產流動的全過程，主要包括數據源的元數據、數據采集的元數據、數據倉庫的元數據、數據集市的元數據、應用服務層的元數據和BI層的元數據等。進行元數據的需求規劃時，需要了解清楚企業的數據環境，明確數據資產的分布，明確數據的流向和路徑，從而進一步確定元數據在數據庫環境中的存儲情況，如數據結構、數據字典、數據關系、報表工具、其他第三方系統或工具等，以及是否需要元數據梳理模板，手動整理元數據作為補充等。元數據需求規劃應重點關注的需求如下。

元數據模型需求：命名規范、結構、元素及關聯關系等。

元數據接口需求：元數據資料庫及其內容，適配器、所有者、系統訪問、元數據血緣關系等。

元數據系統需求：元數據采集、元數據管理、元數據應用等。

數據安全需求：數據的分類分級、敏感數據分布、敏感數據管理要求等。

數據質量需求：數據質量規則、數據標準定義等。

數據管理需求：數據管理的組織、流程、制度、考核等。

元數據需求規劃的步驟如下。

1）企業戰略調研：調研企業的業務發展戰略和主要業務領域的業務發展規劃，梳理IT建設的歷史、現狀和初步規劃。

2）數據管理調研：調研企業數據管理的背景、問題、目標，以及企業數據管理目前的相關制度、流程和組織。

3）元數據現狀清單：功能性信息需求、邏輯模型、物理模型、業務術語字典、已有數據環境、系統文檔等。

4）數據問題分析：基于現狀評估及成熟度評估，找出差異，定位問題并進行問題根本原因分析，結合行業業務、數據發展要求，制定問題解決優先級計劃，并制定改進方案。

5）制定行動路線：元數據實施路線的制定應聚焦企業當前最緊迫、最重要的建設內容，確保項目范圍可控、成效可見。

2.3?元數據規劃設計

2.3.1?元數據設計原則

每個企業的業務各不相同，元數據的設計必須圍繞其特定的業務需求展開，需要確保企業收集正確的元數據清單以解決特定的業務問題。元數據設計應遵循以下原則。

（1）簡單性與準確性原則

對信息對象的描述應簡單易懂，應盡量基于共識采用業務語言進行設計，盡量避免使用晦澀難懂的技術語言。當然，也要考慮簡單化可能導致描述不準確，需在二者之間進行權衡。

（2）互操作性原則

元數據的互操作性體現在對異構系統間的互操作能力的支持，即在各種元數據標準下建立元數據，不僅要滿足當前應用對數據的操作，還應考慮在企業整體IT環境中的互操作性。

（3）可擴展性原則

企業的數據環境時刻在發生變化，因此元數據的設計應具備一定的可擴展性，應允許用戶在不破壞既有標準的前提下，擴充一些元素或屬性。

（4）用戶需求原則

元數據設計的目的是向用戶充分揭示信息資源，因此用戶需求應作為元數據設計的最終衡量標準，特別是在數據結構與格式的設計、數據元素的增加與取舍、語義規則的制定等方面，要盡可能從用戶需求出發，通過用戶交互和用戶反饋來完善元數據的設計。

2.3.2?元數據設計步驟

元數據設計一般分為分類、定義、獲取、發布四個步驟，并以設計結果作為基線，納入元數據平臺管理中。

（1）元數據分類

根據元數據用途及使用者的不同制定元數據分類框架，規劃業務元數據、技術元數據、操作元數據所包含的數據類型和集合。明確元數據管理的種類，如數據字典、邏輯模型、物理模型、報表定義、維度加工規則、數據映射信息、接口信息等，根據規則進行元數據分類。

常用的元數據分類方式有以下兩種。按照業務主題進行組織，即通過從業務域到業務主題、實體數據、數據模型的逐層分解方式，規劃元數據的分類。這是一種站在業務視角管理元數據的方式，能夠形成業務人員容易理解的數據目錄。按照數據源進行組織，即通過源數據系統、數據表、數據結構形式展現企業數據目錄，這種方式更便于IT人員使用元數據。

在實際的使用中，通常需要將兩個分類方式相結合，以形成企業級的元數據地圖。

（2）元數據定義

元數據定義就是對數據的業務屬性、技術屬性、操作屬性進行規范化的定義，主要是描述數據屬性的信息，如屬性名稱、用途、存儲位置、歷史數據、文件記錄等。

（3）元數據獲取

元數據的基本要素包括業務術語、業務規則、報表說明、指標定義，技術細節包括各個業務系統的數據結構、代碼字段取值、數據遷移與轉換規則等。以上元數據除了通過自動化工具獲取，有時候還需要通過模板手工整理作為補充。

對于一些數據源（例如一些老舊的信息系統），由于缺乏最初的元數據設計，所以很難獲取到準確的業務元數據。這些業務元數據更加需要業務人員的配合，由業務人員進行補充，最終形成并交付業務元數據成果。

（4）元數據發布

評估和分析分散在各個應用系統、各個部門中的業務元數據、技術元數據之間的關聯性，建立技術元數據與業務元數據的映射，形成企業級元數據地圖，發布元數據基線。

在后續的運維過程中，根據各業務部門的用數需求，分析判斷元數據倉庫中是否已存在相應的元數據。如果元數據倉庫中已有該元數據，則直接共享使用；如果元數據倉庫中沒有，則需要確定采集方案，進行數據采集，并對采集的元數據進行整理完善，與生產庫建立映射關系，最后完成新增元數據的發布。

元數據規劃設計是元數據管理實施中最重要，也是工作量最大的一個過程，這是國內大多數企業元數據管理的現狀。究其原因，主要還是數據管理體系不夠成熟，也可以說是數據不夠成熟。很多企業從一開始就沒有完整的數據規劃，比如業務術語、指標的定義，現在幾乎要整體倒推，獲得元數據自然就比較困難。

2.4?元數據管理體系設計

在數據治理整體框架下，建立元數據管理體系，從組織、制度、流程、技術與工具等方面保障元數據的有效實施和運營管理，規范元數據的日常采集和處理活動，幫助企業有效管理元數據。

組織保障：明確業務牽頭部門、業務與信息化的協作關系，明確各部門數據認責范圍。在數據治理團隊的指導下，針對企業的數據管理組織現狀，建立公司高層支持、中層管理協調、基層執行三個層面的數據治理組織，明確各層的工作職責，為元數據管理工作提供組織保障。

制度保障：元數據管理是企業的IT基礎設施，涉及的系統較廣，需要調動的資源較多，在實施的過程中，企業高層管理者需要給予強有力的支持，并制定相應的規章制度進行保障，這是項目實施持續推進的動力。

流程保障：為保證數據治理措施的落地執行，需要從數據認責、標準管理、質量管理等多個方面進行流程設計，制定企業范圍內數據的變更管理流程，保證信息系統中的數據與管理規范、數據標準的一致性。

技術與工具：搭建統一的元數據管理平臺，實現企業級元數據集中管控，支持元數據采集、元數據管理、元數據共享、元數據血統分析、元數據影響分析、企業數據地圖等功能。

運營維護：定義捕獲、維護業務元數據、技術元數據、操作元數據，定期分發和交付元數據。

監控管理：提供元數據的新增和變更流程，控制元數據新增、變更等操作，支持元數據的日常監控，管理元數據版本，做好元數據的血緣分析、影響分析。

統計分析：元數據系統運營情況統計報告，支持元數據查詢、元數據使用情況分析（如冷熱度分析）等。

宣傳推廣：通過企業內部網絡、會議等各種渠道，推廣元數據管理平臺，提高元數據管理平臺的使用量，提升元數據在企業中的價值認識度。

03?元數據管理技術

從技術層面來看，元數據管理技術主要包括元數據采集、元數據管理、元數據應用和元數據接口等。

3.1?元數據采集

在數據治理項目中，常見的元數據有數據源的元數據、數據加工處理過程的元數據、數據倉庫或數據主題庫的元數據、數據應用層的元數據、數據接口服務的元數據等。

元數據采集服務提供各類適配器來滿足以上各類元數據的采集需求，并將元數據整合處理后統一存儲于中央元數據倉庫，實現元數據的統一管理。在這個過程中，數據采集適配器十分重要，元數據采集不僅要能夠適配各種數據庫、各類ETL、各類數據倉庫和報表產品，還需要適配各類結構化或半結構化數據源。

3.1.1?關系型數據庫

通過元數據適配器采集來自Oracle、DB2、SQL Server、MySQL、Teradata、Sybase等關系型數據庫的庫表結構、視圖、存儲過程等元數據。關系型數據庫一般都提供了元數據的橋接器，例如Oracle的RDBMS，可實現元數據信息的快速讀取。

3.1.2?NoSQL數據庫

元數據采集工具應支持來自MongoDB、CouchDB、Redis、Neo4j、HBase等NoSQL數據庫中的元數據，NoSQL數據庫適配器多半利用了自身管理和查詢Schema的能力。

3.1.3?數據倉庫

對于主流的數據倉庫，可以基于其內在的查詢腳本，定制開發相應的適配器，對其元數據進行采集。例如MPP數據庫Greenplum，其核心元數據都存儲在pg_database、pg_namespace、pg_class、pg_attribute、pg_proc這幾張表中，通過SQL腳本就可以對其元數據進行采集。Hive表結構信息存儲在外部數據庫中，同時Hive提供類似show table、describe table之類的語法對其元數據信息進行查詢。

當然，也可以利用專業的元數據采集工具來采集數據倉庫系統的元數據。

3.1.4?云中的元數據

隨著公有云的日趨成熟，尤其是在中小企業之間，通過提供安全的云連接將云端企業元數據管理用作核心IT基礎架構的擴展已經成為現實。云端企業元數據管理通過各種上下文改善信息訪問，并將實時元數據管理、機器學習模型、元數據API推進流數據管道，以便更好地管理企業數據資產。

3.1.5?其他元數據適配器

建模工具：PowerDesigner、ERwin、ER/Studio、EA等建模工具適配器。ETL工具：PowerCenter、DataStage、Kettle等ETL工具適配器。

BI工具：Cognos、Power BI等前端工具中的二維報表元數據采集適配器。Excel適配器：采集Excel格式文件的元數據。

當然，目前市場上的主流元數據產品中還沒有哪一個能做到“萬能適配”，在實際應用過程中都需要進行或多或少的定制化開發。

3.2?元數據管理

從技術的角度看，元數據管理一般包括元模型管理、元數據審核、元數據維護、元數據版本管理、元數據變更管理等功能。

3.2.1?元模型管理

元模型管理即基于元數據平臺構建符合CWM規范的元數據倉庫，實現元模型統一、集中化管理，提供元模型的查詢、增加、修改、刪除、元數據關系管理、權限設置等功能，支持概念模型、邏輯模型、物理模型的采集和管理，讓用戶直觀地了解已有元模型的分類、統計、使用情況、變更追溯，以及每個元模型的生命周期管理。同時，支持應用開發的模型管理。

支持元模型的全生命周期管理。元模型生命周期中有三個狀態，分別是設計態、測試態和生產態。

設計態的元數據模型，通常由ERWin、PowerDesigner等設計工具產生。測試態的元數據模型，通常是關系型數據，如Oracle、DB2、MySQL、Teradata等；或非關系型數據庫，如MongoDB、HBase、Hive等。生產態的元數據模型，本質上與測試態元數據差異不大。

通過元數據平臺對應用開發三種狀態的統一管理和對比分析，能夠有效降低元數據變更帶來的風險，為下游ODS、DW的數據應用提供支撐。

3.2.2?元數據審核

元數據審核主要是審核已采集到元數據倉庫中但還未正式發布到數據資源目錄中的元數據。審核過程中支持對數據進行有效性驗證并修復一些問題，例如缺乏語義描述、缺少字段、類型錯誤、編碼缺失或不可識別的字符編碼等。

3.2.3?元數據維護

元數據維護就是對信息對象的基本信息、屬性、被依賴關系、依賴關系、組合關系等元數據的新增、修改、刪除、查詢、發布等操作，支持根據元數據字典創建數據目錄，打印目錄結構，根據目錄發現、查找元數據，查看元數據的內容。元數據維護是最基本的元數據管理功能之一，技術人員和業務人員都會使用這個功能查看元數據的基本信息。

3.2.4?元數據版本管理

在元數據處于一個相對完整、穩定的時期，或者處于一個里程碑結束時期，可以對元數據定版以發布一個基線版本，以便日后對存異的或錯誤的元數據進行追溯、檢查和恢復。

3.2.5?元數據變更管理

用戶可以自行訂閱元數據，當訂閱的元數據發生變更時，系統將自動通知用戶，用戶可根據指引進一步在系統中查詢到變更的具體內容及相關的影響分析。元數據管理平臺提供元數據監控功能，一旦監控到元數據發生變更，就在第一時間通知用戶。

3.3?元數據應用

3.3.1?數據資產地圖

按數據域對企業數據資源進行全面盤點和分類，并根據元數據字典自動生成企業數據資產的全景地圖。該地圖可以告訴你有哪些數據，在哪里可以找到這些數據，能用這些數據干什么。數據資產地圖支持以拓撲圖的形式可視化展示各類元數據和數據處理過程，通過不同層次的圖形展現粒度控制，滿足業務上不同應用場景的圖形查詢和輔助分析需要（見圖2）。圖2? 數據資產地圖示例

3.3.2?元數據血緣分析

元數據血緣分析會告訴你數據來自哪里，經過了哪些加工。其價值在于當發現數據問題時可以通過數據的血緣關系追根溯源，快速定位到問題數據的來源和加工過程，減少數據問題排查分析的時間和難度（見圖3）。圖3? 元數據血緣分析示例

3.3.3?元數據影響分析

元數據影響分析會告訴你數據去了哪里，經過了哪些加工。其價值在于當發現數據問題時可以通過數據的關聯關系向下追蹤，快速找到有哪些應用或數據庫使用了這個數據，從而最大限度地減小數據問題帶來的影響。這個功能常用于數據源的元數據變更對下游ETL、ODS、DW等應用的影響分析。

血緣分析是向上追溯，影響分析是向下追蹤，這是這兩個功能的區別。

3.3.4?元數據冷熱度分析

元數據冷熱度分析會告訴你哪些數據是企業常用數據，哪些數據屬于僵死數據。其價值在于讓數據活躍程度可視化，讓企業中的業務人員、管理人員都能夠清晰地看到數據的活躍程度，以便他們更好地駕馭數據，處置或激活僵死數據，從而為數據的自助式分析提供支撐。

3.3.5?元數據關聯度分析

元數據關聯度分析會告訴你數據與其他數據的關系，以及它們的關系是怎樣建立的。關聯度分析是從某一實體關聯的其他實體及其參與的處理過程兩個角度來查看具體數據的使用情況，形成一張實體和所參與處理過程的網絡，如表與ETL程序、表與分析應用、表與其他表的關聯情況等，從而進一步了解該實體的重要程度。

3.4?元數據接口

建立元數據查詢、訪問的統一接口規范，以將企業核心元數據完整、準確地提取到元數據倉庫中進行集中管理和統一共享。

元數據接口規范主要包括接口編碼方式、接口響應格式、接口協議、接口安全、連接方式、接口地址等方面的內容。

接口編碼方式：接口編碼方式必須在接口的頭信息中注明，常用的接口編碼方式有UTF-8、GBK、GB2312、ISO-8859-1。接口響應格式：元數據接口常用的報文格式，XML或JSON。接口協議：REST/SOAP協議。接口安全：Token身份認證。連接方式：POST。接口地址：http://url/service?[query]。