本文翻譯自 Shirshanka Das 的 DataHub: Popular metadata architectures explained

自從WhereHows（第二代，DataHub前身）在2016年被推出以來，在本文檔編寫時(shí)，元數(shù)據(jù)中心系統(tǒng)架構(gòu)經(jīng)歷了三代演變，WhereHows作為最早的元數(shù)據(jù)中心開源產(chǎn)品影響著后來同類型的項(xiàng)目。在該領(lǐng)域內(nèi)Lyft’s Amundsen、DataHub處于領(lǐng)先者，Amundsen（2019年10月開源）社區(qū)最活躍的，”基于推送“架構(gòu)之上的DataHub在2019年8月重構(gòu)推出以來也越來越被關(guān)注。
（以下的部分競品分析可看這）

第一代架構(gòu)：Pull-based ETL （基于Pull-ETL模式）

整體架構(gòu)會(huì)簡單些，采用單體架構(gòu)。通常會(huì)利用爬取方式定時(shí)抓取并結(jié)構(gòu)化數(shù)據(jù)，存儲(chǔ)在一個(gè)便于檢索的主存儲(chǔ)（MySQL/Postgres），和搜索引擎（ES）中，提供一前端展示數(shù)據(jù)并支持簡單檢索。1.5 代可能會(huì)引入圖形數(shù)據(jù)庫（Neo4j）、批處理作業(yè)（Spark作業(yè)）。

優(yōu)點(diǎn)：

• 較少的組件依賴

只需一個(gè)查找存儲(chǔ)、一個(gè)搜索索引和幾個(gè)爬蟲程序，就可以快速聚合元數(shù)據(jù)，并構(gòu)建一個(gè)有用的應(yīng)用程序

• 資源投入少，可快速響應(yīng)

一般服務(wù)于固定場景，可快速響應(yīng)，較少的資源投入

缺點(diǎn)（主要）：

• pull模式

采集方式雖然很容易實(shí)現(xiàn)并可聚合數(shù)據(jù)，但該方式卻及其脆弱。爬蟲程序與數(shù)據(jù)源在不同環(huán)境下，往往由各自團(tuán)隊(duì)單獨(dú)管理，共識很容易隨著時(shí)間推移、產(chǎn)品迭代、人員變動(dòng)而被打破（比如防火墻規(guī)則或密碼更改、存儲(chǔ)源結(jié)構(gòu)調(diào)整），而導(dǎo)致一系列異常。另一個(gè)問題，爬蟲程序通常會(huì)導(dǎo)致負(fù)載飆升影響到正常的業(yè)務(wù)系統(tǒng)以及需考慮增量、非增量帶來的影響。而在系統(tǒng)負(fù)載過高情況下，爬蟲程序總是會(huì)被優(yōu)先掛起或被關(guān)閉。這就引出了第二個(gè)問題。

• 數(shù)據(jù)時(shí)效性過低

采集模式都是T+1（n）方式進(jìn)行，這僅僅只是比以前更有效率了。然而一旦開始運(yùn)營數(shù)據(jù)，在多數(shù)重要場景下，數(shù)據(jù)的即時(shí)性和高保真度就變得格外重要。（例如數(shù)據(jù)質(zhì)量、數(shù)據(jù)標(biāo)簽）

第二代架構(gòu)：3-tier app with a service API（支持push的微服務(wù)架構(gòu)）

通過添加基于推送的體系和微服務(wù)的API進(jìn)行存儲(chǔ)、檢索元數(shù)據(jù)，第二代架構(gòu)已經(jīng)可以為數(shù)據(jù)資產(chǎn)提供可靠的搜索和發(fā)現(xiàn)服務(wù)?？赡苓€會(huì)引入訪問控制，但是元數(shù)據(jù)依然存儲(chǔ)在單個(gè)元數(shù)據(jù)存儲(chǔ)區(qū)中。

優(yōu)點(diǎn)：

