Unity Catalog 最佳做法

本文档提供有关使用 Unity Catalog 和 Delta Shareing 满足数据治理需求的建议。

Unity Catalog 是 Databricks 平台数据和 AI 的细化治理解决方案。 它通过提供一个集中管理和审核数据访问的位置，来帮助简化数据的安全性和治理。 Delta Sharing 是一个安全的数据共享平台，可用于与组织外的用户共享 Azure Databricks 中的数据。 它使用 Unity Catalog 来管理和审核共享行为。

数据治理和数据隔离构建基块

若要制定适用于组织的数据治理模型和数据隔离计划，了解在 Azure Databricks 中创建数据治理解决方案时可用的主要构建基块会很有帮助。

下图说明了 Unity Catalog 中的主要数据层次结构（某些安全对象灰显，以强调目录下管理的对象层次结构）。

该层次结构中的对象包括：

• 元存储：元存储是 Unity Catalog 中对象的顶级容器。 元存储属于帐户级别，在 Azure Databricks 数据治理模型中位于金字塔顶部。

  元存储管理数据资产（表、视图和卷）以及用于治理对数据资产的访问的权限。 Azure Databricks 帐户管理员可以为他们的每个运营区域创建一个元存储，并将其分配到同一区域中的多个 Azure Databricks 工作区。 元存储管理员可以管理元存储中的所有对象。 他们无权直接读取和写入元存储中注册的表，但可以通过传输数据对象所有权的能力进行间接访问。

  默认情况下，任何给定元存储的物理存储都与帐户中任何其他元存储的存储隔离。

  元存储提供区域隔离，但不用作数据隔离单元。 数据隔离应在目录级别开始。

• 目录：目录是数据层次结构（目录 > 架构 > 表/视图/卷）中的最高级别，由 Unity Catalog 元存储管理。 它们旨在用作典型 Azure Databricks 数据治理模型中数据隔离的主要单元。

  目录表示架构的逻辑分组，通常受数据访问要求的约束。 目录通常镜像组织单位或软件开发生命周期范围。 例如，可以选择生产数据的目录和开发数据的目录，或非客户数据的目录和敏感客户数据的目录。

  可以将目录存储在元存储级别，也可以将目录配置为独立于父元存储的其余部分进行存储。 如果工作区自动启用 Unity Catalog，则没有元存储级存储，你必须在创建目录时指定存储位置。

  如果目录是 Azure Databricks 数据治理模型中数据隔离的主要单位，则工作区是处理数据资产的主要环境。 元存储管理员和目录所有者可以独立于工作区管理对目录的访问权限，也可以将目录绑定到特定工作区，以确保仅在这些工作区中处理某些类型的数据。 例如，可能需要单独的生产和开发工作区，或者需要单独的工作区来处理个人数据。

  默认情况下，安全对象的访问权限由该对象的子级继承，目录位于层次结构的顶部。 这样，可以更轻松地为数据设置默认访问规则，并仅当需要时在层次结构的每个级别指定不同的规则。

• 架构（数据库）：架构也称为数据库，是表格数据（表和视图）、非表格数据（卷）、函数和机器学习模型的逻辑分组。 架构提供了一种比目录更精细的组织和控制对数据的访问权限的方法。 它们通常表示单个用例、项目或团队沙盒。

  架构可以存储在与父级目录相同的物理存储中，也可以将架构配置为与父级目录的其余部分分开存储。

  元存储管理员、父级目录所有者和架构所有者可以管理对架构的访问权限。

• 表：表位于 Unity Catalog 三级命名空间的第三层。 它们包含数据行。

  Unity Catalog 可创建托管表和外部表。

  Unity Catalog 完全管理托管表的生命周期和文件布局。 默认情况下，托管表存储在创建元存储时配置的根存储位置。 可以选择在目录或架构级别隔离托管表的存储。

  外部表是使用云提供商和其他数据平台（非 Unity Catalog）管理其数据生命周期和文件布局的表。 通常使用外部表注册大量现有数据，或者在需要使用 Azure Databricks 群集和 Databricks SQL 仓库之外的工具写入访问数据的情况下使用外部表。 在 Unity Catalog 元存储中注册外部表后，可以按照与托管表相同的方式管理和审核 Azure Databricks 对该表的访问权限。

  父级目录所有者和架构所有者可以管理对表的访问权限，元存储管理员也可以间接管理。

