DataPipeline：Data Hub—LinkedIn

作者：Mars?Lan,?Seyi Adebajo,?Shirshanka Das

譯者：?張雅然

作為全球最大的職場社交平臺，LinkedIn的數據團隊不斷致力于擴展其基礎架構，以滿足不斷增長的大數據生態系統需求。隨著數據量和豐富度的增長，對數據科學家和工程師而言：發現數據資產，理解它們的來源并基于這些見解采取適當的行動變得愈發具有挑戰。

為了在數據增長的同時繼續擴展數據的生產力和創新力，我們創建了一個通用的元數據搜索和發現工具Data Hub。

一、擴展元數據

為提高LinkedIn數據團隊的工作效率，我們之前開發并開源了WhereHows，一個中央元數據存儲庫和數據集門戶。存儲的元數據類型包括技術元數據（例如，位置、模式、分區、所有權）和過程元數據（例如，沿襲、作業執行、生命周期信息）。WhereHows還有一個搜索引擎，以幫助定位感興趣的數據集。?

自2016年最初發布WhereHows以來，業界對通過使用元數據來提高數據科學家生產力的關注度越來越高。例如，在這個領域開發的工具包括AirBnb的Dataportal，Uber的Databook，Netflix的Metacat，Lyft的Amundsen以及最近Google的Data Catalog。在LinkedIn，我們也一直在忙于擴展我們的元數據收集范圍，以便在保持公平性、隱私性和透明度的同時為新用例提供支持。但是，我們開始意識到WhereHows無法滿足我們不斷變化的元數據需求。以下是我們從擴展WhereHows中得到的經驗總結：

1. 推比拉更好
雖然直接從源中提取元數據似乎是收集元數據最直接的方式，但開發和維護很快就會成為一場噩夢。讓各個元數據提供者通過API或消息將信息推送到中央存儲庫的方式更具可擴展性。這種基于推送的方法還可確保更及時地反映新的和更新的元數據。
2. 通用比具體更好?WhereHows對數據集或作業的元數據應該是什么樣子有著強烈意見。這就導致出現固定的API、數據模型和存儲格式，一旦對元數據模型有微小地更改將導致堆棧上下的級聯更改。如果我們設計一個通用的體系結構，該結構不受存儲和服務的元數據模型的影響，那將更具可擴展性。這反過來將使我們能夠專注于發展適合我們業務的元數據模型，而不必擔心堆棧的較低層。
3. 在線與離線同樣重要

一旦收集了元數據，就很自然地想要分析元數據以獲得價值。一個簡單的解決方案是將所有元數據轉儲到離線系統，如Hadoop，可以執行任意分析。但是，我們很快發現僅僅支持離線分析是不夠的。例如訪問控制和數據隱私處理，必須在線查詢最新的元數據。

4.?關系扮演重要角色

元數據通常傳達重要的關系（例如，血統，所有權和依賴關系），這些關系能夠實現強大的功能，如影響分析，數據匯總，更好的搜索相關性等。將所有這些關系建模為最重要的組件并支持對它們進行有效地分析查詢是非常重要的。?

5. 多中心化

我們意識到僅僅圍繞單個實體（數據集）建模元數據是不夠的。整個生態系統的數據，代碼和角色實體（數據集，數據科學家，團隊，代碼，微服務API，指標，AI功能，AI模型，儀表板，筆記本等）都需要集成到元數據地圖。

二、一起了解下Data Hub

大約一年前，我們根據這些知識從頭開始設計WhereHows。我們意識到LinkedIn越來越需要跨各種數據實體的統一的搜索和發現體驗，以及將它們連接在一起的元數據圖。因此，我們決定擴大項目范圍，構建一個完全通用的元數據搜索和發現工具Data Hub，其雄心勃勃的愿景是：將LinkedIn員工與對他們至關重要的數據聯系起來。?

