什么是 Unity Catalog？

2025-06-19

本文介绍 Unity Catalog - Azure Databricks 上的数据和 AI 资产的统一治理解决方案。它介绍了关键概念，并概述了如何使用 Unity 目录管理数据。

注意

Unity Catalog 也可用作开源实施。请参阅公告博客和公共 Unity Catalog GitHub 存储库。

Unity Catalog 概述

Unity 目录是一个集中式数据目录，可在 Azure Databricks 工作区中提供访问控制、审核、世系、质量监视和数据发现功能。

Unity Catalog 的主要功能包括：

一次定义，全域安全：Unity Catalog 提供统一界面，管理适用于该地区所有工作区的数据访问策略。
符合标准的安全模型：Unity 目录的安全模型基于标准 ANSI SQL，并允许管理员使用熟悉的语法授予其现有 Data Lake 中的权限。
内置审核和世系：Unity Catalog 可自动捕获记录数据访问的用户级审核日志。 Unity Catalog 还会捕获世系数据，用于跟踪在所有语言中创建和使用数据资产的方式。
数据发现：使用 Unity Catalog，可以标记和记录数据资产，并提供搜索界面来帮助数据使用者查找数据。
系统表：Unity 目录允许你轻松访问和查询帐户的作数据，包括审核日志、计费使用情况和世系。

元存储

元存储是 Unity Catalog 中元数据的顶级容器。它注册有关数据资产和 AI 资产的元数据，以及用于管理对资产的访问的权限。如果一个工作区想要使用 Unity Catalog，它必须附加 Unity Catalog 元存储。应为拥有工作区的每个区域都设置一个元存储。

与 Hive 元存储不同，Unity 目录元存储不是服务边界：它在多租户环境中运行，并表示给定 Azure Databricks 帐户按区域划分数据的逻辑边界。

Unity 目录对象模型

在 Unity Catalog 元存储中，三级数据库对象层次结构由包含架构的目录组成，而架构又包含数据和 AI 对象，如表和模型。引用表、视图、卷、模型和函数时，此层次结构表示为三级命名空间（catalog.schema.table-etc）。

Unity Catalog 对象模型图

第一级：

目录用于组织数据资产，通常用作数据隔离方案中的顶层。目录通常镜像组织单位或软件开发生命周期范围。请参阅 Azure Databricks 中的目录是什么？。
非数据安全对象（例如存储凭据和外部位置）用于管理 Unity 目录中的数据治理模型。这些内容也直接位于元存储下。在 Unity 目录用来管理对外部数据源的访问的安全对象中更详细地介绍了它们。

第二级：

架构（也称为数据库）包含表、视图、卷、AI 模型和函数。架构将数据和 AI 资产组织成比目录更细粒度的逻辑类别。通常，架构代表单个用例、项目或团队沙盒。请参阅 Azure Databricks 中的架构是什么？。

第三级：

表是按行和列组织的数据集合。表可以是托管的，Unity Catalog 管理表的整个生命周期，也可以是外部的，Unity Catalog 管理 Azure Databricks 内部对数据的访问，但不管理其他客户端对云存储数据的访问。请参阅 Azure Databricks 表简介和托管表与外部表及卷的对比。
视图是针对一个或多个表的已保存查询。请参阅什么是视图？。
卷表示云对象存储中的数据的逻辑卷。可以使用卷来存储、组织和访问任何格式的文件，包括结构化、半结构化和非结构化数据。它们通常用于非表格数据。卷可以是托管的，Unity Catalog 管理存储中数据的整个生命周期和布局，也可以是外部的，Unity Catalog 管理 Azure Databricks 内部对数据的访问，但不管理其他客户端对云存储数据的访问。请参阅什么是 Unity Catalog 卷？和托管表/卷与外部表/卷。
函数是已保存逻辑的单元，返回标量值或行集。请参阅 Unity Catalog 中的用户定义函数 (UDF)。
模型是使用 MLflow 打包并在 Unity Catalog 中注册为函数的 AI 模型。请参阅在 Unity Catalog 中管理模型生命周期。

Unity Catalog 用于管理对外部数据源访问的可保护对象

