前言
近幾年來資料的量級在瘋狂的增長，由此帶來了系列的問題。作為對人工智慧團隊的資料支撐，我們聽到的最多的質疑是 “正確的資料集”，他們需要正確的資料用於他們的分析。我們開始意識到，雖然我們構建了高度可擴充套件的資料儲存，實時計算等等能力，但是我們的團隊仍然在浪費時間尋找合適的資料集來進行分析。
也就是我們缺乏對資料資產的管理。事實上，有很多公司都提供了開源的解決方案來解決上述問題，這也就是資料發現與後設資料管理工具，
在這篇文章中，我將描述行業迄今為止後設資料管理的三代架構，
希望本文能幫助您在選擇自己的資料治理解決方案時做出最佳決策。
什麼是後設資料管理？
簡單地說，後設資料管理是為了對資料資產進行有效的組織。它使用後設資料來幫助管理他們的資料。它還可以幫助資料專業人員收集、組織、訪問和豐富後設資料，以支援資料治理。
三十年前，資料資產可能是 Oracle 資料庫中的一張表。然而，在現代企業中，我們擁有一系列令人眼花繚亂的不同型別的資料資產。可能是關聯式資料庫或 NoSQL 儲存中的表、實時流資料、 AI 系統中的功能、指標平臺中的指標，資料視覺化工具中的儀表板。
現代後設資料管理應包含所有這些型別的資料資產，並使資料工作者能夠更高效地使用這些資產完成工作。
所以，後設資料管理應具備的功能如下：
- 搜尋和發現：資料表、欄位、標籤、使用資訊
- 訪問控制：訪問控制組、使用者、策略
- 資料血緣：管道執行、查詢
- 合規性：資料隱私/合規性註釋型別的分類
- 資料管理：資料來源配置、攝取配置、保留配置、資料清除策略
- AI 可解釋性、再現性：特徵定義、模型定義、訓練執行執行、問題陳述
- 資料操作：管道執行、處理的資料分割槽、資料統計
- 資料質量：資料質量規則定義、規則執行結果、資料統計
第一代架構 基於抽取的後設資料
下圖描述了第一代後設資料架構。它通常是一個經典的單體前端（可能是一個 Flask 應用程式），連線到主要儲存進行查詢（通常是 MySQL/Postgres），一個用於提供搜尋查詢的搜尋索引（通常是 Elasticsearch），並且對於這種架構的第 1.5 代，也許一旦達到關聯式資料庫的“遞迴查詢”限制，就使用了處理譜系（通常是 Neo4j）圖形查詢的圖形索引。
後設資料通常通過連線到後設資料源（如Hive 、Kafka ）使用查詢方式攝取，這種方式通常是單個程式（非並行），每天執行一次左右。
該架構的稍微高階的版本還將允許批處理作業（例如，Spark 作業），然後將此後設資料載入到儲存和索引中。
優點
架構簡單，只需一個儲存、一個搜尋引擎，就可以快速聚合後設資料並構建一個應用程式，使資料工作者提高工作效率。
由於架構簡單，我們需要的開發人員成本也是很低的。
缺點
抽取後設資料的效能壓力。什麼時候去抽取後設資料，跑多久，用多少負載？這些問題估計讓運維團隊很頭疼。隨之導致的就是暫停抽取，或者隔幾天抽取，後設資料也就變得越來越陳舊。
實時性。剛開始的時候，每天跑一次後設資料爬取似乎沒有問題。但是實時計算的興起讓資料的實時性要求越來越高，這種架構就不再適用了。
Amundsen擁有第一代架構，他側重在實現搜尋排名的功能，這一部分非常的強大。
第二代架構：帶有服務 API 的三層應用
很快，我們找到了第二代的架構升級。單體應用程式已拆分為位於後設資料儲存資料庫前面的服務。該服務提供了一個 API，允許使用推送機制將後設資料寫入系統，需要以程式設計方式讀取後設資料的程式可以使用此 API 讀取後設資料。
優點
提供基於推送的模式，可以立即在後設資料生產者和後設資料服務之間建立聯絡。當然還是需要後設資料的實時推送，
實時性得以解決。實時的推送讓後設資料的實時性得到非常大的提高。
缺點
沒有日誌。當出現問題時，很難可靠地引導（重新建立）或修復您的搜尋和圖形索引。
第二代後設資料系統通常可以成為公司資料資產的可靠搜尋和發現門戶，它們確實滿足了資料工作者的需求，Marquez擁有第二代後設資料架構。
第三代架構：基於事件的後設資料
第 1 步：面向日誌的後設資料架構
後設資料提供者可以實時推送或基於 API推送後設資料變化日誌。
日誌是後設資料領域的中心，如果出現任何不一致，您可以隨意引導圖形索引或搜尋索引，並確定性地修復錯誤。
第 2 步：面向領域的解耦後設資料模型
強型別後設資料模型和關係。這種建模使團隊能夠通過新增特定領域的擴充套件來改進全域性後設資料模型。
好處
客戶可以根據他們的需要以不同的方式與後設資料資料庫互動。
後設資料的低延遲查詢、對後設資料屬性進行全文和排名搜尋的能力、對後設資料關係的圖形查詢以及全掃描和分析能力。
下圖顯示了該架構的完全實現版本：
缺點
元件分散。運維難度也就成倍的提高。
我們調查過的所有系統中，擁有第三代後設資料架構的系統是 Altas 和DataHub。
Apache Atlas 與Hadoop 生態系統緊密耦合。一些公司正在嘗試將Amundsen附加在Atlas之上試圖獲得兩全其美，但這種整合似乎存在一些挑戰。例如，您必須攝取後設資料並將其儲存在 Atlas 的圖形和搜尋索引中，完全繞過 Amundsen 的資料攝取、儲存和索引模組。這意味著您想要建模的任何新概念都需要作為 Atlas 概念引入，然後與 Amundsen 的 UI 橋接，從而導致相當多的複雜性。
下圖是當今後設資料格局的簡單直觀表示：
（包含部分非開源方案）
大資料治理方案如何選擇？後設資料管理如何落地？
未來我們會更新更多大資料治理相關技術與實踐方案。歡迎關注 大資料流動
