前言
近幾年來數(shù)據(jù)的量級在瘋狂的增長，由此帶來了系列的問題。作為對人工智能團(tuán)隊的數(shù)據(jù)支撐，我們聽到的最多的質(zhì)疑是 “正確的數(shù)據(jù)集”，他們需要正確的數(shù)據(jù)用于他們的分析。我們開始意識到，雖然我們構(gòu)建了高度可擴(kuò)展的數(shù)據(jù)存儲，實時計算等等能力，但是我們的團(tuán)隊仍然在浪費(fèi)時間尋找合適的數(shù)據(jù)集來進(jìn)行分析。

也就是我們?nèi)狈?shù)據(jù)資產(chǎn)的管理。事實上，有很多公司都提供了開源的解決方案來解決上述問題，這也就是數(shù)據(jù)發(fā)現(xiàn)與元數(shù)據(jù)管理工具，
在這篇文章中，我將描述行業(yè)迄今為止元數(shù)據(jù)管理的三代架構(gòu)，
希望本文能幫助您在選擇自己的數(shù)據(jù)治理解決方案時做出最佳決策。

什么是元數(shù)據(jù)管理？
簡單地說，元數(shù)據(jù)管理是為了對數(shù)據(jù)資產(chǎn)進(jìn)行有效的組織。它使用元數(shù)據(jù)來幫助管理他們的數(shù)據(jù)。它還可以幫助數(shù)據(jù)專業(yè)人員收集、組織、訪問和豐富元數(shù)據(jù)，以支持?jǐn)?shù)據(jù)治理。

三十年前，數(shù)據(jù)資產(chǎn)可能是 Oracle 數(shù)據(jù)庫中的一張表。然而，在現(xiàn)代企業(yè)中，我們擁有一系列令人眼花繚亂的不同類型的數(shù)據(jù)資產(chǎn)?？赡苁顷P(guān)系數(shù)據(jù)庫或 NoSQL 存儲中的表、實時流數(shù)據(jù)、 AI 系統(tǒng)中的功能、指標(biāo)平臺中的指標(biāo)，數(shù)據(jù)可視化工具中的儀表板。
現(xiàn)代元數(shù)據(jù)管理應(yīng)包含所有這些類型的數(shù)據(jù)資產(chǎn)，并使數(shù)據(jù)工作者能夠更高效地使用這些資產(chǎn)完成工作。

所以，元數(shù)據(jù)管理應(yīng)具備的功能如下：
搜索和發(fā)現(xiàn)：數(shù)據(jù)表、字段、標(biāo)簽、使用信息
訪問控制：訪問控制組、用戶、策略
數(shù)據(jù)血緣：管道執(zhí)行、查詢
合規(guī)性：數(shù)據(jù)隱私/合規(guī)性注釋類型的分類
數(shù)據(jù)管理：數(shù)據(jù)源配置、攝取配置、保留配置、數(shù)據(jù)清除策略
AI 可解釋性、再現(xiàn)性：特征定義、模型定義、訓(xùn)練運(yùn)行執(zhí)行、問題陳述
數(shù)據(jù)操作：管道執(zhí)行、處理的數(shù)據(jù)分區(qū)、數(shù)據(jù)統(tǒng)計
數(shù)據(jù)質(zhì)量：數(shù)據(jù)質(zhì)量規(guī)則定義、規(guī)則執(zhí)行結(jié)果、數(shù)據(jù)統(tǒng)計
第一代架構(gòu) 基于抽取的元數(shù)據(jù)
下圖描述了第一代元數(shù)據(jù)架構(gòu)。它通常是一個經(jīng)典的單體前端（可能是一個 Flask 應(yīng)用程序），連接到主要存儲進(jìn)行查詢（通常是 MySQL/POSTGRes），一個用于提供搜索查詢的搜索索引（通常是 Elasticsearch），并且對于這種架構(gòu)的第 1.5 代，也許一旦達(dá)到關(guān)系數(shù)據(jù)庫的“遞歸查詢”限制，就使用了處理譜系（通常是 Neo4j）圖形查詢的圖形索引。

數(shù)據(jù)治理實踐：元數(shù)據(jù)管理架構(gòu)的演變
元數(shù)據(jù)通常通過連接到元數(shù)據(jù)源（如Hive 、Kafka ）使用查詢方式攝取，這種方式通常是單個進(jìn)程（非并行），每天運(yùn)行一次左右。
該架構(gòu)的稍微高級的版本還將允許批處理作業(yè)（例如，Spark 作業(yè)），然后將此元數(shù)據(jù)加載到存儲和索引中。

優(yōu)點(diǎn)
架構(gòu)簡單，只需一個存儲、一個搜索引擎，就可以快速聚合元數(shù)據(jù)并構(gòu)建一個應(yīng)用程序，使數(shù)據(jù)工作者提高工作效率。
由于架構(gòu)簡單，我們需要的開發(fā)人員成本也是很低的。

