原文地址：OpenMetadata vs. DataHub: Compare Architecture, Capabilities, Integrations & More
OpenMetadata 是一个开源元数据存储库，由 Uber 元数据基础架构背后的团队构建。DataHub 是 LinkedIn 推出的一款开源数据编目工具。
这两款工具在数据编目、搜索、发现、管理和质量方面提供了类似的功能。
在本文中，我们将比较 OpenMetadata 和 DataHub 的架构、技术栈、元数据建模和摄取设置、功能和集成。
OpenMetadata 和 DataHub 是目前最流行的两种开源数据编目工具。这两个工具在功能上有很大的重叠，但也有一些不同之处。在此，我们将根据这两个工具的架构、摄取方法、功能、可用集成等进行比较。
OpenMetadata 是创建 Databook 以解决 Uber 数据编目问题的团队的学习成果。OpenMetadata 考察了现有的数据编目系统，发现拼图中缺少的是统一的元数据模型。
除此之外，他们还增加了元数据的灵活性和可扩展性。尽管如此，OpenMetadata 因为其在市场上的新颖性、可靠的数据管理引擎和强大的搜索引擎的支持而备受关注。
DataHub 是 LinkedIn 解决数据发现和编目问题的第二次尝试；此前，他们曾开源了另一款名为 WhereHows 的工具。
在第二次迭代中，LinkedIn 通过创建作为 DataHub 骨干的通用元数据服务，解决了数据系统、查询语言和访问机制种类繁多的问题。
让我们根据以下标准来比较 OpenMetadata 与 DataHub：
我们整理了上述标准，以便对这些工具进行比较，同时了解哪些因素至关重要——尤其是如果您要选择其中一个元数据管理平台来推动企业的特定用例的话。
让我们详细考虑一下这些因素，并阐明我们对它们的理解。
DataHub 使用以 Kafka 为媒介的摄取引擎，将数据存储在三个独立的层中——MySQL、Elasticsearch 和使用 Kafka 流的 neo4j。
这些层中的数据通过 API 服务层提供。除了标准的REST API外，DataHub 还支持Kafka和GraphQL，以便下游消费。DataHub 使用带有自定义注释的 Pegasus 定义语言（PDL）来存储模型元数据。
OpenMetadata 使用 MySQL 作为数据库，在统一的元数据模型中存储所有元数据。元数据由 Elasticsearch 提供支持，与 DataHub 相同，因此可以彻底搜索。OpenMetadata 不使用专用的图数据库，但使用 JSON 模式来存储实体关系。
使用 OpenMetadata 的系统和人员可直接调用或通过用户界面与 REST API 交互。要了解有关数据模型的更多信息，请参阅解释 OpenMetadata 高层设计的文档页面。
这两款工具的主要区别之一是，DataHub 既注重基于拉的数据提取，也注重基于推的数据提取，而 OpenMetadata 显然偏向为拉的数据提取机制而设计。
默认情况下，DataHub 和 OpenMetadata 都主要使用基于推送的提取，但区别在于 DataHub 使用 Kafka 而 OpenMetadata 使用 Airflow 来提取数据。
DataHub 中的不同服务可以过滤 Kafka 中的数据并提取所需内容，而 OpenMetadata 的 Airflow 则将数据推送到 API 服务器 DropWizard，供下游应用使用。
这两种工具在存储元数据的方式上也有所不同。如上一节所述，DataHub 使用带注释的 PDL，而 OpenMetadata 使用带注释的基于 JSON 架构的文档。
在今年早些时候发布的一个版本中，DataHub 集成了他们的行动框架（Action Framework），以增强数据治理引擎。Action Framework 是一个基于事件的系统，可以触发外部工作流以达到可观察性的目的。数据治理引擎会自动注释新的和已更改的实体。
OpenMetadata 和 DataHub 都有内置的基于角色的访问控制，用于管理访问和所有权。
OpenMetadata 引入了其他一些概念，如 “重要性”（Importance），通过附加上下文提供更好的搜索和发现体验。DataHub 使用一种名为 “域”（Domains）的结构，作为常规标签和词汇表术语之上的高级标签，为您提供更好的搜索体验。
DataHub 比 OpenMetadata 更早支持列级数据血缘。
OpenMetadata 的行数据 Python SDK 允许您使用用于存储行数据的 entityLineage 模式规范，从数据源实体中获取自定义行数据。
除了自动线程捕获外，DataHub 还可让您从称为 "基于文件的线程 "的数据源以文件形式摄取线程数据。DataHub 使用指定的基于 YAML 的 lineage 文件格式。
尽管 DataHub 在前不久的路线图中列出了某些与数据质量相关的功能，但这些功能尚未实现。不过，DataHub 确实提供了与 Great Expectations 和 dbt 等工具的集成。您可以使用这些工具获取元数据及其测试和验证结果。
OpenMetadata 对数据质量有不同的看法。他们在工具中集成了数据质量和剖析功能。由于检查数据质量的开源工具很多，定义测试的方法也很多，但 OpenMetadata 选择在定义测试的元数据标准方面支持 Great Expectations。
如果 Great Expectations 已经与你的其他工作流程集成，而你希望将它作为你的核心数据质量工具，你可以通过 OpenMetadata 的 Great Expectations 集成来实现。
DataHub 和 OpenMetadata 都有一个基于插件的元数据摄取架构。这使它们都能与数据堆栈中的一系列工具顺利集成。
DataHub 提供 GraphQL API、开放式 API 和一些 SDK，供您的应用程序或工具开发并与 DataHub 交互。此外，您还可以使用 CLI 安装所需的插件。通过这些与 DataHub 交互的不同方法，您既可以将数据摄入 DataHub，也可以将数据取出 DataHub 以供进一步使用。
OpenMetadata 支持 50 多个用于摄取元数据的连接器，从数据库到 BI 工具，从消息队列到数据管道，包括其他元数据编目工具，如 Apache Atlas 和 Amundsen。OpenMetadata 目前提供两种集成—— Great Expectations 和 Prefect。
DataHub 和 OpenMetadata 都试图解决与数据编目、搜索、发现、管理和质量有关的相同问题。这两款工具的诞生都是为了解决拥有大量数据源、团队和用例的大型企业的这些问题。
虽然这两款工具在发布历史和成熟度上有一定差距，但在功能上却有很大的重叠。下面是其中一些功能的快速总结：
| 功能 | OpenMetadata | DataHub |
|---|---|---|
| 搜索和发现 | Elasticsearch | Elasticsearch |
| 元数据后端 | MySQL | MySQL |
| 元数据模型规范 | JSON 模式 | Pegasus 定义语言 (PDL) |
| 元数据提取 | 拉和推 | 拉 |
| 元数据摄取 | 拉动 | 拉动 |
| 数据管理 | RBAC、术语表、标签、重要性、所有者，以及扩展实体元数据的能力 | RBAC、标签、术语表术语、域和行动框架 |
| 数据血缘 | 列级（即将推出） | 列级 |
| 数据剖析 | 内置，可使用外部工具 | 通过第三方集成，如 dbt 和 Great Expectations |
| 数据质量 | 内置，可使用 Great Expectations 等外部工具 | 通过第三方集成，如 dbt 和 Great Expectations |