【翻译】DataHub：流行的元数据架构讲解

原文：https://engineering.linkedin.com/blog/2020/datahub-popular-metadata-architectures-explained

数据发现：一个问题，多种解决方案

什么是数据目录？

为什么需要目录？

第一代架构：Monolith 一切

好处

缺点

这对我意味着什么？

第二代架构：带有服务 API 的三层应用

好处

缺点

这对我意味着什么？

第三代架构：基于事件的元数据

第 1 步：面向日志的元数据架构

第 2 步：面向领域的解耦元数据模型

好处

不足

这对我意味着什么？

一个好的架构就足够了吗？

加入对话

十年前，当我开始在 LinkedIn 旅程时，公司刚刚开始经历数据在数量、种类和速度的急剧增长。在接下来的几年里，我和 LinkedIn 数据基础设施团队的同事建立了 Espresso、Databus 和 Kafka 等基础技术，以确保 LinkedIn 能够在下一波增长中生存和发展。几年后，我成为当时规模相当小的“数据分析基础设施”团队的技术负责人，该团队运维 LinkedIn 的 Hadoop 使用，并维护一个跨 Hadoop 和 Teradata 的混合数据仓库。

我注意到的第一件事是人们经常询问“正确的数据集”以用于他们的分析。这让我意识到，虽然我们已经构建了高度可扩展的专用数据存储、流功能和具有成本效益的批量计算功能，但我们仍然在浪费时间来寻找合适的数据集来执行分析。

数据发现：一个问题，多种解决方案

快进到今天，我们生活在数据的黄金时代。当数据科学家加入一家数据驱动的公司时，他们希望找到一个数据发现工具（即数据目录），他们可以用它来找出公司中存在哪些数据集，以及他们如何使用这些数据集来测试新假设并产生新的见解。大多数数据科学家并不真正关心这个工具实际上是如何工作的，只要它能让他们提高工作效率。

事实上，有许多可用的数据发现解决方案：可供购买的专有软件、特定公司提供的开源软件和内部构建的软件的组合。过去几年，LinkedIn、Airbnb、Lyft、Spotify、Shopify、Uber 和 Facebook 都分享了他们自己的数据发现解决方案的细节。这就引出了一个问题：这些平台有何不同，对于考虑采用其中一种工具的公司来说，哪种选择最合适？

数据目录的架构将影响您的组织可以真正从数据中提取多少价值。此外，目录很粘，需要很长时间才能在公司中集成和实施。因此，谨慎选择数据发现解决方案非常重要。

在这篇文章中，我将描述行业迄今为止为数据发现工具开发的三代架构，并解释许多行业内知名的案例。LinkedIn DataHub 架构的演变也反映了这种代际之间的进步，因为我们推动了最新的最佳实践（首先在 2016 年开源并作为 WhereHows 与世界共享，然后完全重写并重新开源共享） 2019 年作为 DataHub 的开源社区）。

希望本文能帮助您在选择自己的数据发现解决方案时做出最佳决策。

什么是数据目录？

在我们深入研究不同的架构之前，让我们按顺序了解我们的定义。我发现的最简单的数据目录定义来自 Oracle 网站：“简单地说，数据目录是组织中--数据资产的有组织的清单。它使用元数据来帮助组织管理他们的数据。它还可以帮助数据专业人员收集、组织、访问和丰富元数据，以支持数据发现和治理。”

三十年前，数据资产可能是 Oracle 数据库中的一张表。然而，在现代企业中，我们拥有一系列令人眼花缭乱的不同类型的资产，这些资产构成了环境：关系数据库或 NoSQL 存储中的表、您最喜欢的流存储中的流、人工智能系统中的功能、指标平台中的指标，您最喜欢的可视化工具中的仪表板等。现代数据目录预计将包含所有这些类型的数据资产的清单，并使数据工作者能够更高效地使用这些资产完成工作。

为什么需要目录？

在您决定购买或采用特定的数据目录解决方案或构建自己的解决方案之前，您应该首先问自己：您希望通过数据目录为您的企业实现哪些功能？