除了架构中包含的数据库对象和 AI 资产外，Unity 目录还使用以下安全对象来管理对云存储和其他外部数据源和服务的访问权限：

存储凭据，它封装了提供对云存储的访问的长期云凭据。请参阅创建用于连接到 Azure Data Lake Storage的存储凭据。
外部位置指的是云存储路径以及访问该路径所需的存储凭据。外部位置可用于创建外部表或为托管表和卷分配托管存储位置。请参阅 “创建外部位置”，将云存储连接到 Azure Databricks、云存储和数据隔离，并在 Unity 目录中指定托管存储位置。
连接，表示使用 Lakehouse Federation 授予对 MySQL 等数据库系统中的外部数据库的只读访问权限的凭据。请参阅“什么是 Lakehouse Federation？”。
服务凭据，封装提供对外部服务的访问权限的长期云凭据。请参阅 “创建服务凭据”。

Unity Catalog 用于管理对共享资源访问权限的可安全管理对象

Unity 目录使用以下安全对象来管理跨元存储或组织边界的数据和 AI 资产共享：

洁净室，表示 Databricks 托管环境，其中多个参与者可以协作处理同一个项目，且无需彼此共享基础数据。请参阅什么是 Azure Databricks 洁净室？。
共享，即表示数据提供者与一个或多个接收者共享的只读数据和 AI 资产集合的 Delta Sharing 对象。
接收者，即表示从数据提供者接收共享的实体的 Delta Sharing 对象。
提供者，即表示与接收者共享数据的实体的 Delta Sharing 对象。

有关 Delta Sharing 安全对象的详细信息，请参阅什么是 Delta Sharing？。

管理员角色

默认情况下，以下 Azure Databricks 管理员角色具有许多 Unity 目录权限：

帐户管理员：可以创建元存储、将工作区链接到元存储、添加用户以及为元存储分配特权。
工作区管理员：可将用户添加到工作区，并管理许多特定于工作区的对象，例如作业和笔记本。视工作区而定，工作区管理员还可以在关联到工作区的元存储上拥有许多权限。
元存储管理员：如果要在元存储级别管理表和卷存储，则需要此可选角色。如果想要跨区域中的多个工作区集中管理数据，也很方便。

有关详细信息，请参阅 Unity 目录中的管理员权限。

授予和撤消对安全对象的访问权限

特权用户可以在层次结构中的任何级别（包括元存储本身）授予和撤销对安全对象的访问权限。除非撤销访问权限，否则对对象的访问会隐式授予该对象的所有子对象的相同访问权限。

可以使用典型的 ANSI SQL 命令授予和撤销对 Unity Catalog 中对象的访问权限。例如：

GRANT CREATE TABLE ON SCHEMA mycatalog.myschema TO `finance-team`;

还可以使用 Catalog Explorer、Databricks CLI 和 REST API 来管理对象权限。

使用 Catalog Explorer 授予权限

元存储管理员、对象所有者以及具有 MANAGE privilege 对象的用户可以授予和撤销访问权限。若要了解如何在 Unity Catalog 中管理权限，请参阅在 Unity Catalog 中管理权限。

Unity Catalog 中数据库对象的默认访问权限

Unity Catalog 遵循最小特权原则，用户拥有执行所需任务所需的最小访问权限。创建工作区时，非管理员用户只能访问自动配置的工作区目录，这使得此目录成为用户尝试在 Unity Catalog 中创建和访问数据库对象过程的便捷场所。请参阅工作区目录权限。

使用 Unity Catalog 中的数据库对象

在 Unity Catalog 中使用数据库对象与使用 Hive 元存储中注册的数据库对象非常相似，不同之处在于 Hive 元存储不包括对象命名空间中的目录。可以使用熟悉的 ANSI 语法在 Unity Catalog 中创建数据库对象、管理数据库对象、管理权限和使用数据。还可以使用 Catalog Explorer UI 创建数据库对象、管理数据库对象和管理数据库对象的权限。

有关详细信息，请参阅 Azure Databricks 中的数据库对象。

托管表/卷与外部表/卷

表和卷可以是托管的，也可以是外部的。

