數據治理工具調研之DataHub

1.項目簡介

Apache Atlas是Hadoop社區為解決Hadoop生態系統的元數據治理問題而產生的開源項目，它為Hadoop集群提供了包括數據分類、集中策略引擎、數據血緣、安全和生命周期管理在內的元數據治理核心能力。

官網地址：http://atlas.apache.org/

2.項目架構

Data Hub使用的是Generalized metadata architecture(GMA)，重點面對多種元數據可伸縮性的四項挑戰。

1. 建模：以對開發人員友好的方式對所有類型的元數據和關系進行建模。
2. 攝取：通過API和流大規模攝取大量的元數據更改。
3. 服務：大規模服務收集的原始元數據和派生的元數據，以及針對元數據的各種復雜查詢。
4. 索引：按比例索引元數據，並在元數據更改時自動更新索引。

元數據建模

1. 元數據也是數據：

   要對元數據建模，我們需要一種語言，其功能至少應與通用數據建模所使用的語言一樣豐富。

2. 元數據是分布式的：

   期望所有元數據都來自單一來源是不現實的。例如，管理數據集的訪問控制列表（ACL）的系統很可能不同於存儲架構元數據的系統。一個好的建模框架應允許多個團隊獨立地發展其元數據模型，同時提供與數據實體關聯的所有元數據的統一視圖。

使用Pegasus（一種由LinkedIn創建的開源且完善的數據模式語言）進行元數據建模。

{
  "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記錄中的可選字段。

{
  "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": "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"
            }
          ]
        }
      }
    }
  ]
}

上面是所有權元數據方面的模型。在這里，我們選擇將所有權建模為包含type和ldap字段的記錄數組。但是，在建模元數據方面時，只要它是有效的PDSC記錄，實際上就沒有限制。這樣就可以滿足前面提到的“元數據也是數據”的要求。

元數據攝取

DataHub提供兩種形式的元數據攝取：通過直接API調用或Kafka流。前者用於需要寫入后讀取一致性的元數據更改，而后者更適合於面向事實的更新。

DataHub的API基於Rest.li，這是一種可擴展的強類型RESTful服務架構，已在LinkedIn上廣泛使用。由於Rest.li使用Pegasus作為其接口定義，因此可以逐字使用上一節中定義的所有元數據模型。從API到存儲需要進行多層模型轉換的日子已經一去不復返了-API和模型將始終保持同步。

對於基於Kafka的提取，預計元數據生產者會發出標准化的元數據更改事件（MCE），其中包含由相應實體URN鍵控的對特定元數據方面的建議更改列表。當MCE的模式位於Apache Avro中時，它是從Pegasus元數據模型自動生成的。

對API和Kafka事件模式使用相同的元數據模型，使我們能夠輕松地開發模型，而無需精心維護相應的轉換邏輯。但是，為了實現真正的無縫模式演變，我們需要限制所有模式更改以始終向后兼容。這是在構建時通過添加兼容性檢查來強制實施的。

在領英，由於生產者和消費者之間的松散耦合，我們傾向於更加依賴Kafka流。每天，我們都會收到來自不同生產者的數百萬個MCE，並且隨着我們擴大元數據集合的范圍，其數量只會呈指數增長。為了構建流元數據獲取管道，我們利用Apache Samza作為流處理框架。攝取Samza作業的目的是快速，簡單地實現高吞吐量。它只是將Avro數據轉換回Pegasus，並調用相應的Rest.li API以完成提取。

元數據服務

一旦攝取並存儲了元數據，有效地處理原始和派生的元數據就很重要。DataHub旨在支持對大量元數據的四種常見查詢類型：

1. 面向文檔的查詢
2. 面向圖的查詢
3. 涉及聯接的復雜查詢
4. 全文搜索

為此，DataHub需要使用多種數據系統，每種數據系統專門用於擴展和服務有限類型的查詢。例如，Espresso是LinkedIn的NoSQL數據庫，特別適合大規模面向文檔的CRUD。同樣，Galene可以輕松索引並提供網絡規模的全文搜索。當涉及到非平凡的圖查詢時，毫不奇怪的是，專用圖數據庫的性能要比基於RDBMS的實現好幾個數量級。但是，事實證明，圖結構也是表示外鍵關系的自然方法，從而可以有效地回答復雜的聯接查詢。

DataHub通過一組通用的數據訪問對象（DAO）（例如鍵值DAO，查詢DAO和搜索DAO ）進一步抽象底層數據系統。然后，可以在不更改DataHub中任何業務邏輯的情況下輕松地換入和換出DAO的特定於數據系統的實現。這最終將使我們能夠使用流行的開源系統的參考實現來開源DataHub，同時仍然充分利用LinkedIn的專有存儲技術。

DAO抽象的另一個主要好處是標准化的變更數據捕獲（CDC）。無論基礎數據存儲系統的類型如何，通過鍵值DAO進行的任何更新操作都將自動發出元數據審核事件（MAE）。每個MAE都包含相應實體的URN，以及特定元數據方面的前后圖像。這實現了lambda體系結構，在此體系結構中，MAE可以批量或流式處理。與MCE相似，MAE的架構也可以從元數據模型中自動生成。

元數據索引

最后一個難題是元數據索引管道。該系統將元數據模型連接在一起，並在圖形數據庫和搜索引擎中創建相應的索引，以促進高效的查詢。這些業務邏輯以“索引構建器”和“圖形構建器”的形式捕獲，並作為處理MAE的Samza作業的一部分執行。每個構建者都在工作中注冊了對特定元數據方面的興趣，並將通過相應的MAE進行調用。然后，構建器返回要應用於搜索索引或圖形數據庫的冪等更新的列表。

元數據索引管道還具有高度可伸縮性，因為它可以基於每個MAE的實體URN輕松進行分區，以支持對每個實體的有序處理。

DataHub安裝記錄

1. clone git項目

2. 安裝quickstart

   cd datahub/docker/quickstart
   source ./quickstart.sh
   

3. 此時會開始部署各種docker容器

   

4. https://registry.docker-cn.com