通过

Unity Catalog 最佳做法

本文档提供有关使用 Unity 目录最有效地满足数据治理需求的建议。 有关 Azure Databricks 上的数据管理简介，请参阅 使用 Azure Databricks 进行数据管理。 有关 Unity 目录的简介，请参阅什么是 Unity 目录？

标识

主体（用户、组和服务主体）必须在 Azure Databricks 帐户级别定义，才能为 Unity 目录安全对象分配特权。 Databricks 建议使用 SCIM 从 IdP 向 Azure Databricks 帐户预配主体。

最佳做法：

  • 避免（并关闭现有）工作区级别的 SCIM 预配。 将主体直接预配到工作区的功能应保留给未启用 Unity Catalog 的旧版工作区。 应该完全在帐户级别管理预配。

  • 在 IdP 中定义和管理组。 它们应与组织组定义保持一致。

    组的行为方式不同于用户和服务主体。 尽管添加到工作区的用户和服务主体会自动与 Azure Databricksaccount 同步，但工作区级别组不是。 如果你有工作区内的本地组，则应手动将其迁移到帐户，最好是在你的 IdP（如有必要）中创建其副本，并将其配置到帐户。

  • 设置组，以便你能够有效地使用这些组来授予对数据和其他 Unity 目录安全对象的访问权限。 尽可能避免向用户直接授予。

  • 使用组将所有权分配给大多数可保护对象。

  • 避免将用户手动添加到帐户或工作区。 避免修改 Azure Databricks 中的组：使用 IdP。

  • 使用服务主体来运行作业。 服务主体启用作业自动化。 如果以用户身份来运行写入生产中的作业，则可能会意外覆盖生产数据。

有关详细信息，请参阅管理用户、服务主体和组和使用 SCIM 从 Microsoft Entra ID 同步用户和组。

管理员角色和强大的权限

分配管理员角色和强大的权限，例如ALL PRIVILEGES和MANAGE，需要谨慎对待。

  • 在分配帐户管理员、工作区管理员和元存储管理员之前，请先了解这些权限。 请参阅 Unity Catalog 中的管理员权限。
  • 尽可能将这些角色分配给各个小组。
  • 元存储管理员是可选的。 仅当需要它们时才分配它们。 有关指南，请参阅 （可选）分配元存储管理员角色。
  • 将对象所有权分配给组，尤其是在生产环境中使用对象时。 任何对象的创建者都是其第一个所有者。 创建者应将所有权重新分配给相应的组。
  • 只有具有对象特权的 MANAGE 元存储管理员、所有者和用户才能授予该对象的特权。 父目录和架构的所有者还可以授予对目录或架构中的所有对象的特权。 在分配所有权和 MANAGE 特权时要谨慎。
  • 分配 ALL PRIVILEGES 时请谨慎，其中包含除 MANAGE 之外的所有特权。

特权分配

Unity Catalog 中的安全对象是分层的，特权是向下继承的。 使用此继承层次结构开发有效的特权模型。

最佳做法：

  • 了解 USE CATALOG（或USE SCHEMA）与BROWSE之间的区别：

    • USE CATALOG | SCHEMA 授予查看目录和架构中数据的权限。 这些权限本身不会授予SELECT或READ对目录或架构内对象的访问权，但它们是授予用户这一访问权限的必要前提。 仅向应该能够查看目录或架构中的数据的用户授予这些权限。
    • USE CATALOG | SCHEMA，通过限制对目录或架构的访问，阻止对象所有者（例如表创建者）无意中将对该对象（表）的访问权限分配给不应具有访问权限的用户。 通常为每个团队创建架构，仅将USE SCHEMA和CREATE TABLE授予该团队（以及在父目录上的USE CATALOG）。
    • 可以在目录级别广泛授予 BROWSE，以便用户查看与目录中对象关联的元数据。

  • 了解对象所有权与 MANAGE 特权之间的差异：

    • 对象的所有者对该对象拥有所有权限（例如 SELECT 和 MODIFY 表的权限），包括将对可保护对象的权限授予其他主体的许可，以及将所有权转让给其他主体的权利。
    • 所有者可以授予 MANAGE 将对象所有权能力委派给其他主体的权限。
    • 目录和架构所有者可以转移目录或架构中任何对象的所有权。
    • 最好为对象配置所有权，或者将所有对象上的特权授予负责管理对象授权的组。

  • 为服务主体保留对生产表的直接 MODIFY 访问权限。

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

元存储

以下是创建和管理元存储的规则和最佳做法：

  • 每个区域只能有一个元存储。 该区域内的所有工作区共享该元存储。 若要在区域之间共享数据，请参阅 跨区域和跨平台共享。

  • 元存储提供区域隔离，但不用作数据隔离的默认单位。 数据隔离通常从目录级别开始。 但是，如果更喜欢更集中的治理模型，则可以创建元存储级托管存储。 有关建议，请参阅 托管存储。

  • 元存储管理员角色是可选项。 有关是否分配可选元存储管理员的建议，请参阅 管理员角色和强大的权限。

