通过

旧 Hive 元存储中的数据库对象

  • 项目

Azure Databricks 文档侧重于通过 Unity Catalog 使用数据对象，但大多数说明同样适用于使用旧版 Hive 元存储中注册的对象。

本文重点介绍如何使用在旧版 Hive 元存储中注册的数据库对象。 具体而言，本文将指出使用 Hive 元存储对象与使用 Unity Catalog 对象的不同之处。 它还描述了其他可能的意外行为。

Databricks 建议将所有数据从旧版 Hive 元存储迁移到 Unity Catalog。 请参阅将 Hive 表和视图升级到 Unity Catalog。

Hive 元存储数据管理的工作原理是什么？

尽管 Azure Databricks 工作区仍包含内置的 Hive 元存储，但使用 Hive 元存储进行数据管理已被弃用。 Databricks 建议使用 Unity Catalog 进行所有数据管理。 请参阅使用 Unity Catalog 和旧式 Hive 元存储。

为 Unity Catalog 启用工作区并不会降低你使用 Hive 元存储中已注册数据的能力。 在旧版 Hive 元存储中注册的所有数据对象都显示在 hive_metastore 目录的 Unity Catalog 界面中。 混合 Hive 元存储和 Unity Catalog 工作区是用于转换长期 Hive 元存储工作区的有用模型。 但是，Unity Catalog 在数据管理和性能方面占据优势，应尽快完全转换工作区。

Hive 元存储使用表访问控制（表 ACL）来管理对数据库对象的访问。 在共享访问模式下使用计算时，仍然对表访问控制提供一些支持。 请参阅 Hive 元存储表访问控制（旧版）。

凭据直通身份验证是针对 Hive 元存储数据库对象的数据管理的一种已弃用模式。 本文不处理凭据直通身份验证问题。 请参阅凭据直通身份验证（旧式）。

注意

本文引用的 Hive 元存储中的数据访问控制，指的是旧表访问控制。

什么是 hive_metastore 目录？

在为 Unity Catalog 启用的工作区中，Hive 元存储中的所有架构都显示为 Unity Catalog 三级命名空间中 hive_metastore 目录的子级。 Hive 元存储实际上不使用目录，此结构为 Unity Catalog 用户提供了一个进入旧版 Hive 元存储中的表的入口点。 使用以下语法查询旧版 Hive 元存储中的表：

SELECT * FROM hive_metastore.schema_name.table_name

注意

可以选择在启用了 Unity Catalog 的工作区中将 hive_metastore 目录设置为工作区默认值。 请参阅《管理默认目录》。

Hive 元存储中的架构

在旧版 Hive 元存储中，架构是数据对象层次结构中的最高级别。

Unity Catalog 和 Hive 元存储之间存在一些重要差异，包括：

  • 无法使用目录资源管理器在 Hive 元存储中创建架构。 可以查看和编辑架构的权限。
  • 在 Hive 元存储中创建的架构只能在其名称中使用字母数字 ASCII 字符和下划线。
  • Hive 元存储允许在创建过程中声明架构的 LOCATION。 此功能类似于 Unity Catalog 托管存储位置，其行为差异如下：
    • 如果未提供位置，则将使用默认位置 /user/hive/warehouse/<schema-name>。 此位置位于 DBFS 根目录中，不建议存储任何生产数据。
    • 提供的路径可以是用户用于创建架构的任何云存储位置，包括云 URI、DBFS 根目录和 DBFS 装载路径。
    • 对位置的访问不受 Hive 元存储的管理。
    • 删除 Hive 元存储中的架构会导致该架构位置中的所有文件都以递归方式删除，不管表类型如何（托管或外部）。

为避免数据意外丢失，Databricks 建议在使用 Hive 元存储架构位置时执行以下操作：

  • 不要分配已包含数据的架构位置。
  • 不要在架构位置中创建外部表。
  • 不要在多个架构之间共享位置。
  • 不要分配与另一个架构位置重叠的架构位置。 换而言之，不要使用另一个架构位置的子级路径。
  • 不要分配与外部表位置重叠的架构位置。