我們將單片WhereHows堆棧分成兩個不同的堆棧：模塊化UI前端和通用元數據架構后端。新架構使我們能夠快速擴展元數據收集范圍，而不僅僅是數據集和作業。在撰寫本文時，Data Hub已經存儲并索引數千萬條元數據記錄，這些記錄包含19個不同的實體，包括數據集，指標，作業，圖表，AI功能，人員和組。我們還計劃在不久的將來在機器學習模型和標簽，實驗，儀表板，微服務API和代碼上，發揮元數據的作用。?

三、模塊化UI

Data Hub Web應用程序是大多數用戶與元數據交互的方式。該應用程序用Ember Framework編寫，運行在Play中間層上。為了使開發具有可擴展性，我們充分利用各種現代化的網絡技術，包括ES9，ES.Next，TypeScript, Yarn以及 Prettier和 ESLint這樣的代碼質量工具。展現層，控制層和數據層被模塊化為包，以便應用程序中的特定視圖由相關包組合構建。?

?組件服務框架
在應用模塊化UI基礎架構時，我們將Data Hub Web應用程序構建為一系列為了完成業務的組件，這些組件分組為可安裝的軟件包。該軟件包架構在基礎上使用了Yarn Workspaces和Ember附加組件，并使用Ember的組件和服務進行組件化。您可以將此視為使用小型構建塊（即組件和服務）構建的UI，以創建更大的構建塊（即Ember附加組件和npm / Yarn軟件包），這些構建塊組合在一起最終構成Data Hub Web應用程序。
將組件和服務作為應用程序的核心，該框架允許我們分離不同的方面并將應用程序中的其他功能組合在一起。此外，每一層的分段提供了一個非常可定制的架構，允許消費者擴展或簡化其應用程序，以便僅利用與其領域相關的功能或構建新的元數據模型。?與Data Hub交互

在最高級別，前端提供三種類型的交互：（1）搜索，（2）瀏覽，（3）查看/編輯元數據。以下是一些實際應用的截圖（點開看更清晰哦）

Data Hub應用截圖

與典型的搜索引擎體驗類似，用戶可以通過提供關鍵字列表來搜索一種或多種類型的實體。他們可以通過篩選一系列方面來進一步實現結果。高級用戶還可以使用OR，NOT和regex等運算符來執行復雜搜索。
Data Hub中的數據實體可以以樹狀方式組織和瀏覽，其中每個實體都允許出現在樹中的多個位置。這使用戶能夠以不同的方式瀏覽相同的目錄，例如，通過物理部署配置或業務功能組織。樹中甚至有一個專門的部分，僅顯示“經過認證的實體”，這些實體可通過單獨的治理過程進行策劃。
最終的交互視圖/編輯元數據也是最復雜的一個。每個數據實體都有一個可以顯示所有相關元數據的“配置文件頁面”，例如，數據集配置文件頁面可能包含其架構，所有權，合規性，運行狀況和沿襲元數據。它還可以顯示實體與其他實體之間的關系。對于可編輯的元數據，用戶還可以直接通過UI進行更新。?

四、通用元數據架構

為了充分實現Data Hub的愿景，我們需要一種能夠使用元數據進行擴展的架構。可擴展性挑戰有以下四種不同形式：
1. 建模：以開發人員友好的方式為所有類型的元數據和關系建模。
2. 獲取：通過API和流，大規模獲取大量元數據更改。
3. 服務：服務于收集的原始和派生元數據，以及針對元數據的各種復雜查詢。
4. 索引：大規模索引元數據，并在元數據發生更改時自動更新索引。?元數據建模

簡而言之，元數據是“?提供關于其他數據的信息的數據。”在元數據建模方面，帶來了兩個不同要求：

