元數據新型存儲架構的探索

轉載本文需註明出處：微信公衆號EAWorld，違者必究。

引言：

一個軟件產品存儲架構是須要仔細斟酌和考慮的事情，既要保持穩定性也要保持跟上主流技術的發展趨勢。元數據產品從最初主要支持關係型的數據管理到如今的大數據平臺、數據湖、微服務這種新的數據架構形態的管理。原有的存儲架構從分析元數據關係效率、檢索速度都不能知足應用的需求了。

目錄：

1、國內主流元數據產品發展示狀
2、當前元數據存儲架構存在的問題
3、新型存儲架構的探索
4、新型存儲架構的應用
5、新型存儲架構的優勢

1、國內主流元數據產品發展示狀

國內主流的元數據產品主要有MetaCube、MetaOne、MetaManager等，基本上都採用了遵循MOF規範，設計了可擴展的元數據存儲架構。這種存儲架構的特徵就是，以元模型管理爲基礎，元模型是描述元數據的元數據。你能夠把元數據當作一種特殊的數據，要存儲這種特殊的數據，須要事先定義它的結構。就和咱們管理學生的數據同樣，要先定義學生數據模型。以下圖:



元模型設計有兩種方式:

第一種方式如上左圖所示，要管理那些元數據事先就定義好它的元模型，好比要管理字段這種元數據，我就定義字段都包括那些屬性，好比字段英文名稱、字段名稱、字段類型、字段長度、精度等。而後按照字段的屬性，建一張表專門存儲字段這種元數據。

第二種方式，就是基於MOF的元模型設計，定義一系列的管理元模型的模型，就是元元模型。如上右圖，這裏面有類表、類屬性表、類組合關係和類繼承關係等等，這些就是元元模型。採用這種方式就解決了模型穩定性的問題，還帶了很靈活的擴展性。當一個組織要增長一種新的元數據管理時，只須要經過元模型管理的功能，定義好元數據的屬性（包含屬性與元數據存儲表字段映射關係）。元數據採集適配器按照模型的定義，把元數據存儲到表。使用的時候，在按照元模型的定義把表裏的元數據轉義出來，展示到頁面上。

2、當前元數據存儲架構存在的問題

方式一：按照要管理的元數據類型一對一建表

若是要建一個元數據管理系統，只管理字段元數據，那就只須要建這一張表就能夠了。可是一個組織裏要管理元數據有不少，按照第一種方式，就須要不斷的新增長表，以管理更多的元數據。這樣就嚴重破壞了模型的穩定性。通常不多有人採用這種方式。

方式二：經過元模型管理定義元數據的屬性

這種方式的缺點就是，違背了Java面向對象的編程思想，程序處理邏輯複雜，須要編寫大量的自定義SQL來實現元數據的管理。以下圖所示查詢元數據基本信息的邏輯。除了元數據公共屬性instance_id(ID),instance_name(名稱),instance_code（編碼）,parent_id（父ID）,classifier_id（元數據類型）,namespace（上下文命名空間）外，還有fileld這個動態屬性，是須要在java程序中動態拼接的。以下圖所示：



再來看下T_MD_INSTANCE表的結構，以下圖，咱們發現裏面有大量STRING_一、STRING_2 .....STRING_40的字段。設置40個擴展字段，不會所有用到，用到的表明什麼含義由元模型來決定。



以字段元數據來舉例，要知道STRING_8這個字段表明什麼含義，須要從元模型表、元模型屬性表和元模型屬性映射表來解讀。



在顯示一個元數據的基本信息的時候，須要經過至少4張表才能顯示出來。

3、新型存儲架構的探索

說到元數據存儲架構，有人會很自認想到有分佈存儲分散管理，分佈式存儲集中管理、統一存儲集中管理之分。這種屬於宏觀的存儲架構，咱們不展開討論。這裏是在統一存儲集中管理的假設下來討論元數據微觀的存儲架構。

咱們把元數據管理系統的表劃分爲三類：