一个重要的问题--您希望在数据目录中存储哪些类型的元数据，因为这直接影响您可以启用的用例类型。

以下是一些常见用例及其所需元数据类型的示例：

搜索和发现：数据schema、字段、标签、使用信息
访问控制：访问控制组、用户、策略
数据血缘：任务执行、查询、API 日志、API 模式
合规性：数据隐私/合规性注释类型的分类
数据管理：数据源配置、摄取配置、保留配置、数据清除策略（例如，针对 GDPR“被遗忘权”）、数据导出策略（例如，针对 GDPR“访问权”）
AI 可解释性、再现性：特征定义、模型定义、训练运行执行、问题陈述
数据操作：管道执行、处理的数据分区、数据统计
数据质量：数据质量规则定义、规则执行结果、数据统计

一个有趣的观察结果是，每个单独的用例通常都会带来自己特殊的元数据需求，但还需要连接到其他用例的元数据。当我们深入研究这些数据目录的不同架构及其对您成功的影响时，我们将回顾这一见解。

第一代架构：Monolith 一切

下图描述了第一代元数据架构。它通常是一个经典的单体前端（可能是一个 Flask 应用程序），连接到主要存储进行查找（通常是 MySQL/Postgres），一个用于服务搜索查询的搜索索引（通常是 Elasticsearch），并且对于该架构的第 1.5 代，可能是一个图形索引，用于在达到“递归查询”的关系数据库的限制时处理谱系（通常是 Neo4j）的图查询。

元数据通常通过连接到元数据源（如数据库目录、Hive 目录、Kafka 架构注册表或工作流编排器的日志文件）使用爬取方法摄取，然后将此元数据与需要的部分一起写入主存储并添加到搜索索引和图形索引中。这种爬行通常是单个进程（非并行），每天运行一次左右。在这种抓取和摄取过程中，原始元数据通常会转换为应用程序的元数据模型，因为数据很少采用目录所需的确切形式。通常，此转换直接嵌入到摄取作业中。

该架构的稍微高级的版本也将允许批处理作业（例如，Spark 作业）大规模处理元数据、计算关系、推荐等，然后将此元数据加载到存储和索引中。

通常需要几个工程师两周左右的时间来建立这个基本后端架构的第一个原型并将数据加载到其中。另外，建立一个简单的前端可能需要几周时间，该前端可以显示此元数据并支持简单搜索。

好处

以下是关于这种架构的优点。

很少的活动部分：只需一个主存储、一个搜索索引和一些爬虫，您就可以快速聚合元数据并构建一个有用的应用程序，使数据工作者提高工作效率。没有多少基础设施需要您来运营。
一个团队可以做很多事情：该架构面向一个能够访问元数据源并可以构建应用程序来为其提供服务的团队。

缺点

但是，这种架构确实存在一些问题。我只强调前两个。

push vs pull：虽然爬取数据源作为一种收集元数据的方式很容易开始，但很快这些摄取任务开始显示出脆弱的迹象。爬虫运行在与数据源不同的环境中，其配置需要由中央团队单独管理。因此，这些管道中的一组问题是网络连接（防火墙规则）或凭证共享（密码可以在不通知中央团队的情况下更改）等操作障碍。另一组问题更微妙，但本质上也是可操作的。基于爬虫的摄取通常会导致批量（您多久调用一次源？）和非增量（我们应该在一次拉取中检索多少记录？）的工作负载。这让你的数据源的运维团队非常不高兴，因为没有人喜欢在半夜被一个熔断的数据库或一个没有响应的 HDFS Namenode 吵醒，然后发现它在报警，因为元数据爬虫导致的。此类问题的第一个受害者通常是元数据爬虫任务！您的元数据摄取任务将暂停--当运维团队致力于让系统恢复健康时，他们通常会要求元数据爬虫长时间保持暂停，即使系统已恢复。同时，您的元数据变得“越来越陈旧”，导致对目录的信任度降低。这就给我们带来了第二个问题。
元数据新鲜度：与push & pull的决策密切相关的是数据（元数据）新鲜度的问题。在元数据之旅开始时，每晚爬取一次 Hive 元存储（或 S3 存储桶）并填充目录似乎完全没问题。毕竟，你只是想让数据科学家比以前更有效率。但是，一旦您开始进入数据创建工作流程（例如，一旦您创建了一些数据，您可以来到这里并提供数据分类标签）或提供操作元数据（例如，您最新分区的数据质量清单），然后元数据的新鲜度开始变得更加重要。如果您只有一个基于爬虫的元数据目录，那么此时您大概率会很不走运。

