DataHub——實時數據治理平臺_ZenDei技術網路在線

DataHub 首先，阿裡雲也有一款名為DataHub的產品，是一個流式處理平臺，本文所述DataHub與其無關。數據治理是大佬們最近談的一個火熱的話題。不管國家層面，還是企業層面現在對這個問題是越來越重視。數據治理要解決數據質量，數據管理，數據資產，數據安全等等。而數據治理的關鍵就在於元數據管 ...

file

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）查看/編輯元數據。以下是實際應用中的一些示例屏幕截圖：

file
file
file

DataHub應用截圖

類似於典型的搜索引擎體驗，用戶可以通過提供關鍵字列表來搜索一種或多種類型的實體。他們可以通過篩選多個方面來進一步對結果進行切片和切塊。高級用戶還可以利用運算符（例如OR，NOT和regex）執行複雜的搜索。

DataHub中的數據實體可以以樹狀方式組織和瀏覽，其中每個實體都可以出現在樹中的多個位置。這使用戶能夠以不同方式（例如，通過物理部署配置或業務功能組織）瀏覽同一目錄。甚至有樹的專用部分僅顯示“認證實體”，這些實體是通過單獨的治理流程進行管理的。

最終交互（查看/編輯元數據）也是最複雜的交互。每個數據實體都有一個“配置文件頁面”，其中顯示了所有關聯的元數據。例如，數據集配置文件頁面可能包含其架構，所有權，合規性，運行狀況和沿襲元數據。它還可以顯示實體與其他實體之間的關係，例如，生成數據集的作業，從該數據集計算出的度量或圖表等。對於可編輯的元數據，用戶也可以直接通過UI更新。

元數據獲取

簡而言之，元數據是“ 提供有關其他數據的信息的數據。” 對於元數據建模，這帶來了兩個不同的要求：

元數據也是數據：要對元數據建模，我們需要一種語言，其功能至少應與通用數據建模所使用的語言一樣豐富。
元數據是分散式的：期望所有元數據都來自單一來源是不現實的。例如，管理數據集的訪問控制列表（ACL）的系統很可能不同於存儲架構元數據的系統。一個好的建模框架應允許多個團隊獨立地發展其元數據模型，同時提供與數據實體相關聯的所有元數據的統一視圖。

我們沒有發明一種新的元數據建模方法，而是選擇使用Pegasus（一種由LinkedIn創建的開源且完善的數據模式語言）。Pegasus專為通用數據建模而設計，因此適用於大多數元數據。但是，由於Pegasus沒有提供對關係或關聯進行建模的顯式方法，因此我們引入了一些自定義擴展來支持這些用例。

為了演示如何使用Pegasus對元數據進行建模，讓我們看一下下麵的修改後的實體關係圖（ERD）所說明的簡單示例。

file

該示例包含三種類型的實體-用戶，組和數據集-由圖中的藍色圓圈表示。我們使用箭頭表示這些實體之間的三種關係類型，即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事件模式使用相同的元數據模型，使我們能夠輕鬆地開發模型，而無需精心維護相應的轉換邏輯。