• 视图：视图是派生自元存储中的一个或多个表和视图的只读对象。

• 行和列：行和列级访问权限以及数据掩码是使用动态视图或行筛选器和列掩码授予的。 动态视图是只读的。

• 卷：卷驻留在 Unity Catalog 三级命名空间的第三层。 它们管理非表格数据。 可以使用卷来存储、组织和访问任何格式的文件，包括结构化、半结构化和非结构化数据。 卷中的文件不能注册为表。

• 模型和函数：严格地说，尽管它们不是数据资产，已注册的模型和用户定义的函数也可以在 Unity Catalog 中管理，并驻留在对象层次结构的最低级别。 请参阅 Unity Catalog 中的用户定义函数 (UDF)。

规划数据隔离模型

当组织使用 Azure Databricks 等数据平台时，通常需要在环境（如开发环境和生产环境）间或组织运营单位间设置数据隔离边界。

隔离标准可能因组织而异，但通常包括以下预期：

• 用户只能按照指定的访问规则获取对数据的访问权限。
• 数据只能由指定的人员或团队管理。
• 数据在存储中以物理方式分隔。
• 只能在指定环境中访问数据。

对数据隔离的需求可能导致环境孤立，这会给数据治理和协作带来不必要的困难。 Azure Databricks 使用 Unity Catalog 解决此问题，它在维护统一数据治理平台的同时提供了多种数据隔离选项。 本部分讨论 Azure Databricks 中可用的数据隔离选项以及如何使用这些选项，无论首选集中式数据治理模型还是分布式数据治理模型。

用户只能按照指定的访问规则获取对数据的访问权限

大部分组织都根据内部或法规要求对数据访问有严格的要求。 必须保持安全的典型数据示例包括员工工资信息或信用卡付款信息。 对此类信息的访问通常受到严格控制和定期审核。 Unity Catalog 可以对目录中的数据资产进行精细控制，以满足这些行业标准。 借助 Unity Catalog 提供的控件，用户只能查看和查询他们有权查看和查询的数据。

数据只能由指定的人员或团队管理

Unity Catalog 提供集中式治理模型或分布式治理模型的选择。

在集中式治理模型中，治理管理员是元存储的所有者，可以获取任何对象的所有权，并可以授予和撤销权限。

在分布式治理模型中，目录或一组目录为数据域。 目录的所有者可以创建并拥有所有资产，并管理数据域中的治理。 任何给定域的所有者都可以独立于其他域的所有者进行操作。

无论选择元存储还是目录作为数据域，Databricks 强烈建议将组设置为元存储管理员或目录所有者。

数据在存储中以物理方式分隔

组织可能需要将特定类型的数据存储在云租户的特定帐户或存储桶中。

可通过 Unity 目录在元存储、目录或架构级别配置存储位置以满足此类要求。

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

如果不需要这种存储隔离，可以在元存储级别设置存储位置。 此位置会作为默认位置，用于在元存储中跨目录和架构存储托管表和卷。

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

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

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

只能在指定环境中访问数据

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

在 Databricks 中，工作区是主要数据处理环境，目录是主数据域。 Unity Catalog 允许元存储管理员和目录所有者将目录分配或“绑定”到工作区。 这些环境感知绑定使你能够确保工作区中只有某些目录可用，而不考虑授予用户的数据对象的特定权限。

现在，让我们更深入地了解设置 Unity Catalog 以满足需求的过程。

配置 Unity Catalog 元存储

元存储是 Unity Catalog 中对象的顶级容器。 元存储可管理数据资产（表、视图和卷）以及由 Unity Catalog 管理的其他安全对象。 有关安全对象的完整列表，请参阅 Unity Catalog 中的安全对象。

本部分提供创建和配置元存储的提示。 如果工作区已自动启用 Unity Catalog，则无需创建元存储，但本部分提供的信息可能仍然有用。 请参阅自动启用 Unity Catalog。

