Get Started With DataHub | DataHub
作为世界上最大的专业网络和Economic Graph的运营商，LinkedIn 的数据团队一直致力于扩展其基础架构，以满足我们不断增长的大数据生态系统的需求。随着数据量和丰富度的增长，数据科学家和工程师越来越难以发现可用的数据资产、了解其来源并根据洞察力采取适当的行动。为了帮助我们在这种增长的同时继续提高数据的生产力和创新，我们创建了一个通用的元数据搜索和发现工具 DataHub。
缩放元数据
为了提高 LinkedIn 数据团队的生产力，我们之前开发并开源了WhereHows，这是一个中央元数据存储库和数据集门户。存储的元数据类型包括技术元数据（例如，位置、模式、分区、所有权）和过程元数据（例如，沿袭、作业执行、生命周期信息）。WhereHows 还提供了一个搜索引擎来帮助定位感兴趣的数据集。
自从我们在 2016 年首次发布 WhereHows 以来，业界对通过使用元数据提高数据科学家的生产力的兴趣与日俱增。例如，在该领域开发的工具包括AirBnb 的 Dataportal、Uber 的 Databook、Netflix 的 Metacat、Lyft 的 Amundsen以及最近的 Google数据目录。在 LinkedIn，我们还一直忙于扩大我们的元数据收集范围，以支持新的用例，同时保持公平、隐私和透明。然而，我们开始意识到 WhereHows 存在根本性的局限性，无法满足我们不断变化的元数据需求。以下是我们从扩展 WhereHows 中吸取的经验教训的总结：
- 推送优于拉取：虽然直接从源中提取元数据似乎是收集元数据的最直接方式，但开发和维护集中的特定领域爬虫群很快就会变成一场噩梦。让各个元数据提供者通过 API 或消息将信息推送到中央存储库更具可扩展性。这种基于推送的方法还确保更及时地反映新的和更新的元数据。
- 概括优于具体： WhereHows 对数据集或作业的元数据应该是什么样子有强烈的看法。这导致了固定的 API、数据模型和存储格式。对元数据模型的一个小改动将导致堆栈上下游所需的级联更改。如果我们设计了一个与其存储和服务的元数据模型无关的通用架构，它的可扩展性会更高。这反过来又可以让我们专注于入职和发展强烈自以为是的元数据模型，而不必担心堆栈的较低层。
- 在线与离线一样重要：收集元数据后，很自然地想要分析该元数据以获取价值。一种简单的解决方案是将所有元数据转储到离线系统，例如 Hadoop，可以在其中执行任意分析。然而，我们很快发现仅仅支持离线分析是不够的。有许多用例，例如访问控制和数据隐私处理，必须在线查询最新的元数据。
- 关系真的很重要：元数据通常传达重要的关系（例如，沿袭、所有权和依赖关系），这些关系可以实现强大的功能，如影响分析、数据汇总、更好的搜索相关性等。将所有这些关系建模为一等公民和支持对它们进行高效的分析查询。
- 多中心宇宙：我们意识到仅仅围绕单个实体（数据集）对元数据进行建模是不够的。有一个完整的数据、代码和人类实体（数据集、数据科学家、团队、代码、微服务 API、指标、AI 功能、AI 模型、仪表板、笔记本等）生态系统需要通过一个集成和连接单个元数据图。
认识数据中心
大约一年前，我们回到绘图板并根据这些知识从头开始重新构建 WhereHows。与此同时，我们意识到 LinkedIn 对跨各种数据实体的一致搜索和发现体验以及将它们连接在一起的元数据图的需求不断增长。因此，我们决定扩大该项目的范围，以构建一个完全通用的元数据搜索和发现工具 DataHub，并怀着雄心勃勃的愿景：将 LinkedIn 员工与对他们重要的数据联系起来。
我们将单一的 WhereHows 堆栈分解为两个不同的堆栈：模块化 UI 前端和通用元数据架构后端。新架构使我们能够迅速扩展我们的元数据收集范围，而不仅仅是数据集和作业。在撰写本文时，DataHub 已经存储并索引了数千万条元数据记录，这些记录包含 19 个不同的实体，包括数据集、指标、作业、图表、AI 功能、人员和组。我们还计划在不久的将来为机器学习模型和标签、实验、仪表板、微服务 API 和代码添加元数据。
模块化用户界面
DataHub 网络应用程序是大多数用户与元数据交互的方式。该应用程序使用Ember Framework编写，并在Play中间层之上运行。为了使开发具有可扩展性，我们利用了各种现代网络技术，包括ES9、ES.Next、TypeScript、带有Yarn Workspaces的 Yarn 以及Prettier和ESLint等代码质量工具。表示层、控制层和数据层被模块化到包中，因此应用程序中的特定视图是根据相关包的组合构建的。
组件服务框架
在应用模块化 UI 基础架构时，我们将 DataHub Web 应用程序构建为一系列内聚的功能对齐组件，这些组件被分组到可安装的包中。该包架构在基础上采用了 Yarn Workspaces 和 Ember 附加组件，并使用 Ember 的组件和服务进行了组件化。您可以将其视为使用小构建块（即组件和服务）构建的 UI，以创建更大的构建块（即 Ember 附加组件和 npm / Yarn 包），当这些构建块组合在一起时，最终构成 DataHub 网络应用程序.
以组件和服务为应用程序的核心，这个框架允许我们将不同的方面分开并将应用程序中的其他功能组合在一起。此外，每一层的分段提供了一个高度可定制的架构，允许消费者扩展或简化他们的应用程序，以仅利用与其领域相关的功能或载入新的元数据模型。
与 DataHub 交互
在最高级别，前端提供三种类型的交互：(1) 搜索，(2) 浏览，以及 (3) 查看/编辑元数据。以下是实际应用程序的一些示例屏幕截图：
数据中心应用截图
与典型的搜索引擎体验类似，用户可以通过提供关键字列表来搜索一种或多种类型的实体。他们可以通过筛选方面列表进一步对结果进行切片和切块。高级用户还可以利用 OR、NOT 和正则表达式等运算符来执行复杂的搜索。
DataHub 中的数据实体可以以树状方式组织和浏览，其中每个实体允许出现在树中的多个位置。这使用户能够以不同的方式浏览相同的目录，例如，通过物理部署配置或业务功能组织。甚至可以有一个专门的树部分显示“认证实体”，这些实体是通过单独的治理流程管理的。
最后的交互——查看/编辑元数据——也是最复杂的交互。每个数据实体都有一个“配置文件页面”，显示所有关联的元数据。例如，数据集配置文件页面可能包含其架构、所有权、合规性、健康状况和沿袭元数据。它还可以显示实体与其他实体的关系，例如，生成数据集的作业、从该数据集计算的指标或图表等。对于可编辑的元数据，用户也可以直接通过 UI 更新它。
通用元数据架构
为了完全实现 DataHub 的愿景，我们需要一个能够随元数据扩展的架构。可扩展性挑战有四种不同的形式：
- 建模：以开发人员友好的方式对所有类型的元数据和关系进行建模。
- 摄取：通过 API 和流大规模摄取大量元数据更改。
- 服务：提供收集的原始元数据和派生元数据，以及针对大规模元数据的各种复杂查询。
- 索引：大规模索引元数据，并在元数据更改时自动更新索引。
元数据建模
简单地说，元数据是“提供有关其他数据的信息的数据”。这在元数据建模方面带来了两个不同的要求：
- 元数据也是数据：为了对元数据进行建模，我们需要一种至少与用于通用数据建模的语言一样功能丰富的语言。
- 元数据是分布式的：期望所有元数据都来自单一来源是不现实的。例如，管理数据集访问控制列表 (ACL) 的系统很可能不同于存储模式元数据的系统。一个好的建模框架应该允许多个团队独立地发展他们的元数据模型，同时呈现与数据实体关联的所有元数据的统一视图。
我们没有发明一种新的元数据建模方法，而是选择利用Pegasus，这是一种由 LinkedIn 创建的开源且完善的数据模式语言。Pegasus 专为通用数据建模而设计，因此适用于大多数元数据。但是，由于 Pegasus 不提供明确的方式来建模关系或关联，我们引入了一些自定义扩展来支持这些用例。
为了演示如何使用 Pegasus 对元数据建模，让我们看一个简单的示例，该示例由以下修改后的实体关系图 (ERD) 说明。
该示例包含三种类型的实体——用户、组和数据集——在图中用蓝色圆圈表示。我们用箭头表示这些实体之间的三种关系，即 OwnedBy、HasMember 和 HasAdmin。换句话说，一个组由一个管理员和多个用户成员组成，用户可以依次拥有一个或多个数据集。
与传统的 ERD 不同，我们将实体和关系的属性分别直接放在圆圈内和关系名称下方。这允许我们将一种称为“元数据方面”的新型组件附加到实体。不同的团队可以拥有和发展同一实体的元数据的不同方面，而不会相互干扰，从而满足分布式元数据建模要求。三种类型的元数据方面：Ownership、Profile 和 Membership 在上例中作为绿色矩形包含。元数据方面与实体的关联使用虚线表示。例如，配置文件可以关联到用户，所有权可以关联到数据集等。
您可能已经注意到，实体和关系属性与元数据方面存在重叠，例如，用户的 firstName 属性应与关联配置文件的 firstName 字段相同。这种重复信息的原因将在本文的后面部分进行解释，但现在将属性视为元数据方面的“有趣部分”就足够了。
为了在 Pegasus 中对示例进行建模，我们会将每个实体、关系和元数据方面转换为单独的 Pegasus 模式文件 (PDSC)。为简洁起见，我们将在此处仅包含每个类别的一个模型。首先，让我们看一下用户实体的 PDSC：
每个实体都需要具有URN形式的全局唯一 ID ，可以将其视为类型化的 GUID。用户实体具有包括名字、姓氏和 LDAP 的属性，每个属性都映射到用户记录中的一个可选字段。
接下来是 OwnedBy 关系的 PDSC 模型：
每个关系模型自然包含“源”和“目标”字段，它们使用它们的 URN 指向特定的实体实例。该模型可以选择包含其他属性字段，例如本例中的“类型”。在这里，我们还引入了一个名为“配对”的自定义属性，以将关系限制为特定的源和目标 URN 类型对。在这种情况下，OwnedBy 关系只能用于将数据集连接到用户。
最后，您将在下面找到所有权元数据方面的模型。在这里，我们选择将所有权建模为包含类型和 ldap 字段的记录数组。但是，只要是有效的 PDSC 记录，元数据方面的建模几乎没有任何限制。这使得满足前面所说的“元数据也是数据”的要求成为可能。
创建所有模型后，下一个合乎逻辑的问题是如何将它们连接在一起以形成建议的 ERD。我们将把讨论推迟到本文后面的元数据索引部分。
元数据摄取
DataHub 提供两种形式的元数据摄取：通过直接 API 调用或Kafka流。前者适用于需要先读后写一致性的元数据更改，而后者更适合面向事实的更新。
DataHub 的 API 基于Rest.li，这是一种在 LinkedIn 中广泛使用的可扩展、强类型的 RESTful 服务架构。由于 Rest.li 使用 Pegasus 作为其接口定义，因此可以逐字使用上一节中定义的所有元数据模型。从 API 到存储需要多级模型转换的日子已经一去不复返了——API 和模型将始终保持同步。
对于基于 Kafka 的摄取，元数据生产者应发出标准化的元数据更改事件 (MCE)，其中包含对由相应实体 URN 键入的特定元数据方面的建议更改列表。虽然 MCE 的架构在Apache Avro中，但它是从 Pegasus 元数据模型自动生成的。
对 API 和 Kafka 事件模式使用相同的元数据模型使我们能够轻松地改进模型，而无需费力地维护相应的转换逻辑。然而，要实现真正的无缝模式演进，我们需要限制所有模式更改始终向后兼容。这是在构建时通过添加兼容性检查强制执行的。
在 LinkedIn，我们倾向于更多地依赖 Kafka 流，因为它在生产者和消费者之间提供了松耦合。每天，我们都会收到来自不同生产商的数百万个 MCE，而且随着我们扩大元数据收集范围，预计数量只会呈指数级增长。为了构建流元数据摄取管道，我们利用Apache Samza作为我们的流处理框架。摄取 Samza 作业的目的是快速和简单地实现高吞吐量。它只是将 Avro 数据转换回 Pegasus 并调用相应的 Rest.li API 来完成摄取。
元数据服务
一旦元数据被摄取和存储，重要的是有效地提供原始和派生的元数据。DataHub 旨在支持四种常见的大量元数据查询：
- 面向文档的查询
- 面向图的查询
- 涉及联接的复杂查询
- 全文搜索
为实现这一点，DataHub 需要使用多种数据系统，每种数据系统专门用于扩展和服务有限类型的查询。例如，Espresso是 LinkedIn 的 NoSQL 数据库，特别适合面向文档的大规模 CRUD。同样，Galene可以轻松地为网络规模的全文搜索建立索引和提供服务。当谈到非平凡的图形查询时，专用图形数据库的性能比基于 RDBMS 的实现好几个数量级也就不足为奇了。然而，事实证明，图形结构也是表示外键关系的一种自然方式，可以有效地回答复杂的连接查询。
DataHub通过一组通用的Data Access Objects（DAO），如key-value DAO、query DAO、search DAO，进一步抽象出底层数据系统。然后可以轻松地换入和换出 DAO 的特定于数据系统的实现，而无需更改 DataHub 中的任何业务逻辑。这最终将使我们能够使用流行的开源系统的参考实现来开源 DataHub，同时仍然充分利用 LinkedIn 的专有存储技术。
DAO 抽象的另一个主要好处是标准化的变更数据捕获 (CDC)。无论底层数据存储系统的类型如何，通过键值 DAO 进行的任何更新操作都会自动发出元数据审计事件 (MAE)。每个 MAE 都包含相应实体的 URN，以及特定元数据方面的前后图像。这实现了lambda 架构，其中 MAE 可以批处理或流处理。与 MCE 类似，MAE 的模式也是从元数据模型自动生成的。
元数据索引
最后一个缺失的部分是元数据索引管道。这是将元数据模型连接在一起并在图数据库和搜索引擎中创建相应索引以促进高效查询的系统。这些业务逻辑以索引生成器和图形生成器的形式捕获，并作为处理 MAE 的 Samza 作业的一部分执行。每个构建器都在作业中注册了他们对特定元数据方面的兴趣，并将使用相应的 MAE 进行调用。然后，构建器返回要应用于搜索索引或图形数据库的幂等更新列表。
元数据索引管道还具有高度可扩展性，因为它可以根据每个 MAE 的实体 URN 轻松分区，以支持每个实体的顺序处理。
总结与展望
在这篇文章中，我们介绍了 DataHub，这是我们在 LinkedIn 元数据之旅中的最新发展。该项目包括一个模块化 UI 前端和一个通用元数据架构后端。
过去六个月，DataHub 一直在 LinkedIn 的生产环境中运行。每周有 1,500 多名员工访问它，支持搜索、发现和各种特定操作工作流。LinkedIn 的元数据图包含超过 100 万个数据集、23 个数据存储系统、25k 指标、500 多个 AI 特征，最重要的是所有 LinkedIn 员工，他们是这个图的创建者、消费者和操作者。
DataHub: A generalized metadata search & discovery tool | LinkedIn Engineering