重磅！Netflix开源大数据发现服务框架Metacat

策划编辑 | Natalie

做者 | Ajoy Majumdar，Zhen Li

编译 | 无明

编辑 | Natalie

AI 前线导读： 喜闻乐见！Netflix 又贡献了一个全新的开源项目！对于 Netflix 来讲，开放开源是身为技术公司的竞争战略。既可以将本身的解决方案创建为行业标准和最佳实践，又能创建 Netflix 的技术品牌，还能从共享生态中得到反馈输入并受益。

而过去几年，Netflix 已经为开源社区贡献了不少很是成功的开源项目。Netflix 微服务技术栈的核心组件基本上都是开源的，如今你们耳熟能详的 Zuul 网关、Eureka 服务发现注册中心、Hystrix 熔断限流、Archaius 配置等组件，Netflix 早在 2012 年左右就都开源出来了。今天，Netflix 又将其大数据发现服务框架 Metacat 开源了出来，旨在让发现、处理和管理数据变得更为方便。Netflix 官网技术博客对 Metacat 进行了详细介绍，AI 前线将内容编译以下。

更多优质内容请关注微信公众号“AI 前线”，（ID：ai-front）

不少大公司都拥有大量的数据源，它们的数据格式不尽相同，并且体量巨大。在 Netflix，咱们的数据仓库由不少大型的数据集组成，这些数据存储在 Amazon S三、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 没有保存这部分元数据。Metacat 只保存业务相关和用户定义的元数据。它还将全部关于数据集的信息发布到 Elasticsearch，以便进行全文搜索和发现。

Metacat 的功能能够分为如下几类：

• 数据抽象和互操做性

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

• 数据发现

• 数据变动审计和通知

• Hive Metastore 优化

数据抽象和互操做性

Netflix 使用多种查询引擎（如 Pig、Spark、Presto 和 Hive）来处理和使用数据。经过引入通用的抽象层，不一样的引擎能够交互访问这些数据集。 例如：从 Hive 读取数据的 Pig 脚本可以从 Hive 列类型的表中读取数据，并转成 Pig 类型。在将数据从一个数据存储移动到另外一个数据存储时，Metacat 经过在目标数据存储中建立具备目标类型的表来简化这一过程。Metacat 提供了一组预约义的数据类型，可将这些类型映射到各个数据存储中的数据类型。例如，咱们的数据移动工具使用上述功能将数据从 Hive 移动到 Redshift 或 Snowflake。

Metacat 的 Thrift 服务支持 Hive 的 Thrift 接口，便于与 Spark 和 Presto 集成。咱们所以可以经过一个系统聚集全部的元数据变动，并发布有关这些变动的通知，实现基于数据驱动的 ETL。当新数据到达时，Metacat 能够通知相关做业开始工做。

业务和用户定义的元数据

Metacat 也会保存数据集的业务和用户定义元数据。咱们目前使用业务元数据来存储链接信息（例如 RDS 数据源）、配置信息、度量指标（Hive/S3 分区和表）以及数据表的 TTL（生存时间）等。顾名思义，用户定义的元数据是一种自由格式的元数据，可由用户根据本身的用途进行定义。

业务元数据也能够大体分为逻辑元数据和物理元数据。有关逻辑结构（如表）的业务元数据被视为逻辑元数据。咱们使用元数据进行数据分类和标准化咱们的 ETL 处理流程。数据表的全部者可在业务元数据中提供数据表的审计信息。他们还能够为列提供默认值和验证规则，在写入数据时会用到这些。

存储在表中或分区中的实际数据的元数据被视为物理元数据。咱们的 ETL 处理在完成做业时会保存数据的度量标准，在稍后用于验证。相同的度量可用来分析数据的成本和空间。由于两个表能够指向相同的位置（如 Hive），因此要可以区分逻辑元数据与物理元数据。两个表能够具备相同的物理元数据，但应该具备不一样的逻辑元数据。

数据发现

做为数据的消费者，咱们应该可以轻松发现和浏览各类数据集。Metacat 将模式元数据和业务及用户定义的元数据发布到 Elasticsearch，以便进行全文搜索。咱们的 Big Data Portal SQL 编辑器所以可以实现 SQL 语句的自动建议和自动完成功能。将数据集组织为目录有助于消费者浏览信息，根据不一样的主题使用标签对数据进行分类。咱们还使用标签来识别表格，进行数据生命周期管理。

数据变动通知和审计

做为数据存储的中央网关，Metacat 将捕获全部元数据变动和数据更新。咱们还围绕数据表和分区变动开发了通知推送系统。目前，咱们正在使用此机制将事件发布到咱们本身的数据管道（Keystone），以更好地了解数据的使用状况和趋势。咱们也将事件发布到 Amazon SNS。咱们正在将咱们的数据平台架构发展为基于事件驱动的架构。将事件发布到 SNS 可让咱们数据平台中的其余系统对这些元数据或数据变动作出“反应”。例如，在删除数据表时，咱们的 S3 数据仓库管理员服务能够订阅这些事件，并适当地清理 S3 上的数据。

Hive Metastore 优化

由 RDS 支持的 Hive Metastore 在高负载下表现不佳。咱们已经注意到，在使用元数据存储 API 写入和读取分区方面存在不少问题。为此，咱们再也不使用这些 API。咱们对 Hive 链接器（在读写分区时，该链接器直接与 RDS 通讯）进行了改进。以前，添加数千个分区的 Hive Metastore 调用一般会超时，在从新实现后，这再也不是个问题。

下一步

咱们在构建 Metacat 方面已经走了很长的一段路，但尚未完成咱们的使命。如下是咱们仍须要努力加强的一些特性。

• 模式和元数据的版本控制，用于提供数据表的历史记录。例如，跟踪特定列的元数据变动，或查看表的大小随时间变化的趋势。可以查看过去某个时刻元数据的信息对于审计、调试以及从新处理和回滚来讲都很是有用。

• 为数据 lineage 服务提供数据表的上下文信息。例如，在 Metacat 中汇总数据表访问频率等元数据，并发布到数据 lineage 服务中，用于对数据表的关键性程度进行排序。

• 增长对 Elasticsearch 和 Kafka 等数据存储的支持。

• 可插拔的元数据验证。因为业务和用户定义的元数据是自由形式的，为了保持元数据的完整性，咱们须要对其进行验证。Metacat 应该有一个可插拔的架构，可在存储元数据以前执行验证策略。

相关连接

Metacat GitHub 地址：

https://github.com/Netflix/metacat

原文连接：

https://medium.com/netflix-techblog/metacat-making-big-data-discoverable-and-meaningful-at-netflix-56fb36a53520