https://engineering.linkedin.com/blog/2020/datahub-popular-metadata-architectures-explained前言
十年前，当我开始在 LinkedIn 工作时，公司刚刚开始经历数据的数量、种类和速度的极速增长。在接下来的几年里，我和 LinkedIn 数据基础架构团队的同事们开发了 Espresso、Databus 和 Kafka 等基础技术，以确保 LinkedIn 能够在下一波增长浪潮中生存并茁壮成长。几年后，我成为当时规模相当小的 “数据分析基础架构” 团队的技术负责人，该团队负责运行和支持 LinkedIn 的 Hadoop 使用，还负责维护横跨 Hadoop 和 Teradata 的混合数据仓库。
我注意到的第一件事是，大家经常四处打听用于分析的 “正确数据集（原文：right dataset）”。这让我意识到，虽然我们已经建立了高度可扩展的专用数据存储、流功能和具有成本效益的批量计算功能，但我们仍在浪费时间寻找合适的数据集来进行分析。
数据发现： 一个问题，多种解决方案
时至今日，我们正生活在数据的黄金时代。当数据科学家加入一家数据驱动型公司时，他们希望能找到一个数据发现工具（即数据目录），用来找出公司存在哪些数据集，以及如何使用这些数据集来测试新假设和产生新见解。大多数数据科学家其实并不关心这个工具在引擎盖下的实际工作原理，只要能让他们提高工作效率就行。
事实上，有许多数据发现解决方案可供选择：既有可供购买的专有软件，也有特定公司提供的开源软件，还有公司内部开发的软件。在过去几年中，LinkedIn、Airbnb、Lyft、Spotify、Shopify、Uber 和 Facebook 都分享了各自数据发现解决方案的细节。这就引出了一个问题：这些平台各有什么不同，对于打算采用这些工具的公司来说，哪种选择是最好的呢？
数据目录的架构将影响企业从数据中真正提取价值的程度。此外，数据目录具有粘性，需要很长时间才能在公司内集成和实现。因此，谨慎选择数据发现解决方案非常重要。
在本篇文章中，我将介绍业界迄今为止为数据发现工具所提供的三代架构，并解释许多最知名的选项在这三代架构中的位置。这三代之间的发展也反映了 LinkedIn DataHub 架构的演变，我们一直在推动最新的最佳实践（2016 年首次开源并作为 WhereHows 与世界共享，然后在 2019 年完全重写并作为 DataHub 与开源社区重新共享）。
希望这篇文章能帮助您在选择自己的数据发现解决方案时做出最佳决策。
什么是数据目录？
在深入探讨不同的架构之前，让我们先理清定义。我从 Oracle 网站上找到了关于数据目录的一个最简单的定义：“简单地说，数据目录是组织中数据资产的有组织清单。它使用元数据来帮助组织管理数据。它还可以帮助数据专业人员收集、组织、访问和丰富元数据，以支持数据发现和治理”。
30 年前，数据资产可能是 Oracle 数据库中的一个表。然而，在现代企业中，我们拥有各种令人眼花缭乱的资产：关系数据库或 NoSQL 存储中的表格、您最喜欢的流存储中的流、您的人工智能系统中的功能、您的度量平台中的度量、您最喜欢的可视化工具中的仪表板等。现代数据目录有望包含所有这些类型数据资产的清单，并使数据工作者能够更有效地利用这些资产完成工作。
为什么需要目录？
在决定购买或采用特定的数据目录解决方案或构建自己的数据目录之前，首先应该问一问自己想通过数据目录为企业实现哪些功能。与此相关的一个重要问题是，你想在数据目录中存储哪些类型的元数据，因为这直接影响到你可以启用的用例类型。
下面是一些常见的使用案例及其所需的元数据类型示例：
- 搜索和发现： 数据模式、字段、标签、数据使用信息
- 访问控制： 访问控制组、用户、策略
- 数据关系： 流水线执行、查询、API 日志、API 模式
- 合规性： 数据隐私/合规性注释类型的分类标准
- 数据管理： 数据源配置、数据集成配置、数据历史版本策略、数据清除策略（例如，针对通用数据保护条例（GDPR） 的 “被遗忘权”、数据导出策略（例如，针对通用数据保护条例（GDPR）的“访问权”）。
- 人工智能可解释性、可重复性： 特征定义、模型定义、训练运行执行、问题陈述
- 数据操作：流水线执行、处理的数据分区、数据统计
- 数据质量： 数据质量规则定义、规则执行结果、数据统计
一个有趣的现象是，每个用例通常都会带来自己的特殊元数据需求，但同时也需要与其他用例带来的现有元数据进行连接。当我们深入探讨这些数据目录的不同架构及其对成功的影响时，我们会再次提到这一观点。
第一代架构： 一切皆单体
下图描述了第一代元数据架构。它通常是一个经典的单体前端（也许是一个 Flask 应用程序），连接到一个主存储器用于查询（通常是 MySQL/Postgres），一个搜索索引用于提供搜索查询（通常是 Elasticsearch），对于该架构的第 1.5 代，也许是一个图索引，用于处理线程的图查询（通常是 Neo4j），一旦你在“递归查询”方面遇到关系数据库的限制。
第一代架构： 基于主动抓取机制的 ETL
元数据的获取通常采用主动抓取方式，即连接到数据库目录、Hive catalog、Kafka shema registry 或工作流协调器的日志文件等元数据源，然后将这些元数据写入主存储，并将需要索引的部分添加到搜索索引和图索引中。这种抓取通常是单个流程（非并行），每天运行一次左右。在这种抓取过程中，通常会将原始元数据转换为应用程序的元数据模型，因为数据很少是目录想要的精确形式。通常情况下，这种转换会直接嵌入到抓取任务中。
这种架构的稍高级版本还允许批处理作业（如 Spark 作业）大规模处理元数据、计算关系、推荐等，然后将这些元数据加载到存储和索引中。
一般来说，几个工程师需要两周左右的时间才能建立这种基本后端架构的第一个原型，并将数据加载到其中。另外，建立一个简单的前端也需要几周时间，这个前端可以显示这些元数据并支持简单的搜索。
优点
- 活动部件少： 只需一个查询存储库、一个搜索索引和几个爬虫，就能快速聚合元数据并构建一个有用的应用程序，从而提高数据工作者的工作效率。为了证明这一点，你不需要建立和运行很多基础设施。
- 一个团队可以做很多事情： 这种架构面向有能力访问元数据源并能构建应用程序为其提供服务的单一团队。
缺点
不过，这种架构也有一些真正的缺点。我只想强调其中的前两个。
- 推送（Push）与拉取（Pull）： 将爬取数据源作为一种收集元数据并将其聚合到一个地方的方法很容易上手，但很快这些摄取管道就开始显示出脆弱的迹象。爬虫运行在与数据源不同的环境中，其配置需要由中央团队单独管理。因此，这些管道中的一组问题是操作障碍，如网络连接（防火墙规则）或凭据共享（密码可以在不通知中央团队的情况下更改）。
另一组问题更为微妙，但本质上也是操作问题。基于抓取的摄取通常会导致批量（你多长时间调用一次数据源？这让数据源的运营团队非常不满，因为没有人喜欢半夜被融化的数据库或无响应的 HDFS Namenode 惊醒，发现它正在呻吟，因为元数据爬虫已经将它推到了边缘。此类运行问题的第一个受害者通常是元数据爬虫管道，无论它是否真正负有责任！您的元数据摄取管道将被暂停，在运营团队努力使系统恢复健康的同时，他们通常会要求元数据爬虫在较长时间内保持暂停状态，即使系统已经恢复。与此同时，您的元数据会变得越来越 "陈旧"，导致对目录的信任度降低。这就引出了第二个问题。 - 元数据的新鲜度： 与“推”还是“拉”的决定密切相关的是数据（这里指元数据）的新鲜度问题。在元数据之旅的开始阶段，每晚抓取一次 Hive metastore（或 S3 存储桶）并填充目录似乎完全没有问题。毕竟，您只是想让数据科学家比以前更有效率。但是，一旦开始进入数据创建工作流（例如，一旦创建了一些数据，就可以来这里提供数据分类标签）或提供操作元数据（例如，最新分区的数据质量清单），那么元数据的新鲜度就开始变得更加重要。如果你只有一个基于抓取的元数据目录，那你在这一点上基本就没戏了。
这对我意味着什么？
作为读者，你可能会想：“那么，现在有哪些第一代元数据系统呢？” Amundsen 采用了这种架构，我们在 2016 年开源的 WhereHows 原始版本也是如此。在内部系统中，Spotify 的 Lexikon、Shopify 的 Artifact 和 Airbnb 的 Dataportal 也采用了相同的架构。
这些系统在提高人类使用数据的效率方面发挥了重要作用，但在保持高保真数据清单和实现元数据的程序化用例方面却显得力不从心。
第二代架构： 带有服务应用程序接口的 3 层应用程序
下图描述了我认为的第二代元数据架构。单体应用程序被拆分成一个服务，位于元数据存储数据库的前面。该服务提供了一个应用程序接口（API），允许使用推送机制将元数据写入系统，需要以编程方式读取元数据的程序可以使用该应用程序接口读取元数据。不过，通过该应用程序接口访问的所有元数据仍存储在一个元数据存储库中，这个存储库可以是一个关系数据库，也可以是一个按比例扩展的键值存储库。
第二代架构： 带有推送应用程序接口的服务
优点
让我们来谈谈这种演变带来的好处。
- 更好的合约带来更好的结果： 提供基于模式的推送接口，可以立即在元数据生产者和“中央元数据团队”之间建立良好的契约。你仍然需要说服元数据生产团队发布元数据并接受依赖，但有了约定俗成的模式，要做到这一点就容易多了。
- 启用程序化用例： 有了服务应用程序接口，中心团队终于可以为元数据启用编程用例。例如，如果您的数据门户应用允许使用指定字段语义类型（如电子邮件地址、客户标识符）的标签来标记数据集和字段，并将该信息存储在元数据系统中，那么您的数据管理基础架构就可以开始使用这些元数据来自动删除已申请遗忘权的客户ID 的数据资产，或为数据科学家自动创建这些数据集的别名版本。事实上，在 LinkedIn，我们使用 Apache Gobblin 来做这些工作，由 DataHub 的元数据驱动。
缺点
不过，这种架构仍然存在一些值得强调的问题。
- 没有变更日志： 第二代架构提供了一个基于微服务的 API，用于读写元数据，但并不支持从外部系统流式传输元数据的变更，也不支持订阅数据目录中发生的元数据变更流。
您可能很熟悉这篇热门博文：为什么日志应成为数据生态系统的核心。事实证明，元数据也是如此。现代数据目录应能实时订阅元数据中的变化，并将此作为一流的服务。
如果没有元数据日志，当出现问题时，就很难可靠地引导（重新创建）或修复搜索和图表索引。没有实时元数据变更日志，也就无法在中央元数据平台之上建立高效的响应式系统，如数据触发器或访问控制滥用检测系统。要建立这样的系统，就必须通过过度轮询或全面扫描，使用键值 API 访问元数据。或者，您需要等待每晚对元数据数据库进行 ETL，才能最终处理快照。我们在数据方面经历过这种痛苦的过程，因此我们非常希望在元数据方面也能跳过这种过程！然而，现代元数据系统往往忘记设计这一重要功能。 - 集中式团队的问题： 这种架构的另一个大问题是，它继续依赖于一个集中式团队来处理太多事情：拥有元数据模型、运行中央元数据服务、数据存储和索引，以及支持所有下游消费者及其访问元数据的不同方式。这严重限制了中央系统为公司现有的各种用例（生产力、治理、人工智能可解释性等）提供支持的能力。以 LinkedIn 为例，当我们还处于第二代元数据架构时，我们让数据质量团队建立了一个单独的用户界面和元数据存储，用于存储规则和显示数据集上的数据质量结果。
基于服务的集成对运营的影响还会导致生产者和中央服务的可用性紧密耦合，这让采用者担心在体系中增加一个停机源。
“中央元数据团队遇到的问题与中央数据仓库团队遇到的问题相同”。
数据工程本身正在演变成一种不同的模式--分散化正在成为常态。因此，中央元数据团队不应重蹈覆辙，试图成功跟上元数据生态系统快速发展的复杂性。
这对我意味着什么？
在商业元数据系统中，Collibra 和 Alation 似乎拥有第二代架构。在开源元数据系统中，Marquez 拥有第二代元数据架构。
我的经验是，第二代元数据系统通常可以成为公司数据资产的可靠搜索和发现门户，因此它们确实满足了数据工作者的生产力需求。它们还可以开始提供基于服务的集成到程序化工作流中，如访问控制配置。实际上，我们在将 WhereHows 从 Gen 1 发展到 Gen 2 的过程中也经历了这样的过程，我们增加了基于推送的架构和专门用于存储和检索元数据的服务。
然而，集中化瓶颈往往会导致为不同用例构建或采用新的、独立的目录系统，从而削弱了单一、一致的元数据图的威力。为数据科学家建立或采用搜索和发现门户的公司，有时最终也会为业务部门安装不同的数据治理产品，并配备自己的元数据后台。为了使数据集定义和词汇表保持同步，这些公司必须建立和监控新的数据管道，以便可靠地复制元数据，而这些元数据是使用不同的元数据模型从一个目录复制到另一个目录的。这个问题并不局限于大公司，而是会影响到任何已达到一定数据知识水平并启用了元数据各种用例的组织。
第三代架构： 事件源元数据
第三代元数据架构的关键点是，基于“中央服务”的元数据解决方案难以跟上企业对元数据用例提出的要求。要解决这个问题，必须满足两个需求。首先，元数据本身必须是自由流动、基于事件和可实时订阅的。其次，元数据模型必须支持随着新扩展和新增内容的出现而不断演进，而不会受到中央团队的阻塞。这将允许元数据始终可被多种类型的消费者大规模消费。
步骤 1：面向日志的元数据架构
元数据提供商可以根据自己的偏好，向基于流的 API 推送元数据，或者对目录的服务 API 执行 CRUD 操作。由此产生的元数据突变将反过来生成元数据变更日志。该元数据日志可以自动、确定地具体化到适当的存储和索引（如搜索索引、图索引、数据湖、OLAP 存储）中，以满足所有查询模式的需要。如下图所示，这样就形成了一个为现代企业准备就绪的非捆绑元数据数据库架构。既然日志是元数据宇宙的中心，在出现任何不一致的情况下，就可以随意引导图索引或搜索索引，并确定性地修复错误。
第三代架构： 非捆绑元数据数据库
步骤 2：面向领域的解耦元数据模型
除了 "流优先 "架构外，第三代目录还支持可扩展的强类型元数据模型和关系，以便企业协同定义。强类型化非常重要，因为如果没有强类型化，我们就会在元数据存储中存储最小公分母的通用属性包。这样，元数据的程序化消费者就无法在处理元数据时保证向后兼容性。
在下面的元数据模型图中，我们使用 DataHub 的术语 "实体类型"、"方面 "和 "关系 "来描述包含三种实体的图： 数据集、用户和组。不同的团队可将所有权、简介等不同方面附加到这些实体上，从而在这些实体类型之间创建关系。请注意，描述这些图模型的方法多种多样，从基于 RDF-based 模型到完整的 ER 模型，再到像 DataHub 所用的自定义混合方法。
元数据模型图示例： 类型、方面、关系
这种建模方式使团队能够通过添加特定领域的扩展来发展全局元数据模型，而不会受到中心团队的瓶颈限制。例如，合规团队可能会签入所有权方面，而核心元数据团队可能会签入数据集实体的模式方面。同时，数据摄取团队可能会为数据集实体设计并签入 ReplicationConfig 方面。所有这些对模型的添加都可以独立进行，冲突点极少。当然，在将核心实体类型引入图之前，我们需要对它们进行管理并达成一致。
好处
通过这种演进，客户可以根据自己的需求，以不同的方式与元数据库对接。他们可以获得基于流的元数据日志（用于摄取和更改消费）、元数据低延迟查询、元数据属性全文和排序搜索能力、元数据关系图查询以及完整的扫描和分析能力。不同的用例和应用可以在核心元数据模型的基础上进行不同的扩展，而不会牺牲一致性或新鲜度。您还可以将这些元数据与您偏好的开发人员工具（如 git）集成，在编写代码的同时编写元数据并对其进行版本控制。通过低延迟处理元数据变更日志，或将压缩后的元数据日志作为数据湖上的表格进行批量处理，可以对元数据进行完善和丰富。
下图展示了这一架构的完整实现版本：
第三代架构： 端到端数据流
任何全局企业元数据需求，如全局生命周期管理、审计或合规性，都可以通过构建工作流来解决，工作流可以以流形式或批处理形式查询这些全局元数据。
“良好的元数据架构”与“良好的数据架构”极为相似
一个好的第三代元数据架构实施的典型标志是，你总是能够以最详细的形式读取最新的元数据并对其采取行动，而且不会失去一致性。在 LinkedIn，当我们从 WhereHows（第二代）过渡到 DataHub（第三代）时，我们发现我们能够极大地提高元数据的可信度，从而使元数据系统成为企业的中心。现在，元数据系统正逐步成为数据工作者研究新假设、发现新指标、管理现有数据资产生命周期等工作的起点。
缺点
先进性往往与复杂性并存。第三代元数据系统通常会有几个活动部件，需要对其进行设置才能使整个系统运转良好。拥有少量数据工程师的公司可能会发现，将一个简单的使用案例付诸实践所需的工作量让他们望而却步，不知道最初投入的时间和精力是否值得长期回报。不过，像 DataHub 这样的第三代元数据系统已经开始在可用性和开箱即用体验方面取得重大进步，以确保这种情况不会发生。
这对我意味着什么？
在我们调查过的所有系统中，采用第三代元数据架构的只有 Apache Atlas、Egeria、Uber Databook 和 DataHub。其中，Apache Atlas 与 Hadoop 生态系统紧密结合。一些公司正在尝试在 Atlas 的基础上附加 Amundsen，试图获得两全其美的效果，但这种集成似乎存在一些挑战。例如，你必须摄取元数据并将其存储在Atlas的图形和搜索索引中，完全绕过Amundsen的数据摄取、存储和索引模块。这就意味着你想要建模的任何新概念都需要以Atlas概念的形式引入，然后再与Amundsen的用户界面连接，这就导致了相当大的复杂性。Egeria 支持通过元数据事件总线整合不同的目录，但到目前为止功能似乎还不完善。Uber Databook 似乎基于与 DataHub 非常相似的设计原则，但没有开源。当然，由于我们个人使用 DataHub 的经验，我们的看法有失偏颇，但开源的 DataHub 具有第三代元数据系统的所有优点，能够支持多种类型的实体和关系以及流优先架构。
在 LinkedIn，DataHub 的部署包括数据集、模式、流、合规性注释、GraphQL 端点、指标、仪表盘、功能和人工智能模型，使其在规模和战备方面真正成为第三代元数据系统。它每天通常要处理多达一千多万个实体和关系变更事件，总计索引了五百多万个实体和关系，同时以低毫秒级的服务水平协议（SLA）为运营元数据查询提供服务，为我们的所有员工实现数据生产力、合规性和治理工作流。
以下是当今元数据状况的简单可视化展示。
当然，这只是目前不同系统的一个缩影。随着企业对元数据的需求日益增长，第 3 代系统可能会进一步整合和更新。
一个好的架构就够了吗？
通过 DataHub 实施的第三代架构，我们似乎已经获得了一个良好的元数据架构，它具有可扩展性，能很好地满足我们的多种使用情况。这个领域还有其他问题需要解决吗？简短的回答是 "是的"。第三代元数据架构确保您能够以最具可扩展性和灵活性的方式集成、存储和处理元数据。但这还不够。
“让元数据发挥作用，比把元数据放在一起更难”。
首先，您需要定义正确的元数据模型，真正捕捉对企业有意义的概念。然后，您需要一个人工智能支持的途径，从这个完整、可靠的数据资产清单过渡到可信的元数据知识图谱。这将使您真正释放企业的生产力和治理能力。不过，这是另一篇博文的内容了！