十年前，當我在 LinkedIn 開始我的旅程時，該公司剛剛開始經曆資料量、種類和速度的極端增長。在接下來的幾年裡，我和 LinkedIn 資料基礎設施團隊的同僚們建構了如 Espresso、Databus 和 Kafka 等基礎技術，以確定 LinkedIn 在下一波增長中生存和繁榮。幾年後，我成為當時規模相當小的“資料分析基礎設施”團隊的技術負責人，該團隊運作并支援 LinkedIn 的 Hadoop 使用，還維護了一個橫跨 Hadoop 和 Teradata 的混合資料倉庫。
我首先注意到的一件事是，人們詢問用于分析的“正确的資料集”的頻率有多高。這讓我意識到，盡管我們已經建構了高度可擴充的專用資料存儲、流式處理能力和經濟高效的批處理計算能力，但我們仍然在浪費時間尋找正确的資料集來執行分析。
資料發現：一個問題，多個解決方案
時至今日，我們正生活在資料的黃金時代。當資料科學家加入資料驅動型公司時，他們希望找到一種資料發現工具（即資料目錄），可以用來找出公司中存在哪些資料集，以及如何使用這些資料集來測試新假設和産生新見解。大多數資料科學家并不真正關心這個工具在幕後是如何工作的，隻要它能使他們富有成效。
事實上，有許多可用的資料發現解決方案：可直接購買的專有軟體、特定公司提供的開源軟體和内部建構的軟體等等。在過去幾年中，LinkedIn、Airbnb、Lyft、Spotify、Shopify、Uber 和 Facebook 都分享了各自資料發現解決方案的詳細資訊。這就引出了一個問題：這些平台各有哪些不同，對于考慮采用其中一種工具的公司來說，哪種選擇是最好的？
資料目錄的架構将影響組織能夠從資料中真正提取多少價值。而且，目錄工作是非常棘手的，需要很長時間才能在公司中內建和實施。是以，仔細選擇資料發現解決方案非常重要。
在這篇文章中，我将描述業界迄今為止資料發現工具的三代架構，并說明許多知名的資料發現工具在這其中的位置。LinkedIn 資料中心架構的演變也反映了代際間的這種進步，因為我們推動了最新的最佳實踐（首先是開源的，并在2016年作為 WhereHows 與世界共享，然後在2019年作為 DataHub 完全重寫并與開源社群重新共享）。
希望本文能幫助您在選擇自己的資料發現解決方案時做出最佳決策。
什麼是資料目錄
在深入研究不同的架構之前，讓我們先整理一下定義。我找到的資料目錄最簡單的定義之一來自 Oracle 網站：
簡單地說，資料目錄是組織中資料資産的有組織的清單。它使用中繼資料幫助組織管理其資料。它還幫助資料專業人員收集、組織、通路和豐富中繼資料，以支援資料發現和治理。
30年前，資料資産很可能是Oracle資料庫中的表。然而，在現代企業中，我們擁有一系列令人眼花缭亂的不同類型的資産，這些資産構成了整個景觀：關系資料庫或 NoSQL 存儲中的表、流式存儲中的流、AI系統中的功能、名額平台中的名額、可視化工具中的儀表盤等等。現代資料目錄預計将包含所有此類資料資産的清單，并使資料工作者能夠更高效地使用這些資産完成工作。
為什麼你需要一個目錄？
在您決定購買或采用特定的資料目錄解決方案或建構自己的解決方案之前，您應該首先詢問您希望通過資料目錄為您的企業實作哪些功能。一個相關且重要的問題涉及您希望在資料目錄中存儲何種中繼資料，因為這直接影響您可以啟用的用例的類型。
以下是一些常見的用例以及它們所需的中繼資料類型的示例：
- 搜尋和發現：資料模式、字段、标記、使用資訊
- 通路控制：通路控制組、使用者、政策
- 資料血緣：管道執行、查詢、API日志、API模式
- 合規性：資料隐私/合規性标注類型的分類（資料分級分類）
- 資料管理：資料源配置、接入配置、保留配置、資料清除政策（例如，對于GDPR“被遺忘的權利”）、資料導出政策（例如，對于GDPR“通路權”）
- AI可解釋性、再現性：特征定義、模型定義、訓練執行、問題陳述
- 資料操作：管道執行、資料分區處理、資料統計
- 資料品質：資料品質規則定義、規則執行結果、資料統計
一個有趣的觀察結果是，每個用例通常都會有自己的特殊中繼資料需求，但也需要關聯到其他用例帶來的現有中繼資料。在深入研究這些資料目錄的不同架構及其對您的成功的影響時，我們會再回顧這一觀點。
第一代架構：單體架構
下圖描述了第一代中繼資料架構。它通常是一個經典的單體的前端（可能是一個Flask應用程式），連接配接到一個主存儲以進行查找（通常是 MySQL/Postgres），一個用于服務搜尋查詢的搜尋索引（通常是 Elasticsearch），對于該體系結構的第1.5代，當您達到關系資料庫“遞歸查詢”的極限時，可以使用圖形索引來處理資料血緣（通常是Neo4j）的圖形查詢。
第一代體系結構：基于拉取的ETL
中繼資料通常使用爬取方法（crawling approach）接入，方法是連接配接到中繼資料源，如資料庫目錄、Hive 目錄、Kafka 模式系統資料庫或工作流編排器的日志檔案，然後将此中繼資料寫入主存儲，将需要索引的部分添加到搜尋索引和圖形索引中。這種爬取通常是一個單程序（非并行），每天運作一次左右。在爬行和攝取過程中，通常會将原始中繼資料轉換為應用程式的中繼資料模型，因為資料很少以目錄所需的确切形式存在。通常，此轉換直接嵌入到接入作業中。
此體系結構的更進階版本還允許批處理作業（例如Spark作業）大規模進行中繼資料、計算關系、建議等，然後将此中繼資料加載到存儲和索引中。
通常需要兩名工程師兩周左右的時間來建立這個基本後端架構的第一個原型并将資料加載到其中。另外，建立一個簡單的前端可能需要幾周的時間，該前端可以顯示中繼資料并支援簡單的搜尋。
優點
以下是這種架構的優點。
- 可動部件很少：隻需一個查找存儲、一個搜尋索引和幾個爬蟲程式，就可以快速聚合中繼資料并建構一個有用的應用程式，使資料工作者高效工作。要證明這一點，你不需要很多基礎設施。
- 一個團隊可以做很多事情：該架構面向一個團隊，該團隊能夠通路中繼資料源，并可以建構一個應用程式來為其服務。
缺點
然而，這種體系結構确實存在一些問題。我将突出顯示前兩個。
- 推送還是拉取：雖然使用爬取資料源作為一種收集中繼資料并将其聚合到單一位置的方法很容易開始，但很快這些接入管道就開始顯示出脆弱的迹象。爬蟲程式在與資料源不同的環境中運作，其配置需要由中央團隊單獨管理。是以，這些管道中的其中一組問題是操作障礙，如網絡連接配接（防火牆規則）或憑據共享（密碼可以在不通知中央團隊的情況下更改）。
另一組問題更微妙，但本質上也是可操作的。基于爬行的攝取通常會導緻工作負載失常（您多久調用一次源？）和非增量（我們應該在一次拉取中檢索多少條記錄？）。這使得資料源的操作團隊非常不高興，因為沒有人喜歡在午夜被一個快融化資料庫或一個無法響應的HDFS NAMENODE吵醒，并發現它是呱呱叫的，因為中繼資料爬蟲已經把它翻到了邊緣。這類操作問題的第一個受害者通常是中繼資料爬蟲管道，不管它是否真正負責！您的中繼資料攝取管道将暫停，當操作團隊緻力于使您的系統恢複健康時，他們通常會要求中繼資料爬蟲在較長時間内保持暫停，即使系統已恢複正常。同時，中繼資料變得“越來越陳舊”，導緻對目錄的信任度降低。這就引出了第二個問題。
- 中繼資料新鮮度：與推送與拉取決策密切相關的是資料（或者在本例中是中繼資料）新鮮度問題。在中繼資料之旅的開始，每晚抓取一次Hive中繼資料庫并填充目錄似乎是完全可以的。畢竟，你隻是想讓資料科學家比以前更有效率。但是，一旦您開始進入資料建立工作流（例如，一旦您建立了一些資料，您就可以到這裡來提供資料分類标簽）或提供操作中繼資料（例如，最新分區的資料品質清單），那麼中繼資料的新鮮度就開始變得更加重要。如果您隻是有一個基于爬蟲的中繼資料目錄，那麼在這一點上，您大部分都是運氣不佳的。
這對我意味着什麼？
作為一名讀者，你可能會想，“那麼，第一代中繼資料系統是什麼？” Amundsen 采用了這種體系結構，正如我們在2016年開源的 WhereHows 的原始版本一樣。在内部系統中，Spotify 的 Lexikon、Shopify 的 Artifact 和Airbnb 的 Dataportal 也采用了相同的體系結構。
這些系統在提高人類對資料的利用效率方面發揮着重要作用，但在保持高保真資料清單和啟用中繼資料的程式設計用例方面可能會遇到困難。
第二代架構：具有服務API的三層應用程式
下圖描述了我将其歸類為第二代中繼資料架構的内容。單體應用程式已拆分為一個位于中繼資料存儲資料庫前面的服務。該服務提供了一個API，允許使用推送機制将中繼資料寫入系統，需要以程式設計方式讀取中繼資料的程式可以使用該API讀取中繼資料。但是，通過該API通路的所有中繼資料仍然存儲在單個中繼資料存儲中，可以是單個關系資料庫或擴充的鍵值存儲。
第二代架構：帶推送API的服務
讓我們來談談這種進化帶來的好處。
- 更好的契約會帶來更好的結果：提供基于推送的模式化接口可以立即在中繼資料生産者和“中央中繼資料團隊”之間建立良好的契約。您仍然需要說服生産團隊發出中繼資料并擷取依賴關系，但使用商定的模式更容易做到這一點。
- 已啟用的程式設計用例：通過服務API，中央團隊最終可以為中繼資料啟用程式設計用例。例如，如果您的資料門戶應用允許使用指定字段語義類型（例如，電子郵件位址、客戶辨別符）的标記對資料集和字段進行标記，并将該資訊存儲在中繼資料系統中，您的資料管理基礎架構可以開始使用此中繼資料自動删除已請求忘記權限的客戶ID的資料資産，或自動為資料科學家建立這些資料集的假名版本。事實上，在LinkedIn上，我們使用 Apache Gobblin 來實作這一點，由DataHub的中繼資料驅動。
然而，該架構仍然存在一些值得強調的問題。
- 沒有變更日志：第二代體系結構提供了用于讀取和寫入中繼資料的基于微服務的API，但沒有内置支援通過流式方式從外部系統将變更傳輸到中繼資料，或提供發生在資料目錄上的中繼資料變更流的訂閱。
您可能熟悉這篇關于為什麼日志應該是資料生态系統的核心的
流行博文。事實證明，中繼資料也是如此。現代資料目錄應該能夠實時訂閱中繼資料中的更改，這是一流的服務。
如果沒有中繼資料日志，當出現問題時，很難可靠地引導（重新建立）或修複搜尋和圖形索引。如果沒有實時中繼資料更改日志，也不可能在中央中繼資料平台上建構高效的反應式系統，如資料觸發器或通路控制濫用檢測系統。要建構類似的内容，您将被迫通過過度輪詢或完全掃描使用鍵值API通路中繼資料。或者，您需要等待中繼資料資料庫的夜間ETL最終能夠處理快照。我們在資料方面經曆了痛苦的旅程，我們真的想跳過它來擷取中繼資料！然而，現代中繼資料系統常常忘記為這一重要功能進行設計。
- 集中化團隊的問題：這種體系結構的另一個大問題是，它在很多事情上仍然依賴于一個集中的團隊：擁有中繼資料模型、運作中央中繼資料服務、資料存儲和索引、支援所有下遊消費者以及他們希望通路中繼資料的不同方式。這嚴重限制了中央系統為公司中存在的各種用例（生産力、治理、人工智能可解釋性等）提供動力的能力。例如，在LinkedIn，當我們還處于中繼資料體系結構的第二代時，我們讓資料品質團隊建構一個單獨的UI和中繼資料存儲，以存儲規則并在資料集上顯示資料品質結果。
基于服務的內建帶來的的操作影響還導緻生産者和中心服務的可用性緊密耦合，這使得采用者擔心在他們的堆棧中再增加一個停機源。
中央中繼資料團隊遇到的問題與中央資料倉庫團隊遇到的問題相同。
資料工程本身正在演變為一種不同的模式，去中心化正在成為常态。是以，中央中繼資料團隊在試圖成功地跟上中繼資料生态系統快速發展的複雜性時，不應該犯同樣的錯誤。
在商業中繼資料系統中，Collibra 和 Alation 似乎具有第二代架構。在開源中繼資料系統中，Marquez 擁有第二代中繼資料架構。
我的經驗是，第二代中繼資料系統通常可以成為公司資料資産的可靠搜尋和發現門戶，是以它們确實滿足了資料工作者的生産力需求。他們還可以開始提供基于服務的內建到程式設計工作流中，如通路控制配置。實際上，當我們通過添加一個基于推送的架構和一個專門建構的用于存儲和檢索中繼資料的服務，将 WhereHows 從第1代發展到第2代時，我們經曆了這一過程。
然而，集中化瓶頸通常會導緻為不同的用例建構或采用新的、獨立的目錄系統，這會削弱單個一緻中繼資料圖的功能。為資料科學家建構或采用搜尋和發現門戶的公司有時也會為其業務部門安裝不同的資料治理産品，并擁有自己的中繼資料後端。為了保持資料集定義和術語表的同步，這些公司必須建構和監控新的資料管道，以可靠地複制中繼資料，這些中繼資料使用不同的中繼資料模型從一個目錄複制到另一個目錄。這一問題不僅限于大公司，還可能影響到任何已經達到一定資料素養水準并啟用了中繼資料的各種用例的組織。
第三代架構：源自事件的中繼資料
導緻第三代中繼資料體系結構的關鍵洞察是，基于“中心服務”的中繼資料解決方案難以跟上企業對中繼資料用例的要求。要解決這個問題，必須滿足兩個需求。第一個是中繼資料本身需要自由流動、基于事件且可實時訂閱。第二個是中繼資料模型必須支援不斷演化，因為新的擴充和添加突然出現，而不會被中央團隊阻止。這将允許多種類型的使用者在一定範圍内始終可以使用和豐富中繼資料。
步驟1：面向日志的中繼資料架構
中繼資料提供者可以推送到基于流的API，或者對目錄的服務 API 執行 CRUD 操作，具體取決于它們的首選項。中繼資料的結果突變将反過來生成中繼資料變更日志。該中繼資料日志可以為所有需要的查詢模式自動準确地具體化為适當的存儲和索引（例如，搜尋索引、圖形索引、資料湖、OLAP 存儲）。這導緻了一個為現代企業準備好的非綁定中繼資料資料庫體系結構，如下圖所示。既然日志是中繼資料世界的中心，那麼在出現任何不一緻的情況下，您可以随意引導圖形索引或搜尋索引，并确定地修複錯誤。
第三代架構：非綁定中繼資料資料庫
步驟2：面向領域的解耦中繼資料模型
除了流優先體系結構之外，第三代目錄還支援企業協作定義可擴充的強類型中繼資料模型和關系。強類型很重要，因為如果沒有強類型，我們将得到存儲在中繼資料存儲中的通用屬性包的最小公分母。這使得中繼資料的程式設計使用者無法在任何向後相容性保證的情況下進行中繼資料。
在下面的中繼資料模型圖中，我們使用DataHub的實體類型、方面和關系術語來描述包含三種實體的圖：資料集、使用者群組。不同的團隊可以将所有權、配置檔案等不同方面附加到這些實體，進而在這些實體類型之間建立關系。請注意，可以有多種方法來描述這些圖形模型，從基于RDF的模型到全面的ER模型，再到定制的混合方法，如DataHub使用的方法。
中繼資料模型圖示例：類型、方面、關系
這種模組化使團隊能夠通過添加特定于領域的擴充來發展全局中繼資料模型，而不會受到中心團隊的限制。例如，合規性團隊可能簽入所有權方面，而核心中繼資料團隊可能簽入資料集實體的模式方面。同時，資料接入團隊可能為資料集實體設計并簽入副本配置方面。所有這些添加到模型中的操作都可以獨立進行，隻需最小的沖突點。當然，在我們将核心實體類型引入到圖中之前，需要對其進行管理并達成一緻。
通過這一演變，用戶端可以根據需要以不同的方式與中繼資料資料庫進行互動。他們可以獲得基于流的中繼資料日志（用于接入和消費變更）、中繼資料的低延遲查找、對中繼資料屬性進行全文和排名搜尋的能力、中繼資料關系的圖形查詢以及完整掃描和分析功能。可以在此中繼資料流之上建構對核心中繼資料模型具有不同擴充的不同用例和應用程式，而不會犧牲一緻性或新鮮度。您還可以将此中繼資料與開發人員工具（如git）內建，方法是将此中繼資料與代碼一起編寫和版本化。可以通過在低延遲下進行中繼資料變更日志，或者通過将壓縮的中繼資料日志作為資料湖上的表進行批處理，來實作中繼資料的細化和豐富。
下圖顯示了此體系結構的完全實作版本：
第三代架構：端到端資料流
任何全局企業中繼資料需求（如全局生命周期管理、審計或合規性）都可以通過建構以流形式或批處理形式查詢此全局中繼資料的工作流來解決。
“好的中繼資料架構”與“好的資料架構”驚人地相似。
良好的第三代中繼資料體系結構實作的典型标志是，您始終能夠以最詳細的形式閱讀最新的中繼資料并對其采取行動，而不會丢失一緻性。當我們在 LinkedIn 從 WhereHows（第2代）過渡到 DataHub（第3代）時，我們發現我們能夠極大地提高對中繼資料的信任，進而使中繼資料系統成為企業的中心。随着資料工作者研究新假設、發現新名額、管理現有資料資産的生命周期等，DataHub 現在正逐漸成為他們的起點。
先進往往與複雜相伴而生。第三代中繼資料系統通常會有一些活動部件，需要對這些部件進行設定，才能使整個系統正常運作。擁有少量資料工程師的公司可能會發現，他們對開始一個簡單用例所需的工作量感到厭煩，并懷疑在時間和精力上的初始投資是否值得長期回報。然而，像 DataHub 這樣的第三代中繼資料系統開始在可用性和開箱即用的體驗方面取得巨大進步，以確定不會發生這種情況。
在我們調查過的所有系統中，隻有 Apache Atlas、Egeria、Uber Databook 和 DataHub 具有第三代中繼資料體系結構。其中，ApacheAlas 與 Hadoop 生态系統緊密耦合。一些公司正在嘗試将 Amundsen 與 Atlas 相結合，以期在這兩個世界中取得最佳效果，但這種整合似乎存在一些挑戰。例如，您必須攝取中繼資料并将其存儲在Atlas 的圖形和搜尋索引中，完全繞過 Amundsen 的資料攝取、存儲和索引子產品。這意味着您要模組化的任何新概念都需要作為 Atlas 概念引入，然後與 Amundsen 的 UI 連接配接起來，進而導緻相當多的複雜性。Egeria 支援通過中繼資料事件總線內建不同的目錄，但在撰寫本文時，它的功能似乎還不完整。Uber Databook 似乎基于與DataHub 非常相似的設計原則，但不是開源的。當然，由于我們對 DataHub 的個人經驗，我們有偏見，但開源 DataHub 提供了第三代中繼資料系統的所有好處，能夠支援多種類型的實體和關系，并具有流優先架構。
在LinkedIn，DataHub 的部署包括資料集、模式、流、合規性注釋、GraphQL 端點、名額、儀表盤、特征和AI模型，使其在規模和戰備能力方面真正成為第三代。它每天例行處理超過 1000 萬個實體和關系更改事件，總計索引 500 多萬個實體和關系，同時以低毫秒級 SLA 服務于操作中繼資料查詢，為所有員工實作資料生産效率、合規性和治理工作流。
下面是目前中繼資料環境的簡單可視化表示。
當然，這隻是目前不同系統所在位置的快照。随着企業對中繼資料需求的不斷增長，第3代系統中可能會有進一步的整合和更新。
一個好的架構就足夠了嗎？
看來，通過DataHub實作的第三代體系結構，我們已經獲得了一個良好的中繼資料體系結構，它是可擴充的，并且很好地服務于我們的許多用例。這方面還有其他問題需要解決嗎？簡單的回答是“是的”。第三代中繼資料體系結構確定您能夠以最具可擴充性和靈活性的方式內建、存儲和進行中繼資料。但這還不夠。
讓中繼資料發揮作用比把中繼資料放在一起更難。
你首先需要定義正确的中繼資料模型，以真正捕獲對企業有意義的概念。然後，您需要一個從完整、可靠的資料資産清單過渡到可信的中繼資料知識圖的支援 AI 的路徑。這将允許您真正解鎖企業的生産力和治理。
原文連結