现代元数据平台

本文源自：https://metaphor.io/blog/the-modern-metadata-platform

这是一个新概念：The Modern Metadata Platform，直译就是现代元数据平台。这个概念是伴随着 Modern Data Stack 概念而生，是其中的一部分。

元数据管理很多年前就有了，比如很多公司会拿Excel或者是文本存储数据仓库里所有的表结构，以方便大家查询。但是现代元数据平台与传统的元数据管理有什么区别呢？现代元数据平台在于自从拥有了大数据以后，一个公司已经不仅仅只需要一个数据库就可以支撑数据分析等工作，而是需要分布式数据存储、计算、可视化、调度等等复杂的工具组成的现代数据技术栈（Modern Data Stack）。

此时就需要一个现代元数据平台去管理现代数据技术栈，以防止公司的数据生态系统由于分散和增长而变成笨重的野兽。

Metadata management is not a new problem, but it has taken on a whole new dimension since the introduction of the Modern Data Stack.

什么是现代元数据平台呢？

以领英（LinkedIn）为例，公司的持续发展导致公司内部的系统中有数百万个数据集，没有人知道它们是什么，它们是如何计算的，在哪里可以找到正确的数据，甚至如果有问题该问谁。

It had reached a point where there were literally millions of datasets in the system, and no one had any clue about what they were, how they were computed, where to find the right data, and even who to ask if there was a question.

因为这个问题的存在，让领英开发了第一代元数据平台WhereHows，这是一个非常简单的数据发现门户，实现的是传统的元数据管理功能，只能查询数据库里有哪些表和表结构信息。某种程度上来说，确实解决了团队查找不到数据的问题。

但是随着欧洲《通用数据保护条例》的实施，WhereHows要负担起 PII （个人身份信息）标记、数据屏蔽、访问请求和数据管理生命周期管理等功能，那么之前的设计都要推翻重做了。领英希望 WhereHows 能够更加通用化，成为一个真正的元数据平台。

Imagine how much more value we could create by collecting an even richer set of metadata!

在接下来的日子里，领英整合了 40 多个团队和项目，收集了 200 多种元数据，将WhereHows变成了一个真正的元数据平台（名字也变成了DataHub）。自 GDPR 以来，DataHub 为 LinkedIn 的众多新用例提供了支持，包括数据来源、数据治理、数据集成、MLOps 和 API 开发。这就是现代元数据平台的核心。

它是一个平台，可大规模集成、处理和提供丰富的元数据，以应对许多复杂的组织数据挑战。

为什么需要现代元数据平台？

“为什么传统的元数据管理解决方案不够好？” 原因很简单：现代数据技术栈带来的规模和复杂性。

在现代数据技术栈出现之前，数据生态系统要简单得多。大多数公司采用单一的端到端解决方案来提取、加载和转换数据。有些甚至配备了商业智能 (BI) 功能，以提供一站式体验。元数据让生活变得轻松，因为它主要是在单个系统中生成和使用的。事实上，许多解决方案都提供了开箱即用的数据目录和元数据管理软件。

过了几年后，公司开始涌向 Snowflake、Databricks、Looker 和 Fivetran 等供应商寻求专门的 SaaS 解决方案。甚至有的团队部署了 Spark、Presto 和 Airflow 等开源解决方案。甚至云供应商也加入了这一潮流，推出了大杂烩式的数据服务。很快，曾经相当统一的数据基础设施现在由一系列产品组成每个存储或产生专门的元数据孤岛。对元数据进行集中和标准化不再是一件简单的事。

元数据不仅变得更加复杂和异构，而且其规模也开始大量增长。数据生态系统里的每个版本的表结构都被获取和存储，以及每一列、每个看板、数据湖中的每个数据集、每个查询、每个作业运行、每个访问历史等。很快，元数据的查找和存储就像大数据问题一样了。

Very quickly, metadata starts to look and smell like a Big Data problem. You also need to traverse the metadata graph made up of 10s of millions of vertices and 100s of millions of edges. Still think you can hold all that “measly” metadata in a MySQL or PostgreSQL database?

那么，为什么需要现代元数据平台呢？因为您的元数据可能与您的数据一样大和一样复杂，因此应该受到同样的尊重。

如何构建出色的现代元数据平台？

简而言之，一个优秀的元数据平台看起来与一个优秀的数据平台非常相似。

scalable, reliable, extensible, and offers rich APIs

Scalability

Scalability, 表示的是当对一个系统的任务量或工作量增加时，该系统能够用一个优雅的方式来应对，而且达到了很好的效果。比如，当一个系统在增加了硬件资源之后，它的性能随之也能够成比例的提升，这就表明这个系统有很好的Scalability。

这一块的数据存储很容易解决，比如云计算服务商上各种可扩展的MySQL和PostgreSQL服务，甚至还有 NewSQL 可以选择。不过要是牵扯到数据之间的关联等问题时，要使用图数据库和搜索引擎，就比较头疼了。希望后续能有一款数据库能够完美兼容图数据库、搜索引擎和关系型数据库的特点。

Reliability

现代元数据平台在没有一款完美的数据库符合它的数据存储要求时，就需要考虑如何在关系型数据库、搜索引擎和图数据库之间实时同步数据了。要有一种方式可以保证三种类型的数据库的数据一致性。

另一个需要考虑的方面是元数据更改的审计历史，尤其是人工编写的元数据。更改的历史记录通常与最新值一样重要。例如导致数据调度任务失败的最常见原因是表架构的更改。了解元数据的变化可以帮助减少检测时间和解决时间。因此，一个好的现代元数据平台应该捕获所有更改并提供访问它们的简单方法。

Extensibility

Extensibility, 表明系统设计的原则，考虑到了将来对系统实现的更改和增强。如果一个系统有很好的Extensibility，那么当对该系统某部分进行功能的添加或修改时，几乎不会影响到系统现有的其他部分。

使 API 可扩展为平台带来了灵活性、可定制性和使用寿命。这通常归结为为 API 采用可扩展的数据模型。考虑到它捕获的丰富元数据的范围以及数据生态系统不断发展的格局，可扩展性对于现代元数据平台尤其重要。

可以使用类似 Protocol Buffers 的协议去保证向前和向后的数据模型兼容性。

Rich APIs

一个优秀的现代元数据平台必须提供多种 API 的“模式”：

• REST API
• GraphQL API
• Push-based API
• Analytics API

Ease of Integration（易于集成）

这是很重要的一件事。毕竟，如果不从各种来源引入元数据，元数据平台就会变成另一个它应该打破的孤岛。

可以采用事件流架构的方式去集成数据，比如 Datahub 就是用 Kafka 作为缓冲区。除了 Kafka 外，还可以使用云存储（S3、GCS 等）作为缓冲区。使用云存储甚至比 Kafka 更好，不仅可以把运维成本交给云计算厂商，还可以拥有比 Kafka 更大和更久时间的数据存储。

总结

这篇文章可以视为一个新概念的开端，阐述了领英的元数据团队对于现代元数据平台的理解，算是对传统的元数据管理很好补充。