这对我意味着什么？

作为读者，您可能会想，“那么，第一代元数据系统是什么？” Amundsen 采用了这种架构，我们在 2016 年开源的 WhereHows 原始版本也是如此。在内部系统中，Spotify 的 Lexikon、Shopify 的 Artifact 和 Airbnb 的 Dataportal 也遵循相同的架构。

这些系统在提高人们使用数据的效率方面发挥着重要作用，但在保持高保真数据清单和启用元数据的程序化用例方面可能会挣扎。

第二代架构：带有服务 API 的三层应用

下图描述第二代元数据架构。单体应用程序已拆分为前后端分离的服务。该服务提供了一个 API，允许使用推送机制将元数据写入系统，需要以编程方式读取元数据的程序可以使用此 API 读取元数据。但是，通过此 API 可访问的所有元数据仍存储在单个元数据存储中，该存储可以是单个关系数据库或扩展的键值存储。

好处

让我们谈谈随着这种演变发生的好处。

更好的契约会带来更好的结果：提供基于推送的schema定义，可以立即在元数据生产者和“元数据团队”之间创建良好的合同。您仍然需要说服生产团队提交元数据并获取依赖项，但使用商定的schema来做到这一点要容易得多。

启用编程用例：通过服务 API，团队可以为元数据启用编程用例。

例如，如果您的数据应用程序允许使用指定语义类型的字段打标（例如，email_address、customer_identifier），您的数据管理基础架构可以允许使用此元数据自动删除已请求被过滤的客户 ID 的数据资产，或者为数据科学家自动创建这些数据集的脱敏版本。事实上，在 LinkedIn，我们使用 Apache Gobblin 来做到这一点，由来自 DataHub 的元数据驱动。

缺点

但是，这种架构仍然存在一些值得商榷的问题。

没有变更日志：第二代架构提供了一个基于微服务的 API 来读写元数据，但没有内置支持从外部系统流式传输元数据更改或订阅元数据更改流。您可能熟悉这篇关于为什么日志应该成为数据生态系统核心的流行博客文章。事实证明，元数据实际上也是如此。作为一流的产品，现代数据目录应该能够实时订阅元数据的变化。

如果没有元数据日志，当出现问题时，很难可靠地引导（重新创建）或修复您的搜索和图形索引。如果没有实时元数据更改日志，也不可能在中央元数据平台之上构建高效的反应式系统，例如数据触发器或访问控制滥用检测系统。要构建这样的东西，您将被迫通过过度轮询或完全扫描使用键值 API 访问元数据。或者，您需要等待元数据数据库的夜间 ETL完成才能最终处理。我们经历了那段痛苦的数据之旅，我们真的很想跳过它以获取元数据！然而，现代元数据系统经常忘记针对这一重要功能进行设计。

对元数据团队的问题：这种架构的另一个大问题是它在太多事情上继续依赖于元数据团队，维护元数据模型，运行中央元数据服务以及数据存储和索引，并支持所有下游消费者以及他们想要访问元数据的不同方式。这严重限制了团队为公司中存在的其他问题（生产力、治理、AI 可解释性等）提供支持的能力。例如，在 LinkedIn，当我们仍处于元数据架构的第二代时，我们让我们的数据质量团队构建了一个单独的 UI 和元数据存储来存储规则并在数据集上显示数据质量结果。基于服务的集成的运营影响还导致生产者和中央服务的可用性紧密耦合，这让采用者担心在他们的堆栈中增加一个停机时间源。

数据工程本身正在演变成这样一种的模型——去中心化正在成为常态。因此，如果试图跟上元数据生态系统快速发展的复杂性，那元数据团队不应该犯同样的错误。

