DataHub——實時數據治理平臺

DataHub

首先，阿里雲也有一款名爲DataHub的產品，是一個流式處理平臺，本文所述DataHub與其無關。

數據治理是大佬們最近談的一個火熱的話題。無論國家層面，仍是企業層面如今對這個問題是愈來愈重視。數據治理要解決數據質量，數據管理，數據資產，數據安全等等。而數據治理的關鍵就在於元數據管理，咱們要知道數據的前因後果，才能對數據進行全方位的管理，監控，洞察。

DataHub是由LinkedIn的數據團隊開源的一款提供元數據搜索與發現的工具。

提到LinkedIn，不得不想到大名鼎鼎的Kafka，Kafka就是LinkedIn開源的。LinkedIn開源的Kafka直接影響了整個實時計算領域的發展，而LinkedIn的數據團隊也一直在探索數據治理的問題，不斷努力擴展其基礎架構，以知足不斷增加的大數據生態系統的需求。隨着數據的數量和豐富性的增加，數據科學家和工程師要發現可用的數據資產，瞭解其出處並根據看法採起適當的行動變得愈來愈具備挑戰性。爲了幫助增加的同時繼續擴大生產力和數據創新，建立了通用的元數據搜索和發現工具DataHub。

市面上常見的元數據管理系統有以下幾個：
a) linkedin datahub:
https://github.com/linkedin/d...
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/d...

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必定會在實時數據治理領域嶄露頭角。

更多實時數據分析相關博文與科技資訊，歡迎關注 「實時流式計算」