首先，阿裡雲也有一款名為DataHub的産品，是一個流式處理平台，本文所述DataHub與其無關。
資料治理是大佬們最近談的一個火熱的話題。不管國家層面，還是企業層面現在對這個問題是越來越重視。資料治理要解決資料品質，資料管理，資料資産，資料安全等等。而資料治理的關鍵就在于中繼資料管理，我們要知道資料的來龍去脈，才能對資料進行全方位的管理，監控，洞察。
DataHub是由LinkedIn的資料團隊開源的一款提供中繼資料搜尋與發現的工具。
提到LinkedIn，不得不想到大名鼎鼎的Kafka，Kafka就是LinkedIn開源的。LinkedIn開源的Kafka直接影響了整個實時計算領域的發展，而LinkedIn的資料團隊也一直在探索資料治理的問題，不斷努力擴充其基礎架構，以滿足不斷增長的大資料生态系統的需求。随着資料的數量和豐富性的增長，資料科學家和工程師要發現可用的資料資産，了解其出處并根據見解采取适當的行動變得越來越具有挑戰性。為了幫助增長的同時繼續擴大生産力和資料創新，建立了通用的中繼資料搜尋和發現工具DataHub。
市面上常見的中繼資料管理系統有如下幾個：
a) linkedin datahub:
https://github.com/linkedin/datahub
b) apache atlas:
https://github.com/apache/atlas
c) lyft amundsen
https://github.com/lyft/amundsen
atlas之前我們也介紹過，對hive有非常好的支援，但是部署起來非常的吃力。amundsen還是一個新興的架構，還沒有release版本，未來可能會發展起來還需要慢慢觀察。
綜上，datahub是目前我們實時資料治理的最佳選擇，隻是目前datahub的資料還較少，未來我們将持續關注與更新datahub的更多資訊。
Github https://github.com/linkedin/datahub
License Apache-2.0
支援資料源 LDAP, Hive, Kafka, MySQL, DB2, Firebird, SQL Server, Oracle, Postgres, SQLite, ODBC
實作功能 中繼資料 資料血緣 權限 描述 生命周期
datahub的前身是LinkedIn為了提高資料團隊的工作效率，開發并開源的WhereHows。
這是一個中央中繼資料存儲庫和資料集門戶。存儲的中繼資料類型包括技術中繼資料（例如位置，架構，分區，所有權）和過程中繼資料（例如沿襲，作業執行，生命周期資訊）。WhereHows還提供了搜尋引擎來幫助找到感興趣的資料集。
自2016年首次釋出WhereHows以來，業界對通過使用中繼資料提高資料科學家的生産力的興趣日益濃厚。例如，在此領域開發的工具包括AirBnb的Dataportal，Uber的Databook，Netflix的Metacat，Lyft的Amundsen以及最近的Google的Data Catalog。
但是，LinkedIn很快意識到WhereHows具有根本的局限性，使其無法滿足不斷發展的中繼資料需求。主要問題是：
推送比拉動要好：雖然直接從源中拉動中繼資料似乎是收集中繼資料的最直接方法，但開發和維護集中的特定域爬網程式卻很快成為噩夢。讓各個中繼資料提供者通過API或消息将資訊推送到中央存儲庫具有更大的可伸縮性。這種基于推送的方法還可以確定更及時地反映新的和更新的中繼資料。
一般勝于特定：關于資料集或工作的中繼資料有着固定的API，資料模型和存儲格式。對中繼資料模型進行小的更改将導緻在堆棧上下進行一系列更改。如果我們設計了一個通用的體系結構，而該體系結構與其存儲和服務的中繼資料模型無關，那麼它将具有更大的可擴充性。反過來，這将使我們能夠專注于入門和不斷發展的，有見地的中繼資料模型，而不必擔心堆棧的底層。
聯機與脫機同樣重要：收集了中繼資料後，自然要分析該中繼資料以擷取價值。一種簡單的解決方案是将所有中繼資料轉儲到脫機系統（如Hadoop），在該系統中可以執行任意分析。但是，我們很快發現僅支援離線分析還不夠。有許多用例，例如通路控制和資料隐私處理，必須線上查詢最新的中繼資料。
關系确實很重要：中繼資料通常傳達重要的關系（例如，血統，所有權和依賴性），這些關系可以提供強大的功能，例如影響分析，資料彙總，更好的搜尋相關性等。将所有這些關系模組化為頭等公民和支援對其進行有效的分析查詢。
多中心宇宙：我們意識到僅對單個實體（資料集）周圍的中繼資料進行模組化是不夠的。有一個完整的資料，代碼和人員實體生态系統（資料集，資料科學家，團隊，代碼，微服務API，名額，AI功能，AI模型，儀表闆，筆記本等），需要通過以下方式進行內建和連接配接：單個中繼資料圖。
LinkedIn意識到不斷增長的需求，即跨各種資料實體以及将它們連接配接在一起的中繼資料圖的一緻的搜尋和發現體驗。于是決定擴充項目的範圍，以建立一個雄心勃勃的願景：将LinkedIn員工與他們重要的資料聯系起來，進而建構一個完全通用的中繼資料搜尋和發現工具DataHub。
元件服務架構
DataHub Web由Ember Framework開發，在應用子產品化UI基礎結構中，将DataHub Web應用程式建構為一系列緊密結合功能的元件，這些元件被分組為可安裝的軟體包。該軟體包體系結構在基礎上使用了Yarn Workspaces和Ember附加元件，并使用Ember的元件和服務進行了元件化。您可以将其視為一個使用小型建構塊（即元件和服務）建構的UI，以建立較大的建構塊（即Ember附加元件和npm / Yarn軟體包），這些UI放在一起構成最終構成DataHub Web應用程式。
以元件和服務為應用程式的核心，該架構使我們能夠分解不同的方面并将應用程式中的其他功能組合在一起。此外，每一層的分段都提供了非常可定制的體系結構，該體系結構允許消費者擴充或簡化其應用程式，以僅利用與其領域相關的功能或新的中繼資料模型。
前端提供三種互動類型：（1）搜尋，（2）浏覽和（3）檢視/編輯中繼資料。以下是實際應用中的一些示例螢幕截圖：
DataHub應用截圖
類似于典型的搜尋引擎體驗，使用者可以通過提供關鍵字清單來搜尋一種或多種類型的實體。他們可以通過篩選多個方面來進一步對結果進行切片和切塊。進階使用者還可以利用運算符（例如OR，NOT和regex）執行複雜的搜尋。
DataHub中的資料實體可以以樹狀方式組織和浏覽，其中每個實體都可以出現在樹中的多個位置。這使使用者能夠以不同方式（例如，通過實體部署配置或業務功能組織）浏覽同一目錄。甚至有樹的專用部分僅顯示“認證明體”，這些實體是通過單獨的治理流程進行管理的。
最終互動（檢視/編輯中繼資料）也是最複雜的互動。每個資料實體都有一個“配置檔案頁面”，其中顯示了所有關聯的中繼資料。例如，資料集配置檔案頁面可能包含其架構，所有權，合規性，運作狀況和沿襲中繼資料。它還可以顯示實體與其他實體之間的關系，例如，生成資料集的作業，從該資料集計算出的度量或圖表等。對于可編輯的中繼資料，使用者也可以直接通過UI更新。
簡而言之，中繼資料是“ 提供有關其他資料的資訊的資料。” 對于中繼資料模組化，這帶來了兩個不同的要求：
中繼資料也是資料：要對中繼資料模組化，我們需要一種語言，其功能至少應與通用資料模組化所使用的語言一樣豐富。
中繼資料是分布式的：期望所有中繼資料都來自單一來源是不現實的。例如，管理資料集的通路控制清單（ACL）的系統很可能不同于存儲架構中繼資料的系統。一個好的模組化架構應允許多個團隊獨立地發展其中繼資料模型，同時提供與資料實體相關聯的所有中繼資料的統一視圖。
我們沒有發明一種新的中繼資料模組化方法，而是選擇使用Pegasus（一種由LinkedIn建立的開源且完善的資料模式語言）。Pegasus專為通用資料模組化而設計，是以适用于大多數中繼資料。但是，由于Pegasus沒有提供對關系或關聯進行模組化的顯式方法，是以我們引入了一些自定義擴充來支援這些用例。
為了示範如何使用Pegasus對中繼資料進行模組化，讓我們看一下下面的修改後的實體關系圖（ERD）所說明的簡單示例。
該示例包含三種類型的實體-使用者，組和資料集-由圖中的藍色圓圈表示。我們使用箭頭表示這些實體之間的三種關系類型，即OwnedBy，HasMember和HasAdmin。換句話說，一個組由一個管理者和使用者的多個成員組成，而使用者又可以擁有一個或多個資料集。
與傳統的ERD不同，我們将實體和關系的屬性分别直接放置在圓圈内和關系名稱下。這使我們可以将一種稱為“中繼資料方面”的新型元件附加到實體。不同的團隊可以為同一實體擁有和發展中繼資料的不同方面，而不會互相幹擾，進而滿足了分布式中繼資料模組化的需求。上例中包含綠色矩形的三種類型的中繼資料方面：所有權，配置檔案和成員身份。使用虛線表示中繼資料方面與實體的關聯。例如，配置檔案可以與使用者相關聯，所有權可以與資料集相關聯，等等。
您可能已經注意到，實體和關系屬性與中繼資料方面存在重疊，例如，使用者的firstName屬性應與關聯的配置檔案的firstName字段相同。重複資訊的原因将在本文的後半部分中進行解釋，但是到目前為止，将屬性視為中繼資料方面的“有趣部分”就足夠了。
為了在Pegasus中為示例模組化，我們将每個實體，關系和中繼資料方面轉換為單獨的Pegasus Schema檔案（PDSC）。為簡便起見，我們在此僅列出每個類别中的一個模型。首先，讓我們看一下User實體的PDSC：
每個實體都必須具有URN形式的全局唯一ID ，可以将其視為類型化的GUID。User實體具有的屬性包括名字，姓氏和LDAP，每個屬性都映射到User記錄中的可選字段。
接下來是OwnedBy關系的PDSC模型：
每個關系模型自然包含使用其URN指向特定實體執行個體的“源”和“目的地”字段。模型可以選擇包含其他屬性字段，在這種情況下，例如“類型”。在這裡，我們還引入了一個稱為“ pairings”的自定義屬性，以将關系限制為特定的源和目标URN類型對。在這種情況下，OwnedBy關系隻能用于将資料集連接配接到使用者。
最後，您将在下面找到所有權中繼資料方面的模型。在這裡，我們選擇将所有權模組化為包含type和ldap字段的記錄數組。但是，在模組化中繼資料方面時，隻要它是有效的PDSC記錄，實際上就沒有限制。這樣就可以滿足前面提到的“中繼資料也是資料”的要求。
DataHub提供兩種形式的中繼資料攝取：通過直接API調用或Kafka流。前者适合離線，後者适合實時。
DataHub的API基于Rest.li，這是一種可擴充的，強類型的RESTful服務架構，已在LinkedIn上廣泛使用。由于Rest.li使用Pegasus作為其接口定義，是以可以逐字使用上一節中定義的所有中繼資料模型。從API到存儲需要多層轉換的日子已經一去不複返了-API和模型将始終保持同步。
對于基于Kafka的提取，預計中繼資料生産者将發出标準化的中繼資料更改事件（MCE），其中包含由相應實體URN鍵控的針對特定中繼資料方面的建議更改清單。
對API和Kafka事件模式使用相同的中繼資料模型，使我們能夠輕松地開發模型，而無需精心維護相應的轉換邏輯。
旦攝取并存儲了中繼資料，有效地處理原始和派生的中繼資料就很重要。DataHub旨在支援對大量中繼資料的四種常見查詢類型：
面向文檔的查詢
面向圖的查詢
涉及聯接的複雜查詢
全文搜尋
為此，DataHub需要使用多種資料系統，每種資料系統專門用于擴充和服務于有限類型的查詢。
在本文中，我們介紹了DataHub，這是LinkedIn上中繼資料之旅的最新進展。該項目包括一個子產品化UI前端和一個通用中繼資料體系結構後端。
目前datahub正在迅速發展，雖然還不是很活躍，也缺少相關的資料，但憑着與kafka的良好融合，datahub一定會在實時資料治理領域嶄露頭角。
大資料流動 專注于大資料實時計算，資料治理，資料可視化等技術分享與實踐。
請在背景回複關鍵字下載下傳相關資料。相關學習交流群已經成立，歡迎加入~