一類是元數據系統管理表例如元模型管理表之類的。這類數據（例如元元數據）量不大，但對元數據管理很重要。
一類是元數據的應用表例如元數據關聯關係等，元數據中的血緣分析、影響分析和數據地圖的數據就是來源於這裏。有點相似與人的社交網絡分析。這個須要對海量的元數據進行分析，並將關係存儲起來。
一類元數據的事實表；即經過元數據採集適配器採集到來的原始的元數據。這類元數據可讀性不好，是不能拿給用戶直接來使用的。其顯著的特色是數據量大，爲了保持其時效性，須要按照必定頻率進行更新。

對元數據管理系統的三類表的特色有了瞭解後，咱們在來分析要使用那種存儲架構

顯然第一類數據，要用關係型數據庫比較合適，數據量不大，單一致性的要求比較強。例如開源的Mysql,若是在配合redis內存數據庫，那就更好了。

第二類數據，關聯關係的存儲，比較推薦圖數據庫，例如Neo4j。以前使用過關係型數據庫對這類數據進行存儲。在關係比較複雜的狀況下，檢索的速度比較慢。由於這是一個相似與網狀的關係圖。要檢索的數據呈幾何倍數的增加。

第三類數據，元數據事實表，採用非關係型數據庫存儲可以較好知足其特色。推薦使用HBase做爲元數據存儲層。

4、新型存儲架構的應用

關鍵應用一：

用HBase數據庫存儲元數據對象Hbase元數據實例表的設計，要注意兩點：

一是要區分元數據不變屬性和可變屬性的區分。不變屬性是指每一類元數據都固有屬性。例如code、name、path可變屬性：是根據元數據類型的不一樣而發生變化的屬性。例如表類型的元數據和字段類型的元數據，可變屬性是不同的。例如字段含有的屬性例如字段類型、字段長度等這些屬性在表類型的元數據中是沒有的。

二是：rowkey的設計，在這裏咱們選擇將元數據code+元數據類型+元數據路徑這三項數據進行MD5加密生成的字符串做爲元數據的ID，而不是隨機生成的字符串做爲元數據ID，是爲了保證進入到元數據存儲庫的元數據ID都是惟一的，不會出現重複的問題。而這個ID將做爲元數據rowkey。

正是由於不一樣類型的元數據屬性差別很大，而Hbase數據庫字段是能夠擴展的，爲實現不一樣元數據的統一一張表提供了可操做性。

1.1 在HBase插入元數據示例：



1.2 元數據的修改，也是經過Put操做完成。這裏不展開說明。

1.3 元數據的刪除



爲了可以快速的檢索到符合條件的記錄。咱們這裏還會涉及一張索引表，經過元數據code、元數據名稱、元數據類型、元數據路徑，索引到相應的RowID,來快速查詢元數據詳情信息。

關鍵應用二:

用圖數據庫來存儲關聯關係,圖數據庫中的節點、屬性、關係和label四類基本概念，而元數據的圖形展示出來也是節點、關係、節點基本屬性和關係的基本屬性。我在這裏把Node4j和元數據關係的存儲作了示例。沒有把node4j集成到項目中，固然網上有Spring Data Neo4j和Node4j數據庫集成的示例，能夠輕鬆的把Node4j和java項目結合在一塊兒。因爲時間的問題，我沒有作測試。只是使用單獨的Node4j數據庫作了元數據關係存儲的驗證。

2.一、元數據節點示例：



2.2 在圖數據庫上操做




5、新型存儲架構的優勢

經過新型存儲架構，將元數據系統用到的表進行分類存儲，發揮不一樣數據庫的優點，從而提高元數據管理系統的查詢、展示效率。

優勢1：解決了關係型數據庫表的預留字段的限制。
優勢2：下降了程序實現的複雜度。
優勢3：提高了數據的查詢、展示效率。


關於做者：劉慶會，普元雲計算和大數據產品部架構師，主要負責普元大數據治理產品研發和項目實施，十年大型企業信息數據治理架構設計與建設經驗，爲多家大型金融機構、企業設計與規劃數據管理總體框架和項目實施。數據行業有着深刻的研究和洞察，並對企業信息化平臺建設，數據治理及大數據平臺建設有着豐富經驗。


關於EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享。長按二維碼關注！