大數據治理系列：實施元數據管理

元模型（Metamodel）

模型（Model）是用來描述特定的系統、過程、事物或概念的準確而抽象的表示。例如軟體架構師可以用概要設計的形式建立一個應用系統的模型。本質上來說，元數據是數據的形式化模型，是數據的抽象描述，該描述準確地描述了數據。元模型（Metamodel）也就是模型的模型（或者元-元數據），是用來描述元數據的模型。

實施元數據管理

在明確了元數據管理策略和元數據集成體系結構之後，企業可以根據需要選擇合適的業務元數據和技術元數據管理工具，並制定相應的元數據管理制度進行全面的元數據管理。比如可以使用 IBM InfoSphere Business Glossary 進行業務元數據的管理，使用 IBM InfoSphere Metadata Workbench 作為元數據管理統一工具並進行圖形化的元數據分析。

大數據擴大了數據的容量、速度和多樣性，給元數據管理帶來了新的挑戰。在構建關係型數據倉庫、動態數據倉庫和關係型數據中心時進行元數據管理，有助於保證數據被正確地使用、重用並滿足各種規定。同樣，對大數據來說，元數據管理過程中出現的任何錯誤，都會導致數據重複、數據質量差和無法訪問關鍵信息等問題 。隨著大數據技術在企業中的應用越來越廣泛，企業需要在原有的元數據管理策略中增加大數據相關的內容。通常，大數據分析是受用例驅動的，企業可以通過梳理大數據用例的方式逐步完善大數據的元數據管理。

針對大數據的業務元數據，依舊可以通過構建基礎本體、領域本體、任務本體和應用本體等 的方式來實現。通過構建基礎本體，實現對級別且通用的概念以及概念之間關係的描述；通過構建領域本體，實現對於領域的定義，並確定該領域內共同認可的辭彙、辭彙業務含義和對應的信息資產等，提供對該領域知識的共同理解；通過構建任務本體，實現任務元素及其之間關係的規範說明或詳細說明；通過構建應用本體，實現對特定應用的概念描述，其是依賴於特定領域和任務的。這樣就通過構建各種本體，在整個企業範圍提供一個完整的共享辭彙表，保證每個元數據元素在信 息供應鏈中每個組件的語義上保持一致，實現是語義等效。

為了實現信息供應鏈中各個組件元數據的交互和集成，大數據平台的元數據集成體系結構 依然可以採用基於模型驅動的中央輻射式元數據體系結構。對大數據平台中的結構化數據的元數據管理可以遵循公共倉庫元模型（CWM）構建元數據體系結構，以便方便的實現各個組件間元數據的交互；對大數據平台中的半結構化和非結構化數據的元數據管理，因為業內還沒有通用的公共元模型，企業可以嘗試採用基於自定義模型驅動的方式構建中央輻射式元數據體系結構。

簡單來說，企業可以嘗試以下步驟進行大數據的元數據管理：

考慮到企業可以獲取數據的容量和多樣性，應該創建一個體現關鍵大數據業務術語的業務定義詞庫（本體），該業務定義詞庫不僅僅包含結構化數據，還可以將半結構化和非結構化數據納入其中。

及時跟進和理解各種大數據技術中的元數據，提供對其連續、及時地支持，比如 MPP 資料庫、流計算引擎、Apache hadoop/企業級 Hadoop、NoSQL 資料庫以及各種數據治理工具如審計/安全工具、信息生命周期管理工具等。

對業務術語中的敏感大數據進行標記和分類，並執行相應的大數據隱私政策。

將業務元數據和技術元數據進行鏈接，可以通過操作元數據（如流計算或 ETL 工具所生成的數據）監測大數據的流動；可以通過數據世系分析（血緣分析）在整個信息供應鏈中實現數據的正向追溯或逆向追溯，了解數據都經歷了哪些變化，查 看欄位在信息供應鏈各組件間轉換是否正確等；可以通過影響分析可以了解具體某個欄位的變更會對信息供應鏈中其他組件中的欄位造成哪些影響等。