元存储配置提示：

• 应为拥有 Azure Databricks 工作区的每个区域都设置一个元存储。

  附加到单个区域元存储的每个工作区都有权访问由该元存储管理的数据。 若要在元存储之间共享数据，请使用 Delta Sharing。

• 每个元存储都可以在云租户中配置一个托管存储位置（也称为根存储），可用于存储托管表和托管卷。

  如果选择创建元存储级托管位置，则必须确保没有用户有权直接访问它（即通过包含该位置的云帐户）。 授予对此存储位置的访问权限可能会使用户能够绕过 Unity Catalog 元存储中的访问控制，破坏可审核性。 出于这些原因，元存储托管存储应是专用容器。 不应重复使用同时也是 DBFS 根文件系统或之前是 DBFS 根文件系统的容器。

  还可选择在目录和架构级别定义托管存储，从而替代元存储的根存储位置。 在大多数情况下，Databricks 建议在目录级别存储托管数据。

• 你应该了解为 Unity Catalog 启用的工作区中工作区管理员的权限，并查看现有的工作区管理员分配。

  工作区管理员可以管理对工作区的操作，包括添加用户和服务主体、创建群集以及将其他用户委派为工作区管理员。 如果工作区自动启用了 Unity Catalog，则工作区管理员默认能够创建目录和许多其他 Unity Catalog 对象。 请参阅自动为 Unity Catalog 启用工作区时的工作区管理员权限

  工作区管理员还可以执行工作区管理任务，例如管理作业所有权和查看笔记本，这可以间接访问 Unity Catalog 中注册的数据。 工作区管理员是一个特权角色，应该谨慎分配。

• 如果使用工作区来隔离用户数据访问，则可能需要使用工作区目录绑定。 通过工作区目录绑定，可以按工作区边界限制目录访问。 例如，可以确保工作区管理员和用户只能从生产工作区环境 prod_workspace 访问 prod_catalog 中的生产数据。 默认设置是与附加到当前元存储的所有工作区共享目录。 请参阅（可选）为特定工作区分配目录。

  如果工作区自动启用了 Unity Catalog，则默认情况下提前预配的工作区目录都将绑定到工作区。

请参阅创建 Unity Catalog 元存储。

配置外部位置和存储凭据

外部位置允许 Unity Catalog 代表用户在云租户上读写数据。 外部位置定义为云存储的路径，它与可用于访问该位置的存储凭据相结合。

可以使用外部位置在 Unity Catalog 中注册外部表和外部卷。 这些实体的内容在物理上位于用户创建卷或表时引用的外部位置的子路径上。

存储凭据封装提供云存储访问权限的长期云凭据。 它可以是 Azure 托管标识（强烈建议）或服务主体。 与使用服务主体相比，使用 Azure 托管标识具有以下优势：

• 托管标识不需要维护凭据或轮换机密。
• 如果你的 Azure Databricks 工作区已部署到你自己的 VNet（也称为 VNet 注入），你可以连接到受存储防火墙保护的 Azure Data Lake Storage Gen2 帐户。

有关管理外部位置的最佳做法列表，请参阅管理外部位置、外部表和外部卷。 另请参阅创建外部位置以将云存储连接到 Azure Databricks。

整理数据

Databricks 建议使用目录在组织的整个信息体系结构中提供隔离。 这通常意味着目录与软件开发环境范围、团队或业务部门相对应。 如果使用工作区作为数据隔离工具（例如，将不同的工作区用于生产和开发环境，或者使用特定的工作区来处理高度敏感的数据），则还可以将目录绑定到特定的工作区。 这确保指定数据的所有处理都在适当的工作空间中完成。 请参阅（可选）为特定工作区分配目录。

架构（又称数据库）是 Unity Catalog 三级命名空间的第二层，用于组织表、视图和卷。 可使用架构来整理和定义资产的权限。

受 Unity Catalog 管理的对象可以是托管对象，也可以是外部对象：

