## DataHub 首先，阿里雲也有一款名為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的更多資訊。 ## 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具有根本的侷限性，使其無法滿足不斷髮展的元資料需求。主要問題是： 1. **推送比拉動要好：**雖然直接從源中拉動元資料似乎是收集元資料的最直接方法，但開發和維護集中的特定域爬網程式卻很快成為噩夢。讓各個元資料提供者通過API或訊息將資訊推送到中央儲存庫具有更大的可伸縮性。這種基於推送的方法還可以確保更及時地反映新的和更新的元資料。 2. **一般勝於特定：**關於資料集或工作的元資料有著固定的API，資料模型和儲存格式。對元資料模型進行小的更改將導致在堆疊上下進行一系列更改。如果我們設計了一個通用的體系結構，而該體系結構與其儲存和服務的元資料模型無關，那麼它將具有更大的可擴充套件性。反過來，這將使我們能夠專注於入門和不斷髮展的，有見地的元資料模型，而不必擔心堆疊的底層。 3. **聯機與離線同樣重要：**收集了元資料後，自然要分析該元資料以獲取價值。一種簡單的解決方案是將所有元資料轉儲到離線系統（如Hadoop），在該系統中可以執行任意分析。但是，我們很快發現僅支援離線分析還不夠。有許多用例，例如訪問控制和資料隱私處理，必須線上查詢最新的元資料。 4. **關係確實很重要：**元資料通常傳達重要的關係（例如，血統，所有權和依賴性），這些關係可以提供強大的功能，例如影響分析，資料彙總，更好的搜尋相關性等。將所有這些關係建模為頭等公民和支援對其進行有效的分析查詢。 5. **多中心宇宙：**我們意識到僅對單個實體（資料集）周圍的元資料進行建模是不夠的。有一個完整的資料，程式碼和人員實體生態系統（資料集，資料科學家，團隊，程式碼，微服務API，指標，AI功能，AI模型，儀表板，筆記本等），需要通過以下方式進行整合和連線：單個元資料圖。 ## 認識datahub 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更新。 ### 元資料獲取 簡而言之，元資料是“ 提供有關其他資料的資訊的資料。” 對於元資料建模，這帶來了兩個不同的要求： 1. **元資料也是資料：**要對元**資料**建模，我們需要一種語言，其功能至少應與通用資料建模所使用的語言一樣豐富。 2. **元資料是分散式的：**期望所有元資料都來自單一來源是不現實的。例如，管理資料集的訪問控制列表（ACL）的系統很可能不同於儲存架構元資料的系統。一個好的建模框架應允許多個團隊獨立地發展其元資料模型，同時提供與資料實體相關聯的所有元資料的統一檢視。 我們沒有發明一種新的元資料建模方法，而是選擇使用Pegasus（一種由LinkedIn建立的開源且完善的資料模式語言）。Pegasus專為通用資料建模而設計，因此適用於大多數元資料。但是，由於Pegasus沒有提供對關係或關聯進行建模的顯式方法，因此我們引入了一些自定義擴充套件來支援這些用例。 為了演示如何使用Pegasus對元資料進行建模，讓我們看一下下面的修改後的實體關係圖（ERD）所說明的簡單示例。  該示例包含三種類型的實體-使用者，組和資料集-由圖中的藍色圓圈表示。我們使用箭頭表示這些實體之間的三種關係型別，即OwnedBy，HasMember和HasAdmin。換句話說，一個組由一個管理員和使用者的多個成員組成，而使用者又可以擁有一個或多個數據集。 與傳統的ERD不同，我們將實體和關係的屬性分別直接放置在圓圈內和關係名稱下。這使我們可以將一種稱為“元資料方面”的新型元件附加到實體。不同的團隊可以為同一實體擁有和發展元資料的不同方面，而不會互相干擾，從而滿足了分散式元資料建模的需求。上例中包含綠色矩形的三種類型的元資料方面：所有權，配置檔案和成員身份。使用虛線表示元資料方面與實體的關聯。例如，配置檔案可以與使用者相關聯，所有權可以與資料集相關聯，等等。 您可能已經注意到，實體和關係屬性與元資料方面存在重疊，例如，使用者的firstName屬性應與關聯的配置檔案的firstName欄位相同。重複資訊的原因將在本文的後半部分中進行解釋，但是到目前為止，將屬性視為元資料方面的“有趣部分”就足夠了。 為了在Pegasus中為示例建模，我們將每個實體，關係和元資料方面轉換為單獨的Pegasus Schema檔案（PDSC）。為簡便起見，我們在此僅列出每個類別中的一個模型。首先，讓我們看一下User實體的PDSC： ``` { "type": "record", "name": "User", "fields": [ { "name": "urn", "type": "com.linkedin.common.UserUrn", }, { "name": "firstName", "type": "string", "optional": true }, { "name": "lastName", "type": "string", "optional": true }, { "name": "ldap", "type": "com.linkedin.common.LDAP", "optional": true } ] } ``` 每個實體都必須具有URN形式的全域性唯一ID ，可以將其視為型別化的GUID。User實體具有的屬性包括名字，姓氏和LDAP，每個屬性都對映到User記錄中的可選欄位。 接下來是OwnedBy關係的PDSC模型： ``` { "type": "record", "name": "OwnedBy", "fields": [ { "name": "source", "type": "com.linkedin.common.Urn", }, { "name": "destination", "type": "com.linkedin.common.Urn", }, { "name": "type", "type": "com.linkedin.common.OwnershipType", } ], "pairings": [ { "source": "com.linkedin.common.urn.DatasetUrn", "destination": "com.linkedin.common.urn.UserUrn" } ] } ``` 每個關係模型自然包含使用其URN指向特定實體例項的“源”和“目的地”欄位。模型可以選擇包含其他屬性欄位，在這種情況下，例如“型別”。在這裡，我們還引入了一個稱為“ pairings”的自定義屬性，以將關係限制為特定的源和目標URN型別對。在這種情況下，OwnedBy關係只能用於將資料集連線到使用者。 最後，您將在下面找到所有權元資料方面的模型。在這裡，我們選擇將所有權建模為包含type和ldap欄位的記錄陣列。但是，在建模元資料方面時，只要它是有效的PDSC記錄，實際上就沒有限制。這樣就可以滿足前面提到的“元資料也是資料”的要求。 ``` { "type": "record", "name": "Ownership", "fields": [ { "name": "owners", "type": { "type": "array", "items": { "name": "owner", "type": "record", "fields": [ { "name": "type", "type": "com.linkedin.common.OwnershipType" }, { "name": "ldap", "type": "string" } ] } } } ] } ``` ### **元資料攝取** DataHub提供兩種形式的元資料攝取：通過直接API呼叫或Kafka流。前者適合離線，後者適合實時。 DataHub的API基於Rest.li，這是一種可擴充套件的，強型別的RESTful服務架構，已在LinkedIn上廣泛使用。由於Rest.li使用Pegasus作為其介面定義，因此可以逐字使用上一節中定義的所有元資料模型。從API到儲存需要多層轉換的日子已經一去不復返了-API和模型將始終保持同步。 對於基於Kafka的提取，預計元資料生產者將發出標準化的元資料更改事件（MCE），其中包含由相應實體URN鍵控的針對特定元資料方面的建議更改列表。 對API和Kafka事件模式使用相同的元資料模型，使我們能夠輕鬆地開發模型，而無需精心維護相應的轉換邏輯。 ### **元資料服務** 旦攝取並存儲了元資料，有效地處理原始和派生的元資料就很重要。DataHub旨在支援對大量元資料的四種常見查詢型別： 1. 面向文件的查詢 2. 面向圖的查詢 3. 涉及聯接的複雜查詢 4. 全文搜尋 為此，DataHub需要使用多種資料系統，每種資料系統專門用於擴充套件和服務於有限型別的查詢。  在本文中，我們介紹了DataHub，這是LinkedIn上元資料之旅的最新進展。該專案包括一個模組化UI前端和一個通用元資料體系結構後端。 目前datahub正在迅速發展，雖然還不是很活躍，也缺少相關的資料，但憑著與kafka的良好融合，datahub一定會在實時資料治理領域嶄露頭角。  更多實時資料分析相關博文與科技資訊，歡迎關注 “實時流式計算” ![](https://img2020.cnblogs.com/other/1089984/202005/1089984-20200507092247195-14711833