DataHub元数据治理平台架构

1.DataHub架构概述

DataHub 是第三代元数据平台，支持为现代数据堆栈构建的数据发现、协作、治理和端到端可观察性。DataHub 采用模型优先的理念，重点是解锁不同工具和系统之间的互操作性。

下图描述了DataHub的高层架构。

要更详细地了解构成该架构的组件，请查看组件。

1.1.架构亮点

DataHub的架构主要有三个亮点。

1.1.1.元数据建模

DataHub 的元数据模型是使用与序列化无关的语言来描述的。支持REST和GraphQL API 。此外，DataHub 支持基于 AVRO 的 API通过 Kafka 来传达元数据更改并订阅它们。我们的路线图包括一个里程碑，即很快支持无代码元数据模型编辑，这将提高易用性，同时保留类型化 API 的所有优势。在元数据建模中了解元数据建模。

1.1.2.基于流的实时元数据平台

DataHub 的元数据基础设施是面向流的，允许元数据的更改在几秒钟内在平台内进行通信和反映。您还可以订阅 DataHub 元数据中发生的更改，从而允许您构建实时元数据驱动的系统。例如，您可以构建一个访问控制系统，该系统可以观察以前世界可读的数据集，添加包含 PII 的新架构字段，并锁定该数据集以进行访问控制审查。

1.1.3.联合元数据服务

DataHub 附带一个元数据服务 (gms)，作为开源存储库的一部分。然而，它还支持联合元数据服务，这些服务可以由不同的团队拥有和运营——事实上，这就是 LinkedIn 在内部运行 DataHub 的方式。联合服务使用 Kafka 与中央搜索索引和图进行通信，以支持全局搜索和发现，同时仍然实现元数据所有权的解耦。这种架构非常适合实施数据网格的公司。

2.DataHub组件概述

DataHub 平台由下图所示的组件组成。

2.1.元数据存储

元数据存储负责存储构成元数据图的实体和方面。这包括公开用于摄取元数据、通过主键获取元数据、搜索实体以及获取实体之间的关系的 API 。它由托管一组Rest.li API 端点的 Spring Java 服务以及用于主存储和索引的 MySQL、Elasticsearch 和 Kafka 组成。

2.2.元数据模型

元数据模型是定义构成元数据图的实体和方面的形状以及它们之间的关系的模式。它们是使用PDL定义的，PDL 是一种建模语言，其形式与 Protobuf 非常相似，但序列化为 JSON。实体代表特定类别的元数据资产，例如数据集、仪表板、数据管道等。实体的每个实例都由称为 的唯一标识符来标识urn。方面表示附加到实体实例的相关数据包，例如其描述、标签等。在此处查看当前支持的实体集。

2.3.摄取框架

Ingestion Framework 是一个模块化、可扩展的 Python 库，用于从外部源系统（例如 Snowflake、Looker、MySQL、Kafka）提取元数据，将其转换为 DataHub 的元数据模型，并通过 Kafka 或使用元数据存储 Rest API 将其写入 DataHub直接地。DataHub 支持广泛的源连接器列表可供选择，以及许多功能，包括架构提取、表和列分析、使用信息提取等。

摄取框架的入门非常简单：只需定义一个 YAML 文件并执行datahub ingest命令即可。

2.4.GraphQL API

GraphQL API 提供了强类型、面向实体的 API，使与组成元数据图的实体的交互变得简单，包括用于向元数据实体添加和删除标签、所有者、链接等的 API ！最值得注意的是，该 API 由用户界面（如下所述）使用，以实现搜索和发现、治理、可观察性等。

2.5.用户界面

DataHub 配备了 React UI，其中包括一组不断发展的功能，使发现、管理和调试数据资产变得轻松愉快。有关当前支持的功能的完整概述，请查看功能概述。

3.元数据摄取架构

DataHub 支持极其灵活的摄取架构，可以支持推、拉、异步和同步模型。下图描述了将您喜爱的系统连接到 DataHub 的所有可能选项。

3.1.元数据变更提案：核心部分

摄取的核心部分是元数据更改提案，它表示对组织的元数据图进行元数据更改的请求。元数据更改建议可以通过 Kafka 发送，以便从源系统进行高度可扩展的异步发布。它们还可以直接发送到 DataHub 服务层公开的 HTTP 端点，以获得同步成功/失败响应。

3.2.基于拉动的集成

DataHub 附带一个基于 Python 的元数据摄取系统，可以连接到不同的源以从中提取元数据。然后，该元数据通过 Kafka 或 HTTP 推送到 DataHub 存储层。元数据摄取管道可以与 Airflow 集成，以设置计划摄取或捕获血缘。如果您没有找到已支持的源，则可以很容易地编写自己的.

3.3.基于推送的集成

只要您可以向 Kafka 发出元数据更改建议 (MCP)事件或通过 HTTP 进行 REST 调用，您就可以将任何系统与 DataHub 集成。为方便起见，DataHub 还提供简单的Python 发射器，供您集成到系统中，以在源点发射元数据更改 (MCP-s)。

3.4.内部组件

将元数据更改提案应用于 DataHub 元数据服务 (mce-consumer-job )

DataHub 附带了一个 Spring 作业mce-consumer-job，它使用元数据更改提案并使用端点将它们写入 DataHub 元数据服务 (datahub-gms) /ingest。

4.DataHub服务架构

下图显示了 DataHub 服务层的高级系统图。

主要组件称为元数据服务，并公开 REST API 和 GraphQL API，用于对元数据执行 CRUD 操作。该服务还公开搜索和图形查询 API，以支持二级索引样式查询、全文搜索查询以及血缘等关系查询。此外，datahub-frontend服务在元数据图之上公开了 GraphQL API。

4.1.DataHub 服务层组件

4.1.1.元数据存储

DataHub 元数据服务将元数据保存在文档存储（RDBMS，如 MySQL、Postgres 或 Cassandra 等）中。

4.1.2.元数据更改日志流 (MCL )

当元数据更改已成功提交到持久存储时，DataHub 服务层还会发出提交事件元数据更改日志。该事件通过 Kafka 发送。

MCL 流是一个公共 API，可以由外部系统（例如操作框架）订阅，提供一种极其强大的方式来实时响应元数据中发生的更改。例如，您可以构建一个访问控制执行器，对元数据的更改做出反应（例如，以前世界可读的数据集现在有一个 pii 字段），以立即锁定有问题的数据集。请注意，并非所有 MCP 都会生成 MCL，因为 DataHub 服务层将忽略对元数据的任何重复更改。

4.1.3.元数据索引应用程序（mae-consumer-job ）

元数据更改日志由另一个 Spring 作业mae-consumer-job消耗，该作业将更改相应地应用于图表和搜索索引。该作业与实体无关，并将执行相应的图形和搜索索引构建器，当特定元数据方面发生更改时，作业将调用这些构建器。构建器应指示作业如何根据元数据更改更新图形和搜索索引。

为了确保按正确的时间顺序处理元数据更改，MCL 由实体URN键入- 这意味着特定实体的所有 MAE 将由单个线程按顺序处理。

4.1.4.元数据查询服务

对元数据的基于主键的读取（例如，基于 获取数据集的模式元数据dataset-urn）将被路由到文档存储。基于二级索引的元数据读取将路由到搜索索引（或者也可以使用此处描述的强一致二级索引支持）。全文和高级搜索查询将路由到搜索索引。复杂的图形查询（例如血缘）将路由到图形索引。

原文链接：https://datahubproject.io/docs/architecture/architecture