元数据管理、治理、系统、建设方案、范例等
- 【數據治理工具】–元數據系統
1.元數據系統
1.1 概述
如果想建設好元數據系統，需要理解元數據系統的相關概念，如數據、數據模型、元數據、元模型、ETL、數據血緣等等。
首先，要清楚數據的定義、數據模型的定義。數據一般是對客觀事物描述的抽象，在數據庫維度，數據是數據記錄的簡稱，例如，個人的基本信息、產品信息等。數據模型是數據特征的抽象，它從抽象層次上描述了系統的靜態特征、動態行為和約束條件，為數據庫系統的信息表示與操作提供一個抽象的框架。數據模型所描述的內容有三部分，分別是數據結構、數據操作和數據約束。
數據結構：數據模型中的數據結構主要描述數據的類型、內容、性質以及數據間的聯系等。數據結構是數據模型的基礎，數據操作和約束都建立在數據結構上。不同的數據結構具有不同的操作和約束。
數據操作：數據模型中數據操作主要描述在相應的數據結構上的操作類型和操作方式 。
數據約束：數據模型中的數據約束主要描述數據結構內數據間的語法、詞義聯系、它們之間的制約和依存關系，以及數據動態變化的規則，以保證數據的正確、有效和相容。
其次，元數據和元模型。元數據是數據的數據，這句話好抽象、好難理解。結合數據模型的定義，我們把這句話豐富下，換成“元數據是數據記錄的數據模型”。元模型是關于模型的模型，同理也是抽象、晦澀、難以理解，如果將這句話換成“元模型是元數據的數據模型”，是不是瞬間理解了。
需要注意的是，這兩句轉換內容只是為了方便初學者去理解和閱讀接下來的大部分內容，隨著時間的推移，個人對元數據認知的加深，請拋棄這兩個轉換內容，因為這兩句話的描述是以狹隘的定義去描述元數據和元模型，會禁錮你對元數據和元模型的理解。
圖 1 元數據、元模型與數據關系
然后， ETL、數據血緣。ETL是英文Extract-Transform-Load的縮寫，用來描述將數據從來源端經過抽取（extract）、轉換（transform）、加載（load）至目的端的過程。ETL是數據倉庫技術，也經常用于數據湖、數據倉庫、數據中臺等項目建設中，但其對象并不限于數據倉庫。
數據血緣是數據溯源的過程中找到相關數據之間的聯系，它是一個邏輯概念。基于數據血緣，還需要了解血緣分析、影響分析、數據全鏈路。
血統分析一般情況下采用圖形方式展示了以某個元數據為終止節點，其前與其有關系的所有元數據，反應數據的來源與加工過程，使用血統分析可分析數據來源、標準貫標關系、數據質量問題追溯等。
影響分析一般情況下采用圖形方式展示了以某個元數據為起始節點，其后與其有關系的所有元數據，反應數據的流向與加工過程，使用影響分析可分析元數據變更導致下游數據加工、數據關聯的定位。
數據全鏈路分析，又稱數據全鏈路地圖，簡稱數據全鏈路，是血緣分析和影響分析的總和，是以當前元數據為節點，向上了解數據流向和加工過程的為血緣分析，向下了解數據流向和加工鏈路的為影響分析，一般情況下采用圖形方式展示所有元數據節點的數據加工、關聯節點。
圖 2 ETL與數據全鏈路分析關系
圖 3 數據全鏈路分析與血緣分析和影響分析的關系
最后，再根據實際情況去了解其他相關概念來豐富對元數據的理解。沒有元數據，無法了解數據的真實意義。元數據看起來是一堆晦澀、無意義的文字和數字，但它能為企業的各類數據提供上下文環境，使企業能更好地了解、使用和管理數據，進而體現數據的價值。
1.2 元數據
- 必須搞懂元數據相關的9個術語和名詞
元數據最簡單的定義是描述數據的數據。這里有兩個關鍵點，一個是數據，一個是描述數據。企業中一般的可進行管理的數據如下表：
按照不同應用領域或功能，元數據一般大致可分為三類：業務元數據、技術元數據和操作元數據。
1.2.1 業務元數據
業務元數據描述數據的業務含義、業務規則等。明確業務元數據可以讓人們更容易理解和使用業務元數據。元數據消除了數據二義性，讓人們對數據有一致的認知，避免“自說自話”，進而為數據分析和應用提供支撐。
常見的業務元數據有：
- 業務定義、業務術語解釋等；
- 業務指標名稱、計算口徑、衍生指標等；
- 業務引擎的規則、數據質量檢測規則、數據挖掘算法等；
- 數據的安全或敏感級別等。
1.2.2 技術元數據
技術元數據是結構化處理后的數據，方便計算機或數據庫對數據進行識別、存儲、傳輸和交換。技術元數據可以服務于開發人員，讓開發人員更加明確數據的存儲、結構，從而為應用開發和系統集成奠定基礎。技術元數據也可服務于業務人員，通過元數據厘清數據關系，讓業務人員更快速地找到想要的數據，進而對數據的來源和去向進行分析，支持數據血緣追溯和影響分析。
常見的技術元數據有：
- 物理數據庫表名稱、列名稱、字段長度、字段類型、約束信息、數據依賴關系等；
- 數據存儲類型、位置、數據存儲文件格式或數據壓縮類型等；
- 字段級血緣關系、SQL腳本信息、ETL信息、接口程序等；
- 調度依賴關系、進度和數據更新頻率等。
1.2.3 操作元數據
操作元數據描述數據的操作屬性，包括管理部門、管理責任人等。明確管理屬性有利于將數據管理責任落實到部門和個人，是數據安全管理的基礎。
常見的操作元數據有：
- 數據所有者、使用者等；
- 數據的訪問方式、訪問時間、訪問限制等；
- 數據訪問權限、組和角色等；
- 數據處理作業的結果、系統執行日志等；
- 數據備份、歸檔人、歸檔時間等。
元數據的分類及實例見表2。
表2 元數據的分類（以“客戶”信息為例）
我們再來舉個通俗的例子，一本書的封面和目錄向我們展示了這樣的元數據信息：圖書名稱、作者姓名、出版商和版權細節、圖書的提綱、標題、頁碼等。
元數據主要分３種類型，分別是（數據字典＼數據血緣＼數據特征）。
- 數據字典：描述的是數據的結構信息。主要包括表名＼注釋信息＼表的產出任務＼每個表都有哪些字段＼這些字典分別代表什么含義＼字段的類型。
- 數據血緣：一個表是直接通過哪些表加工而來。一般用于做影響分析和故障溯源。
- 數據特征：主要指數據的屬性信息，比如存儲空間大小＼訪問熱度＼主題域＼分層＼表關聯的指標。
1.3 元模型
和元數據管理相關的另一個重要概念是元模型，定義元數據的屬性、關系的模型叫做元模型，每類元數據都屬于一個元模型。
比如，表模型里定義了表的屬性有“注釋”、“是否系統表”、“是否臨時表”、“所有者”等（圖1）；定義了表由索引、外鍵、表分區、字段等組成（圖2）；定義了表受表輸出組件、存儲過程、表等的影響（圖3）。
圖1
圖2
圖3
1.3.1 元模型作用
有了元模型，就能根據元模型來采集元數據信息。要實現企業元數據管理，需要定義一個符合存儲企業數據現狀的元數據模型，且這個模型有不同粒度和層次的元模型，有了層次和粒度的劃分，未來元數據進行批量管理后就可以靈活的從不同維度進行元數據分析，如企業的數據地圖、數據血統都是基于此實現的。
我們試著把企業中的技術元數據、業務元數據、操作元數據、管理元數據進行元模型的梳理，如下圖所示：
將以上梳理出的信息通過UML建模處理就得到了元模型，在元模型中有包、類、屬性、繼承、關系。創建元模型的時候也可以參考CWM（公共倉庫元模型），CWM定義了一套完整的元模型體系結構，用于數據倉庫構建和應用的元數據建模。
1.4 數據血緣
一般可以通過3種方式
-
通過靜態解析SQL，獲得輸入表和輸出表
-
通過實時抓取正在執行的SQL，解析執行計劃，獲取輸入表和輸出表
-
通過任務日志解析的方式，獲取執行后的SQL輸入表和輸出表
-
第一種方式，面臨準確性的問題，因為任務沒有執行，這個 SQL 對不對都是一個問題。
-
第三種方式，血緣雖然是執行后產生的，可以確保是準確的，但是時效性比較差，通常要分析大量的任務日志數據。
-
所以第二種方式，我認為是比較理想的實現方式，而 Atlas 就是這種實現。
2.建設意義與作用
2.1 建設意義
如果想梳理企業數據資產，了解企業數據加工邏輯，發現企業數據質量隱患，整理企業數據標準，建設數據中臺，開展數據治理工作等，你會發現，方方面面或多或少的都和元數據有千絲萬縷的聯系。因為元數據是數據的數據，它是一切工作開展的切入點，如，想了解數據資產，元數據就能給你提供描述數據資產的定義；想查看、申請數據資產，可以基于元數據去控制查看范圍、申請流程。
簡單來說，元數據系統作為元數據管理態的系統，可以把各種各樣復雜的信息統一管理起來，方便企業在數據層面，縱觀全局的了解數據定義進而開展數據中臺建設、數據治理工作建設、數據質量工作建設、數據資產相關工作建設。
2.2 主要作用
在數據治理中，元數據是對數據的描述，存儲著數據的描述信息。我們可以通過元數據管理和檢索我們想要的“書”。可見元數據是用來描述數據的數據，讓數據更容易理解、查找、管理和使用。
元數據是建設數據倉庫的基礎，是構建企業數據資源全景視圖的基礎，清晰的血緣分析、影響分析、差異分析、關聯分析、指標一致性分析等是數據資產管理的重要一環。
如果說數據是物料，那么元數據就是倉庫里的物料卡片；如果說數據是文件夾，那么元數據就是夾子的標簽；如果說數據是書，那么元數據就是圖書館中的圖書卡。
元數據的主要作用是對數據對象進行描述、定位、檢索、管理、評估和交互。
- **描述：**對數據對象的內容、屬性的描述，這是元數據的基本功能，是各組織、各部門之間達成共識的基礎。
- **定位：**有關數據資源位置方面的信息描述，如數據存儲位置、URL等記錄，可以幫助用戶快速找到數據資源，有利于信息的發現和檢索。
- **檢索：**在描述數據的過程中，將信息對象中的重要信息抽出標引并加以組織，建立它們之間的關系，為用戶提供多層次、多途徑的檢索體系，幫助用戶找到想要的信息。
- **管理：**對數據對象的版本、管理和使用權限的描述，方面信息對象管理和使用。
- **評估：**由于有元數據描述，用戶在不瀏覽具體數據對象的情況下也能對數據對象有個直觀的認識，方便用戶的使用。
- **交互：**元數據對數據結構、數據關系的描述方便了數據對象在不同部門、不同系統之間進行流通和流轉，并確保流轉過程中數據標準的一致性。
元數據以數字化方式描述企業的數據、流程和應用程序，為企業數字資產的內容提供了上下文，使得數據更容易理解、查找、管理和使用。準確的元數據是必不可少的，也是迅速、有效地對數據去粗取精的關鍵。沒有元數據，數據就毫無意義，只不過是一堆數字或文字而已。因此，對于元數據的有效管理是企業數據治理的基礎。
2.3 應用價值
良好的元數據架構，能夠給元數據帶來更多的應用價值。我們再看看元數據的應用價值。
- 圍繞核心業務：通常在項目初期的時候，只圍繞一些核心業務主體，使其在使用的時候靈活高效，后續在持續擴展其他能力。
- 數據成本分析：基于元數據中鏈路，分析各個節點數據的生產維護管理等成本，為數據服務中商業定價提供參考，可能直接影響服務是否可提供的決策。
- 配置可視化：在數據服務平臺中，最忌諱的一點就是靠手動去維護各種作業，不管在什么場景下，都要考慮可配置化管理，保證動作可追溯。
- 流程自動化：不管是元數據結構映射，還是配置后數據的抽取，要保證指令生成后可以自動完成該一系列動作，并完成流程監控分析。
- 資產化分析：通常會把元數據視為數據資產體系，因此圍繞元數據去統計數據的使用情況，產生的價值，以及熱點數據識別和分布，業務主體關聯度等，并輸出相應分析結果。
通過元數據管理我們能夠做到：
1、實現多樣、繁雜的元數據信息集中管理，為企業數據(服務)管理提供統一的視圖，實現企業級數據(服務)資產管理，方便數據(服務)交互共享，同時為后 續規劃提供依據;
2、通過管理維護數據(服務)之間關系，實現數據(服務)自動關聯分析，為問題定位、影響分析、上線加速等提供支撐。
3、建立數據(服務)標準，統一交換、存儲、應用口徑，減少共享壁壘，降低應用出錯幾率，提升質量。
通過這些基本能力，元數據在數據管理、微服務管理、業務管理等方面都能發揮很大的作用。
通過元數據管理，在數據方面能做到：
1、數據標準化
2、數據開放
3、數據質量提升等
在微服務方面，能夠提供以下支撐：
1、服務開發、應用等標準化;
2、服務應用監控，優化服務應用等
將來在業務方面也能通過元數據實現業務流程分析、業務流程優化等能力。
大家常見的是元數據在數據倉庫中的應用，數據倉庫是一個典型的分層設計的數據架構，其分層設計反映了數據在數據倉庫中的加工處理過程。
元數據作為數據倉庫的核心組成部分，主要用于記錄和管理數據在數據倉庫中的整個流轉過程，實現對數據倉庫各層級數據進行統一管理。
（圖來源《一本書講透數據治理：戰略、方法、工具與實踐》）
元數據在數據倉庫中的應用如下：
- 描述數據源的庫表結構、數據關系以及每個數據項的定義；
- 描述數據源中每個數據項的值域范圍和更新頻率；
- 描述數據源與數據倉庫之間的數據映射關系；
- 描述數據倉庫中有哪些數據以及它們來自哪里；
- 描述數據在數據倉庫各層中的加工處理過程；
- 元數據管理工具為數據管理者和使用者提供了理解和查詢數據的一致語言；
- 利用元數據管理工具的元數據變更和版本管理功能，管理數據倉庫的數據模型，支持將元數據恢復到某一版本；
- 利用元數據管理工具的血緣分析、影響分析等功能，對數據倉庫中的數據問題快速定位、快速查找；
- 利用元數據管理工具的開放式元數據交換標準，實現數據倉庫中數據的交換和共享。
下面我們用幾個例子，舉例說明元數據的作用。
數據治理之中，元數據是整個治理體系落地的技術核心。
比如：在數據標準中將數據標準作為一類業務元數據存儲，將其和技術元數據一定程度的關聯，去看標準的落地效果。
在數據質量中，通過元數據追溯質量問題。在共享發布中，利用元數據自動形成數據服務等等。
元數據還能夠自動化的準確的管理應用的上線、變更， 通常企業系統建設會分為開發、測試與生產三個不同的環境，而在軟件開發過程中，無論是需求變更還是BUG修改都避免不了元數據的改動，這時候往往會出現開發庫、測試庫測試通過，而在上線過程中又出現問題的情況，這會讓運維部門非常頭疼。
此時若通過元數據對系統的上線變更進行管理，自動采集三個環境的庫表結構與存儲過程等信息，保證各個環境中的元數據都是最新的、最準確的，再將上線環境與測試環境的元數據進行對比，不一致的地方一目了然。如果把系統的開發庫、測試庫、生產庫的元數據都管理起來，上線時突然出現問題的概率就會大大降低。
通過擴展模型，元數據也能夠管理微服務，微服務的生命周期有多個階段，在前期需要與多個微服務協同考慮，上架后也會有多個使用者，在這種復雜的狀況下需要管理微服務的全生命周期。
在規劃階段提供標準元數據規范微服務，在設計階段提供連接其他微服務的元數據信息，在開發階段使用元數據協助開發測試。
上線后分析微服務的使用情況，并協助維護微服務的變更。最后微服務下架時將微服務的元數據存檔，并確保對目前體系不產生影響。
同時微服務的不同版本間的元數據的變化也可以做追溯和分析。
2.4 視角分析
元數據是描述數據的數據，是數據的業務涵義、技術涵義和加工處理過程的定義，是數據管控的基本對象。企業要想知道擁有什么數據，數據在哪里，數據當前歸屬情況，數據的生命周期是什么，那些數據是需要做數據安全保護，數據質量如何開展，都離不開元數據的管理。因此，可以說，元數據系統為用戶更好的認識數據、分析數據、挖掘數據提供了強有力的工具，是用戶的數據由沉默到可用，由資源到資產的基石。
2.5 元數據平臺解決什么問題？
通過元數據建設，為使用數據提效，解決“找數、理解數、評估”難題以及“取數、數據可視化”等難題。
- 數據問題：多種存儲形式的數據來源（mysql、hive、hbase、es）、數據變化評率高；
- 數據使用問題：查看表信息（結構、量級、所屬、是否可用）、表依賴（血緣統計）；
- 數據管理問題：表權限管理、數據質量管控、數據接入管理；
2.6 元數據應用
元數據的比較全的應用場景
可以看到，建立好企業的元數據，便可以為數據治理打下堅實的基礎，也可衍生出豐富的應用，如數據地圖，血緣分析，數據冷熱分析，數據資產管理等。
3. 建設內容
元數據系統建設范圍非常寬泛，當前市面上每個廠商的元數據系統都不盡相同，各有各的特點。最早的元數據系統建設能追溯到十余年前，那時候的元數據理念跟現在也有些不同，如采集元數據的方式、范圍等。
下圖元數據系統建設的內容是參考市面主流元數據系統、《信通院元數據測評要求》以及本人對元數據的理解，結合自己的產品經驗、實施經驗、咨詢經驗將常見的功能整理如下。
系統建設的內容其實不重要，重要的是解決咨詢過程中、實施過程中客戶問題，這部分內容不在這里贅述，后續會在數據治理咨詢、數據治理實施章節中陳述。
圖 2 元數據系統建設范圍圖
下面介紹重點幾個系統功能邏輯。
3.1 元模型管理
元模型定義了各種元數據的結構以及元數據之間的關系，是元數據管理的基礎。因此建設元模型需要考慮元模型需要遵守的規范，元模型建設的范圍，元模型對元數據的影響，元模型是否能讓用戶自定義建設。
建設元模型難點是需要梳理元模型的屬性信息以及屬性信息在哪里存放，技術元模型需要對相關的數據庫、接口等作深入了解，通過深入了解之后，梳理元模型的屬性信息及如何查詢到這些元模型屬性；是業務元模型跟技術元模型調研對象是不一樣的，需要跟業務人員溝通屬性口徑、屬性關系，基于溝通內容整理元模型的屬性，如果涉及業務元模型出處的業務系統，還需要跟對方業務系統調研，確定采集方式。
由此可見，元模型的范圍是非常重要的，如果是剛剛建設元數據系統，推薦先從關系數據庫著手，后續隨著產品交付、項目的實施在逐步完善其他技術元模型、業務元模型的建設。
一般情況下，建設元模型都會參考CWM（公共倉庫元模型）規范，按照CWM規范開展元模型的設計工作。不建議讓客戶去對元模型進行增刪改。因為，技術元模型一般對應的數據庫層面，相關數據庫底層的元數據是固定的，不會因為調整元數據的元模型而改變數據庫的元數據信息，通常需要根據具體的數據庫去設計不同的元模型；業務元模型是根據具體業務場景去分析整理相關元模型；管理元模型是根據業務要求抽象的管理屬性，需要依托于技術元模型和業務元模型，不能孤立使用。
元模型主要分技術元模型、業務元模型、管理元模型，后續的采集管理、元數據管理、統計與分析等都是基于這個分類開展相關工作。這三大類元模型的技術元模型在數據源系統章節已經講述，這里不再贅述。業務元數據很多，后續數據標準系統的基礎類標準、指標類標準，數據質量系統的檢核規則都屬于業務元數據，可以參考數據標準、數據質量系統相關章節。
管理元模型核心是管理元模型的屬性，屬性包括管理部門、分類、分級等，這些屬性信息用來擴展技術元模型和業務元模型的屬性，為了后續對元模型管理做到從字段屬性層面的支撐工作。從數據治理源頭來說，一般管理部門也會在源頭系統進行統一要求，這樣當元數據采集后，相關管理屬性就存在了，不需要再次歸類梳理。
3.2 采集管理
元數據采集管理，簡稱采集管理，是將目標庫、文件、接口中的元數據通過技術的方式自動化或者半自動化獲取具體內容。采集管理核心內容是采集引擎、任務調度、采集日志、消息通知。
采集引擎，是元數據采集引擎的簡稱，作用是對數據源進行元數據采集。由于元模型的多樣性和元模型是對采集范圍的定義，且元模型需要與采集引擎一一對應，因此采集引擎是包含多種元數據采集引擎的集合。采集引擎是解決自動化或者半自動化獲取元數據的訴求。自動化一般是基于分析好的元模型，結合數據源系統提供的目標地址，獲取元數據信息；半自動化儀表是基于分析好的元模型，導出需要采集的元模型表頭樣式，用戶通過線下收集的方式整理元數據，最后，將整理好的元數據文件導入到系統中。
任務調度，簡單來說就是定時任務，是指基于給定時間點，給定時間間隔或者給定執行次數自動執行任務。通過任務調度可以按照調度排期順序啟動元數據采集工作，解決自動化采集元數據問題。也需要考慮與第三方調度平臺對接，將任務調度納管到客戶整體的任務調度系統中。
采集日志是在采集引擎工作的時候，將采集信息收集起來，例如開始結束時間、相關元數據數量等。用戶通過采集日志能看到本次任務調度的成功與失敗，通過分析采集日志了解到當前采集引擎的性能等。
消息通知是對采集任務結束之后，對采集任務的整理匯總后，通過系統消息通知渠道、短信、郵箱、釘釘、微信等將采集任務結果推送給用戶，達到用戶實時了解采集任務情況。
消息通知主要有如下幾種形式：任務失敗成功信息、采集元數據變化情況匯總消息、元數據異動情況分析消息等。
采集管理是元數據管理的入口，元數據采集引擎是采集管理的核心，只有把元數據采集管理梳理清楚，才能更好的為后續的元數據版本、數據地圖等提供基礎數據。
3.3 元數據管理
元數據管理是對采集到的元數據統一的后臺管理端，主要包括三個子功能，分別是完善元數據、元數據版本、環境巡檢。
元數據管理是指與確保正確創建、存儲和控制元數據，以便在整個企業中一致地定義數據有關的活動。
元數據管理是對涉及的業務元數據、技術元數據、操作元數據進行盤點、集成和管理。采用科學有效的機制對元數據進行管理，并面向開發人員、業務用戶提供元數據服務，可以滿足用戶的業務需求，為企業業務系統和數據分析的開發、維護等過程提供支持。
可以從技術、業務和應用三個角度理解元數據管理。
**技術角度：**元數據管理著企業的數據源系統、數據平臺、數據倉庫、數據模型、數據庫、表、字段以及字段間的數據關系等技術元數據。
**業務角度：**元數據管理著企業的業務術語表、業務規則、質量規則、安全策略以及表的加工策略、表的生命周期信息等業務元數據。
**應用角度：**元數據管理為數據提供了完整的加工處理全鏈路跟蹤，方便數據的溯源和審計，這對于數據的合規使用越來越重要。通過數據血緣分析，追溯發生數據質量問題和其他錯誤的根本原因，并對更改后的元數據進行影響分析。
企業元數據管理的主要活動包括：
- 創建并記錄主題領域的實體和屬性的數據定義；
- 識別數據對象之間的業務規則和關系；
- 證明數據內容的準確性、完整性和及時性；
- 建立和記錄內容的上下文（數據血緣、數據影響的全鏈路跟蹤分析）；
- 為多樣化的數據用戶提供一系列上下文理解，包括用于合規性、內部控制和更好決策的可信數據；
- 為技術人員提供元數據信息，支持數據庫或應用的開發。
3.3.1 元數據完善
如果只是對元數據簡單管理，不涉及數據資產相關管理內容，或者說不對原始元數據添加任何管理元數據，也沒有相關元數據發布流程，那么，元數據完善功能可以不做建設。元數據完善主要是對采集過來的元數據進一步的加工，通過元數據完善的操作豐富元數據管理屬性和添加相關流程以滿足咨詢團隊編制的《元數據管理辦法》中提到的元數據管理流程。
一般情況下，元數據通過采集任務根據調度任務通過增量的方式自動采集，為了確保數據源頭與采集內容的一致性，不會對采集的元數據做任何內容的修改，根據客戶需求添加相關管理屬性，如管理部門、元數據目錄、安全等級等。通過元數據發布流程完成元數據從管理態到發布態，讓元數據進入下一個展示環節元數據展示中。如果元數據是通過線下Excel梳理，通過文件導入的方式獲取元數據，那么除了自動采集的操作之外，還可以根據具體情況對導入的元數據進行優化調整。
在元數據完善過程中，完善的重點是元數據目錄、管理部門、安全等級、甚至訪問元數據的申請流程，換一個維度思考，這些完善信息就是確定數據所有者、數據管理者、數據生產者、數據使用者、數據使用流程、數據使用是脫敏要求，簡單歸納四個字，數據確權，就是確定數據的權利屬性，包括確定數據權利主體、確定權利的內容。這些其實就是在確定數據資產的權屬問題。數據確權是數據資產化的基礎，是數據交易和數據流通的前提，是保護數據安全的重要手段。
數據資產一般是對用數層面，體現數據價值的角度，為什么在完善元數據時，說是在確定數據資產的權屬呢？因為，元數據是展示數據資產，或者管理數據資產的承接者。舉個例子，假設把數據比喻為液體，元數據比喻為容器，偏離片、蒸餾器、分離器等工具和糖、鹽等各種試劑比喻為展示液體的工具，如數據查詢、商業智能等。那么，液體需要用各式各樣的容器存放，當用戶用使用液體時，根據不同需求，對液體進行處理，如蒸餾獲取純潔的液體、添加試劑掩蓋液體真實顏色或者味道等。
元數據目錄還可以理解為資產目錄，資產目錄是什么，相關定義請查閱理論知識章節，如果建設，等后續實施章節在詳細陳述。這里簡單概述數據資產目錄到底是什么，解開他神秘的面紗。
先說數據資產一般都包含什么，如果從元數據是數據資產管理的抓手，那么，數據資產包括存儲元數據、業務元數據。而這些元數據其實在采集的時候就有相關目錄，這些目錄組裝起來就是資產目錄。存儲元數據采集后，一般都會以技術口徑、管理口徑、業務口徑掛載到相關目錄上，例如，科技部、計劃財務部、網絡金融部等。業務元數據中的基礎類數據標準的主題、層級，質量檢核規則中的規則目錄，例如唯一性、完整性、一致性等這些都是目錄，把他們整理匯總起來，就是數據資產目錄。
圖 3 依托于存量目錄建設數據資產目錄（僅供參考）
當然，如果您經濟實力夯實，相關業務人員充足，也可以重新基于采集來的各類元數據，按需要重新劃分資產目錄，如按客戶、業務、經營管理等。需要說明的是，數據作為可以快速復制的特性，同一個數據資產最少會在一個資產目錄下，也就是說，同一個數據資產可以出現在多個資產目錄下。
圖 4 重新梳理數據資產目錄（僅供參考）
如果僅從管理元數據就是管理數據資產，那么元數據完善功能還可以使用資產盤點、資產確權、資產認責等名稱。
3.3.2 元數據版本
元數據版本管理解決相同數據源、相同環境（開發、測試、生產）下，不同時期采集的元數據支持任意對比，并基于版本對比功能，展示元數據各個維度之間的變化情況，如新增、修改、刪除。
一般情況下，元數據采集使用增量的方式獲取元數據，元數據版本中會包含所有采集的增量內容。只有這樣，才能完成元數據版本工作，也就是說，元數據完善功能是最新的元數據，元數據展示中是添加過管理屬性或者允許發布的元數據。
3.3.3 環境巡查
環境巡查解決不同環境下元數據是否一致的問題，一般環境巡查主要針對數據庫相關的技術元數據，是元數據版本管理的特殊場景下的功能延伸，因為其他類型元數據可以通過元數據版本解決。
做過開發的小伙伴都知道，理論上系統部署在開發環境、測試環境、生產環境都是物理隔絕的。開發小伙伴在開發環境基于產品經理整理的需求開發相關功能，開發完畢后將代碼、數據庫腳本提供給測試小伙伴，由測試小伙伴基于發布的文件部署到測試環境，測試小伙伴在測試環境測試通過，相關人員準備上線文檔（軟件程序、配置文件、數據庫腳本等）由配置管理員基于文檔發布到生產環境中。
在實際過程中，需求的變動、人員的變動、配置管理不標準化，會出現測試環境的庫表字段和生產環境的庫表字段差異特別大，如何知道兩個環境之間庫表字段的差異，是非常費力的一件事情。環境巡查就是解決不同環境下元數據不一致的問題。
首先，從某個元數據環境上的采集最新的元數據信息，通過導出的方式獲取全量元數據信息（建議導出的元數據信息是加密，只有元數據系統才能解析）。將導出元數據信息在另一個元數據系統環境上的環境巡查中導入，通過與最新采集的元數據進行比對，發現兩個環境上元數據的不同，并形成差異分析報告，提供給原業務系統，便于原業務系統整改。
3.3.4 元數據管理的目標
企業元數據管理的本質是有效利用企業數據資產，讓數據發揮出盡可能大的價值。元數據管理可以幫助業務分析師、系統架構師、數據倉庫工程師和軟件開發工程師等相關干系人清楚地知道企業擁有什么數據，它們存儲在哪里，如何抽取、清理、維護這些數據并指導用戶使用。
以下元數據管理目標是企業的普遍訴求。
3.3.4.1 建立指標解釋體系
滿足用戶對業務和數據理解的需求，建立標準的企業內部知識傳承的信息承載平臺，建立業務分析知識庫，實現知識共享。能夠回答以下問題：
- 企業有哪些數據？
- 什么是企業有效客戶？有效客戶和客戶有何區別？
- 什么是產品的生命周期？
- 這個數據還叫什么名字？
- 數據倉庫中的存儲過程是誰寫的？它用來干什么？現在還在用嗎？
典型應用有數據資源目錄和業務術語表。
3.3.4.2 提高數據溯源能力
讓用戶能夠清晰地了解數據倉庫中數據流的來龍去脈、業務處理規則、轉換情況等，提高數據的溯源能力，支持數據倉庫的成長需求，降低因員工換崗造成的影響。元數據有助于回答以下問題：
- 這張表是從哪個業務系統中抽取過來的？
- ETL過程是否對數據進行過加工處理？進行了哪些處理？
- 指標數據是從哪些表匯總計算出來的？
典型應用有血緣分析、影響分析、全鏈路分析。
3.3.4.3 數據質量稽核體系
通過非冗余、非重復的元數據信息提高數據完整性、準確性。元數據管理解決的問題是如何將業務系統中的數據分門別類地進行管理，建立報警、監控機制，出現故障時能及時發現問題，為數據倉庫的數據質量監控提供基礎素材。能夠回答以下問題：
- 今天的在線用戶數為什么是0？
- 為什么A報表中的本月收入值與B報表中的不同？
典型應用有指標標準和數據質量規則。
3.4 元數據展示
通過元數據采集任務和元數據完善，元數據的相關屬性信息已經相當豐滿，這時候的元數據展示主要包括三個方面，按元數據分類的數據方式層級展示元數據（或者叫數據資產展示），基于采集的ETL相關腳本解析后的元數據地圖（或者叫數據地圖、資產地圖等），基于搜索引擎的元數據搜索（或者叫數據資產搜索）。
3.4.1 元數據展示
元數據展示主要基于元數據完善添加數據分類、安全分級、管理屬性等信息之后，用戶通過數據分類可以層級點開展示元數據，查看元數據詳情。
3.4.2 元數據地圖
有一種特殊的元數據，從廣義上講屬于技術元數據，從在細粒度劃分上，歸屬為計算元數據，基于計算解析引擎處理后，展示數據加工邏輯、數據引用關系，這就是元數據地圖。
元數據地圖或者叫血緣地圖，通常展示庫表字段的數據加工鏈路。讓用戶知道基于某個字段或者某個表，數據加工的上游是哪個表、哪個字段，數據下游是哪個表、哪個字段。在廣義些，指標標準依賴的模型是那些，數據標準貫標的表和字段有哪些，質量規則是對那些表和字段進行檢核的，調度任務的先后依賴等等。也就是說，除了常見的庫表字段的數據加工血緣鏈路圖，也有業務元數據依賴的庫表字段關系，把他們這些關系融為一體，就能形成三維立體的元數據關系地圖。
按數據域對企業數據資源進行全面盤點和分類，并根據元數據字典自動生成企業數據資產的全景地圖。該地圖可以告訴你有哪些數據，在哪里可以找到這些數據，能用這些數據干什么。
數據資產地圖支持以拓撲圖的形式可視化展示各類元數據和數據處理過程，通過不同層次的圖形展現粒度控制，滿足業務上不同應用場景的圖形查詢和輔助分析需要：
3.4.3 元數據搜索
元數據搜索又稱數據地圖，是通過全文搜索的方式，讓用戶找到目標元數據，但用戶點擊元數據時，除了展示當前元數據的基本信息，還需要展示元數據的關聯信息、血緣信息等。假設搜到的是某個數據標準，展示數據標準的基礎屬性、業務屬性、技術屬性、管理屬性等通用信息，還展示當前數據標準貫標的庫表字段，及關聯的庫表字段數據血緣加工鏈路，展示這些庫表字段引用的數據檢核規則、指標標準、標簽規則、報表等信息。
如果元數據搜索的結果，能讓用戶申請資產訪問，通過資產訪問申請通過之后，可以看到具體當前元數據關聯的部分或者全部，脫敏或者未脫敏的數據記錄信息，或者說業務數據信息，那么，這時候的元數據搜索或者數據地圖，應該成為資產地圖，且當前功能不能放到元數據系統中，應該放到數據門戶或者數據資產系統中。
3.4.4 血緣關系
從上層業務側追溯到底層結構，形成血緣關系的概念，概念本身并不重要的，背后的核心是鏈路的管理，鏈路上的節點（中間實體）是通過多種計算手段生成；
如果某個節點數據一旦出現質量問題，則需要根據這里的鏈路關系進行逐級向底層排查，完成問題修復后，還需要根據關系向上逐級修復清洗；如此通過血緣關系進行數據質量的分析和把控。
3.5 監控管理
元數據監控管理是元數據系統重要的功能，但不一定是必須的功能。
元數據系統其實是對存量的元數據管理工具，從另一個維度說，是對元數據事后管理的工具。當元數據變更時，系統通過采集的方式感知元數據的變化，但系統發現元數據變化時，其實已經對某些數據產生了影響。如某個字段的變化，導致后續數據ETL開發調度的運行報錯。在元數據監控管理中，重點是元數據的事前監控和元數據的事后監控。
3.5.1 事后監控
元數據事后監控主要在采集任務的時候，但元數據發生變化時，及時通知相關元數據負責人，通過元數據的血緣分析可以分析出元數據變化的影響，基于采集的數據源管理屬性，系統可以給數據影響的相關人員發生短信、郵件、微信等信息。
3.5.2 事前監控
元數據的事前監控是最重要的，這里的元數據事前監控主要針對的數據庫層面的，如數據庫表、字段、函數、存儲過程等變化。如果客戶有系統上線管理系統，那么與元數據接口，可以更好的管控元數據事前監控。如果沒有相關上線管理系統，只能在上線之前，將相關上線腳本提前預制到系統中，并制定預警時間范圍，當系統監控到數據源變化情況時，將變化情況及時采集，并與提前預制的上線腳本進行比對，發現兩種異常時，及時告知上線人員及相關管理人員，在最短的時間內容，提醒上線人員異常信息，根據具體情況來更新上傳腳本或者數據回滾。
與上線管理系統對接的事前監控重點是打通上線時運行的數據庫腳本，通過接口的方式獲取腳本信息，同時啟動監控系統上線，但系統數據庫一旦發生變化時，及時進行預警。
3.6 統計與分析
元數據統計分析通過搜集、匯總、計算統計元數據，利用統計信息對元數據本身的分布、變更趨勢，系統、人員等特性進行不同維度的定量定性分析，既可橫向對比，也可總結歷史、預測未來。 總體反映元數據的現狀與發展規律 ，協助企業更進一步的提升元數據管理認知，提高元數據管理水平，輔助企業管理者作出正確決策 。
元數據統計解決元數據匯總之后的日變化量、分布情況等。常見的統計維度有時點數、元數據類型、元數據更新狀態（新增、刪除、修改）、元數據來源，度量值主要是個數、占比等。
元數據分析解決元數據的影響分析、視圖關系分析、關聯度分析等。影響分析解決某一個元數據變動產生的影響鏈路，視圖關系分析解決視圖加工鏈路，關聯度分析是基于血緣關系，將關聯度特別高的元數據排名。
元數據稽查是解決元數據質量問題，主要從元數據注釋、元數據同名不同義、元數據命名規則等對某個數據源的元數據質量檢查。通過元數據稽查功能發現元數據的質量問題。
3.7 接口管理
元數據非常重要，很多系統都與元數據對接，元數據常見的對外接口有：元數據列表、元數據詳情、元數據血緣鏈路、元數據解析引擎等。
4 元數據系統設計
- 數據管理之元數據管理
4.1 架構設計
元數據管理的應用通常一款元數據管理工具應具備元模型設計、元數據采集、元數據分析、數據地圖展現等核心功能。元數據包括:元模型、元數據采集、元數 據注冊、元數據應用、元數據服務等;
架構圖2：
元數據系統整體分為接入層、存儲層、功能層和應用層。
- 接入層：適配不同元數據生產方，轉換成標準定義，輸出全種類實體、關系變更消息。
- 存儲層：基于元模型的實體、關系的存儲與查詢，支持統計與分析能力。
- 功能層：提供元模型管理、元數據分析應用、元數據管理、元數據檢核等功能。
- 應用層：基于定板元數據提供單點、復雜查詢服務，基于分析引擎提供面向不同角色的元數據分析服務。
作為企業數據治理的基礎，元數據管理平臺從功能上主要包括：元數據采集服務，元數據訪問服務、元數據管理服務和元數據分析服務。
一文徹底了解元數據管理與架構設計
元數據的架構，一般分為集中式架構和分散式架構。
集中式的架構，指的是采集多種數據源的元數據到元數據自己的存儲中來，再集中加工給其他場景提供服務；而分散式的架構，沒有自己的元數據存儲，而是在使用的時候，去即時的查詢其他數據源的元數據。
這兩種架構各有利弊。
集中式的架構，可以快速的檢索元數據，抽取的時候，也可以自由的轉換，自定義補充，提升了元數據的質量；同時也有缺點，需要保證自身存儲和其他源數據的一致性，增加了流程復雜度和工作量。
分散式架構的優點是，元數據總能夠保持最新，查詢更加的簡單；缺點也很明顯，無法自定義或修改元數據項，查詢也受源系統可用性的影響。
一般我們推薦使用集中式架構，定時采集源系統的元數據，通過 hook 方式捕捉各種引擎運行時數據血緣關系，并且定義通用的數據模型提供給第三方接入使用。
元數據架構：
（1）使用 Hook 方式采集作業運行時數據血緣
作業的數據血緣，有三種方式來采集：
- 靜態解析 SQL；
- 實時抓取正在執行的 SQL，解析執行計劃，解析輸入表和輸出表；
- 解析任務日志，獲取輸入表和輸出表。
第一種方式，靜態解析 SQL，可以使用 Antlr4 仿照 Hive 的 SQL 解析來實現，但是不能保證 SQL 的準確性，因為任務都沒有執行。
第二種方式，實時抓取執行的 SQL，這是執行后產生的，可以保證是準確的；
第三種方式，要分析大量的日志，而且時效性很難保證。
所以，第一種方式和第二種方式都是可以的，優先選擇第二種方式來做。
當前眾多大數據組件都提供了 Hook 鉤子的方式，相當于以插件的方式實時的捕捉執行計劃。解析之后，推送到 Kafka，再去解析到分布式的圖數據庫中。
（2）通用的數據源模塊來對接多種數據源
一般公司肯定是存在多種不同類型的數據源的，比如 Mysql，Oracle，Hive 等，可以制作一個通用的模塊，提供統一的接口，來對接這些不同的數據源。
數據源模塊則提供三方接口供采集模塊定時采集數據源的元數據信息。
核心的技術點，就是要隔離不同數據源的驅動，這些驅動也需要以插件化來集成到數據源模塊中。
（3）還需要提供個性化的 SDK 接入
如果公司的核心業務部門比較多，公司的數據平臺產品比較多，那么勢必會產生一些其他的元數據。比如監控平臺監控的資源使用情況、任務調度的任務運行情況等。
這種 SDK 接入，需要考慮接入時的安全校驗，限流（可定時消費一批Kafka數據來實現）等問題。
（4）后端存儲的統一模型
元數據類型紛繁雜亂，需要統一整理抽象，再分類存儲，并且設計之初，就要盡可能的詳盡所有情況，設計出統一的表模型，預留擴展字段。
有一套模型是專門解決元數據模型通用性問題的，叫做 CWM （Common Warehouse Metamodel）標準，翻譯過來是公共倉庫元模型，這里提供了三層元模型來存儲一切不同類型的元數據，當然設計起來比較復雜，一般超大型企業會采用這種模型。
如果可以詳盡公司未來的元數據種類，可以分門別類建不同類型的元數據模型表來解決。
參考有贊這樣的大公司，元數據可分為：
- 基礎元數據表；
- 趨勢數據表；
- 任務元數據表；
- 血緣數據表
4.2 元數據采集服務
能夠適應異構環境，支持從傳統關系型數據庫和大數據平臺中采集從數據產生系統到數據加工處理系統到數據應用報表系統的全量元數據，包括過程中的數據實體（系統、庫、表、字段的描述）以及數據實體加工處理過程中的邏輯；數據管理平臺內置多種采集適配器，支持多種存儲格式的元數據自動獲取，如：數據庫、報表工具、ETL工具、文件系統等，同時無法完成自動獲取的元數據，提供了可自定義的元數據采集模版完成元數據的批量導入。
4.3 元數據管理服務
實現元數據的模型定義并存儲，在功能層包裝成各類元數據功能，最終對外提供應用及展現；提供元數據分類和建模、血緣關系和影響分析，方便數據的跟蹤和回溯。
數據管理平臺提供各類元數據管理，包括：業務元數據、技術元數據和管理元數據，支持元數據的基本信息、屬性、依賴關系、組合關系的增刪改查操作。
最新元數據和定版元數據隔離，在最新元數據中的改動不影響定版元數據的正常使用，同時每次發布都有版本留痕，支持各版本的對比分析。
4.4 元數據分析服務
元數據的應用一般包括數據地圖，數據的血緣、影響分析，全鏈分析等；元數據管理平臺提供了豐富的元數據分析功能，包括血緣分析、影響分析、全鏈分析、關聯度分析、屬性值差異分析等，分析出元數據的來龍去脈，快速識別元數據的價值，掌握元數據變更可能造成的影響，以便更有效的評估變化帶來的風險，從而幫助用戶高效準確的對數據資產進行清理、維護與使用。
血緣分析：告訴你數據來自哪里，都經過了哪些加工。
影響分析：告訴你數據都去了哪里，經過了哪些加工。
冷熱度分析：告訴你哪些數據是企業常用數據，哪些數據屬于僵死數據。
關聯度分析：告訴你數據和其他數據的關系以及它們的關系是怎樣建立的。
數據資產地圖：告訴你有哪些數據，在哪里可以找到這些數據，能用這些數據干什么。
附錄A：建設范例
A.1 網易元數據管理方案
- 你真的了解數倉元數據嗎，數據地圖你又知道多少？
網易的元數據中心的界面（數據地圖）是基于元數據中心構建的一站式企業數據資產目錄，可以看作是元數據中心的界面。數據開發、分析師、數據運營、算法工程師可以在數據地圖上完成數據的檢索，解決了“不知道有哪些數據？”“到哪里找數據？”“如何準確的理解數據”的難題。
數據地圖提供了多維度的檢索功能，使用者可以按照表名、列名、注釋、主題域、分層、指標進行檢索，結果按照匹配相關度進行排序。考慮到數據中臺中有一些表是數倉維護的表，有一些表數倉已經不再維護，在結果排序的時候，增加了數倉維護的表優先展示的規則。同時數據地圖還提供了按照主題域、業務過程導覽，可以幫助使用者快速了解當前有哪些表可以使用。
當使用者定位到某一個表打開時，會進入詳情頁，詳情頁中會展示表的基礎信息，字段信息、分區信息、產出信息以及數據血緣。數據血緣可以幫助使用者了解這個表的來源和去向，這個表可能影響的下游應用和報表，這個表的數據來源。
數據地圖同時還提供了數據預覽的功能，考慮到安全性因素，只允許預覽 10 條數據，用于判斷數據是否符合使用者的預期。數據地圖提供的收藏功能， 方便使用者快速找到自己經常使用的表。當數據開發、分析師、數據運營找到自己需要的表時，在數據地圖上可以直接發起申請對該表的權限申請。數據地圖對于提高數據發現的效率，實現非技術人員自助取數有重要作用。經過我的實踐，數據地圖是數據中臺中使用頻率最高的一個工具產品，在網易，每天都有 500 以上人在使用數據地圖查找數據。
A.2 美團團隊元數據管理方案
美團數據地圖作為元數據應用的一個產品，聚焦于數據使用者的“找數”場景，實現檢索數據和理解數據的“找數”訴求。我們通過對離線數據集和在線數據集的元數據刻畫，滿足了用戶找數和理解數的訴求，通過血緣圖譜，完成物理表到產品的血緣建設，消除用戶人肉評估的痛苦。
1.離線場景下的元數據中心
關鍵字檢索和向導查詢共同解決了“找數據”的問題：大部分的檢索數據場景下，數據使用者都可以通過關鍵字檢索來得到匹配結果。剩下的一小部分場景，例如，對于新人入職后如何了解整個數倉和指標的體系（數倉分幾層，每層解決什么問題，都孵化出什么模型；整個指標、維度體系都是怎么分類，有哪些指標和維度），這部分場景可以使用向導查詢功能。向導查詢相當于分類查詢，將表和指標按照業務過程進行分類，用戶可以按照分類逐步找到想要的表或指標。
打通了業務元數據和技術元數據之間的關系，提高了“找數據”的能力：通過“Wherehows”查找到指標后，不僅不可查看指標的業務定義，還能查看指標的技術實現邏輯，指標在哪些維度或維度組合中已經實現，并且能夠在哪張表里找到這些維度，或維度組合的指標數據。反之，也可以知道在某個維度下已經實現了哪些指標，對應的指標在哪些表里。這些功能能讓用戶更加方便地找到想要的數據。
提供了較為完善的數據信息，幫助用戶更好理解數據：對于表的信息，“Wherehows”除了提供表和字段的中英文名稱、描述信息等基礎信息外，為了幫助用戶更好地理解表的建設思路，我們還提供了表的星型模型（可以關聯的一致性維度及對應的維度表）、表的血緣關系等信息。
2.業務數據場景下的元數據中心
業務數據場景主要想解決的一個問題是，如何知道一個業務表（MySQL表）有沒有同步到數倉。如果沒有同步，能夠找誰進行同步。因為已經打通“業務表 -> 數倉表 -> 產品”三者之間的血緣關系，我們能夠輕松解決業務數據場景的問題。
3.生產評估場景下的元數據中心
在日常數據生產工作中，我們經常需要對表進行影響評估、故障排查、鏈路分析等工作，這些工作如果靠純人工去做，費時費力。但現在我們已經打通了“業務表/字段 -> 數倉表/字段 -> 產品”三者之間的血緣關系，就能夠在10分鐘內完成評估工作。對于不同的場景，血緣鏈路提供了兩個便捷的功能：過濾和剪枝。例如，某個表邏輯需要修改，需要看影響哪些下游表或產品？應該要通知哪些RD和PM？這種情況下，血緣工具直觀地顯示影響了哪些負責人和產品，以及這個表的下游鏈路。
有些表的鏈路很長，整個血緣關系圖很大，這樣會導致用戶定位信息或問題。所以血緣工具提供了剪枝的功能，對于沒用的、不想看到的分支可以剪掉，從而讓整個鏈路變得更加直觀。
4. 元數據功能
A.3 元數據管理系統設計
- 元數據管理系統設計
1. 數據表管理模塊
數據表信息維護需要如下信息：
- 表的元數據信息（引擎、字段等）
- 表類型（維表或事實表）
- 表的使用情況（是否被模型使用）
- 表對應的ETL
- 描述信息
- 表的所有人
- 表的建表語句
2. 模型管理模塊
模型分為 數據表模型 和 SQL模型
2.1 數據表模型管理
需要維護如下信息：
- 事實表名稱（必填）
- 備注信息
關聯配置
- 主數據表（表名）
- 關聯方式（join、left join、semi join）
- 關聯表
- 關聯字段（關聯字段，關聯關系(=,<,>)）
- 關聯限制（限制字段，限制關系，限制值）
- 模型ER圖（繪制表關系圖）
模型詳情
- 數據表
- 字段名稱
- 字段類型
- 字段描述
- 是否使用
- 維度信息
2.2 SQL模型
- 數據主題（業務用途）
- 查詢引擎（查詢工具）
- SQL語句
模型詳情
- 字段名稱
- 字段類型
- 字段描述
- 維度信息
- 是否使用
3. 維度管理模塊
- 維度名稱
- 業務定義
- 業務分類
- 維表
- 是否是日期維
- 對應code
- 對應name
- 綁定維表（如果有維表）
4. 指標管理模塊
包括基礎信息管理、技術信息管理、關聯指標管理、關聯應用管理
核心部分是指標與模型的綁定關系，通過使用演進形成了當前系統兩類綁定關系：綁定物理模型和構建虛擬模型。
基礎信息管理(業務維護)
- 指標名稱
- 業務分類
- 統計頻率
- 精度
- 單位
- 指標類型
- 指標定義
- 計算邏輯
- 分析方法
- 影響因素
- 分析維度
技術信息管理（技術維護）
- 指標名稱（必填）
- 數據類型
模型信息
- 模型名稱
- 篩選指標
- 公共引擎
- 查詢引擎
基礎指標信息
- 基礎指標
- 業務線/主題
- 指標代碼
- 數據模型
- 支持維度
- 計算公式
- 分析維度
- 場景描述
基礎模型信息
- 數據模型名稱
- 查詢引擎
- 綁定字段
- 計算公式
- 操作人
- 操作時間
- 支持維度
5. 應用管理
應用管理由數據應用、外部應用、數據地圖三大模塊組成，它們構成了對外服務的主體，記錄了外部應用與平臺內管理的指標、維度、模型和表的關聯關系，也提供數據查詢展示、應用層ETL生產的能力。而且數據開發人員從底層向上觀察，可以追蹤數據最終的所有流向；業務分析人員從頂層向下觀察，可以看到構成服務的所有數據來源。
5.1 數據應用模塊
數據應用模塊是記錄生成每個服務所需的指標、維度和數據模型的關系。每次服務中可以包含多個指標，這些指標可以來源于多個數據模型，不過不同的數據模型中需要包含公共維度，因為是通過這些公共維度將不同模型關聯起來。
數據應用中構建的服務可以發布成查詢服務、應用層ETL生產服務、對外API數據接口服務、通用報表配置服務，來滿足業務的不同需求
需要信息：
- 應用名稱
- 查詢引擎
統計指標列表
- 統計指標
- 指標代碼
- 數據模型
- 支持維度
- 分析維度列表
where條件
- 邏輯運算
- 過濾字段
- 是否為動態參數
- 比較運算
- 值
- 操作
- 備注
需要功能：
- 生成SQL
- 執行查詢
5.2 外部應用模塊
外部應用模塊管理外部應用和應用內的模塊，以及這些模塊訂閱的對應數據應用，目標是實現API接口調用的權限管理和數據最終流向的記錄。
具體的實現上模塊
首先創建對應的外部應用，記錄：
- 對應的外部應用
- 記錄外部應用的名稱
- URL
-APPKEY等信息
然后由對應應用的負責人創建模塊，記錄：
- 模塊名稱
- URL
- moduleKey等信息。
這些信息完善后，由對應的數據應用賦權給對應的模塊，建立起數據應用與外部應用的聯系。最后在外部應用調用平臺對外API接口時，進行權限管理。
5.3 數據地圖
數據地圖功能是追查數據的流向，可以從數據表、模型、指標、數據應用、外部應用任意節點查看上游數據來源和下游數據去向
A.4 元數據治理產品案例實踐
- 元數據治理：產品方案介紹及案例實踐
1. 案例場景描述
目標：通過一個簡化的案例，介紹元數據基本的治理流程，該案例將介紹業務庫存量表的元數據治理流程。
場景：某業務系統的MySQL庫中存儲了一張「客戶信息表」，該表在實際業務中使用比較頻繁，但是由于元數據缺失導致經常面臨各種數據答疑、數據使用不規范等問題。故計劃將該表采集到平臺上進行治理，治理內容主要是完善表的業務信息、技術信息、管理信息等，以便將治理后的數據表呈現給用戶，方便用戶快速理解和使用表。
2. 操作流程說明
為了實現上述案例的場景，我們需要完成以下事項：
（1）登記MySQL數據源，方便后續元數據使用；
（2）采集MySQL數據源中的「客戶信息表」的元數據；
（3）「客戶信息表」的元數據治理，包括元數據的安全、質量、標準、部門歸屬等信息；
（4）已治理的元數據表進行發布，發布后業務人員可以在資產目錄中查看完整的元數據信息，以便業務使用。
3. 操作步驟
第一步：登記數據源
在平臺的數據源管理模塊中，登記業務系統的MySQL數據源信息。登記內容主要包括數據源名稱、負責人、數據源連接、用戶名和密碼等信息。
第二步：創建元數據采集任務
在元數據采集模塊創建采集任務，采集上一步中登記的MySQL數據源中的「客戶信息表」，根據實際業務場景需要設置采集的間隔周期。
第三步：申請元數據治理
元數據治理是整個操作實踐過程中最重要，也是最復雜的一步。元數據治理一般會涉及到多部門間的協作治理，例如業務信息的補充完善需要業務部門專員參與治理，技術信息完善需要IT部門開發參與治理，最終治理的元數據在發布申請時需要治理部門進行最終審核確認。
上一步中采集的元數據表會在平臺自動注冊為一條元數據記錄，此時元數據只有基本的物理信息例如表名、字段名、字段類型等，信息非常不完善。此時元數據是草稿狀態，需要通過申請治理來派發治理工單給相關人員處理，如下圖所示：
工單接收人接收到治理工單后，可以對元數據信息進行補充，包括表級和字段級的業務元數據、技術元數據等信息。表級元數據治理頁面如下所示：
表級元數據信息分為基礎信息、業務信息、技術信息，如果上述元數據內容還不夠，還需要更多的元數據屬性，系統也支持自定義屬性及值域，以便業務靈活擴展元數據。
Tips：元數據治理頁中，表的技術信息可以點擊右側的“掃描技術信息”按鈕，觸發一次元數據掃描功能。掃描后系統會自動將源庫中的一些物理信息展示在頁面上，方便用戶確認最新表信息并覆蓋填充。
接下來是字段的元數據治理頁面，如下所示：
這里可以針對表的每個字段進行治理，治理內容包括基礎信息、業務信息、技術信息。圖中紅色圈選出來的幾個信息是和平臺其他子產品相關聯的內容，這里簡單說明一下：
- 安全級別：可以在配置管理模塊中設置安全級別的自動推薦方式，可以通過安全中心識別任務掃描獲取安全級別，也可以通過第三方NLP接口智能推薦安全級別；
- 數據元：和平臺的數據標準模塊打通，數據標準中會定義數據元規范、格式、值域等；
- 數據質量管理信息：和平臺數據質量中心打通，關聯系統規則模板；
- 關聯指標：和指標系統打通，能夠了解字段和指標的關聯關系；
- 關聯標簽：和標簽系統打通，能夠了解字段和標簽的關聯關系。
其他字段的治理項操作頁面基本一致，這里就不一一展示了。
第四步：申請元數據發布
經過第三步的元數據治理后（實際治理過程可能需要多輪治理才能達到申請發布的條件）可以申請發布，以便將治理后的表資產共享給業務人員。
第五步：數據資產查看
已治理并發布后的元數據，可在資產目錄中的對應業務目錄下找到表，或者直接根據關鍵字搜索表。找到表后在表詳情頁可查看元數據信息，其中表和字段的基礎信息、業務信息、技術信息都比較完善，在此基礎上平臺也提供了元數據其他豐富的功能例如數據預覽、產出信息、數據血緣等等。
以上通過一個簡單案例完成了元數據表從業務系統登記、采集、治理、發布、查看使用的主流程。實際業務場景中企業往往存在著大量歷史數據亟待治理、同時新增數據的規范治理等，數據治理工作也會更加艱巨、復雜，治理項涵蓋內容也會更多更深，由此也是對產品提出了更多的要求和挑戰。
附錄B：其他相關參考博文
- 數據治理：元數據及元數據管理策略、方法和技術
- 數據倉庫中的元數據管理！
- 元數據管理拉垮得一批，還談啥數據治理？
- 數據服務基礎能力之元數據管理
- 終于有人把元數據講明白了
- 元數據是什么？如何管理元數據？
- 別人家的元數據系統是怎么設計的
- 元數據管理-解決方案調研一：元數據概述
- 元數據管理-解決方案調研二：元數據管理解決方案——Saas/內部解決方案（1）
- 元數據管理-解決方案調研二：元數據管理解決方案——Saas/內部解決方案（2）
- 元數據管理-解決方案調研二：元數據管理解決方案——Saas/內部解決方案（3）
- 元數據管理-解決方案調研二：元數據管理解決方案——Saas/內部解決方案（4）
- 元數據管理-解決方案調研三：元數據管理解決方案——開源解決方案
總結
以上是生活随笔為你收集整理的元数据管理、治理、系统、建设方案、范例等的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 软件测试风险清单
- 下一篇： 第24章 让唯美的雪花飘扬——三维粒子系