重要

不要将经常访问的表注册为多个元存储中的外部表。 如果这样做，由于写入元存储 A 而发生的架构、表属性、注释和其他元数据的更改根本不会注册到元存储 B。还可以对 Azure Databricks 提交服务造成一致性问题。

目录和架构

目录是典型的 Unity 目录数据治理模型中数据隔离的主要单元。 架构添加额外的组织层。

目录和架构用法的最佳做法：

  • 将数据和 AI 对象组织到反映组织部门和项目的目录和架构中。 通常，这意味着目录对应于环境范围、团队、业务部门或这些目录的一些组合。 这样，使用特权层次结构可以更轻松地有效地管理访问权限。
  • 当工作环境和数据都具有相同的隔离要求时，可以将目录绑定到特定工作区。 在需要时，创建可以限定在有限工作区范围内的目录。
  • 始终将生产目录和架构的所有权分配给组，而不是单个用户。
  • 应该只向能够查看或查询其中数据的用户授予USE CATALOG和USE SCHEMA。

有关授予目录和架构特权的更多建议，请参阅 “特权分配”。

托管存储

托管表格和卷，其生命周期完全由 Unity Catalog 管理，存储在默认存储位置，称为 管理存储。 可以在元存储、目录或架构级别设置托管存储。 数据存储在层次结构中可用的最低位置。 有关详细信息，请参阅 托管存储位置层次结构 ，并在 Unity 目录中指定托管存储位置。

托管存储位置的最佳做法：

  • 优先使用目录级存储作为数据隔离的主要单元。

    在早期的 Unity 目录环境中需要元存储级别的存储，但现在不再需要。

  • 如果选择创建元存储级托管位置，请使用专用容器。

  • 请勿使用可从 Unity 目录外部访问的容器。

    如果外部服务或主体绕过 Unity Catalog 访问托管存储位置中的数据，托管表和卷的访问控制和审核功能可能会受到影响。

  • 请勿重复使用已用于或曾经用于 DBFS 根文件系统的容器。

  • 如果有存储密集型工作负荷，请不要将单个存储帐户和容器用于托管存储和其他外部位置。

    re：[ADLS] 帐户默认支持每秒 20,000 个请求。 这可能会导致工作负荷限制和速度减慢。 在同一存储帐户中使用多个容器不会更改此帐户范围限制。 因此，应该跨多个存储帐户来条带化存储。

    这种条带化对于 Unity Catalog 最终用户来说是不可见的。

托管表和外部表

托管表完全由 Unity Catalog 管理，这意味着 Unity Catalog 管理每个托管表的治理和底层数据文件。 它们始终采用 Delta 或 Apache Iceberg 格式。

外部表是指表，其从 Azure Databricks 的访问由 Unity Catalog 管理，但其数据生命周期和文件布局由您的云提供商和其他数据平台管理。 在 Azure Databricks 中创建外部表时，请指定其位置，该位置必须位于 Unity 目录 外部位置中定义的路径上。

使用托管表：

  • 对于大多数用例而言。 Databricks 建议使用托管表和卷，因为它们允许充分利用 Unity Catalog 治理功能和性能优化，包括：

    • 自动压缩
    • 自动优化
    • 更快地读取元数据（元数据缓存）
    • 智能文件大小优化

    新的 Azure Databricks 功能优先于托管表。

  • 适用于所有新表。

使用外部表：

  • 当你已经在使用它们并且正在从 Hive 元存储升级到 Unity Catalog 时。

    • 使用外部表可以提供快速无缝的“一键式”升级，而无需移动数据。
    • Databricks 建议最终将外部表迁移到托管表。

  • 如果对此数据有灾难恢复要求，而托管表无法满足该要求。

    托管表不能在同一个云中的多个元存储中注册。

  • 如果外部读取器或编写器必须能够与 Databricks 外部的数据进行交互。

    通常，应该避免让外部访问，即使是在 Unity Catalog 中注册的外部表。 这样做会绕过 Unity 目录访问控制、审核和世系。 最好使用托管表，并通过 Delta Sharing 在不同地区或云服务提供商之间共享数据。 如果必须允许外部访问外部表，请将其限制为读取，所有写入都通过 Azure Databricks 和 Unity 目录进行。

  • 必须支持非 Delta 或非 Iceberg 表，例如 Parquet、Avro、ORC 等。

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

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

另请参阅 Azure Databricks 表简介。

托管卷和外部卷

托管卷由 Unity Catalog 完全托管，这意味着 Unity Catalog 管理对云提供商帐户中卷存储位置的访问。 外部卷是指存储在 Azure Databricks 之外的存储位置中的现有数据，这些数据在 Unity Catalog 中注册，以便于在 Azure Databricks 内部实现对其访问的控制和审核。 在 Azure Databricks 中创建外部卷时，请指定其位置，该位置必须位于 Unity Catalog 外部位置中定义的路径上。