这对我意味着什么？

在商业元数据系统中，Collibra 和 Alation 似乎具有第二代架构。在开源元数据系统中，Marquez 拥有第二代元数据架构。我的经验是，第二代元数据系统通常可以成为公司数据资产的可靠搜索和发现门户，因此它们确实满足了数据工作者的生产力需求。他们还可以开始提供基于服务的集成到编程工作流中，例如访问控制配置。当我们通过添加基于推送的架构和用于存储和检索此元数据的专用服务将 WhereHows 从 Gen 1 演变为 Gen 2 时，我们实际上经历了这一过程。

然而，集中化瓶颈通常会导致为不同的用例构建或采用新的、独立的目录系统，这会削弱统一、一致的元数据图的能力。为其数据科学家构建或采用搜索和发现门户的公司有时最终也会为其业务部门安装具有自己的元数据后端的不同数据治理产品。为了使数据集定义和术语表保持同步，这些公司必须构建和监控新的数据任务以可靠地复制元数据，这些元数据使用不同的元数据模型在各种不通目录中。该问题不仅存在于大公司，还可能影响任何已达到一定数据素养水平并支持元数据多样化用例的组织。

第三代架构：基于事件的元数据

导致第三代元数据架构的关键洞察是，基于“中央服务”的元数据解决方案难以跟上企业对元数据用例的需求。为了解决这个问题，必须满足两个需求。首先是元数据本身需要是自由流动的、基于事件的、可实时订阅的。第二个是元数据模型必须支持随着新扩展和添加的出现而不断发展——而不会受限于中央团队。这将使元数据始终可以被多种类型的消费者大规模使用和扩展。

第 1 步：面向日志的元数据架构

元数据提供者可以推送到基于流的 API 或针对目录的服务 API 执行 CRUD 操作，具体取决于他们的偏好。对元数据的由此产生的更改将反过来生成元数据更改日志。对于所有所需的查询模式，此元数据日志可以自动地转化为适当的存储和索引（例如，搜索索引、图形索引、数据湖、olap 存储）。这产生了一个为现代企业做好准备的非捆绑元数据数据库架构，如下图所示。现在日志是元数据领域的中心，如果出现任何不一致，您可以随意引导图形索引或搜索索引，并确定性地修复错误。

第 2 步：面向领域的解耦元数据模型

除了流优先架构之外，第三代目录还支持企业协同定义可扩展的强类型元数据模型和关系。强类型很重要，因为没有它，我们将只能获得元数据存储中的通用属性。这使得元数据的编程消费者无法在保证向后兼容性的情况下处理元数据。

在下面的元数据模型图中，我们使用 DataHub 的实体类型、方面和关系的术语来描述具有三种实体的图：数据集、用户和组。不同的方面，例如所有权、个人资料等。可以由不同的团队附加到这些实体，从而在这些实体类型之间创建关系。请注意，可以有多种方法来描述这些图模型，从基于 RDF 的模型到成熟的 ER 模型，再到 DataHub 使用的自定义混合方法。

这种建模使团队能够通过添加特定领域的扩展来改进全局元数据模型，而不会受到中央团队的阻碍。例如，合规团队可能会签入所有权方面，而核心元数据团队可能会签入数据集实体的架构方面。同时，数据摄取团队可能会为 Dataset 实体设计和签入备份配置方面。所有这些对模型的添加都可以独立发生，耦合点最小。当然，在我们将它们引入图中之前，需要对核心实体类型进行管理和商定。

好处

随着这种演变，客户可以根据他们的需要以不同的方式与元数据数据库交互。他们获得基于流的元数据日志（用于摄取和更改消费）、元数据的低延迟查找、对元数据属性进行全文和排名搜索的能力、对元数据关系的图形查询以及全扫描和分析能力。可以在此元数据流之上构建具有不同核心元数据模型扩展的不同用例和应用程序，而不会牺牲一致性或新鲜度。您还可以将此元数据与您的开发工具（例如 git）集成，方法是与代码一起创作和版本化此元数据。元数据的改进和丰富可以通过以低延迟处理元数据更改日志或通过批处理压缩的元数据日志作为数据湖上的表来执行。下图显示了该架构的完全实现版本的样子：

