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