DataHub：通用元数据搜索和发现工具

---

前言

作为全球最大的专业社交网络和经济图表的运营商，LinkedIn的数据团队不断努力扩展其基础设施，以满足不断增长的大数据生态系统的需求。随着数据量和丰富度的增加，数据科学家和工程师要发现可用的数据资产、了解它们的来源以及根据洞察采取适当的行动变得越来越具有挑战性。为了帮助我们在数据的不断增长中继续扩展生产力和创新，我们创建了一款通用的元数据搜索和发现工具DataHub。

扩展元数据

为了提高LinkedIn数据团队的生产力，我们此前已经开发并开源了WhereHows，这是一个用于数据集的中央元数据存储库和门户网站。存储的元数据类型包括技术元数据（例如位置、架构、分区、所有权）和过程元数据（例如谱系、作业执行、生命周期信息）。WhereHows还具有一个搜索引擎，帮助定位感兴趣的数据集。

自2016年首次发布WhereHows以来，行业对通过使用元数据提高数据科学家的生产力产生了越来越浓厚的兴趣。例如，该领域开发的工具包括AirBnb的Dataportal、Uber的Databook、Netflix的Metacat、Lyft的Amundsen，以及最近的Google的Data Catalog。在LinkedIn，我们也一直在不断扩大我们的元数据收集范围，以支持新的用例，同时保护公平性、隐私性和透明性。然而，我们逐渐认识到WhereHows存在根本性局限，不能满足我们不断发展的元数据需求。以下是我们从扩展WhereHows中获得的经验教训摘要：

• 推动优于拉动：直接从源头提取元数据似乎是收集元数据最直接的方法，但是开发和维护一个集中式的专业爬虫车队很快就变成了一场噩梦。通过API或消息，让各个元数据提供者将信息推送到中央存储库，这种推送式方法更具可伸缩性。这种推送方法还可以确保更及时地反映新的和更新的元数据。

• 通用胜于特定：WhereHows对数据集或作业的元数据的外观有非常明确的看法。这导致了一个明确的API、数据模型和存储格式。对元数据模型的微小更改将导致需要对整个堆栈进行上下游的一系列更改。如果我们设计了一个通用的体系结构，不考虑它存储和提供的元数据模型，那么它将更具伸缩性。这反过来将允许我们专注于引入和演化明确定义的元数据模型，而无需担心堆栈的下层。

• 在线与离线同等重要：一旦收集了元数据，就自然而然地希望分析该元数据以获取价值。一个简单的解决方案是将所有元数据转储到离线系统，如Hadoop，可以在其中执行任意分析。然而，我们很快发现，仅支持离线分析是不够的。有许多用例，例如访问控制和数据隐私处理，必须在线查询最新的元数据。

• 关系真的很重要：元数据通常传达重要的关系（例如谱系、所有权和依赖关系），这些关系可以实现强大的功能，如影响分析、数据汇总、更好的搜索相关性等。将所有这些关系建模为一流公民，并支持对它们的高效分析查询至关重要。

• 多中心宇宙：我们意识到，仅仅围绕一个单一实体（数据集）建模元数据是不够的。存在着一个完整的数据、代码和人员实体生态系统（数据集、数据科学家、团队、代码、微服务API、度量、AI功能、AI模型、仪表板、笔记本等）需要通过单一的元数据图进行集成和连接。

遇见DataHub

大约一年前，我们回到了绘制板前，从头开始重新架构了WhereHows。同时，我们意识到在LinkedIn内部，需要一个跨各种数据实体提供一致的搜索和发现体验的工具，以及一个将它们连接在一起的元数据图。因此，我们决定扩大项目的范围，构建一个完全通用的元数据搜索和发现工具DataHub，其雄心勃勃的愿景是将LinkedIn员工与对他们重要的数据连接起来。

我们将单片WhereHows堆栈分为两个不同的堆栈：一个是模块化UI前端，另一个是通用元数据架构后端。新的架构使我们能够迅速扩展元数据收集的范围，不仅限于数据集和作业。撰写本文时，DataHub已经存储和索引了数千万个元数据记录，涵盖了19种不同的实体，包括数据集、度量、作业、图表、AI功能、人员和团队。我们还计划在不久的将来为机器学习模型和标签、实验、仪表板、微服务API和代码添加元数据。

模块化UI

DataHub Web应用程序是大多数用户与元数据互动的方式。该应用程序使用Ember框架编写，运行在Play中间层之上。为了使开发具有可伸缩性，我们利用了各种现代Web技术，包括ES9、ES.Next、TypeScript、Yarn与Yarn Workspaces，以及Prettier和ESLint等代码质量工具。呈现、控制和数据层被模块化成包，以便从相关包的组合构建出特定的应用程序视图。

组件服务框架

在应用模块化UI基础设施时，我们将DataHub Web应用程序构建为一系列具有内聚性的特性对齐组件，这些组件分组到可安装的包中。这个包架构使用了Yarn Workspaces和Ember插件作为基础，使用Ember的组件和服务进行组件化。您可以将其视为使用小构建块（即组件和服务）构建的UI，以创建更大的构建块（即Ember插件和npm/Yarn包），这些构建块最终构成了DataHub Web应用程序。