托管表完全由 Unity Catalog 管理，这意味着 Unity Catalog 管理每个托管表的治理和底层数据文件。托管表存储在云存储中 Unity Catalog 管理的位置。托管表始终使用 Delta Lake 格式。可以将托管表存储在元存储、目录或架构级别。
外部表是指使用 Unity Catalog 管理其 Azure Databricks 访问权限，但使用云提供程序和其他数据平台管理其数据生命周期和文件布局的表。通常情况下，使用外部表在 Azure Databricks 中注册大量现有数据，或者在需要使用 Azure Databricks 之外的工具对数据进行写访问时使用外部表。外部表支持多种数据格式。在 Unity Catalog 元存储中注册外部表后，可以按照与托管表相同的方式管理和审核 Azure Databricks 对该表的访问（和使用）。
托管卷由 Unity Catalog 完全托管，这意味着 Unity Catalog 管理对云提供商帐户中卷存储位置的访问。创建托管卷时，它会自动存储在分配给包含架构的托管存储位置中。
外部卷表示在 Azure Databricks 之外管理的存储位置中，但在 Unity Catalog 中注册以控制和审核 Azure Databricks 内部的访问的现有数据。在 Azure Databricks 中创建外部卷时，请指定其位置，该位置必须位于 Unity Catalog 外部位置中定义的路径上。

Databricks 建议大多数用例使用托管表和卷，因为它们允许充分利用 Unity Catalog 治理功能和性能优化。有关外部表和卷的典型用例的信息，请参阅托管表和外部表以及托管卷和外部卷。

另请参阅：

云存储和数据隔离

Unity 目录以两种主要方式使用云存储：

托管存储：在 Azure Databricks 中创建的托管表和托管卷（非结构化的非表格数据）的默认位置。可以在元存储、目录或架构级别定义这些托管存储位置。在云提供商中创建托管存储位置，但其生命周期完全由 Unity 目录管理。
存储外部表和卷的位置。这些表和卷从 Azure Databricks 的访问由 Unity 目录管理，但其数据生命周期和文件布局是使用云提供程序和其他数据平台管理的。通常情况下，使用外部表或卷在 Azure Databricks 中注册大量现有数据，或者在需要使用 Azure Databricks 之外的工具对数据进行写访问时使用外部表。

使用外部位置控制对云存储的访问

托管存储位置和存储外部表和卷的存储位置都使用外部位置安全对象来管理来自 Azure Databricks 的访问。外部位置对象引用云存储路径和访问它所需的 存储凭据 。存储凭据本身是 Unity 目录安全对象，用于注册访问特定存储路径所需的凭据。这些安全对象共同确保对存储的访问由 Unity Catalog 控制和跟踪。

下图显示了单个云存储容器的文件系统层次结构，其中 4 个外部位置共享一个存储凭据。

外部位置

有关详细信息，请参阅 Unity 目录如何控制对云存储的访问？。

托管存储位置层次结构

在 Unity 目录中定义托管存储的级别取决于首选的数据隔离模型。组织可能需要将特定类型的数据存储在云租户的特定帐户或存储桶中。

Unity 目录使你能够在元存储、目录或架构级别配置托管存储位置以满足此类要求。

例如，假设你的组织有一个公司合规性策略，它要求与人力资源相关的生产数据驻留在容器 abfss://mycompany- 中hr-prod@storage-account.dfs.core.windows.net。在 Unity 目录中，可以通过在目录级别设置位置、创建名为 hr_prod目录的目录，以及向其分配位置 abfss://mycompany/hr-prod@storage-account.dfs.core.windows.netunity-catalog 来实现此要求。这意味着，在 hr_prod 目录中创建的托管表或卷（例如，使用 CREATE TABLE hr_prod.default.table …）将其数据存储在 abfss://mycompany-hr-prod@storage-account.dfs.core.windows.net/unity-catalog 中。（可选）可以选择提供架构级别位置，以更精细地组织 hr_prod catalog 内部的数据。

如果某些目录不需要存储隔离，你可以选择在元存储级别设置存储位置。此位置用作未分配存储的目录和架构中的托管表和卷的默认位置。但是，通常情况下，Databricks 建议为每个目录分配单独的托管存储位置。

系统会评估存储位置从架构到目录到元存储的层次结构。