1. 元數據也是數據
為模擬元數據，我們需要一種通用的建模語言。
2. 元數據是分布式的
期望所有元數據來自單一來源是不現實的。例如，管理數據集的訪問控制列表（ACL）的系統很可能與存儲模式元數據的系統不同。一個好的建模框架應該允許多個團隊獨立地發展他們的元數據模型，同時呈現與數據實體相關的所有元數據的統一視圖。
我們選擇利用Pegasus，這是一種由LinkedIn創建的開放源碼和完善的數據模式語言。Pegasus專為通用數據建模而設計，因此適用于大多數元數據。但是，由于Pegasus沒有提供模型關系或關聯的明確方法，因此我們引入了一些自定義擴展來支持這些用例。
為了演示如何使用Pegasus對元數據建模，讓我們看一個簡單的例子，它由以下修改后的實體關系圖(ERD)演示。

該示例包含三種類型的實體：用戶、組和數據集，由圖中的藍色圓圈表示。我們用箭頭來表示這些實體之間的三種關系類型，即OwnedBy，HasMember和HasAdmin。換句話說，一個組由一個管理員和多個用戶組成，他們可以擁有一個或多個數據集。
?與傳統的ERD不同，我們將實體和關系的屬性分別直接放在圓圈內和關系名稱下面，以便將新類型的組件（稱為“元數據方面”）附加到實體。不同的團隊可以擁有和發展同一實體元數據的不同方面，而不會相互干擾，從而實現分布式元數據建模要求。三種類型的元數據方面：所有權，配置文件和成員資格在上面的示例中呈現為綠色矩形。虛線表示元數據方面與實體的關聯。例如，配置文件可以與用戶相關聯，且所有權可以與數據集等相關聯。
您可能已經注意到實體和關系屬性與元數據方面存在重疊，例如，User的firstName屬性應該與關聯的Profile的firstName字段相同。重復的原因將在本文的后半部分進行解釋。
以Pegasus為例，我們將每個實體，關系和元數據方面轉換為單獨的Pegasus架構文件（PDSC）。為簡單起見，我們在此僅包含每個類別的一個模型。首先，讓我們看一下用戶實體的PDSC：
每個實體都需要具有URN形式的全局唯一ID ，可以將其視為一種類型的GUID。User實體具有包括名字，姓氏和LDAP的屬性，每個屬性都映射到用戶記錄中的可選字段。
接下來是OwnedBy關系的PDSC模型：

每個關系模型自然包含“源”和“目標”字段，這些字段使用其URN指向特定實體實例。該模型可以選擇包含其他屬性字段，例如本例中的“type”。在這里，我們還引入了一個名為“pairings”的自定義屬性，以限制與特定的源和目標URN類型的關系。在這種情況下，OwnedBy關系只能用于將數據集連接到用戶。
最后，您將在下面找到Ownership 元數據方面的模型。在此，我們選擇將所有權建模為包含type和ldap字段的記錄數組。但是，只要它是有效的PDSC記錄，對于元數據方面的建模幾乎沒有限制。這令滿足先前所述的“元數據也是數據”的要求成為可能。

在創建所有模型之后，下個問題是如何將它們連接在一起以形成所提議的ERD。我們將把這個討論推遲到本文后面的元數據索引部分。
元數據獲取
Data Hub提供兩種獲取元數據的形式：直接API調用或Kafka流。前者用于需要讀寫一致性的元數據更改，后者更適用于面向事實的更新。?

Data Hub的API基于Rest.li，這是一種可擴展，強類型的RESTful服務架構，廣泛用于LinkedIn。由于Rest.li使用Pegasus作為其接口定義，因此可以逐字使用上一節中定義的所有元數據模型。從API到存儲需要多級模型轉換的日子已經成為歷史?- API和模型將始終保持同步。