任何全局企业元数据需求，例如全局生命周期管理、审计或合规性，都可以通过构建以流形式或批处理形式查询此全局元数据的工作流来解决。

良好的第三代元数据架构实施的典型标志是，您始终能够以最详细的形式读取最新的元数据并对其采取行动，而不会失去一致性。当我们从 LinkedIn 的 WhereHows（第 2 代）过渡到 DataHub（第 3 代）时，我们发现我们能够极大地提高对元数据的信任度，从而使元数据系统成为企业的中心。现在它正在成为数据工作者的起点，因为他们能在这里研究新假设、发现新指标、管理现有数据资产的生命周期等。

不足

丰富往往与复杂相伴而生。第三代元数据系统通常会有一些移动部件，需要对这些部件进行设置，才能使整个系统正常运行。拥有少量数据工程师的公司可能会发现自己对实现简单用例所需的工作量感到厌烦，并怀疑最初的时间和精力投入是否值得长期回报。然而，像 DataHub 这样的第三代元数据系统开始在可用性和开箱即用体验方面取得重大进步，以确保这种情况不会发生。

这对我意味着什么？

在我们调查的所有系统中，唯一拥有第三代元数据架构的系统是 Apache Atlas、Egeria、Uber Databook 和 DataHub。其中，Apache Atlas 与Hadoop 生态系统紧密耦合。一些公司正在尝试将 Amundsen 附加到 Atlas 之上，以尝试两全其美，但这种集成似乎存在一些挑战。例如，您必须摄取元数据并将其存储在 Atlas 的图形和搜索索引中，完全绕过 Amundsen 的数据摄取、存储和索引模块。这意味着您想要建模的任何新概念都需要作为 Atlas 概念引入，然后与 Amundsen 的 UI 桥接，从而导致相当多的复杂性。Egeria 支持通过元数据事件总线集成不同的目录，但在撰写本文时，它的功能似乎尚未完成。 Uber Databook 似乎基于与 DataHub 非常相似的设计原则，但不是开源的。当然，由于我们对 DataHub 的个人经验会有偏见，但开源的 DataHub 提供了第三代元数据系统的所有好处，能够支持多种类型的实体和关系以及流优先架构。

在 LinkedIn，DataHub 的部署包括数据集、模式、流、合规性注释、GraphQL 端点、指标、仪表板、功能和 AI 模型，使其在经过验证的规模和战备方面真正成为第三代。它通常在一天内处理超过 1000 万个实体和关系更改事件，总计索引超过 500 万个实体和关系，同时以低毫秒级 SLA 提供操作元数据查询，从而为我们的员工提供数据生产力、合规性和治理工作流。

这是当今元数据格局的简单直观表示。

当然，这只是当今不同系统所处位置的当前快照。随着企业对元数据的需求不断增长，第三代系统和更新等可能会进一步整合。

一个好的架构就足够了吗？

看起来，通过 DataHub 实现的第三代架构，我们已经获得了一个良好的元数据架构，它是可扩展的，并且可以很好地服务于我们的许多用例。在这方面还有其他需要解决的事情吗？简短的回答是“是的”。第三代元数据架构确保您能够以最具可扩展性和灵活性的方式集成、存储和处理元数据。但这还不够。您首先需要定义正确的元数据模型，以真正捕捉对您的企业有意义的概念。然后，您需要一个支持 AI 的途径，从这个完整、可靠的数据资产清单过渡到一个可信的元数据知识图。这将使您真正为您的企业释放生产力和治理能力。但那是另一天的另一篇博文！

加入对话

我们正在与一些领先的思想家和影响者合作，于 12 月 14 日举办虚拟元数据峰会，将深入探讨所有这些问题以及更多问题。参加互动活动，了解围绕元数据的项目、想法和用例的多样性，并听取领先从业者和思想领袖关于将元数据投入生产的挑战和前进的方向。我们期待与您合作！