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