本文討論了什么是元數據，元數據管理的架構和應用價值，希望對大數據從業者有些許啟發。
各位晚上好，很高興能與大家分享對元數據架構與應用的一些思考。
首先簡單介紹下我自己，我2010年加入普元，目前負責普元大數據產品部，我和我的團隊主要在做大數據治理相關的產品和解決方案。在來到普元之前在人民銀行軟件開發中心擔任核心架構師，參與了人民銀行的一些大型項目的建設。
整個分享分為三個部分：
第一部分，說說我和我的團隊眼中的元數據。
第二部分簡單介紹如何實現元數據管理的架構。
第三部分，我將通過舉例的方式，說明元數據的應用價值。
元數據是什么
元數據是信息的維度，可以說，掌握了元數據就掌握了信息的維度。
只有充分利用好元數據(也就是信息的維度)，通過合理的元數據建模(維度整合)，對元數據進行科學管理(維度完善)，才能更好地認知信息。
那么，就可以將元數據管理看成是這些信息概念和信息本身之間的一種連接。其中信息概念表示某個業務所有維度的集合，連接則是描述元數據與元數據之間關系的方式。
元數據管理是隨著數據倉庫的建設逐漸完善起來的，這也決定了元數據管理主要集中在數據領域。例如數據結構、數據加工轉換關系等。
而隨著我們對元數據理解的不斷深入，其實元數據廣泛存在于企業架構的方方面面，而不僅僅局限于數據領域里。
因此，元數據管理的范圍也在不斷擴大，從簡單的庫表，到整個數據平臺，再到服務管理，不斷地突破傳統管理的范疇，形成了廣義元數據管理。
在這個過程中，對元數據的技術架構也有了新的要求，穩定可擴展的架構才是實現廣義元數據管理的基礎。
元數據管理的架構
要實現元數據管理有三個方面，
1、采集：指從各種工具中，把各種類型的元數據采集進來，采集是元數據管理第一步。
2、存儲：采集之后需要相應的存儲策略來對元數據進行存儲，這需要在不改變存儲架構的情況下擴展元數據存儲的類型；
3、管理和應用：在采集和存儲完成后，對已經存儲的元數據進行管理和應用。
隨著元數據管理范疇的不斷擴大，如何保證元數據從采集、存儲到應用等關鍵環節的穩定和擴展，成為元數據管理架構設計的關鍵問題。
OMG的模型體系規范為元數據管理提供了基礎，所以整個元數據管理設計的關鍵應該以模型體系規范為指導。
OMG提出的CWM(Common Warehouse Metamodel)規范對數據倉庫相關的所有模型進行了描述，在初期我們也遵照此規范設計元數據管理的架構，但是規范里也有坑，我們很快就發現了問題。
我們發現CWM規范本質上是針對數據倉庫領域的規范，按照OMG的模型體系來看，模型的抽象層次還是太低。
如果繼續提高抽象層級，MOF規范位于模型體系最底層，所有模型體系規范的基礎都應該是MOF(Meta Object Facility)規范，UML，CWM都是由MOF擴展而來。
基于MOF的還有模型交換的規范XMI，為不同元數據交換提供了很好的模型基礎。
那么若整個元數據圍繞MOF設計和擴展，不用修改元數據管理核心部分，就可以適應元數據種類的不斷擴展。
下面我們來看看如何設計元數據的存儲。
元模型對元數據屬性及關系進行了定義，一般來講，元模型存儲有兩種方式。
1、第一種方式是將元模型轉換成系統數據庫表和屬性，實現一對一管理存儲。例如可以將主鍵元模型存儲在主鍵記錄表中、將存儲過程元模型存儲在存儲過程記錄表中等。
2、另一種方式是基于MOF元元模型把所有屬性和關系打散，以此來實現元模型的通用存儲結構。
如圖所示，以CWM模型中關系型包為例進行說明，方式一是直接將元模型轉化為庫表，方式二按照元元模型的方式存儲元模型；
盡管第二種實現方式上復雜度會更高一些，但是在擴展性有絕對優勢，是元數據管理實現的優先選擇方式。
再來看看模型體系的層次結構。
和元數據有關的體系分三層，M1(元數據)、M2(元模型)、M3(元元模型)，其中MOF元元模型中描述了包、元素、屬性、命名空間和約束等對象及其關系，位于層次結構的最上層，也是最抽象的一層。
以MOF作為底層元元模型來支持元數據管理，在M2層中就可以對元模型進行定義和擴展(例如CWM模型)，將來還可以擴展到微服務模型、業務模型等。
選定了實現方式后，一般可以通過三步來實現元數據的管理，
第一步，以MOF規范設計元模型存儲結構，從而支持元模型的擴展。
第二步，基于MOF設計元模型，例如將CWM(公共倉庫元模型)規范中定義的元模型，存儲在元模型中。
第三步，按照擴展后的元模型，采集元數據，存儲到元數據系統中。
在元數據管理三層管理架構的支持下，通常只需要做元模型定義和元數據采集，就對不同元數據進行管理。
例如，要將表與字段元數據采集到元數據管理系統，只需要如下兩步：
首先，對元模型定義并描述元數據特征，包括類屬性描述、關系的描述等；
然后，將元數據采集進來，存儲到系統中；
元數據的應用價值
良好的元數據架構，能夠給元數據帶來更多的應用價值。我們再看看元數據的應用價值。
通過元數據管理我們能夠做到：
1、實現多樣、繁雜的元數據信息集中管理，為企業數據(服務)管理提供統一的視圖，實現企業級數據(服務)資產管理，方便數據(服務)交互共享，同時為后續規劃提供依據；
2、通過管理維護數據(服務)之間關系，實現數據(服務)自動關聯分析，為問題定位、影響分析、上線加速等提供支撐。
3、建立數據(服務)標準，統一交換、存儲、應用口徑，減少共享壁壘，降低應用出錯幾率，提升質量。
通過這些基本能力，元數據在數據管理、微服務管理、業務管理等方面都能發揮很大的作用。
通過元數據管理，在數據方面能做到：
1、數據標準化；2、數據開放；3、數據質量提升等
在微服務方面，能夠提供以下支撐：
1、服務開發、應用等標準化；2、服務應用監控，優化服務應用等
將來在業務方面也能通過元數據實現業務流程分析、業務流程優化等能力。
下面我們用幾個例子，舉例說明元數據的作用。
數據治理之中，元數據是整個治理體系落地的技術核心。
比如：在數據標準中將數據標準作為一類業務元數據存儲，將其和技術元數據一定程度的關聯，去看標準的落地效果。
在數據質量中，通過元數據追溯質量問題。在共享發布中，利用元數據自動形成數據服務等等。
元數據還能夠自動化的準確的管理應用的上線、變更， 通常企業系統建設會分為開發、測試與生產三個不同的環境，而在軟件開發過程中，無論是需求變更還是BUG修改都避免不了元數據的改動，這時候往往會出現開發庫、測試庫測試通過，而在上線過程中又出現問題的情況，這會讓運維部門非常頭疼。
此時若通過元數據對系統的上線變更進行管理，自動采集三個環境的庫表結構與存儲過程等信息，保證各個環境中的元數據都是最新的、最準確的，再將上線環境與測試環境的元數據進行對比，不一致的地方一目了然。如果把系統的開發庫、測試庫、生產庫的元數據都管理起來，上線時突然出現問題的概率就會大大降低。
通過擴展模型，元數據也能夠管理微服務，微服務的生命周期有多個階段，在前期需要與多個微服務協同考慮，上架后也會有多個使用者，在這種復雜的狀況下需要管理微服務的全生命周期。
在規劃階段提供標準元數據規范微服務，在設計階段提供連接其他微服務的元數據信息，在開發階段使用元數據協助開發測試。
上線后分析微服務的使用情況，并協助維護微服務的變更。最后微服務下架時將微服務的元數據存檔，并確保對目前體系不產生影響。
同時微服務的不同版本間的元數據的變化也可以做追溯和分析。
最后，未來元數據將是連接業務，數據與服務的企業核心基礎設施，可擴展的元數據架構也能夠產生更多更有價值的應用場景。
今天的分享就到這里，謝謝大家，也歡迎大家提出問題。
Q&A：
Q1：談談您對于基于元數據驅動的自動化文檔編寫、ETL設計、調度設計、測試設計、數據質量管控和業務監控的可行性、難點和思路？目前我正在設計這塊的東西。
王軒：我覺得這個問題蠻好，也是我們思考很久的問題。
其中難度在于如何收集更多的元數據，同時能夠用自動化的手段和工具緊密結合。
比如，ETL設計，很多ETL是重復性的，如何能夠通過一定規則自動生產ETL任務，我們有了一系列的方法，不過支持的工具的類型有限制。
比如數據質量管控，其中很明顯的是能夠用元數據的血統分析，獲得問題數據的源頭，但是這還不夠，是不是能夠自動形成數據質量檢核方法？ 和業務元數據結合，就能夠自動生成一部分檢核方法。
Q2：對元模型的圖看不清，能不能額外講解下？怎么實現多表的元元模型？謝謝
王軒：其實遵照規范，是有很多表，在這里需要做一定的簡化，實現需要的就可以了。
Q3：想了解一下你們用什么存儲元數據？
王軒：目前用關系數據庫存儲，用MOF規范存儲元數據的限制也在這里，表間關系會很復雜，這樣就限制了存儲的方式。但是可以在應用層用一些技術解決性能的問題。
Q4：元數據有很多上下游關系，這種場景下用關系數據庫會有性能問題嗎？
王軒：坦白的說，會有。 尤其在元數據管理大數據環境的時候。
元數據的數量級會增加，這樣就必須要解決性能問題，我們也做了很多嘗試，比如預先的匯總，預先的分析。比如，利用內存數據庫緩存等。
現在也在研究用圖數據庫實現，但還沒有加入到產品中。
Q5：王老師，您說元數據是數據治理的核心，那我想問個關于數據治理的問題，在數據治理中，數據標準是否可以通過元數據來落地？如果可以，能講下主要思想嗎？非常感謝！
王軒：數據標準的落地是一個非常復雜的問題，除了技術以外有很多管理和組織架構的因素。
我們把數據標準作為一種特殊的業務元數據存儲在元數據中(利用可擴展的能力)。 數據標準中的標準項中也有每個標準建議的字段英文。
這樣可以通過技術元數據的自動匹配發現與表與數據標準的不一致的地方，從而促進標準的落地進程，在很多客戶那里有很好的效果。
Q6：分布式系統的環境下，如何有效的管理元數據？ 元數據管理與主數據管理在實現上有什么異同點？
王軒：先回答第二部分問題，元數據和主數據是有很大不同，一個管理的是數據的定義，一個管理的是數據本身。但是也有統一的地方，都需要集中的管理。
那么前一部分問題，比如在微服務環境中的元數據是個典型的分布式系統，我們現在在新一代產品中已經有很好的管理方式，還是基于可擴展的元模型，管理更多的內容，從而實現更好的分析和應用。
Q7：目前你們是基于什么樣的考量而不使用圖數據庫的呢？
王軒：我團隊的元數據產品已經發展了8年，團隊已經認為可以使用圖數據庫，后續會逐步加入，在保證產品穩定的基礎上。
講師簡介：王軒，普元信息軟件產品部副總、大數據產品線總經理，2010年加入普元，全面主持普元大數據產品的研發、拓展及團隊管理工作。十年大型企業信息化架構設計與建設經驗，曾任中國人民銀行核心平臺架構師。主持參與了國家開發銀行大數據項目、中國人民銀行軟件開發平臺、國家電網云計算平臺等大型項目建設。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文網址：http://www.guhuozai8.cn/html/consultation/10839319892.html
相關文章
