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