• 托管对象是在 Unity Catalog 中创建数据对象的默认方法。

  Unity Catalog 可管理这些安全对象的生命周期和文件布局。 不应使用 Azure Databricks 以外的工具直接操作托管表或卷中的文件。

  托管表和卷存储在托管存储中，该存储可能存在于任何给定表或卷的元存储、目录或架构级别。 请参阅数据在存储中以物理方式分隔。

  当需要为内容预配受管理位置时，托管表和卷是一种方便的解决方案，无需创建和管理外部位置和存储凭据。

  托管表始终使用 Delta 表格式。

• 外部对象是其数据生命周期和文件布局不由 Unity Catalog 管理的安全对象。

  外部卷和表在外部位置注册，以提供对云存储中已存在的大量文件的访问权限，而无需数据复制活动。 如果你拥有其他系统生成的文件，并且需要将它们暂存以便从 Azure Databricks 中访问，或者如果 Azure Databricks 外部的工具需要直接访问这些文件，请使用外部对象。

  外部表支持 Delta Lake 和许多其他数据格式，包括 Parquet、JSON 和 CSV。 托管卷和外部卷都可用于访问和存储任意格式的文件：数据可以是结构化的、半结构化的或非结构化的。

有关创建表和卷的详细信息，请参阅在 Unity Catalog 中创建表和创建和使用卷。

管理外部位置、外部表和外部卷

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

在 Unity Catalog 中配置外部位置后，可以在外部位置内的目录上创建外部表和卷。 然后，可以使用 Unity Catalog 管理用户和组对这些表和卷的访问权限。 这样，你能够向特定用户或组提供对云存储容器中特定目录和文件的访问权限。

外部位置的使用建议

有关授予外部位置权限的建议：

