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具有根本的局限性，使其無法滿足不斷發展的元資料需求，主要問題是：
-
推送比拉動要好：雖然直接從源中拉動元資料似乎是收集元資料的最直接方法，但開發和維護集中的特定域爬網程式卻很快成為噩夢，讓各個元資料提供者通過API或訊息將資訊推送到中央存盤庫具有更大的可伸縮性，這種基于推送的方法還可以確保更及時地反映新的和更新的元資料，
-
一般勝于特定：關于資料集或作業的元資料有著固定的API，資料模型和存盤格式，對元資料模型進行小的更改將導致在堆疊上下進行一系列更改，如果我們設計了一個通用的體系結構，而該體系結構與其存盤和服務的元資料模型無關，那么它將具有更大的可擴展性，反過來，這將使我們能夠專注于入門和不斷發展的，有見地的元資料模型，而不必擔心堆疊的底層，
-
聯機與脫機同樣重要：收集了元資料后，自然要分析該元資料以獲取價值，一種簡單的解決方案是將所有元資料轉儲到脫機系統（如Hadoop），在該系統中可以執行任意分析，但是，我們很快發現僅支持離線分析還不夠，有許多用例，例如訪問控制和資料隱私處理，必須在線查詢最新的元資料，
-
關系確實很重要：元資料通常傳達重要的關系（例如，血統，所有權和依賴性），這些關系可以提供強大的功能，例如影響分析，資料匯總，更好的搜索相關性等，將所有這些關系建模為頭等公民和支持對其進行有效的分析查詢，
-
多中心宇宙：我們意識到僅對單個物體（資料集）周圍的元資料進行建模是不夠的，有一個完整的資料，代碼和人員物體生態系統（資料集，資料科學家，團隊，代碼，微服務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更新，
元資料獲取
簡而言之，元資料是“ 提供有關其他資料的資訊的資料，” 對于元資料建模，這帶來了兩個不同的要求：
- 元資料也是資料：要對元資料建模，我們需要一種語言，其功能至少應與通用資料建模所使用的語言一樣豐富，
- 元資料是分布式的：期望所有元資料都來自單一來源是不現實的，例如，管理資料集的訪問控制串列（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旨在支持對大量元資料的四種常見查詢型別：
- 面向檔案的查詢
- 面向圖的查詢
- 涉及聯接的復雜查詢
- 全文搜索
為此，DataHub需要使用多種資料系統，每種資料系統專門用于擴展和服務于有限型別的查詢，
在本文中，我們介紹了DataHub，這是LinkedIn上元資料之旅的最新進展，該專案包括一個模塊化UI前端和一個通用元資料體系結構后端，
目前datahub正在迅速發展，雖然還不是很活躍，也缺少相關的資料，但憑著與kafka的良好融合，datahub一定會在實時資料治理領域嶄露頭角，
更多實時資料分析相關博文與科技資訊，歡迎關注 “實時流式計算”
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/12636.html
標籤：大數據
上一篇：去 HBase，Kylin on Parquet 性能表現如何？
下一篇：實時流式計算系統中的幾個陷阱