Hive 元存储中的托管表

Hive 元存储中的托管表不具备 Unity Catalog 中托管表的任何性能优势。 与 Unity Catalog 托管表一样，Hive 元存储托管表默认使用 Delta Lake。 但是，在 Hive 元存储中，与 Unity Catalog 不同，还可以使用 Azure Databricks 支持的大多数其他数据格式创建托管表。

Hive 元存储中的托管表始终在包含架构的存储位置创建。 用于查询托管表的计算必须有权访问存储位置。

Hive 元存储不按照 Unity Catalog 的方式管理托管表的数据布局。 在 Hive 元存储中删除托管表时，会立即删除所有基础数据文件。 另一方面，在 Unity Catalog 中，可以 UNDROP 托管表 7 天，数据将在 30 天内永久删除。

可以使用基于路径的访问来读取或写入 Hive 元存储托管表中的数据，而在 Unity Catalog 中，则不能也不需要这样做。

Hive 元存储中的外部表

引入 Unity Catalog 之前在 Azure Databricks 中创建的大多数表都配置为 Hive 元存储中的外部表。 支持外部表的旧式建议通常侧重于以下几个关键方面：

  • 可以在云对象存储中的现有数据的基础上注册外部表。
  • 可以直接从外部系统访问外部表中的数据文件进行读取或写入。
  • 如果意外删除了表，不会删除数据文件。
  • 由于外部表需要 LOCATION，因此生产数据不太可能意外出现在 DBFS 根目录中。

Azure Databricks 目前建议将 Unity Catalog 托管表用于大多数表格数据存储。 请参阅使用托管表。

Hive 元存储中的视图

可以在 Hive 元存储中声明视图，该视图由 Azure Databricks 支持的任何数据源提供支持。 在 Unity Catalog 中，只能针对 Unity Catalog 表和视图声明视图，包括外表、具体化视图和 Delta Sharing 表。

由于能够针对非表格数据源声明视图，Hive 元存储中的视图可以授予意外或无意访问数据的权限，并结合用户环境中的其他访问配置。

例如，请考虑如下事项：

  • 使用 DBFS 装载路径 /mnt/my_table 定义表 my_table。
    • DBFS 装载凭据存储在工作区中，因此默认情况下所有用户都有权访问此路径。
  • 表 ACL 用于将对 my_table 的访问权限限制为一组用户。
    • 旧版表 ACL 仅适用于配置了共享访问模式或 SQL 仓库的计算。
  • 视图 my_view 是直接针对支持相同数据文件 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table' 的云 URI 定义的。
    • URI 凭据依赖于 Spark 会话或计算配置中定义的访问策略。

视图 my_view 具有以下属性：

  • 它不使用用于将云对象存储装载到 /mnt/my_table 的 DBFS 装载凭据。
  • 它不遵循在 my_table 上设置的表 ACL，无论计算配置如何。
  • 它需要为计算配置的数据访问策略，该策略提供对 'abfss://container-name@storage-account-name.dfs.core.windows.net/my_table' 的读取访问。

注意

这是你可能遇到的一个意外行为示例，并没有全面地介绍旧版 Hive 元存储中视图呈现的所有潜在缺陷。 Databricks 建议对所有视图定义使用 Unity Catalog。

旧版 Hive 表和 HiveQL 支持

Azure Databricks 包括对 Hive 表和 HiveQL 功能的一些旧式支持。 此功能是早期版本的 Azure Databricks 和 Apache Hadoop 工具生态系统的遗留部分。 Databricks 不建议使用 Hive 表或其他 Hive 功能，因为此功能未经过优化，并且在某些计算配置中不受支持。

下面的文章将介绍旧版 Hive 功能：