使用托管卷：

  • 对于大多数用例，充分利用 Unity Catalog 治理功能。
  • 如果想从卷中的文件开始创建表而不运行 COPY INTO 或 CTAS (CREATE TABLE AS) 语句。

使用外部卷：

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

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

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

提示

对于将数据复制到另一个位置的引入用例（例如，使用自动加载程序或 COPY INTO），请使用外部卷。 如果要以表的形式查询数据，且不涉及复制，请使用外部表。

另请参阅托管卷与外部卷和外部位置。

外部位置

外部位置安全对象通过组合存储凭据和存储路径，提供对存储访问的强控制和可审核性。 请务必防止用户直接访问注册为外部位置的容器，从而绕过 Unity 目录提供的访问控制。

要有效地使用外部位置：

  • 确保限制直接访问用作外部位置的任何容器的用户数。

  • 如果存储帐户也用作外部位置，请不要将存储帐户装载到 DBFS。 Databricks 建议使用目录资源管理器将云存储位置上的装载迁移到 Unity Catalog 中的外部位置。

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

    外部位置提供从 Unity Catalog 内部到云存储中广泛包含位置的访问，例如整个存储桶或容器（存储桶路径）或广泛的子路径（存储桶子路径）。 目的是让云管理员能够参与设置一些外部位置，然后将管理这些位置的责任委托给你的组织中的 Azure Databricks 管理员。 然后，Azure Databricks 管理员可通过在外部位置下以特定前缀注册外部卷或外部表，进一步将外部位置整理到具有更精细权限的区域。

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

    还可以通过将外部位置绑定到特定工作区来控制对外部位置的访问。 请参阅（可选）将外部位置分配给特定工作区。

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

    用户不应将外部位置用于创建表、卷或管理位置以外的其他用途。 对于数据科学或其他非表格数据用例，用户不应使用外部位置进行基于路径的访问。

    对于基于路径访问非表格数据，请使用卷。 云 URI 对卷路径下的数据的访问受卷上授予的权限控制，而不是受存储卷的外部位置授予的权限控制。

    可以通过卷使用 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 命令注册外部表和卷。
  • 将存储位置注册为托管存储。 必须先具备 CREATE MANAGED STORAGE 权限。
  • 在以特定前缀创建外部表或卷之前，请先浏览云存储中的现有文件。 必须先具备 READ FILES 权限。 请谨慎分配此权限。 有关详细信息，请参阅上一个列表中的建议。

外部位置与外部卷

在卷发布之前，一些 Unity Catalog 实现将 READ FILES 访问权限直接分配给外部位置以进行数据探索。 由于可以使用以任何格式注册文件（包括结构化、半结构化和非结构化数据）的卷，因此除了创建表、卷或托管位置之外，没有理由使用外部位置进行任何操作。 有关何时使用外部位置以及何时使用卷的详细信息，请参阅托管卷和外部卷和外部位置。

跨区域和跨平台共享

每个区域只能有一个元存储。 如果想在不同区域的工作区之间共享数据，请使用 Databricks-to-Databricks Delta Sharing。

最佳做法：

  • 将单区域元存储用于所有软件开发生命周期范围和业务部门，例如开发、测试、生产、销售和营销。 确保需要频繁共享数据访问的工作区位于同一区域。
  • 在云区域或云提供商之间使用 Databricks 到 Databricks Delta 共享。
  • 对于不经常访问的表使用 Delta Sharing，因为你需要负责从云区域到云区域的流出量费用。 如果您必须在不同地区或云服务提供商之间共享经常访问的数据，请参阅：监视和管理 Delta Sharing 的出口成本（面向提供商）。

使用 Databricks 到 Databricks 共享时请注意以下限制：

  • 世系图是在元存储级别创建的，并且不跨越区域或平台边界。 即使资源在同一 Databricks 帐户中的元存储之间共享，也是如此：源中的世系信息在目标中不可见，反之亦然。
  • 访问控制在元存储级别定义，不会跨越区域或平台边界。 如果某个资源分配了权限并且该资源被共享到账户中的另一个元存储中，则该权限不适用于目标共享。 必须授予目标中目标共享的权限。

计算配置

Databricks 建议使用计算策略来限制基于一组规则配置群集的能力。 通过计算策略，可以限制用户创建启用了 Unity 目录的群集，特别是使用标准访问模式（以前共享访问模式）或专用访问模式（以前是单用户或分配访问模式）的群集。

只有使用这些访问模式之一的群集才能访问 Unity 目录中的数据。 所有无服务器计算和 DBSQL 计算都支持 Unity 目录。

Databricks 建议对所有工作负荷采用标准访问模式。 仅当标准访问模式不支持所需的功能时，才使用专用访问模式。 请参阅 访问模式。