例如，如果在 myCatalog.mySchema.myTable 中创建了表 my-region-metastore，则根据以下规则确定表存储位置：

如果为 mySchema 提供了一个位置，则会将其存储在该位置。
如果未提供，并且已在 myCatalog 提供了位置，则会将其存储在该位置。
最后，如果未在 myCatalog 提供任何位置，则会将其存储在与 my-region-metastore 关联的位置中。

Unity Catalog 存储层次结构

有关详细信息，请参阅在 Unity 目录中指定托管存储位置。

通过工作空间目录绑定进行环境隔离

默认情况下，目录所有者（以及元存储管理员，如果已为帐户定义）可以使目录可供连接到同一 Unity Catalog 元存储的多个工作区中的用户访问。

组织和合规性要求通常会规定，你要保证只能在特定环境中访问某些数据（如个人数据）。你可能还需要将生产数据与开发环境隔离，或确保某些数据集和域永远不会联接在一起。

在 Azure Databricks 中，工作区是主要数据处理环境，目录是主数据域。 Unity Catalog 允许元存储管理员、目录所有者和具有 MANAGE 权限的用户将目录“绑定”到特定工作区。这些环境感知绑定使你能够确保工作区中只有某些目录可用，而无需考虑授予用户的数据对象的特定权限。但是，如果使用工作区隔离用户数据访问，则可能需要将目录访问限制到帐户中的特定工作区，以确保仅在这些工作区中处理某些类型的数据。例如，可能需要单独的生产和开发工作区，或者需要单独的工作区来处理个人数据。这称为工作区-目录绑定。请参阅限制对特定工作区的目录访问。

Unity Catalog 目录

注意

为了提高数据隔离度，还可以将云存储访问和云服务访问权限绑定到特定工作区。请参阅（可选）向特定工作区分配存储凭据，（可选）将外部位置分配给特定工作区，以及（可选）向特定工作区分配服务凭据。

如何实现为组织设置 Unity 目录？

若要使用 Unity Catalog，Azure Databricks 工作区必须支持 Unity Catalog，这意味着要将工作区附加到 Unity Catalog 元存储。

工作区如何附加到元存储？这取决于帐户和工作区：

通常，首次在区域中创建 Azure Databricks 工作区时，会自动创建元存储并将其附加到工作区。
对于某些较旧的帐户，帐户管理员必须创建元存储，并将该区域中的工作区分配给该元存储。如需说明，请参阅创建 Unity Catalog 元存储。
如果帐户已为某个区域分配了元存储，帐户管理员可以决定是否自动将元存储附加到该区域中的所有新工作区。请参阅 “启用元存储”以自动分配给新工作区。

无论工作区是否自动支持 Unity Catalog，都需要执行以下步骤才能开始使用 Unity Catalog：

创建目录和架构以包含数据库对象（如表和卷）。
创建托管存储位置以将托管表和卷存储在这些目录和架构中。
授予用户对目录、架构和数据库对象的访问权限。

自动启用 Unity Catalog 的工作区会预配工作区目录，并向所有工作区用户授予广泛的权限。可以从此目录开始，方便地试用 Unity Catalog。

有关详细的设置说明，请参阅 Unity 目录入门。

将现有工作区升级到 Unity Catalog

若要了解如何将非 Unity 目录工作区升级到 Unity 目录，请参阅将 Azure Databricks 工作区升级到 Unity 目录。

Unity Catalog 要求和限制

Unity Catalog 需要特定类型的计算和文件格式，如下所述。下面还列出了一些 Azure Databricks 功能，这些功能并非在所有 Databricks Runtime 版本的 Unity Catalog 中都完全受支持。

区域支持

所有区域都支持 Unity Catalog。有关详细信息，请参阅 Azure Databricks 区域。

计算要求

运行 Databricks Runtime 11.3 LTS 或更高版本的群集支持 Unity Catalog。默认情况下，所有 SQL 仓库计算版本都支持 Unity Catalog。

在早期版本的 Databricks Runtime 上运行的群集不支持所有 Unity Catalog 正式版的功能。