• 統(tǒng)一接入方式
• 可編程

通過服務(wù)API，最終可以做到對數(shù)據(jù)集或字段進(jìn)行標(biāo)記，并可對這些數(shù)據(jù)進(jìn)行業(yè)務(wù)操作（如自動(dòng)刪除，提取，備份）

缺點(diǎn)：

• 沒有變更日志

沒有日志，當(dāng)出現(xiàn)問題時(shí)，很難重建或修復(fù)搜索和圖形索引。另外沒有實(shí)時(shí)的元數(shù)據(jù)變更日志，也無法構(gòu)建高效的反應(yīng)系統(tǒng)。

• 中心化團(tuán)隊(duì)

這種架構(gòu)仍然依賴一個(gè)集中化的團(tuán)隊(duì)，需要參與到業(yè)務(wù)數(shù)據(jù)構(gòu)建中，支持所有下游消費(fèi)者希望訪問元數(shù)據(jù)的方式。這不僅限制了中心服務(wù)為下游提供動(dòng)力的能力，也阻礙了業(yè)務(wù)的快速發(fā)展。基于服務(wù)的集成操作，還需考慮服務(wù)提供方停機(jī)帶來的影響。

第三代架構(gòu)：Event-sourced metadata （基于流的組件服務(wù)）

基于”中心服務(wù)“的元數(shù)據(jù)解決方案難以跟上企業(yè)對元數(shù)據(jù)用例的需求。要解決這個(gè)問題，必須滿足兩個(gè)要求，第一個(gè)元數(shù)據(jù)本身可流動(dòng)、基于事件的、可實(shí)時(shí)訂閱的；第二個(gè)元數(shù)據(jù)模型是開放的，使用方可按需擴(kuò)展豐富模型。
在三代架構(gòu)中做出了兩個(gè)重大改進(jìn)：面向日志的元數(shù)據(jù)體系、面向領(lǐng)域的元數(shù)據(jù)建模
面向日志的元數(shù)據(jù)體系：

面向領(lǐng)域的元數(shù)據(jù)建模：

完整版：

優(yōu)點(diǎn)：

• 可以獲得基于流的元數(shù)據(jù)日志（如變更通知）

元數(shù)據(jù)的細(xì)化和豐富可以通過低延遲的日志更改事件來執(zhí)行

• 開放擴(kuò)展

不同的業(yè)務(wù)團(tuán)隊(duì)/用例可附加屬性到需要的模型上，以滿足不同的需求

缺點(diǎn)：

• 系統(tǒng)復(fù)雜、更多的組件依賴
• 用戶體驗(yàn)可能差、繁瑣

開發(fā)一個(gè)簡單的用例，所需的工作量大，繁瑣。需要投入一定精力和經(jīng)驗(yàn)成本在可用性和體驗(yàn)方面下功夫。

經(jīng)過這樣的演化，優(yōu)良的架構(gòu)讓使用方可以按不同的方式進(jìn)行對接；可以獲得基于流的事件通知；更低時(shí)延的查詢和全文檢索能力；直觀的元數(shù)據(jù)關(guān)系圖形查詢；在不犧牲一致性或時(shí)效性情況細(xì)化和豐富元數(shù)據(jù)；更優(yōu)的用戶體驗(yàn)。第三代架構(gòu)確保我們能夠以最具伸縮性和靈活性的方式集成、存儲(chǔ)和處理元數(shù)據(jù)。但這還不夠。

“Putting metadata to work is harder than just putting metadata together.”
使用元數(shù)據(jù)比將元數(shù)據(jù)放一起更難

首先需要定義正確的元數(shù)據(jù)模型，以真正捕獲對企業(yè)有意義的概念。然后，您需要一個(gè)支持AI的途徑，從這個(gè)完整、可靠的數(shù)據(jù)資產(chǎn)清單過渡到元數(shù)據(jù)的可信知識圖。這將允許您真正釋放企業(yè)的生產(chǎn)力和治理。