對于基于Kafka的獲取，元數據生成者被期望產生一個標準化的元數據改變事件（MCE），其包含一個由相應實體URN鍵控的對特定元數據方面的建議更改列表。MCE的格式是Apache Avro，它是由Pegasus元數據模型自動生成的。
在API和Kafka事件模式中使用相同的元數據模型，使得我們可以輕松地改進模型，而無需費力地維護相應的轉換邏輯。但是，要實現真正無縫的模式演變，我們需要將所有模式更改限制為始終向后兼容。這在構建時通過添加兼容性檢查強制執行。
在LinkedIn，我們傾向于更多地依賴Kafka流，因為它在生產者和消費者之間提供了松散的耦合。我們每天都會收到來自不同制作人的數百萬個MCE，隨著擴大元數據收集的范圍，預計該數量將呈指數級增長。為了構建流式元數據提取管道，我們利用Apache Samza作為流處理框架。獲取Samza作業的目的是快速簡單地實現高吞吐量。它只是將Avro數據轉換回Pegasus并調用相應的Rest.li API來完成獲取。

元數據服務

一旦攝取存儲了元數據，就必須有效地提供原始元數據和派生元數據。Data Hub旨在支持四種常見的大量元數據查詢：

1.?面向文檔的查詢
2.?面向圖形的查詢
3.?涉及連接的復雜查詢
4.?全文檢索
為實現這一目標，Data Hub需要使用多種數據系統，每種數據系統都專門用于擴展和提供有限類型的查詢。例如，Espresso是LinkedIn的NoSQL數據庫，特別適合大規模面向文檔的CRUD。同樣，Galene可以輕松索引和提供網絡規模的全文搜索。當談到非平凡的圖形查詢時，specialized graph DB可以比RDBMS更好地執行數量級，這并不奇怪。然而，事實證明，圖結構也是表示外鍵關系的自然方式，能有效地回答復雜的連接查詢。
Data Hub通過一組通用數據訪問對象（DAO）進一步抽象底層數據系統，例如鍵值DAO，查詢DAO和搜索DAO。進而，當修改DAO的實現時，無需再更改Data Hub中的任何業務邏輯。這將使我們能夠在充分利用LinkedIn專有存儲技術的同時，能夠為流行的開源系統提供參考實現的開源Data Hub。

DAO抽象的另一個主要好處是標準化的變更數據捕獲（CDC）。無論底層數據存儲系統的類型如何，通過鍵值DAO的任何更新操作都將自動發出元數據審計事件（MAE）。每個MAE包含相應實體的URN，以及特定元數據方面的前后圖像。這支持lambda架構，其中可以批量或流處理MAE。與MCE類似，MAE的模式也是由元數據模型自動生成的。
元數據索引
最后一個缺失的部分是元數據索引管道。該系統將元數據模型連接在一起，并在圖形數據庫和搜索引擎中創建相應索引，以促進有效查詢。這些業務邏輯以索引構建器和圖形構建器的形式捕獲，并作為處理MAE的Samza作業的一部分執行。每個構建器都在作業中注冊了它們對特定元數據方面的興趣，并將使用相應的MAE進行調用。然后，構建器會返回到一個冪等更新列表，這些更新將應用于搜索索引或graph DB。
元數據索引管道也是高度可擴展的，因為它可以基于每個MAE的實體URN進行分區，以支持每個實體的有序處理。

五、結論和期待

在這篇文章中，我們介紹了Data Hub，這是我們在LinkedIn元數據之旅中的最新進展。該項目包括模塊化UI前端和通用元數據架構后端。

過去六個月，Data Hub在LinkedIn每周支持1500多員工的搜索和各種特定的操作工作。LinkedIn的元數據圖包含超過一百萬個數據集，23個數據存儲系統，25k個指標，500多個AI功能，最重要的是所有LinkedIn員工都是該圖的創建者，消費者和操作者。?
我們通過向產品添加更多有趣的用戶故事和相關性算法來繼續改進Data Hub。我們還計劃為GraphQL添加原生支持，并利用Pegasus領域特定的語言(PDL)在不久的將來自動生成代碼。與此同時，我們正積極與開源社區分享WhereHows的演變，并將在Data Hub公開發布后發表聲明。

文章來源：Linkedin Engineering ,?《Data Hub: A Generalized Metadata Search & Discovery Tool》作者 / Mars?Lan,?Seyi Adebajo,?Shirshanka Das