最近，数据论坛中关于元数据管理的话题引起了很多讨论和困惑。您可能在各种情况下听说过它，例如数据发现、数据来源、数据可观察性、数据治理、数据隐私和 DataOps/MLOps。也许您在众多思想领袖倡导的新数据操作系统或数据网格范例中发现了它的影子。或者，它可能是 Gartner 的主动元数据管理或 Forrester 的企业数据编织指南中出现的。该领域及其周边似乎也有源源不断的新闻，主要是新初创公司加入竞争，现有公司获得天文数字的估值。然而，当你仔细观察时，你会发现每个产品看起来都一样——但它们都声称自己在做一些不同的事情。
我们中的一些人可能会想，“元数据管理不是一个已经解决的问题吗?我清楚地记得十年前使用过其中一种企业产品。这有什么问题?”而其他人则只是举手抗议，“为什么要这么复杂?为什么不能有一个工具来解决所有问题?”
事实是，元数据管理并不是一个新问题，但自从引入现代数据堆栈以来，它已经呈现出一个全新的维度。过去只是一个只有核心数据团队关注的小而深奥的问题，现在已经发展成为困扰大大小小的公司的复杂组织挑战。换句话说，如果已经采用现代数据堆栈来使数据的创建、处理和分析自助化，那么就需要一个配套工具来防止数据生态系统因分散和不断增长而变成一个难以驾驭的野兽。这就需要一个现代元数据平台 (MMP) 。
元数据管理并不是一个新问题，但自从引入现代数据堆栈以来，它已经呈现出一个全新的维度。
一 什么是现代元数据平台 (MMP)
那么 MMP 到底是什么?它与传统元数据管理解决方案有何不同?要回答这些问题，首先介绍一下LinkedIn- DataHub上构建的元数据平台，该系统具有 MMP 的许多关键要素。
LinkedIn 是大数据和数据民主化的先驱之一。它的开放数据文化促进了Kafka、Pinot和Gobblin等多种先进数据基础设施以及Economic Graph、PYMK和LinkedIn Salary等创新数据产品的创建。然而，随着数据功能的增长和民主化，赋予数据科学家权力的因素也成为了数据生态系统随着时间的推移变得越来越不可用的原因。它已经达到了这样的地步：系统中有数百万个数据集，但没有人知道它们是什么、如何计算、在哪里可以找到正确的数据，甚至不知道如果有问题该问谁。
2016 年，元数据团队正式成立，负责解决 LinkedIn 的数据搜索和发现问题。团队创建了一个简单的数据发现门户WhereHows，随后将其开源，成为同类中第一个 OSS 项目。2017 年，随着 GDPR 的即将实施，团队的重点转向数据隐私。搜索和发现收集的元数据不仅构成了 LinkedIn 遵守 GDPR 的基石，而且小型 Web 应用程序还成为 PII 标记、数据屏蔽、访问请求和数据管理生命周期管理的首选工具。为了处理 LinkedIn 实施 GDPR 的规模和可靠性，团队将简单的整体架构发展为由微服务和现代存储系统提供支持的一流三层架构。
这个项目具有两个重要的教训。首先，构建一个通用平台来支持多种用例比构建单点解决方案更有效率。能够在严格的期限内为 LinkedIn 解决 GDPR 问题的主要原因之一是利用了已经构建的内容。许多后端基础设施需求对于搜索和发现以及合规性而言都是常见的，因此可以整合到平台中。第二个教训是关于集中元数据的力量，它解锁了原本难以解决的用例。例如，通过将数据目录与 PII 标签连接起来，系统能够在访问数据时屏蔽敏感列。通过跟踪沿线的数据管理，能够找出计划弃用或迁移时应该联系谁。通过将 PII 标签与基于 ML 的数据分析系统的输出进行比较，可以识别可能被错误标记的字段。而这仅仅是个开始。想象一下，通过收集更加丰富的元数据集可以创造多少价值!
在接下来的 18 个月里，整合了 40 多个团队和项目，收集了 200 多种元数据，并将整个平台变成了一个真正的元数据平台。自 GDPR 以来，DataHub 为 LinkedIn 提供了许多新用例，包括数据来源、数据治理、数据集成、MLOps 和 API 开发。这就是 MMP 的本质。它是一个大规模集成、处理和提供丰富元数据的平台，可以应对许多复杂的组织数据挑战。
二 为什么需要现代元数据管理平台
以上说明了元数据平台的优点。但是，您可能仍然对现代版本的需求存有疑虑。“为什么传统的元数据管理解决方案不够好?”原因很简单——规模和复杂性。
在现代数据堆栈出现之前，数据生态系统要简单得多。大多数公司采用单一的端到端解决方案来提取、加载和转换数据。有些甚至配备了商业智能 (BI) 功能，以提供一站式体验。元数据的使用非常简单，因为它主要是在单个系统中生成和使用的。事实上，许多解决方案都提供了开箱即用的数据目录和元数据管理软件。
几年后，旧的数据堆栈发生了翻天覆地的变化。公司开始涌向 Snowflake、Databricks、Looker 和 Fivetran 等供应商，寻求专门的 SaaS 解决方案。更勇敢的团队部署了 Spark、Presto 和 Airflow 等开源解决方案。甚至云供应商也加入了这股潮流，推出了各种各样的数据服务。很快，曾经相当统一的数据基础设施现在由一系列产品组成，每个产品都在孤岛中存储或生成专门的元数据。集中和标准化元数据不再是轻而易举的事。让问题更加复杂的是，许多公司创建了自己的专有元数据 - 存储在电子表格、YAML 文件或某种形式的注册表或服务中。这些元数据通常会为数据带来独特的业务角度并使其变得有意义。毕竟，如果不是为了改善业务，存储所有这些数据有什么意义呢?
元数据不仅变得更加复杂和异构，其规模也显著增长。想象一下这样一个世界，每个版本的表模式都被捕获和存储，以及每个列、每个仪表板、数据湖中的每个数据集、每个查询、每个作业运行、每个访问历史记录等。很快，元数据开始看起来和闻起来像是一个大数据问题。哦，我是不是忘了说你还需要遍历由数千万个顶点和数亿条边组成的元数据图?你还认为你能在 MySQL 或 PostgreSQL 数据库中保存所有这些“微不足道”的元数据吗?
很快，元数据开始看起来像是一个大数据问题。你还认为可以将所有“微不足道”的元数据保存在 MySQL 或 PostgreSQL 数据库中吗?
那么为什么需要 MMP?因为元数据可能和数据一样大、一样复杂，值得得到同样的尊重。
三 如何打造优秀的现代元数据平台
简而言之，一个优秀的元数据平台与一个优秀的数据平台非常相似。您通常对一个优秀的数据平台的期望——可扩展、可靠、可扩展并提供丰富的 API——也适用于一个优秀的元数据平台。此外，要使 MMP 真正有用，它还应该非常容易集成新的元数据源并提供对集成过程的完全可见性。
优秀的 MMP 需要具有可扩展性、可靠性、可扩展性、提供丰富的 API 并且易于集成。
1.可扩展性
既然我们已经确定了元数据的潜在规模，那么设计一个能够以相同规模存储和提供服务的系统就很重要了。幸运的是，由于为消费者互联网开发的技术，这个问题在很大程度上得到了解决。各种云供应商都可以轻松提供可以无限扩展的 NoSQL 数据库。不喜欢 NoSQL?没问题。许多 NewSQL 供应商都乐于提供分布式 SQL 数据库，这些数据库可以随心所欲地扩展。
可扩展性的另一个有趣方面是索引。虽然大多数数据库系统完全能够扩展二级索引，但它仍然很容易因涉及大量表/集合或多级自连接的复杂连接而陷入困境。事实上，这正是图形数据库的优势所在——在眨眼间穿越涉及数百万个关系的多个跳跃。同样，大多数二级索引在执行比精确关键字匹配更复杂的自由文本搜索时很快就会变得毫无用处。
那么解决方案是什么呢?为了大规模支持广泛的查询模式，您需要使用专门的数据系统，例如图形数据库和搜索引擎，而不是滥用事务数据库。不幸的是，这将需要在数据系统之间同步内容的额外复杂性和各种一致性挑战。希望有一天会有一个真正的多模型数据库，能够神奇地满足所有的可扩展性要求。
MMP 的服务层也需要可扩展。虽然员工点击 Web 应用程序不会产生大量流量，但通过数据管道等方式对元数据进行编程访问很容易导致配置不足的 MMP 崩溃。幸运的是，一旦我们拥有可扩展的存储后端，扩展系统的这一部分就简单得多。如果服务层保持无状态，我们可以通过投入更多机器来继续扩展它，前提是存储可以跟上。
2.可靠性
可靠性和可扩展性通常齐头并进。两者本质上都是通过添加更多机器来实现的。与可扩展性类似，构建可靠的基础设施也被认为是云计算时代的一个已解决的问题。我们需要更加关注的是 MMP 的“数据可靠性”。
数据可靠性不仅仅局限于主存储。如上一节所述，MMP 需要额外的专用数据系统(例如搜索引擎和图形数据库)来应对规模和复杂性。因此，在所有这些系统之间同步数据至关重要。主存储中的更改应近乎实时地复制到其他数据系统。此外，必须有一种方法可以轻松地从主存储引导新索引，而不会导致任何停机时间。
另一个需要考虑的方面是元数据更改的审计历史，尤其是人工编写的元数据。更改历史通常与最新值一样重要。例如，管道中断的最常见原因之一是表模式的更改。了解确切的更改是什么可以帮助减少检测时间和解决问题的时间。因此，好的 MMP 应该捕获所有更改并提供访问它们的简便方法。
3.可扩展性
使 API 可扩展可以为平台带来灵活性、可定制性和长效性。这通常归结为为 API 采用可扩展的数据模型。考虑到 MMP 所捕获的丰富元数据的范围以及不断发展的数据生态系统格局，可扩展性对于 MMP 尤其重要。
一种常见的方法是添加一个“字典”字段来保存任意键值对，或添加一个字符串/字节数组字段来存储序列化的复杂对象。虽然这确实为模型带来了近乎无限的可扩展性，但这些字段的“无模式”性质也使模型极难使用，并且几乎没有办法以向后兼容的方式发展。最后，在存储这些“黑盒”字段时，索引任何内容也非常困难，这会导致查询性能不佳。
另一种方法是使用以向后兼容的方式演化的强类型数据模型。这与在不破坏旧读取器的情况下演化表或 Avro/Parquet 文件的架构没有太大区别。某些数据格式(例如Protocol Buffers)更进一步，强制所有字段为可选字段，以保证所有更改都是向后和向前兼容的。
4.丰富的API
在许多情况下，平台和其 API 几乎是同义词。API 使得其他应用程序、流程或技术能够在平台上开发。对于优秀的 MMP 来说，API 不仅是先决条件，更是解锁众多元数据驱动用例的关键。
然而，与许多只需一个简单的 Web API 即可满足需求的平台不同，优秀的 MMP 必须提供多种“模式”的 API：
REST API：几乎可以预料到，任何服务都应该有一个 REST API。优秀的 MMP 也不例外。理想情况下，API 应该符合流行的标准，例如OpenAPI，而不是基于 JSON 的自定义协议。
GraphQL API：自 2015 年公开推出以来，GraphQL 已迅速在整个行业中得到采用。它经常被誉为前端工程师的理想 API 语言。其面向图形的语言也非常适合查询高度连接的数据结构，例如 MMP 的复杂元数据图。
基于推送的 API：与前两种 API 不同，基于推送的 API 会在触发事件后立即通知客户端，而不是让客户端忙于轮询 API。实现包括消息队列、事件流、webhook、发布/订阅等。当需要立即采取行动以响应元数据的变化时，这种 API 样式特别有用，例如，在出现合规性问题时创建 Jira 票证。
分析 API：这可能是设计元数据平台 API 时最容易被忽视的方面。许多用例都需要全局级别的分析。例如，“显示所有包含 PII 的数据集，这些数据集在过去 3 个月内通过沿袭直接或间接访问，按访问者的标题分组，并突出显示没有关联 Jira 票证的数据集”。这些类型的查询不需要亚秒级响应，更适合交互式分析。因此，MMP 应该为这些“离线分析”提供一个接口，而不会损害其“在线性能” 。
5.易于集成
易于集成无疑是优秀 MMP 的一个重要因素。毕竟，如果不从各种来源引入元数据，元数据平台就会成为另一个需要打破的孤岛。
许多人会立即将“集成”一词与 REST API 联系起来。显然，向 API 发送 HTTP 请求是如此普遍，以至于认为有更好的方法与服务交换数据会很奇怪。但是，REST API 存在几个问题，使得它们不是 MMP 的理想选择：
API 版本控制：REST API 通常不是为持续演进而设计的。大多数情况下，服务最终都会拥有额外的 v2/v3 端点，以引入重大更改。这通常意味着客户端需要采用新版本的 SDK 并大幅更改其代码。端点的激增也使其难以维护，从而不可避免地导致旧端点被丢弃，未升级的客户端被抛弃。
可审计性和可调试性：这不是如果，而是当元数据没有被正确提取时，人们通常需要手动仔细检查来自多个地方的日志，以找出到底出了什么问题。客户端是否首先发送了请求?请求的格式是否正确?是否存在暂时性问题?最糟糕的是，日志甚至可能没有足够的信息来回答这些问题。审计和调试提取问题很快就会变成一场反复出现的噩梦。
回填：假设上一点中的采集错误最终已修复，那么是时候重新采集并重新处理所有遗漏的元数据了。在理想情况下，客户端可以再次重新发送他们的请求。但是，如果切实可行，大规模地做到这一点可能并不容易。最糟糕的情况是，重新发送是不可能的，因为元数据是在瞬态事件期间生成的，例如，当某个特定作业运行时。
实际上，还有另一种与服务交换数据的方法，而没有上述缺点——通过中间缓冲区。在DataHub的情况下，我们使用 Kafka 作为缓冲区。它确实提供了一个可演进的模式，但由于日志保留有限，因此提供了有限的可审计性和回填能力。Kafka 还为系统增加了另一层复杂性，并且维护起来并不容易。
更好的替代方案是使用云存储(S3、GCS 等)作为缓冲区。大多数云存储系统提供无限的版本控制和审计历史记录，使调试和回填变得轻而易举。读取器和写入器还可以就随时间演变的文件模式达成一致。这种方法还享有 Kafka 提供的其他好处，例如生产者-消费者解耦、高可扩展性、容错性和耐用性，同时将工程和运营成本转嫁给云供应商。
小结
在这篇文章中，我们讨论了什么是现代元数据平台、为什么首先需要它以及如何构建出色的 MMP。MMP 是现代数据堆栈的重要补充，随着数据成熟度的提升，越来越多的公司将采用它。