擴展企業現有的元數據管理角色，以適應大數據治理的需要，比如可以擴充數據治理管理者、元數據管理者、數據主管、數據架構師以及數據科學家的職責，加入大數據治理的相關內容。

在實施元數據管理的過程中，可以參照元數據管理的成熟度模型確定企業當前元數據管理所在層次，並根據業務需要制定路線圖實現元數據管理水平的提升。元數據管理成熟度模型具體如圖 1 所示：

圖 1. 元數據管理成熟度模型

根據元數據管理的成熟度，大體可以分成 6 個級別，具體如圖 1 所示：

L0: 初始狀態

元數據分散於日常的業務和職能管理中，由某個人或某一組人員在局部產生或獲取，並在局部使用，其他人如果想獲得該元數據需要找到相應的人進行溝通獲取。

L1: 從屬於業務系統

在這個階段，隨著各個業務系統自動化構建完成，相應的元數據也隨著需求整理、設計、開發、實施和維護等過程被各個業務系統孤立的全部或部分管理起來。業務元數據可能分散在 各種業務規章、流程規定、需求、需求分析和概要設計等文檔以及業務系統中，技術元數據可能分散在詳細設計、模型設計和部署方案等各種文檔和各種中間件以及 業務系統中。由於各個業務系統處於一個個豎井之中，元數據之間互通互聯困難，如果需要獲取其他系統的元數據，除了調閱各種文檔外，對分散在各種中間件和業 務系統中的技術元數據需要通過橋（bridge）的方式實現互通互聯。

L2：元數據統一存儲

元數據依然在局部產生和獲取，但會集中到中央存儲庫進行存儲，業務元數據會手工錄入到中央存儲庫中，技術元數據分散在文檔中的部分也通過手工錄入到中央存儲庫中，而散落在 各個中間件和業務系統中的技術元數據則通過橋（bridge）的方式被讀取到中央存儲庫中。業務元數據和技術元數據之間全部或部分通過手工方式做了關聯。 中央存儲庫的構建，使得元數據在整個企業層面可被感知和搜索，極大地方便了企業獲取和查找元數據。缺點是，元數據仍然在各業務系統上維護，然後更新到中央存儲庫，各業務豎井之間仍然使用不同的命名法，經常會造成相同的名字代表不同意義的事情，而同一件事情則使用了多個不同的名字，有些沒有納入業務系統管理 的元數據則容易缺失。元數據沒有有效的許可權管理，局部元數據更改後也不自動通知其他人。

L3: 元數據集中管理

在 L2 的基礎上做了改進，增強了元數據的集中控制，局部業務單元或開發小組如不事先通知其他人，將無法對元數據進行修改。局部元數據的修改完成後將被廣播給其他 人。和其他中間件和應用系統的交互，仍然通過橋（bridge）的方式進行，中央存儲庫中的業務元數據和技術元數據之間還是通過手工方式進行映射。

L4：元模型驅動管理

在 L3 的基礎上，通過構建元模型以及元元模型，優化各業務單元之間的各種衝突和各種副本，創建、管理和共享業務辭彙表和分類系統（基於主題領域的層次結構）。業務辭彙表（業務元數據）包含與企業相關的辭彙、辭彙業務含義以及辭彙與信息資產（技術元數據）的關係，可以有效幫助企業用戶了解其業務元數據和技術元數據 對應的業務含義。分類是基於主題領域的層次結構，用以對業務術語歸類。和其他中間件和應用系統的交換，通過基於 CWM 的適配器方式進行連接。

L5: 元數據管理自動化

在 L5 元數據管理是高度自動化的，當邏輯層次元數據變更時，會被傳播到物理層次，同樣物理層次變更時邏輯層次將被更新。元數據中的任何變化將觸發業務工作流，以 便其他業務系統進行相應的修改。由於各個業務系統遵照相同的業務辭彙表和分類系統（元模型），他們之間的關係可以通過知識本體進行推斷，因此各個應用系統 之間的數據格式的映射自動產生。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！