元數據是描述數據的數據，用于打破業務和IT之間的語言障礙，幫助業務更好地理解數據。
元數據是數據中臺的重要的基礎設施，元數據治理貫徹數據產生、加工、消費的全過程，沉淀了數據資產，搭建了技術和業務的橋梁。
一、 華為數據分類管理框架
華為根據數據特性及治理方法的不同對數據進行了分類定義：
(1) 內部數據和外部數據
(2) 結構化數據和非結構化數據。結構化數據又進一步劃分為基礎數據、主數據、事務數據、報告數據、觀測數據和規則數據。
(3) 元數據
華為數據分類管理框架如圖所示：
轉自大魚的數據人生公眾號，作者歪老師
原文鏈接：//mp.weixin.qq.com/s/iAbzMo-cueIErJc_bTHKnQ
contents
目錄
數據中臺的基礎設施-元數據管理方案
01
數據中臺的基礎設施-元數據管理方案
03
03
關于元數據和元數據管理，這是我的見過最全的解讀！
03
《XX集團元數據管理辦法》
無論結構化數據，還是非結構化數據，或者內部數據還是外部數據，最終都會通過元數據治理落地。
華為將元數據治理貫穿整個數據價值流，覆蓋從數據產生、匯聚、加工到消費的全生命周期。
相較于結構化數據，非結構化元數據管理除了需要管理文件對象的標題、格式、Owner等基本特征和定義外，還需對數據內容的客觀理解進行管理，如標簽、相似性檢索、相似性連接等，以便于用戶搜索和消費使用。因此，非結構化數據的治理核心是對其基本特征與內容進行提取，并通過元數據落地來開展的。
非結構化數據的管理模型如圖所示：
二、 元數據治理面臨的挑戰
華為在進行元數據治理以前，遇到的元數據問題主要表現為數據找不到、讀不懂、不可信，數據分析師們往往會陷入數據沼澤中，例如以下常見的場景：
- ?某子公司需要從發貨數據里對設備保修和維保進行區分，用來不對過保設備進行服務場景分析。為此，數據分析師需面對幾十個IT系統，不知道該從哪里拿到合適的數據。
- 因盤點內部要貨的研發領料情況，需要從IT系統中獲取研發內部的要貨數據，面對復雜的數據存儲結構（涉及超過40個物理表和超過1000個字段）、物理層和業務層脫離的情況，業務部門的數據分析師無法讀懂物理層數據，只能提出需求向IT系統求助。
- 某子公司存貨和收入管理需要做繁重的數據收集與獲取工作，運行一次計劃耗時超過20個小時。同時，由于銷售、供應、交付各領域計劃的語言不通，還需要數據分析師進行大量人工轉換與人工校驗。
以上場景頻繁出現在公司日常運營的各個環節，極大地阻礙了公司數字化轉型的進行，其根本原因就在于：
1) 業務元數據與技術元數據未打通，導致業務讀不懂IT系統中的數據。
2) 缺乏面向普通業務人員的準確、高效的數據搜索工具，業務人員無法快速獲取可信數據。
元數據管理的痛點如圖所示：
為解決以上痛點，華為建立了公司級的元數據管理機制：
- 制定了統一的元數據管理方法、機制和平臺，拉通業務語言和機器語言。
- 確保數據“入湖有依據，出湖可檢索”成為華為元數據管理的使命與目標。
- 基于高質量的元數據，通過數據地圖就能在企業內部實現方便的數據搜索。
元數據通常分為業務、技術和操作三類：
1) 業務元數據：用戶訪問數據時了解業務含義的途徑，包括資產目錄、Owner、數據密級等。
2) 技術元數據：實施人員開發系統時使用的數據，包括物理模型的表與字段、ETL規則、集成關系等。
3) 操作元數據：數據處理日志及運營情況數據，包括調度頻度、訪問記錄等。
在企業的數字化運營中，元數據作用于整個價值流，在從數據源到數據消費的五個環節中都能充分體現元數據管理的價值：
2、針對找數據及獲取數據難的痛點，明確業務元數據、技術元數據、操作元數據的設計原則。
1）業務元數據設計原則
● 一個主題域分組下有多個主題域，一個主題域下有多個業務對象，一個業務對象下有多個邏輯實體，一個邏輯實體下有多個屬性，一個屬性有一個數據標準。● 每個數據標準可被一個或多個屬性引用，每個屬性歸屬于一個邏輯實體，每個邏輯實體歸屬于一個業務對象，每個業務對象歸屬于一個主題域，每個主題域歸屬于一個主題域分組。
2）技術元數據設計原則
3）操作元數據設計原則● 物理表設計須滿足三范式，如為了降低系統的總體資源消耗，提高查詢效率，可反范式設計。● 物理表、視圖和字段的設計須基于用途進行分類。● 承載業務用途的物理表、虛擬表、視圖必須與邏輯實體一一對應，承載業務用途的字段必須與屬性一一對應。● 系統間的數據傳遞須優先采用數據服務。
日志目的不同的進行分類設計，日志目的相同的進行相同設計（非自研場景按軟件包適配）。
（1) 數據消費側：元數據能支持企業指標、報表的動態構建。
（2) 數據服務側：元數據支持數據服務的統一管理和運營，并實現利用元數據驅動IT敏捷開發。
（3) 數據主題側：元數據統一管理分析模型，敏捷響應井噴式增長的數據分析需求，支持數據增值、數據變現。
（4) 數據湖側：元數據能實現暗數據的透明化，增強數據活性，并能解決數據治理與IT落地脫節的問題。
（5) 數據源側：元數據支撐業務管理規則有效落地，保障數據內容合格、合規。
三、 元數據管理架構及策略
元數據管理架構包括產生元數據、采集元數據、注冊元數據和運維元數據：
1) 產生元數據：制定元數據管理相關流程與規范的落地方案，在IT產品開發過程中實現業務元數據與技術元數據的連接。
2) 采集元數據：通過統一的元模型從各類IT系統中自動采集元數據。
3) 注冊元數據：基于增量與存量兩種場景，制定元數據注冊方法，完成底座元數據注冊工作。
4) 運維元數據：打造公司元數據中心，管理元數據產生、采集、注冊的全過程，實現元數據運維。
5) 元數據管理方案：通過制定元數據標準、規范、平臺與管控機制，建立企業級元數據管理體系，并推動其在公司各領域落地，支撐數據底座建設與數字化運營。
華為元數據管理整體方案如圖所示：
（一） 產生元數據
1、明確業務元數據、技術元數據和操作元數據之間的關系，定義華為公司元數據模型，如圖所示：
2）數據資產編碼原則
數據資產編碼（DAN）是通過一組數字、符號等組成的字符串去唯一標識華為公司內部每一個數據資產，基于此唯一標識，保證各業務領域對同一數據資產的理解和使用一致，它的設計遵循以下原則：
● 統一性原則：華為公司內部只能使用一套數據資產編碼，以方便不同業務部門之間的溝通和IT應用之間的數據交換。● 唯一性原則：每一個數據資產只能用唯一的數據資產編碼進行標識，不同數據資產的編碼不允許重復，同一個編碼也只能對應到一個數據資產上。● 可讀性原則：數據資產編碼作為數據資產分類、檢索的關鍵詞和索引，需要具備一定的可讀性，讓用戶通過編碼就能初步判斷其對應的數據資產類型。● 擴展性原則：數據資產的編碼要從數據管理角度適當考慮未來幾年的業務發展趨勢，其編碼長度要能適當擴展，同時不影響整個編碼體系。
3）業務元數據資產編碼規則
業務元數據資產編碼規則主要包含三個部分：第一部分為主題域分組的編碼規則，主題域分組的編碼由公司統一分配；第二部分為主題域、業務對象、邏輯實體、屬性的編碼規則，這部分主要由數據治理平臺按照編碼規則自動生成；第三部分主要為業務元數據包含的子類對應的數據資產類型代碼。
（二） 采集元數據
元數據采集是指從生產系統、IT設計平臺等數據源獲取元數據，對元數據進行轉換，然后寫入元數據中心的過程。
元數據的來源可分為如表所示的六類：
3、規范數據資產管理，設計數據資產編碼規范
1）數據資產編碼規范
華為數據資產編碼的主要包括業務元數據和技術元數據兩大類，其中業務元數據包含主題域分組、主題域、業務對象、邏輯實體、屬性、數據標準；技術元數據包含物理數據庫、Schema、表、字段。
具體的定義與描述如表所示：
1）準備度評估項包括如下檢查要點
● IT系統名稱必須是公司標準名稱；● 數據資產目錄是否經過評審并正式發布；● 數據Owner是否確定數據密級；● 物理表/虛擬表/視圖名。
2）元數據連接需遵從以下規范
● 邏輯實體和物理表/虛擬表/視圖一對一連接規范：在業務元數據與技術元數據連接的過程中，必須遵從邏輯實體和物理表/虛擬表/視圖一對一的連接原則，如果出現一對多、多對一或多對多的情況，各領域需根據實際場景，參照元數據連接的設計模式進行調整。● 業務屬性與字段一對一連接規范：除了邏輯實體與物理表/虛擬表/視圖要求一一對應外，屬性和非系統字段（具備業務含義）也要求遵從一對一的連接原則，如出現屬性與字段匹配不上的情況，可參考元數據關聯的設計模式進行調整。
（3）元數據注冊方法
元數據注冊分為增量元數據注冊和存量元數據注冊兩種場景。
增量場景相對容易，在IT系統的設計與開發過程中，落實元數據的相關規范，確保系統上線時即完成業務元數據與技術元數據連接，通過元數據采集器實現元數據自動注冊。
針對存量場景，華為設計了元數據注冊的四大模式。在符合元數據設計規范的前提下，進行業務元數據與技術元數據的連接及注冊。
模式一：一對一模式
適用場景：
適用于數據已發布信息架構和數據標準且物理落地，架構、標準與物理落地能一一對應的場景。
解決方案：
● 將邏輯實體和物理表一對一連接。● 邏輯實體屬性和物理表字段一對一連接。
應用實例：
1）選擇適配器
適配器是指針對不同的元數據來源，采用相應的采集方式獲取元數據的程序，元數據的來源種類繁多，因而須選擇相對應的適配器及元模型。
2）配置數據源
配置數據源是采集元數據的關鍵，在確定數據源所選擇的適配器類型、適配器版本、元模型的基礎上，配置數據源的名稱、連接參數和描述。
3）配置采集任務
采集任務為自動調度的工作單元，為元數據的采集提供自動化的、周期性的、定時的觸發機制。
（三） 注冊元數據
大多數企業的數字化建設都存在增量和存量兩種場景，如何同時有效地管理這兩種場景下的元數據就成了問題的關鍵。華為通過標準的元數據注冊規范和統一的元數據注冊方法，實現了兩種場景下業務元數據和技術元數據的高效連接，使業務人員能看懂數據、理解數據，并通過數據底座實現數據的共享與消費。
（1）元數據注冊原則
元數據注冊的原則包括如下三點：
● 數據Owner負責，是誰的數據就由誰負責業務元數據和技術元數據連接關系的建設和注冊發布；● 按需注冊，各領域數據管理部根據數據搜索、共享的需求，推進元數據注冊；● 注冊的元數據的信息安全密級為內部公開。
（2）元數據注冊規范
通過“元數據注冊三步法”完成元數據注冊，如圖所示：
模式二：主從模式
適用場景：
適用于主表和從表結構一致，但數據內容基于某種維度分別存儲在不同物理表中的場景。例如，按時間或項目歸檔，或按區域進行分布式存儲。
解決方案：
● 識別主物理表和從屬物理表。● 以主物理表為核心，縱向UNION所有從屬物理表，并固化為視圖。● 將視圖、邏輯實體、字段和業務屬性一對一連接。
應用實例：
模式四：父子模式
適用場景：
適用于多個邏輯實體業務屬性完全相同，按不同場景區分邏輯實體名稱，但落地在同一張物理表的場景。
解決方案：
● 識別一張物理表和對應的多個邏輯實體。
● 將物理表按場景拆分和多個邏輯實體一對一連接。
● 將物理表字段和多個邏輯實體屬性一對一連接。
應用實例：
模式三：主擴模式
適用場景：
適用于邏輯實體的大部分業務屬性在主物理表，少數屬性在其他物理表中的場景。
解決方案：
● 識別主物理表和擴展物理表。● 以主物理表為核心，橫向JOIN所有擴展物理表，完成擴展屬性與主表的映射，并固化為視圖。● 將視圖、邏輯實體、字段和業務屬性一對一連接。
應用實例：
具體應用實例如圖所示
完成元數據注冊后，通過元數據中心自動發布。
（四） 運維元數據
運維元數據是為了通過對元數據進行分析，發現數據注冊、設計、使用的現狀及問題，確保元數據的完整、準確。
通過數據資產分析，了解各區域/領域的數據注冊情況，進而發現數據在各信息系統使用過程中存在的問題。
通過業務元數據與技術元數據的關聯分析，反向校驗架構設計與落地的實施情況，檢查公司數據管理政策的執行情況。
主要分為如下四個場景：
● 場景一：基于數據更新發現，數據源上游創建，下游更新；● 場景二：通過數據調用次數發現，某數據源上游調用次數<下游調用次數；● 場景三：雖制定了架構標準，但不知落地情況，比如某個屬性建立了數據標準，但是卻找不到對應落地的物理表字段；● 場景四：通過物理表的字段分析，發現很多字段缺少數據標準。
四、 元數據與一體化建模管理
華為公司過去長期存在信息架構與IT開發實施“兩張皮”的現象，數據人員和IT開發實施人員缺乏統一和協同，數據架構遵從無法進行實質、有效管理，信息架構資產和產品實現的物理表割裂、不匹配，同時各種數據模型資產缺失。
針對應用系統設計應遵從信息架構設計的政策要求，在相關項目、產品的流程中，缺乏顯性化的且有實操指導的角色和活動。
信息架構設計大多集中在變革項目層的設計輸出和領域層的例行刷新，未與系統落地有效拉通。
IT產品聚焦在版本交付，產品級的數據模型與數據字典缺少有效看護和及時維護。
為了解決這個問題，華為推行了一體化模型設計，不僅在工具上實現了一體化設計和開發，而且在機制上形成了信息架構設計與IT開發實施的有效協同。
通過一體化設計不僅確保了元數據驗證、發布和注冊的一致性，而且實現了產品數據模型管理和資產可視
同時，由于促成了產品元數據的持續運營，進而能夠持續對物理模型進行規范，如整改、清理各類作廢表等。
五、 元數據與數據湖管理
（一） 統一的元數據語義層管理數據湖
華為數據湖是邏輯上對內外部的結構化、非結構化的原始數據的邏輯匯聚。
數據入湖要遵從6項入湖標準，基于6項標準保證入湖的質量，同時面向不同的消費場景提供兩種入湖方式，滿足數據消費的要求。經過近兩年的數據湖建設，目前已經完成1.2萬個邏輯數據實體、28萬個業務屬性的入湖，同時數據入湖在華為公司也形成了標準的流程規范，每個數據資產都要入湖成為數據工作的重要標準。
華為數據湖不是一個單一的物理存儲，而是根據數據類型、業務區域等由多個不同的物理存儲構成，并通過統一的元數據語義層進行定義、拉通和管理。
基于良好的一體化建模架構，不僅可以打通設計和物理實現，而且能夠對設計、發布、管理運營等完整生命周期進行融合管理，包括：
● 產品邏輯模型和物理模型一體化設計，元數據管理和數據模型管理融合；● 構建數據標準池，實體屬性只能從數據標準池選擇；● 產品元數據和數據庫自動比對和驗證；● 產品元數據發布認證和信息資產打通；● 基于交易側產品元數據自助入湖。
（二） 元數據與數據入湖
數據入湖是數據消費的基礎，需要嚴格滿足入湖的6項標準，包括明確數據Owner、發布數據標準、定義數據密級、明確數據源、數據質量評估、元數據注冊。通過這6項標準保證入湖的數據都有明確的業務責任人，各項數據都可理解，同時都能在相應的信息安全保障下進行消費。
是邏輯上各種原始數據的集合，除了“原始”這一特征外，還具有“海量”和“多樣”（包含結構化、非結構化數據）的特征。數據湖保留數據的原格式，原則上不對數據進行清洗、加工，但對于數據資產多源異構的場景需要整合處理，并進行數據資產注冊。數據入湖必須要遵循6項標準，共同滿足數據聯接和用戶數據消費需求。
1、 結構化數據入湖
結構化數據是指由二維表結構來邏輯表達和實現的數據，嚴格遵循數據格式與長度規范，主要通過關系型數據庫進行存儲和管理。
觸發結構化數據入湖的場景有兩種：
第一，企業數據管理組織基于業務需求主動規劃和統籌；第二，響應數據消費方的需求。
結構化數據入湖過程包括：數據入湖需求分析及管理、檢查數據入湖條件和評估入湖標準、實施數據入湖、注冊元數據。
(1) 數據入湖需求分析及管理
對于規劃驅動入湖場景而言，由對應的數據代表基于數據湖的建設規劃，輸出入湖規劃清單，清單包含主題域分組、主題域、業務對象、邏輯實體、業務屬性、源系統物理表和物理字段等信息。
對于需求驅動入湖場景而言，由數據消費方的業務代表提出入湖需求，并提供數據需求的業務元數據和技術元數據的信息，包括業務對象、邏輯實體、業務屬性對應界面的截圖。
(2) 評估入湖標準
入湖標準包括以下幾點。
● 明確數據Owner：為保證入湖數據的管理責任清晰，在數據入湖前應明確數據Owner。● 發布數據標準：入湖數據應有數據標準，數據標準定義了數據屬性的業務含義、業務規則等，是正確理解和使用數據的重要依據，也是業務元數據的重要組成部分。
(3) 注冊元數據
元數據是公司的重要資產，是數據共享和消費的前提，為數據導航和數據地圖建設提供關鍵輸入。對元數據進行有效注冊是實現上述目的的前提。
虛擬表部署完成后或IT實施完成后，由數據代表檢查并注冊元數據，元數據注冊應遵循企業元數據注冊規范。
2、 非結構化數據入湖
(1) 非結構化數據管理的范圍
非結構化數據包括無格式的文本、各類格式的文檔、圖像、音頻、視頻等多樣異構的格式文件。相較于結構化數據，非結構化數據更難標準化和理解，因而非結構化數據的管理不僅包括文件本身，而且包括對文件的描述屬性，也就是非結構化的元數據信息。
這些元數據信息包括文件對象的標題、格式、Owner等基本特征，還包括對數據內容的客觀理解信息，如標簽、相似性檢索、相似性連接等。這些元數據信息便于用戶對非結構化數據進行搜索和消費。
非結構化數據的元數據實體如圖所示：
都柏林核心元數據是一個致力于規范Web資源體系結構的國際性元數據解決方案，它定義了一個所有Web資源都應遵循的通用核心標準。
基本特征類屬性由公司進行統一管理，內容增強類屬性由承擔數據分析工作的項目組自行設計，但其分析結果都應由公司元數據管理平臺自動采集后進行統一存儲。
(2) 非結構化數據入湖的4種方式
非結構化數據入湖包括基本特征元數據入湖、文件解析內容入湖、文件關系入湖和原始文件入湖4種方式，其中基本特征元數據入湖是必選內容，后面三項內容可以根據分析訴求選擇性入湖和延后入湖。
1）基本特征元數據入湖
主要通過從源端集成的文檔本身的基本信息入湖。入湖的過程中，數據內容仍存儲在源系統，數據湖中僅存儲非結構化數據的基本特征元數據。基本特征元數據入湖需同時滿足如下條件。
● 已經設計了包含基本特征元數據的索引表。● 已經設計了信息架構，如業務對象和邏輯實體。● 已經定義了索引表中每筆記錄對應文件的Owner、標準、密級，認證了數據源并滿足質量要求。
參考都柏林核心元數據，非結構化數據的基本特征類屬性元數據規范如表所示。
● 已經確定文件對應的Owner、密級和使用的范圍。● 已經獲取了文件的基本特征元數據。● 已經確定了關系實體的存儲位置，并保證至少一年內不會遷移。
4）原始文件入湖
根據消費應用案例從源端把原始文件搬入湖。數據湖中存儲原始文件并進行全生命周期管理。原始文件入湖需同時滿足如下條件。
● 已經確定原始文件對應的Owner、密級和使用的范圍。● 已經獲取了基本特征元數據。● 已經確定了存儲位置，并保證至少一年內不會遷移
六、 元數據與數據服務管理
針對數據需求，規范數據服務識別過程，列出數據服務識別過程需要了解的關鍵內容，明確數據服務的實現方式和準入條件，提高數據服務的可復用性，減少重復建設，如圖所示。
2）文件解析內容入湖
對數據源的文件內容進行文本解析、拆分后入湖。入湖的過程中，原始文件仍存儲在源系統，數據湖中僅存儲解析后的內容增強元數據。內容解析入湖需同時滿足如下條件。
● 已經確定解析后的內容對應的Owner、密級和使用的范圍。● 已經獲取了解析前對應原始文件的基本特征元數據。● 已經確定了內容解析后的存儲位置，并保證至少一年內不會遷移。
3）文件關系入湖
根據知識圖譜等應用案例在源端提取的文件上下文關系入湖。入湖的過程中，原始文件仍存儲在源系統，數據湖中僅存儲文件的關系等內容增強元數據。文件關系入湖需同時滿足如下條件：
（二） 設計質量度量與元數據為確保設計質量標準穩定，從信息架構的四個角度（數據資產目錄、數據標準、數據模型、數據分布）進行綜合評估，其范圍覆蓋度量期間內已通過IA-SAG評審發布的所有數據資產。當實際業務有例外場景時，可向IA-SAG專業評審團申請仲裁，若評審通過，則可采用白名單的方式進行管理。（1）數據資產目錄1）業務對象需有明確、唯一的數據Owner，并對該業務對象全流程端到端質量負責，如是否有定義數據質量目標、是否有數據質量工作規劃等。2）業務對象的元數據質量，如數據分類是否完整、業務定義是否準確、數據管家是否有效等。3）資產目錄完整性。（2）數據標準1）數據標準元數據質量，如數據標準是否唯一、業務用途及定義是否準確、各責任主體是否有效等。2）所有業務對象應準確關聯數據標準。
3）數據標準在IT系統及其對應的業務流程中應得到應用和遵從
1）分析數據服務需求：通過數據需求調研與需求交接，判斷數據服務類型（面向系統或面向消費）、數據內容（指標/維度/范圍/報表項）、數據源與時效性要求。
2）識別可重用性：結合數據需求分析，通過數據服務中心匹配已有的數據服務，判斷以哪種方式（新建服務、直接復用、服務變更）滿足業務需求。對于已有數據服務，必須使用服務化方式滿足需求，減少數據“搬家”。
3）判斷準入條件：判斷服務設計條件是否已具備，包括數據Owner是否明確、元數據是否定義、業務元數據和技術元數據是否建立聯接、數據是否已入湖等。
七、 元數據與構建數據地圖
在解決數據的“可供應性”之后，企業應該幫助業務更便捷、更準確地找到它們所需要的數據，這就需要打造一個能夠滿足用戶體驗的“數據地圖”。
（一） 數據地圖的核心價值
數據供應者與消費者之間往往存在一種矛盾：供應者做了大量的數據治理工作、提供了大量的數據，但數據消費者卻仍然不滿意，他們始終認為在使用數據之前存在兩個重大困難。
1）找數難
企業的數據分散存儲在上千個數據庫、上百萬張物理表中，已納入架構、經過質量、安全有效管理的數據資產也會超過上萬個，并且還在持續增長中
。例如，用戶需要從發貨數據里對設備保修和維保進行區分，以便為判斷哪類設備已過保（無法繼續服務）提供準確依據，但生成和關聯的交易系統有幾十個，用戶不知道應該從哪里獲取這類數據，也不清楚獲取的數據是否正確。
2）讀不懂
企業往往會面對數據庫物理層和業務層脫離的現狀，數據的最終消費用戶無法直接讀懂物理層數據，無法確認數據是否能滿足需求，只能尋求IT人員支持，經過大量轉換和人工校驗，才最終確認可消費的數據，而熟悉物理層結構的IT人員，并不是數據的最終消費者。例如，當需要盤點研發內部要貨情況的時候，就需要從供應鏈系統獲取研發內部的要貨數據，但業務用戶不了解該系統復雜的數據存儲結構（涉及超過40個表、1000余個字段），也不清楚每個字段名稱下所包含的業務的含義和規則。
企業在經營和運營過程中產生了大量數據，但只有讓用戶“找得到”“讀得懂”，能夠準確地搜索、便捷地訂閱這些數據，數據才能真正發揮價值。數據地圖（DMAP）是華為公司面向數據的最終消費用戶針對數據“找得到”“讀得懂”的需求而設計的，基于元數據應用，以數據搜索為核心，通過可視化方式，綜合反映有關數據的來源、數量、質量、分布、標準、流向、關聯關系，讓用戶高效率地找到數據，讀懂數據，支撐數據消費。
數據地圖作為數據治理成果的集散地，需要提供多種數據，滿足多類用戶、多樣場景的數據消費需求，所以華為公司結合實際業務制定了如圖所示的數據地圖框架。
1、總則
為了規范和加強集團的元數據管理，提升數據標準化與數據管控能力，持續改善數據質量，制定本辦法。
本辦法所稱元數據，是數據的數據，是數據的業務涵義、技術涵義和加工處理過程的定義，是數據管控的基本手段。元數據可將其按用途的不同分為業務元數據、技術元數據和操作元數據：
1.1 業務元數據主要描述數據業務涵義及應用場景，包括業務及業務延伸定義、業務規則定義，以及數據之間關系、數據所屬部門等業務相關信息；
1.2 技術元數據主要描述數據的技術涵義，包括數據庫的結構、字段長度、匯總算法、數據庫操作系統及服務器名稱、版本等技術相關信息；
1.3 操作元數據主要描述數據的加工處理過程，包括源系統名稱、源系統類型、目標系統名稱、目標系統類型、抽取轉換頻率、轉換規則等操作相關信息。本辦法所稱元數據管理，是指元數據的定義、收集、管理和發布的方法、工具及流程的集合。元數據管理旨在針對數據全生命周期的各個環節，清晰、完整地勾勒出數據資產的血緣關系視圖。
3、元數據采集與檢核
XX集團元數據管理辦法
02
文章轉自數據工程師微信公眾號
原文鏈接：//mp.weixin.qq.com/s/0dOCrTYI6SlogTpku21p2A
2、元數據管理的組織與職責
2.1 決策機構集團數據治理委員會負責元數據管理的決策，具體職責包括：
2.1.1 審批元數據管理相關辦法；
2.1.2 對元數據管理工作的重大事項和爭議事項進行決策；
2.1.3 定期聽取集團數據治理辦公室對元數據管理工作的匯報。
2.2 集團數據治理辦公室是元數據管理的責任單位，負責元數據管理工作，具體職責包括：
2.2.1 元數據管理辦法的制定、解釋和監督；
2.2.2 負責組織、推動和協調元數據管理相關工作，包括元數據采集與檢核、元數據發布與維護、元數據使用、元數據變更；
2.2.3 及時采集和維護業務元數據和各信息系統的技術和操作元數據；
2.2.4 檢核和監控元數據落地和變更情況；
2.2.5 制定元數據管理整改方案，推動元數據管理問題解決；
2.2.6 總結元數據管理工作，并定期向集團數據治理委員會匯報。
2.3 集團各職能部門或由產業、成員企業代行相關職能的單位作為數據的業務主管部門和使用部門，應對其所擁有的業務元數據進行定義與維護，具體職責包括：
2.3.1 協助集團數據治理辦公室采集業務元數據；
2.3.2 明確業務規則，制定數據標準，定義業務元數據；
2.3.3 負責本部門業務元數據的日常維護，確保相關信息系統的業務元數據完整和有效；
2.3.4 提出業務元數據變更申請并配合變更工作。
2.4 各產業集團及直管企業應遵循集團元數據管理原則和要求建立產業集團及直管企業自身的元數據管理組織及職能，組織推動產業集團及直管企業元數據管理工作。具體職責為：
2.4.1 根據集團元數據管理工作要求，制定產業集團及直管企業元數據管理工作方案和管理制度；
2.4.2 組織、推動產業集團及直管企業元數據管理工作的具體實施，包括元數據采集與檢核、元數據發布與維護、元數據使用、元數據變更等，并建立高效的元數據管理流程，及時、有效地解決產業集團及直管企業元數據管理相關問題；
2.4.3 負責定期（每月）搜集、整理和分析產業集團及直管企業元數據管理的開展情況和具體問題，并反饋至集團數據治理辦公室；對于重大元數據問題或事項，應及時向集團數據治理辦公室進行溝通和匯報。
3.1 數據需求描述、數據責任歸屬、數據標準內容、數據質量規則等均屬于元數據的范疇，當新建或修改數據需求、數據認責關系、數據標準及數據質量規則時，應及時備案，采集元數據。
3.2 集團數據治理辦公室按照“誰主管、誰提供、誰負責”的原則組織進行元數據的采集，相關職能部門應按照元數據采集要求和標準規范提供元數據信息，并對所提供的元數據信息負責。
3.3 元數據采集需合理規劃，盡可能采用自動化手段，以嚴格保證元數據采集的準確性和元數據采集的效率。
3.4 元數據采集應遵循科學的流程方法，依照以下順序進行展開：
3.4.1 確定元數據采集范圍，分業務、分系統建立自上而下的采集目錄；
3.4.2 參考開發文檔，熟悉源系統基本框架和層次邏輯；
7、其他
6.4 集團數據治理辦公室組織落實變更后的元數據發布。變更發布時應主送變更提出部門等相關部門，并及時更新和記錄發布版本作為唯一的最新版本，同時要求保留歷史版本信息。
7.1 因違反本辦法產生的不良后果或造成損失，視情節按照有關規定追究相關人員責任。
7.2 如果元數據管理工作中出現爭議或者分歧，由集團數據治理辦公室協調解決。對無法解決的重大爭議和分歧，則由集團數據治理辦公室上報集團數據治理委員會決策。
7.3 本辦法由集團數據治理辦公室負責制定、解釋和修改。
7.4 各產業集團及下屬業態公司/成員企業可參照本辦法制定本產業集團或本級機構業務數據管理實施細則并嚴格執行。
7.5 本辦法自印發之日起執行。本辦法實施前，公司頒布的相關辦法與本辦法不一致的，以本辦法為準。
4、元數據發布與維護
3.4.3 明確相關人員，對業務模塊、技術模塊和操作模塊區分不同聯系人，保證工作順利進行；
3.4.4 理解業務模型，從數據入手，結合數據進行業務模型的理解。
3.5 元數據采集完畢，集團數據治理辦公室對采集的元數據進行檢核。
3.6 元數據檢核主要針對元數據的一致性和元數據關系的健全性進行檢核，并對元數據獲取數據源及這些數據源之間的關系進行集中登記管理。
4.1元數據檢核通過后，由集團數據治理辦公室在全集團正式發布檢核確認后的元數據。
4.2 集團數據治理辦公室負責已發布元數據的日常維護，包括元數據數量和定義的更新、源數據映射關系的管理及元數據版本的管理等。
4.3 集團數據治理辦公室應定期從應用系統中抽取元數據，并與元數據庫中的對應信息進行比較，保證元數據維護及時、準確地反映了實際情況的變化。如在檢查中發現差異，集團數據治理辦公室應出具各類元數據的差異報告，并分發給相關職能部門確認，經確認無誤后再進行元數據的更新維護。
5、元數據使用
5.1 集團各職能部門均可向集團數據治理辦公室提交元數據查詢和使用請求，并經集團數據治理辦公室審批通過后，方可進行元數據的使用。
5.2 元數據的使用包括元數據查詢、元數據報表以及元數據分析，應區分業務用戶、技術用戶和IT/操作用戶的元數據使用范圍，明確其訪問控制權限。
5.3 數據的業務主管部門應通過元數據的血緣分析對所負責數據的變動情況進行監測，分析數據變化可能對上、下游數據產生的影響，并及時提示相應的職能部門。集團數據治理辦公室應履行日常監督并協調解決跨部門的相關工作事項。
6、元數據變更
6.1 集團各職能部門均可發起元數據變更申請，應向集團數據治理辦公室提交需要變更的元數據清單以及變更細節。
6.2 集團數據治理辦公室接受元數據變更申請，應考量變更的必要性，并與變更影響相關方開展變更影響分析，變更細節確認后方可批準變更。
6.3 元數據變更批準后，集團數據治理辦公室應組織元數據采集，進行元數據質量檢核，并通過血緣分析和影響分析，確定與此變更相關的數據對象、數據處理模塊和數據流程，形成完整的數據流圖及元數據變更說明文檔，發送至變更元數據上下游環節的各數據使用部門。
關于元數據和元數據管理，這是我的見過最全的解讀！
03
文章轉自知乎，作者胤子
原文鏈接：//zhuanlan.zhihu.com/p/338658341
本文主要從元數據的定義、作用、元數據管理現狀、管理標準和元數據管理功能等方面講述了我對元數據(Metadata)和元數據管理的認知及理解。
元數據管理
一、元數據的定義
按照傳統的定義，元數據（Metadata）是關于數據的數據。在數據倉庫系統中，元數據可以幫助數據倉庫管理員和數據倉庫的開發人員非常方便地找到他們所關心的數據；元數據是描述數據倉庫內數據的結構和建立方法的數據，可將其按用途的不同分為兩類：技術元數據（Technical Metadata）和業務元數據（Business Metadata）。
技術元數據
技術元數據是存儲關于數據倉庫系統技術細節的數據，是用于開發和管理數據倉庫使用的數據，它主要包括以下信息：
數據倉庫結構的描述，包括倉庫模式、視圖、維、層次結構和導出數據的定義，以及數據集市的位置和內容；
業務系統、數據倉庫和數據集市的體系結構和模式；
匯總用的算法，包括度量和維定義算法，數據粒度、主題領域、聚集、匯總、預定義的查詢與報告；
由操作環境到數據倉庫環境的映射，包括源數據和它們的內容、數據分割、數據提取、清理、轉換規則和數據刷新規則、安全（用戶授權和存取控制）。
業務元數據
業務元數據從業務角度描述了數據倉庫中的數據，它提供了介于使用者和實際系統之間的語義層，使得不懂計算機技術的業務人員也能夠“讀懂”數據倉庫中的數據。業務元數據主要包括以下信息：使用者的業務術語所表達的數據模型、對象名和屬性名；訪問數據的原則和數據的來源；系統所提供的分析方法以及公式和報表的信息。具體包括以下信息：
- 企業概念模型：這是業務元數據所應提供的重要的信息，它表示企業數據模型的高層信息、整個企業的業務概念和相互關系。以這個企業模型為基礎，不懂數據庫技術和SQL語句的業務人員對數據倉庫中的數據也能做到心中有數。
- 多維數據模型：這是企業概念模型的重要組成部分，它告訴業務分析人員在數據集市當中有哪些維、維的類別、數據立方體以及數據集市中的聚合規則。這里的數據立方體表示某主題領域業務事實表和維表的多維組織形式。
- 業務概念模型和物理數據之間的依賴：以上提到的業務元數據只是表示出了數據的業務視圖，這些業務視圖與實際的數據倉庫或數據庫、多維數據庫中的表、字段、維、層次等之間的對應關系也應該在元數據知識庫中有所體現。
二、元數據的作用
與其說數據倉庫是軟件開發項目，還不如說是系統集成項目，因為它的主要工作是把所需的數據倉庫工具集成在一起，完成數據的抽取、轉換和加載，OLAP分析和數據挖掘等。如下圖所示，它的典型結構由操作環境層、數據倉庫層和業務層等組成。
其中，第一層（操作環境層）是指整個企業內有關業務的OLTP系統和一些外部數據源；第二層是通過把第一層的相關數據抽取到一個中心區而組成的數據倉庫層；第三層是為了完成對業務數據的分析而由各種工具組成的業務層。圖中左邊的部分是元數據管理，它起到了承上啟下的作用，具體體現在以下幾個方面：
如圖所示，與元數據相關的數據倉庫工具大致可分為四類：
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等。
1.元數據是進行數據集成所必需的
數據倉庫最大的特點就是它的集成性。這一特點不僅體現在它所包含的數據上，還體現在實施數據倉庫項目的過程當中。一方面，從各個數據源中抽取的數據要按照一定的模式存入數據倉庫中，這些數據源與數據倉庫中數據的對應關系及轉換規則都要存儲在元數據知識庫中；另一方面，在數據倉庫項目實施過程中，直接建立數據倉庫往往費時、費力，因此在實踐當中，人們可能會按照統一的數據模型，首先建設數據集市，然后在各個數據集市的基礎上再建設數據倉庫。不過，當數據集市數量增多時很容易形成“蜘蛛網”現象，而元數據管理是解決“蜘蛛網”的關鍵。如果在建立數據集市的過程中，注意了元數據管理，在集成到數據倉庫中時就會比較順利；相反，如果在建設數據集市的過程中忽視了元數據管理，那么最后的集成過程就會很困難，甚至不可能實現。
2.元數據定義的語義層可以幫助用戶理解數據倉庫中的數據
最終用戶不可能象數據倉庫系統管理員或開發人員那樣熟悉數據庫技術，因此迫切需要有一個“翻譯”，能夠使他們清晰地理解數據倉庫中數據的含意。元數據可以實現業務模型與數據模型之間的映射，因而可以把數據以用戶需要的方式“翻譯”出來，從而幫助最終用戶理解和使用數據。
3.元數據是保證數據質量的關鍵
數據倉庫或數據集市建立好以后，使用者在使用的時候，常常會產生對數據的懷疑。這些懷疑往往是由于底層的數據對于用戶來說是不“透明”的，使用者很自然地對結果產生懷疑。而借助元數據管理系統，最終的使用者對各個數據的來龍去脈以及數據抽取和轉換的規則都會很方便地得到，這樣他們自然會對數據具有信心；當然也可便捷地發現數據所存在的質量問題。甚至國外有學者還在元數據模型的基礎上引入質量維，從更高的角度上來解決這一問題。
4.元數據可以支持需求變化
隨著信息技術的發展和企業職能的變化，企業的需求也在不斷地改變。如何構造一個隨著需求改變而平滑變化的軟件系統，是軟件工程領域中的一個重要問題。傳統的信息系統往往是通過文檔來適應需求變化，但是僅僅依靠文檔還是遠遠不夠的。成功的元數據管理系統可以把整個業務的工作流、數據流和信息流有效地管理起來，使得系統不依賴特定的開發人員，從而提高系統的可擴展性。
三、元數據管理現狀
由以上幾節我們了解到元數據幾乎可以被稱為是數據倉庫乃至商業智能（BI）系統的“靈魂”，正是由于元數據在整個數據倉庫生命周期中有著重要的地位，各個廠商的數據倉庫解決方案都提到了關于對元數據的管理。但遺憾的是對于元數據的管理，各個解決方案都沒有明確提出一個完整的管理模式；它們提供的僅僅是對特定的局部元數據的管理。當前市場上與元數據有關的主要工具見下圖：
招生文案
對于比較復雜的環境，分別建立各部分的元數據管理系統，形成分布式元數據知識庫，然后，通過建立標準的元數據交換格式，實現元數據的集成管理。
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元數據知識庫體系結構如下圖所示。
指標一致性分析
指標一致性分析是指用圖形化的方式來分析比較兩個指標的數據流圖是否一致，從而了解指標計算過程是否一致。該功能是指標血緣分析的一種具體應用。指標一致性分析可以幫助用戶清楚地了解到將要比較的兩個指標在經營分析數據流圖中各階段所涉及的數據對象和轉換關系是否一致，幫助用戶更好地了解指標的來龍去脈，清楚理解分布在不同部門且名稱相同的指標之間的差異，從而提高用戶對指標值的信任。
3. 輔助應用優化
元數據對數據系統的數據、數據加工過程以及數據間的關系提供了準確的描述，利用血緣分析、影響分析和實體關聯分析等元數據分析功能，可以識別與系統應用相關的技術資源，結合應用生命周期管理過程，輔助進行數據系統的應用優化.
4. 輔助安全管理
企業數據平臺所存儲的數據和提供的各類分析應用，涉及到公司經營方面的各類敏感信息。因此在數據系統建設過程中，須采用全面的安全管理機制和措施來保障系統的數據安全。
數據系統安全管理模塊負責數據系統的數據敏感度、客戶隱私信息和各環節審計日志記錄管理，對數據系統的數據訪問和功能使用進行有效監控。為實現數據系統對敏感數據和客戶隱私信息的訪問控制，進一步實現權限細化，安全管理模塊應以元數據為依據，由元數據管理模塊提供敏感數據定義和客戶隱私信息定義，輔助安全管理模塊完成相關安全管控操作。
5. 基于元數據的開發管理
數據系統項目開發的主要環節包括：需求分析、設計、開發、測試和上線。開發管理應用可以提供相應的功能，對以上各環節的工作流程、相關資源、規則約束、輸入輸出信息等提供管理和支持。
本文主要從元數據的定義、作用、元數據管理現狀、管理標準和元數據管理功能等方面講述了我對元數據(Metadata)和元數據管理的認知及理解。朋友們有什么建議和補充，歡迎留言或私信我。一鍵三連！
CWM為數據倉庫和商業智能（BI）工具之間共享元數據，制定了一整套關于語法和語義的規范。它主要包含以下四個方面的規范：
CWM元模型（Metamodel）：描述數據倉庫系統的模型；
CWM XML：CWM元模型的XML表示；
CWM DTD：DW/BI共享元數據的交換格式；
CWM IDL：DW/BI共享元數據的應用程序訪問接口（API）。
五、元數據管理功能
1. 數據地圖
數據地圖展現是以拓撲圖的形式對數據系統的各類數據實體、數據處理過程元數據進行分層次的圖形化展現，并通過不同層次的圖形展現粒度控制，滿足開發、運維或者業務上不同應用場景的圖形查詢和輔助分析需要。
2. 元數據分析
血緣分析
血緣分析（也稱血統分析）是指從某一實體出發，往回追溯其處理過程，直到數據系統的數據源接口。對于不同類型的實體，其涉及的轉換過程可能有不同類型，如：對于底層倉庫實體，涉及的是ETL處理過程；而對于倉庫匯總表，可能既涉及ETL處理過程，又涉及倉庫匯總處理過程；而對于指標，則除了上面的處理過程，還涉及指標生成的處理過程。數據源接口實體由源系統提供，作為數據系統的數據輸入，其它的數據實體都經過了一個或多個不同類型的處理過程。血緣分析正是提供了這樣一種功能，可以讓使用者根據需要了解不同的處理過程，每個處理過程具體做什么，需要什么樣的輸入，又產生什么樣的輸出。
影響分析
影響分析是指從某一實體出發，尋找依賴該實體的處理過程實體或其他實體。如果需要可以采用遞歸方式尋找所有的依賴過程實體或其他實體。該功能支持當某些實體發生變化或者需要修改時，評估實體影響范圍。
實體關聯分析
實體關聯分析是從某一實體關聯的其它實體和其參與的處理過程兩個角度來查看具體數據的使用情況，形成一張實體和所參與處理過程的網絡，從而進一步了解該實體的重要程度。本功能可以用來支撐需求變更影響評估的應用。
實體差異分析
實體差異分析是對元數據的不同實體進行檢查，用圖形和表格的形式展現它們之間的差異，包括名字、屬性及數據血緣和對系統其他部分影響的差異等,在數據系統中存在許多類似的實體。這些實體（如數據表）可能只有名字上或者是在屬性中存在微小的差異，甚至有部分屬性名字都相同，但處于不同的應用中。由于各種原因，這些微小的差異直接影響了數據統計結果，數據系統需要清楚了解這些差異。本功能有助于進一步統一統計口徑，評估近似實體的差異
聯系電話：1580-136-5057
地址：北京市朝陽區朝外大街甲6號萬通中心D座
網址：www.yeepay.com
投稿：kai.zhao@yeepay.com
增值電信業務經營許可證：陜B2-20210327 |