在应用程序的核心是组件和服务，这个框架允许我们拆分不同的方面，并组合其他特性到应用程序中。此外，每个层面的分段提供了一个非常可定制的体系结构，允许消费者扩展或简化他们的应用程序，以利用与其域相关的仅限于特定功能或新的元数据模型。

与DataHub互动

在最高级别上，前端提供三种类型的交互：（1）搜索、（2）浏览和（3）查看/编辑元数据。以下是实际应用程序的一些示例屏幕截图：



与典型的搜索引擎体验类似，用户可以通过提供关键字列表来搜索一个或多个类型的实体。他们可以通过筛选一系列方面来进一步切分和细化结果。高级用户还可以使用运算符，如OR、NOT和regex，执行复杂的搜索。

DataHub中的数据实体可以以树状结构组织和浏览，其中每个实体允许出现在树的多个位置。这使用户能够以不同的方式浏览相同的目录，例如，按物理部署配置或业务功能组织。甚至可以有一个专用部分的树，仅显示经过单独管理流程策划的“认证实体”。

最后一个交互——查看/编辑元数据——也是最复杂的交互之一。每个数据实体都有一个“个人资料页面”，显示所有相关的元数据。例如，数据集个人资料页面可能包含其模式、所有权、合规性、健康状况和谱系元数据。它还可以显示实体与其他实体的关系，例如生成数据集的作业、从此数据集计算出的度量或图表等等。对于可编辑的元数据，用户还可以通过UI直接更新它。

通用元数据架构

为了充分实现DataHub的愿景，我们需要一种能够与元数据一起扩展的体系结构。可扩展性挑战以四种不同形式出现：

• 建模：以开发人员友好的方式对所有类型的元数据和关系建模。
• 摄入：通过API和流处理大量的元数据变更。
• 服务：提供原始和派生的元数据，以及针对大规模元数据的各种复杂查询。
• 索引：以及在元数据发生更改时自动更新索引的元数据。

元数据建模

简而言之，元数据是“提供有关其他数据的信息的数据”。这在元数据建模方面带来了两个不同的要求：

• 元数据也是数据：要对元数据建模，我们需要一种至少与用于通用数据建模的语言一样丰富的语言。
• 元数据是分布式的：不太可能期望所有的元数据来自单一来源。例如，管理数据集的访问控制列表（ACL）的系统很可能与存储架构元数据的系统不同。一个良好的建模框架应该允许多个团队独立地演进其元数据模型，同时提供与数据实体相关的所有元数据的统一视图。

我们选择利用Pegasus，这是LinkedIn创建的一种开源且经过良好验证的数据模式语言，而不是发明一种新的元数据建模方式。Pegasus专为通用数据建模而设计，因此对于大多数元数据都可以很好地工作。但是，由于Pegasus不提供明确的建模关系或关联的方法，因此我们引入了一些自定义扩展以支持这些用例。

为了演示如何使用Pegasus来建模元数据，让我们看一个简单的示例，如下图所示的修改后的实体-关系图（ERD）。

该示例包含三种类型的实体——User（用户）、Group（群组）和Dataset（数据集）——在图表中由蓝色圆圈表示。我们使用箭头表示这些实体之间的三种类型的关系，即OwnedBy（拥有者）、HasMember（拥有成员）和HasAdmin（有管理员）。换句话说，一个群组由一个管理员和多个用户成员组成，这些用户成员又可以拥有一个或多个数据集。

与传统的ERD不同，我们将实体和关系的属性直接放在圆圈内，并放在关系名称下方。这使我们能够附加一种称为“元数据方面”的新组件到实体上。不同的团队可以为同一实体拥有和演进不同方面的元数据，而不会相互干扰，从而满足了分布式元数据建模的要求。在上面的示例中，包括三种类型的元数据方面：Ownership（拥有权）、Profile（个人资料）和Membership（成员关系），表示为绿色矩形。元数据方面与实体的关联使用虚线表示。例如，Profile可以与User相关联，Ownership可以与Dataset相关联，依此类推。

您可能已经注意到实体和关系属性与元数据方面之间存在重叠，例如，User的firstName属性应该与关联的Profile的firstName字段相同。重复信息的原因将在本文的后面部分解释，但目前将属性视为元数据方面的“有趣部分”就足够了。

为了在Pegasus中建模示例，我们将把每个实体、关系和元数据方面都转化为单独的Pegasus模式文件（PDSC）。出于简洁起见，我们只在这里包括每个类别中的一个模型。首先，让我们看一个有关User实体的PDSC：

每个关系模型自然包含指向特定实体实例的“源”和“目标”字段，使用它们的URN进行指向。该模型还可以选择包含其他属性字段，例如在这种情况下的“type”。在这里，我们还引入了一个名为“pairings”的自定义属性，以限制关系连接到特定的源和目标URN类型对。在这种情况下，OwnedBy关系只能用于将Dataset连接到User。