• 仅向负责在 Unity Catalog 和云存储之间建立连接的管理员或者受信任的数据工程师授予创建外部位置的能力。

  通过外部位置，可以从 Unity Catalog 内部访问云存储中广泛包含的位置，例如整个存储桶或容器 (abfss://my-container@storage-account.dfs.core.chinacloudapi.cn) 或广泛的子路径 (abfss://my-container@storage-account.dfs.core.chinacloudapi.cn/path/to/subdirectory)。 目的是让云管理员能够参与设置一些外部位置，然后将管理这些位置的责任委托给你的组织中的 Azure Databricks 管理员。 然后，Azure Databricks 管理员可通过在外部位置下以特定前缀注册外部卷或外部表，进一步将外部位置整理到具有更精细权限的区域。

  由于外部位置非常多，Databricks 建议仅向负责在 Unity Catalog 和云存储之间建立连接的管理员后者受信任的数据工程师授予 CREATE EXTERNAL LOCATION 权限。 若要为其他用户提供更精细的访问权限，Databricks 建议在外部位置上注册外部表或卷，并使用这些卷或表授予用户访问数据的权限。 由于表和卷是目录和架构的子级，因此目录或架构管理员对访问权限拥有最终控制权。

• 不要向最终用户授予对外部位置的常规 READ FILES 或 WRITE FILES 权限。

  由于卷的可用性，用户只能将外部位置用于创建表、卷或托管位置。 对于数据科学或其他非表格数据用例，他们不应使用外部位置进行基于路径的访问。

  卷支持使用 SQL 命令、dbutils、Spark API、REST API、Terraform 和用户界面来处理文件，其中该用户界面用于浏览、上传和下载文件。 此外，卷还提供 FUSE 装载，可在 /Volumes/<catalog_name>/<schema_name>/<volume_name>/ 下的本地文件系统上访问该装载。 通过 FUSE 装载，数据科学家和 ML 工程师能够像在本地文件系统中那样访问文件，这是许多机器学习或操作系统库所需要的。

  如果必须授予对外部位置中的文件的直接访问权限（例如，为了在用户创建外部表或卷之前浏览云存储中的文件），可以授予 READ FILES。 授予 WRITE FILES 的用例很少见。

应使用外部位置执行以下操作：

• 使用 CREATE EXTERNAL VOLUME 或 CREATE TABLE 命令注册外部表和卷。
• 在以特定前缀创建外部表或卷之前，请先浏览云存储中的现有文件。 必须先具备 READ FILES 权限。
• 将位置注册为目录和架构的托管存储，而不是元存储根存储桶。 必须先具备 CREATE MANAGED STORAGE 权限。

关于使用外部位置的更多建议：

• 避免出现路径重叠冲突：切勿在外部位置的根目录中创建外部卷或表。

  如果在外部位置根目录中创建外部卷或表，则不能在外部位置创建任何其他外部卷或表。 转而请在外部位置内的子目录中创建外部卷或表。

关于使用外部卷的建议

应使用外部卷执行以下操作：

• 为外部系统生成的原始数据注册登陆区域，以支持其在 ETL 管道和其他数据工程活动的早期阶段的处理。
• 注册用于引入的暂存位置，例如使用自动加载程序、COPY INTO 或 CTAS (CREATE TABLE AS) 语句。
• 为数据科学家、数据分析师和机器学习工程师提供文件存储位置，以便当无法选择托管卷时在探索性数据分析和其他数据科学任务期间使用。
• 使 Azure Databricks 用户可以访问由其他系统生成和存储在云存储中的任意文件，例如，由监视系统或 IoT 设备捕获的大量非结构化数据（例如图像、音频、视频和 PDF 文件）的集合，或从本地依赖项管理系统或 CI/CD 管道导出的库文件（JAR 和 Python wheel文件）。
• 当无法选择托管卷时存储操作数据，例如日志记录或检查点文件。

关于使用外部卷的更多建议：

• Databricks 建议从一个架构中的某个外部位置创建外部卷。

关于使用外部表的建议

无法选择创建托管表时，应使用外部表来支持在云存储中存储的数据之上的正常查询模式。

关于使用外部表的更多建议：

• Databricks 建议对每个架构使用一个外部位置来创建外部表。
• Databricks 强烈建议不要将表注册为多个元存储中的外部表，因为存在出现一致性问题的风险。 例如，对一个元存储中的架构的更改不会注册到第二个元存储中。 使用 Delta Sharing 在元存储之间共享数据。 参阅使用 Delta Sharing 安全共享数据。

配置访问控制

Unity 目录中的每个安全对象都有一个所有者。 创建对象的主体将成为其初始所有者。 对象的所有者拥有该对象的所有权限（例如对表的 SELECT 和 MODIFY 权限），并且有权向其他主体授予对安全对象的权限。 只有安全对象的所有者有权向其他主体授予对该对象的权限。 因此，最佳做法是将所有对象的所有权配置为负责管理对象授权的组。 所有者和元存储管理员都可以将安全对象的所有权转让给组。 此外，如果对象包含在目录（如表或视图）中，目录和架构所有者将可以更改对象的所有权。

Unity Catalog 中的安全对象是分层的，特权是向下继承的。 这意味着如果授予了对目录或架构的特权，系统会自动授予对该目录或架构内的所有当前和未来对象的特权。 有关详细信息，请参阅继承模型。

为了从表或视图中读取数据，用户必须具有以下权限：

• 对表或视图的 SELECT 权限
• 对该表所属的架构的 USE SCHEMA 权限
• 对架构所属的目录的 USE CATALOG 权限

USE CATALOG 允许被授权者遍历目录以访问其子对象，USE SCHEMA 允许被授权者遍历架构以访问其子对象。 例如，若要从表中选择数据，用户需要拥有对该表的 SELECT 权限和对其父目录的 USE CATALOG 权限，以及对其父架构的 USE SCHEMA 权限。 因此，可以使用此权限将数据命名空间部分的访问权限限制为特定组。 常见方案是为每个团队设置一个架构，其中只有对应团队具有对架构的 USE SCHEMA 和 CREATE 权限。 这意味着团队成员生成的任何表只能在团队内共享。

可以使用以下 SQL 语法保护对表的访问：

GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;

可以使用辅助架构中的动态视图保护对列的访问，如以下 SQL 语法所示：

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  id,
  CASE WHEN is_account_group_member(< group_name >) THEN email ELSE 'REDACTED' END AS email,
  country,
  product,
  total
FROM
  < catalog_name >.< schema_name >.< table_name >;
GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >.< view_name >;
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< view_name >;
TO < group_name >;

可以使用辅助架构中的动态视图保护对行的访问，如以下 SQL 语法所示：

CREATE VIEW < catalog_name >.< schema_name >.< view_name > as
SELECT
  *
FROM
  < catalog_name >.< schema_name >.< table_name >
WHERE
  CASE WHEN is_account_group_member(managers) THEN TRUE ELSE total <= 1000000 END;
GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;
GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;
GRANT
SELECT
  ON < catalog_name >.< schema_name >.< table_name >;
TO < group_name >;

还可以向用户授予使用行筛选器和列掩码来保护对表的访问权限。 有关详细信息，请参阅使用行筛选器和列掩码筛选敏感表数据。

有关 Unity Catalog 中所有特权的详细信息，请参阅管理 Unity Catalog 中的权限。

管理群集配置

Databricks 建议使用群集策略来限制基于一组规则配置群集的能力。 通过群集策略，可以将权限限制为仅创建启用 Unity Catalog 的群集。 使用群集策略可减少可用的选择，这将大大简化用户的群集创建过程，并确保他们能够无缝访问数据。 群集策略还可让你通过限制每个群集的最大成本来控制成本。

为确保访问控制的完整性并强制实施强隔离保证，Unity Catalog 对计算资源提出了安全要求。 为此，Unity Catalog 引入了群集访问模式的概念。 Unity Catalog 默认是安全的；如果群集未配置适当的访问模式，则群集无法访问 Unity Catalog 中的数据。 请参阅 Unity Catalog 支持的计算和群集访问模式。

Databricks 建议在共享群集时使用共享访问模式，并对自动化作业和机器学习工作负载使用单一用户访问模式。

下面的 JSON 为采用共享访问模式的群集提供策略定义：

{
"spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9]*\\.x-scala.*",
    "defaultValue": "10.4.x-scala2.12"
},
"access_mode": {
    "type": "fixed",
    "value": "USER_ISOLATION",
    "hidden": true
}
}

