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必定会在实时数据治理领域崭露头角。

更多实时数据分析相关博文与科技资讯，欢迎关注 “实时流式计算”