缺點(diǎn)
抽取元數(shù)據(jù)的性能壓力。什么時候去抽取元數(shù)據(jù)，跑多久，用多少負(fù)載？這些問題估計讓運(yùn)維團(tuán)隊很頭疼。隨之導(dǎo)致的就是暫停抽取，或者隔幾天抽取，元數(shù)據(jù)也就變得越來越陳舊。
實時性。剛開始的時候，每天跑一次元數(shù)據(jù)爬取似乎沒有問題。但是實時計算的興起讓數(shù)據(jù)的實時性要求越來越高，這種架構(gòu)就不再適用了。
Amundsen擁有第一代架構(gòu)，他側(cè)重在實現(xiàn)搜索排名的功能，這一部分非常的強(qiáng)大。
第二代架構(gòu)：帶有服務(wù) API 的三層應(yīng)用
很快，我們找到了第二代的架構(gòu)升級。單體應(yīng)用程序已拆分為位于元數(shù)據(jù)存儲數(shù)據(jù)庫前面的服務(wù)。該服務(wù)提供了一個 API，允許使用推送機(jī)制將元數(shù)據(jù)寫入系統(tǒng)，需要以編程方式讀取元數(shù)據(jù)的程序可以使用此 API 讀取元數(shù)據(jù)。

數(shù)據(jù)治理實踐：元數(shù)據(jù)管理架構(gòu)的演變

優(yōu)點(diǎn)
提供基于推送的模式，可以立即在元數(shù)據(jù)生產(chǎn)者和元數(shù)據(jù)服務(wù)之間建立聯(lián)系。當(dāng)然還是需要元數(shù)據(jù)的實時推送，
實時性得以解決。實時的推送讓元數(shù)據(jù)的實時性得到非常大的提高。

缺點(diǎn)
沒有日志。當(dāng)出現(xiàn)問題時，很難可靠地引導(dǎo)（重新創(chuàng)建）或修復(fù)您的搜索和圖形索引。

第二代元數(shù)據(jù)系統(tǒng)通?？梢猿蔀楣緮?shù)據(jù)資產(chǎn)的可靠搜索和發(fā)現(xiàn)門戶，它們確實滿足了數(shù)據(jù)工作者的需求，Marquez擁有第二代元數(shù)據(jù)架構(gòu)。

第三代架構(gòu)：基于事件的元數(shù)據(jù)

第 1 步：面向日志的元數(shù)據(jù)架構(gòu)
元數(shù)據(jù)提供者可以實時推送或基于 API推送元數(shù)據(jù)變化日志。

日志是元數(shù)據(jù)領(lǐng)域的中心，如果出現(xiàn)任何不一致，您可以隨意引導(dǎo)圖形索引或搜索索引，并確定性地修復(fù)錯誤。

數(shù)據(jù)治理實踐：元數(shù)據(jù)管理架構(gòu)的演變

第 2 步：面向領(lǐng)域的解耦元數(shù)據(jù)模型
強(qiáng)類型元數(shù)據(jù)模型和關(guān)系。這種建模使團(tuán)隊能夠通過添加特定領(lǐng)域的擴(kuò)展來改進(jìn)全局元數(shù)據(jù)模型。

數(shù)據(jù)治理實踐：元數(shù)據(jù)管理架構(gòu)的演變

好處
客戶可以根據(jù)他們的需要以不同的方式與元數(shù)據(jù)數(shù)據(jù)庫交互。
元數(shù)據(jù)的低延遲查找、對元數(shù)據(jù)屬性進(jìn)行全文和排名搜索的能力、對元數(shù)據(jù)關(guān)系的圖形查詢以及全掃描和分析能力。
下圖顯示了該架構(gòu)的完全實現(xiàn)版本：

數(shù)據(jù)治理實踐：元數(shù)據(jù)管理架構(gòu)的演變

缺點(diǎn)
組件分散。運(yùn)維難度也就成倍的提高。
我們調(diào)查過的所有系統(tǒng)中，擁有第三代元數(shù)據(jù)架構(gòu)的系統(tǒng)是 Altas 和DataHub。
Apache Atlas 與Hadoop 生態(tài)系統(tǒng)緊密耦合。一些公司正在嘗試將Amundsen附加在Atlas之上試圖獲得兩全其美，但這種整合似乎存在一些挑戰(zhàn)。例如，您必須攝取元數(shù)據(jù)并將其存儲在 Atlas 的圖形和搜索索引中，完全繞過 Amundsen 的數(shù)據(jù)攝取、存儲和索引模塊。這意味著您想要建模的任何新概念都需要作為 Atlas 概念引入，然后與 Amundsen 的 UI 橋接，從而導(dǎo)致相當(dāng)多的復(fù)雜性。