下面的 JSON 为采用单一用户访问模式的自动化作业群集提供策略定义：

{
"spark_version": {
    "type": "regex",
    "pattern": "1[0-1]\\.[0-9].*",
    "defaultValue": "10.4.x-scala2.12"
},
"access_mode": {
    "type": "fixed",
    "value": "SINGLE_USER",
    "hidden": true
},
"single_user_name": {
    "type": "regex",
    "pattern": ".*",
    "hidden": true
}
}

审核访问

完整的数据治理解决方案需要审核对数据的访问并提供警报和监视功能。 Unity Catalog 捕获针对元存储执行的操作的审核日志，这些日志作为 Azure Databricks 审核日志的一部分提供。

可使用系统表来访问帐户的审核日志。 有关审核日志系统表的详细信息，请参阅审核日志系统表参考。

请参阅使用审核日志监视 Databricks Data Intelligence 平台，详细了解如何全面了解与 Databricks Data Intelligence 平台相关的关键事件。

使用 Delta Sharing 安全共享数据

Delta Sharing 是由 Databricks 开发的开放协议，用于与其他组织或组织内的其他部门进行安全数据共享，而不论他们使用哪种计算平台。 如果对元存储启用了 Delta Sharing，则 Unity Catalog 将运行 Delta Sharing 服务器。

若要在元存储之间共享数据，可以利用 Databricks 到 Databricks Delta Sharing。 这样，就可以从不同区域中的元存储注册表。 这些表将在使用的元存储中显示为只读对象。 可以为这些表授予访问权限，就像 Unity Catalog 中的任何其他对象那样。

使用 Databricks 到 Databricks Delta Sharing 在元存储之间进行共享时，请记住，访问控制仅限于一个元存储。 如果安全对象（例如表）对其具有授权，并且该资源共享到帐户内元存储，则来源的授权将不会应用到目标共享。 目标共享必须设置自己的授权。

了解详细信息

• 设置和管理 Unity Catalog
• 使用 Delta Sharing 安全共享数据和 AI 资产
• 将表和视图升级到 Unity Catalog