Metacat：在Netflix上使大数据可发现并有意义

大多数大型公司都有大量具有不同数据格式和大量数据的数据源。 整个企业中的许多人都可以访问和分析这些数据存储。 在Netflix，我们的数据仓库由存储在Amazon S3（通过Hive），Druid，Elasticsearch，Redshift，Snowflake和MySql的大量数据集组成。 我们的平台支持Spark，Presto，Pig和Hive来使用，处理和生成数据集。 给定多样化的数据源，并确保我们的数据平台可以作为一个"单个"数据仓库跨这些数据集进行互操作，我们构建了Metacat。 在此博客中，我们将讨论构建Metacat（一种使数据易于发现，处理和管理的元数据服务）的动机。

目标

Netflix的大数据平台的核心架构涉及三个关键服务。 这些是执行服务（Genie），元数据服务和事件服务。 这些想法并不是Netflix独有的，而是反映了我们认为构建一个系统的必要体系结构，该系统不仅适用于现在，而且适用于未来数据基础架构的规模。

许多年前，当我们开始构建平台时，我们采用Pig作为我们的ETL语言，并采用Hive作为我们的临时查询语言。 由于Pig本身没有元数据系统，因此对于我们而言，构建一个可以在两者之间互操作的系统似乎是理想的选择。

因此，Metacat诞生了，该系统充当了我们支持的所有数据存储的联合元数据访问层。 我们的各种计算引擎可以用来访问不同数据集的集中式服务。 通常，Metacat可以实现三个主要目标：

· 元数据系统的联合视图

· 有关数据集的元数据的统一API

· 数据集的任意业务和用户元数据存储

值得注意的是，其他拥有大量分布式数据集的公司也面临类似的挑战。 Apache Atlas，Twitter的数据抽象层和Linkedin的WhereHows（Linkedin上的数据发现）就是为了解决类似问题而建立的，但要考虑到公司各自的架构选择。

Metacat

Metacat是一项联合服务，提供统一的REST / Thrift接口来访问各种数据存储的元数据。 各个元数据存储仍然是架构元数据的真实来源，因此Metacat不会在其存储中实现它。 它仅直接存储有关数据集的业务和用户定义的元数据。 它还会将有关数据集的所有信息发布到Elasticsearch以进行全文本搜索和发现。

在较高级别上，Metacat功能可以分类如下：

· 数据抽象和互操作性

· 业务和用户定义的元数据存储

· 数据发现

· 数据变更审核和通知

· Hive Metastore优化

数据抽象和互操作性

Netflix使用Pig，Spark，Presto和Hive等多个查询引擎来处理和使用数据。 通过引入一个通用的抽象层，可以由不同的引擎互换访问数据集。 例如：从Hive读取数据的Pig脚本将能够读取Pig类型中具有Hive列类型的表。 为了将数据从一个数据存储移动到另一个数据存储，Metacat通过使用目标表数据类型帮助在目标数据存储中创建新表来简化此过程。 Metacat具有受支持的规范数据类型的已定义列表，并具有从这些类型到每个相应数据存储类型的映射。 例如，我们的数据移动工具使用上述功能将数据从Hive迁移到Redshift或Snowflake。

Metacat节俭服务支持Hive节俭界面，可轻松与Spark和Presto集成。 这使我们能够通过一个系统集中所有元数据更改，从而进一步使我们能够发布有关这些更改的通知，以启用数据驱动的ETL。 当新数据到达时，Metacat可以通知相关作业开始。

业务和用户定义的元数据

Metacat在其存储中存储有关数据集的其他业务和用户定义的元数据。 当前，我们在其他用例中使用业务元数据来存储连接信息（例如，用于RDS数据源），配置信息，指标（Hive / S3分区和表）和表TTL（生存时间）。 顾名思义，用户定义的元数据是一种自由格式的元数据，可由用户设置以供其自己使用。

业务元数据也可以大致分为逻辑和物理元数据。 有关诸如表的逻辑构造的业务元数据被视为逻辑元数据。 我们使用元数据进行数据分类和标准化ETL处理。 表所有者可以在业务元数据中提供有关表的审核信息。 它们还可以提供列默认值和验证规则，以用于写入表中。

有关存储在表或分区中的实际数据的元数据被视为物理元数据。 我们的ETL处理存储有关作业完成时数据的指标，此指标随后用于验证。 可以使用相同的指标来分析数据的成本+空间。 给定两个表可以指向相同的位置（例如在Hive中），区分逻辑元数据和物理元数据很重要，因为两个表可以具有相同的物理元数据但具有不同的逻辑元数据。

数据发现

作为数据的使用者，我们应该能够轻松浏览并发现各种数据集。 Metacat将模式元数据和业务/用户定义的元数据发布到Elasticsearch，以帮助全文搜索数据仓库中的信息。 这还可以在我们的大数据门户网站SQL编辑器中自动建议和自动完成SQL。 将数据集组织为目录有助于消费者浏览信息。 标签用于根据组织和主题领域对数据进行分类。 我们还使用标签来标识用于数据生命周期管理的表。

数据变更通知和审核

Metacat是数据存储的中央网关，可捕获任何元数据更改和数据更新。 我们还围绕表和分区更改构建了一个推送通知系统。 当前，我们正在使用此机制将事件发布到我们自己的数据管道（Keystone）中进行分析，以更好地了解我们的数据使用情况和趋势。 我们还将发布到Amazon SNS。 我们正在将数据平台架构发展为事件驱动架构。 将事件发布到SNS允许我们数据平台中的其他系统对这些元数据或数据更改进行"响应"。 例如，当一个表被删除时，我们的S3仓库管理员服务可以订阅此事件并适当地清理S3上的数据。

Hive Metastore优化

由RDS支持的Hive元存储在高负载下无法正常运行。 我们注意到使用metatore API编写和读取分区方面存在许多问题。 鉴于此，我们不再使用这些API。 我们对Hive连接器进行了改进，该连接器直接与支持RDS进行通信以读取和写入分区。 以前，Hive Metastore调用添加通常会超时的数千个分区，但是在我们的实现中，这不再是问题。

下一步

在构建Metacat方面，我们已经走了很长一段路，但是我们还远远没有完成。 这是我们仍需要努力以增强我们的数据仓库体验的一些其他功能。

· 提供表历史记录的架构和元数据版本控制。 例如，跟踪特定列的元数据更改或能够查看表大小随时间变化的趋势很有用。 能够询问过去某个时间点的元数据对审核，调试非常重要，对于重新处理和回滚用例也很有用。

· 提供有关数据沿袭的表的上下文信息。 例如，可以在Metacat中聚合诸如表访问频率之类的元数据，并将其发布到数据沿袭服务，以用于对表的重要性进行排名。

· 添加对诸如Elasticsearch和Kafka的数据存储的支持。

· 可插拔元数据验证。 由于业务和用户定义的元数据是自由格式，因此为了保持元数据的完整性，我们需要进行验证。 Metacat应该具有可插入的体系结构，以合并可以在存储元数据之前执行的验证策略。

在我们继续开发功能以支持未来的用例时，我们随时欢迎社区的反馈和贡献。 您可以通过Github与我们联系，也可以在Google网上论坛中与我们联系。 我们希望在今年晚些时候分享我们团队正在做的更多工作！