原文

本文翻译自《SPIP: Spark API for Table Metadata》

背景和动机

DataSource v2 是用来读取和写入数据的新型 API ，旨在支持更多外部数据存储，并且可以更灵活地集成这些存储。

但是，v2 API目前缺少该集成的关键部分：在外部存储中创建，更改和删除表的方法。

SQL 和 DataFrames 都支持 CTAS（Create Table As Select），用户期望在一次操作中创建一个表并将数据写入该表。

但是没有 API 创建目标表，实际行为取决于 DataSource v2 实现。

如果写入失败，则剩下来实现的要么表已经存在要么表已经被删除。

此外，除了模糊的 SaveMode 之外，还没有什么可以区分 CTAS 和正常的写入操作，因此可能使用 Append 模式的写入出现失败的情况，因为表丢失或创建了一个新表，具体取决于实现。

最后，Spark 没有机制来配置 v2 中 CTAS 创建的表：例如，分区就不受支持。

数据工程师期望跨数据源的类似CTAS的高级操作能够出现一致的行为。

SPIP to Standardize SQL Logical Plans 介绍了一小批的高级操作，总结了它们行为的共同期望，并且希望 Spark 能够做到在自身中实现它们，只依赖于现有的DataSource v2 写数据的 API。

这就需要一个 Catalog 的 API，Spark 可以对这些数据源创建，更改和删除表。

例如，Spark 可以在一个数据源上面调用创建，写入和删除（仅当写入失败时）来实现CTAS。

这就导致少数场景下写入失败后表依然存在：当备份的元数据存储不可用，或者驱动程序自己就失败的时候。

除了用于数据源的 Catalog API之外，还需要用于 Catalog 操作的公共 API。

在 Scala 和其他支持的语言中 DataFrame API 将 SQL 引擎和计划器暴露给 Spark 的应用程序，但没有等效的 API 可以处理创建，更改或删除，这在 Spark 所支持的 DDL 中是可以表达的操作。

Catalog 接口起了一个头，但在 2.x 版本中它不能处理分区，它也没有暴露可以更改表的Schema 的接口。

Catalog 接口也不支持多个元数据的 catalog，只有一个全局 catalog 时才可用。

目标

定义 catalog API 用来 create，alter，load 和 drop 表。

非目标

• 多 catalog 的支持：Spark 中使用多个 catalog 将依赖于所提出的API，但需要更详细的实现计划。
• Identifiers for tables, views, or functions with multi-catalog support
• 视图：Spark 支持可以使用 DataFrame API 定义的视图。
• 函数：一些 catalog（如hive）可以存储函数，但这超出了范围。

视图和函数超出了范围，我们应该专注于从 catalog 中create，alter，load 和 drop 表的内容。

catalog 可以实现上面提出的管理表的方法以及稍后定义的视图和函数的方法。

这些可以在单个 Catalog 接口或单独的接口中来特定的目的，如 TableCatalog，FunctionCatalog和ViewCatalog。

目标角色

• 开发人员：数据源实现者需要能够对 Spark 进行 CREATE，ALTER 和 DROP 操作。
• 数据工程师：
• • 数据工程师期望在数据源实现中， INSERT 和CTAS等高级操作能够达到一致的行为。
• • 数据工程师应该能够使用一致的 API 来定义和更新表，而不仅仅是DDL。

建议的更改

Spark 表引用的方法与本提案中的大多数内容都是比较吻合的，因此这将使用通用的CatalogIdentifier代替表标识符或 URI。

这是一个为了达到多 catalog 支持在 Spark 中标识表的占位符。

因此可以专注于那些传递用来创建和管理表的信息。