若要访问 Unity Catalog 中的数据，必须为群集配置正确的访问模式。默认情况下，Unity Catalog 是安全的。如果未使用标准或专用访问模式配置群集，则群集无法访问 Unity 目录中的数据。请参阅访问模式。

有关每个 Databricks Runtime 版本中 Unity 目录功能更改的详细信息，请参阅发行说明。

Unity Catalog 的限制因访问模式和 Databricks Runtime 版本而异。请参阅 Unity Catalog 的计算访问模式限制。

文件格式支持

Unity Catalog 支持以下表格式：

托管表必须使用 delta 表格式。
外部表可以使用 delta、CSV、JSON、avro、parquet、ORC 或 text。

限制

Unity Catalog 具有以下限制。其中一些特定于较旧的 Databricks Runtime 版本和计算访问模式。

根据 Databricks Runtime 和访问模式，结构化流工作负载还存在其他限制。请参阅 Unity Catalog 的计算访问模式限制。

Databricks 发布了定期缩减此列表的新功能。

以前在工作区中创建的组（即工作区级组）不能在 Unity Catalog GRANT 语句中使用。这是为了确保跨工作区的组视图保持一致。若要在 GRANT 语句中使用组，请在帐户级别创建组，并更新主体或组管理的任何自动化（例如 SCIM、Okta 和 Microsoft Entra ID 连接器以及 Terraform），用于引用帐户终结点，而不是工作区终结点。请参阅组源。
R 中的工作负荷不支持在运行 Databricks Runtime 15.3 及更低版本的计算上使用动态视图实现行级或列级安全性。

使用专门的计算资源运行 Databricks Runtime 15.4 LTS 或更高版本，以处理 R 中查询动态视图的工作负载。此类工作负荷还需要为无服务器计算启用的工作区。有关详细信息，请参阅专用计算上的精细访问控制。

在运行 Databricks Runtime 12.2 LTS 及更低版本的计算上，Unity Catalog 不支持浅表克隆。可以使用浅表克隆在 Databricks Runtime 13.3 LTS 及更高版本上创建托管表。无论 Databricks Runtime 版本如何，都无法使用它们创建外部表。请参阅适用于 Unity Catalog 表的浅表克隆。
Unity Catalog 表不支持 Bucket。如果运行尝试在 Unity Catalog 中创建 Bucket 表的命令，则会引发异常。
如果某些群集访问 Unity Catalog，而其他群集不访问，则从多个区域的工作区写入相同的路径或 Delta Lake 表可能会导致性能不可靠。
使用命令操作外部表的分区，例如 ALTER TABLE ADD PARTITION 需要启用分区元数据日志记录。请参阅外部表的分区发现。
对于非 Delta 格式的表格使用覆盖模式时，用户必须对父架构具有 CREATE TABLE 权限，且必须是现有对象的所有者，或者对对象具有 MODIFY 权限。
Databricks Runtime 12.2 LTS 及更低版本不支持 Python UDF。这包括 UDAF、UDTF 和 Spark 上的 Pandas（applyInPandas 和 mapInPandas）。 Databricks Runtime 13.3 LTS 及更高版本支持 Python 标量 UDF。
在采用标准访问模式的计算中，Databricks Runtime 14.1 及更低版本不支持 Scala UDF。在采用标准访问模式的计算中，Databricks Runtime 14.2 及更高版本支持 Scala 标量 UDF。
不支持标准 Scala 线程池。请改用 org.apache.spark.util.ThreadUtils 中的特殊线程池，例如 org.apache.spark.util.ThreadUtils.newDaemonFixedThreadPool。但是，不支持 ThreadUtils 中的以下线程池：ThreadUtils.newForkJoinPool 和任何 ScheduledExecutorService 线程池。

只有工作区级别的 Unity Catalog 事件支持审核日志记录。不会记录在帐户级别发生的、不引用工作区的事件，例如创建元存储。

在 Unity Catalog 中注册的模型具有其他限制。请参阅限制。

资源配额

Unity Catalog 对所有安全对象强制实施资源配额。这些配额列在资源限制中。如果预期超过这些资源限制，请联系 Azure Databricks 帐户团队。

可以使用 Unity Catalog 资源配额 API 来监视配额使用情况。请参阅监视 Unity Catalog 资源配额的使用情况。