最后，您将在下面找到Ownership元数据方面的模型。在这里，我们选择将所有权建模为包含类型和ldap字段的记录数组。然而，对于建模元数据方面来说，实际上没有什么限制，只要它是有效的PDSC记录。这使得满足前面提到的“元数据也是数据”的要求成为可能。

完成所有模型的创建后，下一个逻辑问题是如何将它们连接在一起以形成提议的ERD。我们将把这个讨论推迟到本文后面的“元数据索引”部分。

元数据摄取

DataHub提供两种形式的元数据摄取：直接API调用或Kafka流。前者用于需要读写一致性的元数据更改，而后者更适用于面向事实的更新。

DataHub的API基于Rest.li，这是LinkedIn内部广泛使用的可伸缩的、强类型的RESTful服务架构。由于Rest.li使用Pegasus作为其接口定义，前面部分定义的所有元数据模型都可以逐字使用。过去需要从API到存储的多层模型转换的日子已经一去不复返了——API和模型将始终保持同步。

对于基于Kafka的摄取，预期元数据生产者将发出标准化的Metadata Change Event (MCE)，其中包含按相应实体URN键入的特定元数据方面的建议更改列表。虽然MCE的模式是Apache Avro格式，但它是从Pegasus元数据模型自动生成的。

使用相同的元数据模型来定义API和Kafka事件模式使我们能够轻松地演进模型，而无需费力地维护相应的转换逻辑。然而，要实现真正的无缝模式演化，我们需要限制所有模式更改始终向后兼容。这是在构建时通过添加兼容性检查来强制执行的。

在LinkedIn，我们更倾向于更多地依赖Kafka流，因为它在生产者和消费者之间提供了松散的耦合。每天，我们从各种生产者那里接收数百万个MCE，而且随着我们扩大元数据收集范围，这个数量只会呈指数级增长。为了构建流式元数据摄取管道，我们利用了Apache Samza作为我们的流处理框架。摄取Samza作业特意设计为快速简单，以实现高吞吐量。它只是将Avro数据转换回Pegasus，并调用相应的Rest.li API来完成摄取。

元数据服务

一旦元数据被摄取并存储，高效提供原始和派生的元数据就变得很重要。DataHub旨在支持对大量元数据进行四种常见查询的查询：

1. 文档导向查询
2. 图导向查询
3. 涉及连接的复杂查询
4. 全文搜索

为实现这一点，DataHub需要利用多种类型的数据系统，每种数据系统专门用于扩展和提供有限类型的查询。例如，Espresso是LinkedIn的NoSQL数据库，特别适用于大规模文档导向的CRUD。同样，Galene可以轻松索引和提供Web规模的全文搜索。当涉及到非平凡的图查询时，专门的图数据库可以比基于RDBMS的实现提供更高效数倍的性能并不足为奇。然而，事实证明，图结构也是表示外键关系的自然方式，允许高效地回答复杂的连接查询。

DataHub通过一组通用的数据访问对象（DAO），如键值DAO、查询DAO和搜索DAO，进一步抽象了底层的数据系统。然后，可以轻松地替换和替换DAO的数据系统特定实现，而不需改变DataHub中的任何业务逻辑。这最终将使我们能够开源DataHub，并提供流行的开源系统的参考实现，同时仍然充分利用LinkedIn的专有存储技术。

DAO抽象的另一个关键好处是标准化的更改数据捕获（CDC）。无论底层数据存储系统的类型如何，通过键值DAO的任何更新操作都会自动发出元数据审计事件（MAE）。每个MAE包含相应实体的URN，以及特定元数据方面的前后图像。这使得可以对MAE进行批处理或流处理的lambda体系结构成为可能。与MCE类似，MAE的模式也是从元数据模型自动生成的。

元数据索引

拼图的最后一个缺失部分是元数据索引管道。这是连接元数据模型并在图形数据库和搜索引擎中创建相应索引以促进高效查询的系统。这些业务逻辑以Index Builder和Graph Builder的形式捕获，并作为处理MAE的Samza作业的一部分执行。每个构建器都在作业中注册了对特定元数据方面的兴趣，并将使用相应的MAE调用。然后构建器返回一系列幂等更新，以应用于搜索索引或图形数据库。

元数据索引管道也具有高度可扩展性，因为它可以根据每个MAE的实体URN轻松分区，以支持每个实体的顺序处理。

结论和展望

在这篇文章中，我们介绍了DataHub，这是LinkedIn在其元数据旅程中的最新演进。该项目包括Modular UI前端和通用化的元数据架构后端。

DataHub已经在LinkedIn的生产环境中运行了六个月。每周有超过1500名员工访问它，支持搜索、发现和各种特定的操作工作流程。LinkedIn的元数据图包含一百多万个数据集，23个数据存储系统，25000多个度量标准，500多个人工智能功能，最重要的是所有LinkedIn员工，他们是这个图的创建者、消费者和运营商。

我们将继续改进DataHub，通过向产品添加更多有趣的用户故事和相关性算法来提高其质量。我们还计划在不久的将来增加对GraphQL的本机支持，并利用Pegasus领域特定语言（PDL）自动化代码生成。