阶段 3：设计 Unity 目录体系结构

在此阶段，你将设计 Unity 目录基础结构，以支持 Lakehouse 的数据治理、访问控制和数据组织。

Unity Catalog 在 2023 年 11 月 9 日之后创建的 Azure Databricks 账户中工作区上自动启用。对于这些帐户，系统会自动创建一个元存储，并将其分配给工作区。

有关全面的 Unity 目录指南，包括实现步骤和高级功能，请参阅什么是 Unity 目录？

选择治理操作模型

在设计 Unity Catalog 体系结构之前，请选择符合组织结构和数据文化的治理运营模型。治理模型确定在整个组织中如何管理数据所有权、访问控制和策略强制实施。

治理模型选项

集中治理：每个业务部门或域在不同的业务边界中运行，但所有单位都属于管理所有数据和 AI 资产（多租户）的相同运营边界。单个平台或数据管理团队控制所有数据资产、策略和访问权限。
分散式治理：每个业务部门或域都有独立的业务和运营边界（这意味着它具有自己的租户）。治理委托给每个业务部门，以最少的集中监督来独立定义和强制实施自己的策略。
联合治理：每个业务部门或域都有独立的业务和运营边界。但是，治理策略由集中式治理办公室定义，并由每个业务部门强制执行。关键资产由治理办公室（例如共享数据产品）管理。
混合治理：集中式和分散式之间的模型，允许每个业务部门或域管理自己的数据（分散）。但是，关键业务数据在一个位置收集和治理，供所有人使用（集中式）。

治理模型的最佳做法

首先，对大多数组织进行联合治理（平衡控制和敏捷性）。
对高度管控行业（例如，财务、医疗保健、政府）使用集中治理。
为每个治理模型清楚地记录角色和职责。
使治理模型与现有组织结构保持一致。
随着数据平台的成熟，审查并调整治理模式。

	集中式治理	分散式治理	联合治理	混合治理
定义	单个中央机构控制整个组织中的所有数据和 AI 策略。	每个业务部门独立管理自己的数据和 AI 策略。	中心团队设置了准则和标准，而本地团队则拥有自主实施这些准则和标准的权利。	核心数据和策略是集中管理的，而业务部门控制其特定于域的数据和策略。
决策	所有决策都使用自上而下的方法，由中心团队处理。	业务部门在没有集中协调的情况下独立做出决策。	中心团队制定准则，本地团队在这些边界内做出决策。	中央团队为核心数据和基础结构做出决策。业务部门根据特定于域的需求做出自己的决策。
数据所有权	中央团队拥有和管理所有数据资产。	单个团队或业务部门拥有其数据，没有共享治理。	多个团队在整个组织中共享所有权责任。	中央团队拥有核心共享数据。业务部门拥有其领域特定的数据。
可伸缩性	缩放取决于中心团队的容量，当组织增长时，可能会成为瓶颈。	业务部门可以独立缩放，但团队之间的协调可能很困难。	组织可以通过建立的治理结构进行缩放，同时保持协调。	核心数据随着中心资源的变化而变化。业务部门可以在其领域内独立扩展。
符合性和安全性	组织内的政策在强有力的中央监督下始终得到强制实施。	强制措施因团队而异，这可能会导致安全漏洞和不一致的做法。	中心团队设置安全标准，本地团队在其域中强制实施这些标准。	核心数据遵循严格的符合性规则。业务部门对特定于域的要求具有灵活性。
运营效率	运营效率高，但官僚流程和审批链可能会放缓。	团队可快速轻松地适应工作，但工作可能会重复，孤岛可以形成。	组织平衡效率和灵活性，尽管广泛的协调可能会减缓决策速度。	核心操作可能有瓶颈。业务部门在其域中高效运行。
用例适用性	最适合需要严格监管的金融和医疗保健等高度监管的行业。	最适合优先考虑速度的敏捷企业、初创公司和创新驱动型组织。	最适合需要中央标准和地方灵活性的大型企业和跨国公司。	最适合需求多样化的组织，例如那些在合规要求与创新之间取得平衡的金融科技公司。

选择治理操作模型会影响元存储设计。在集中式模型中，可以分配单个元存储管理员。在分散模型中，通过自动化部署管道（使用 CI/CD 工具（如 Terraform）管理权限，而不是委派给单个业务部门或环境管理员。

设计元存储体系结构

Unity Catalog 元存储区是用于元数据和管理的顶级区域性容器。每个元存储存储可控对象（例如表、视图、卷、外部位置、共享）的元数据，以及管理其访问的权限。元存储托管为Azure Databricks控制平面中的多租户服务。

Unity Catalog 允许每个区域只能有一个元存储，并且该元存储只能在其分配的区域使用。必须将每个工作区分配给一个元存储。

元存储管理员角色

可以选择使用元存储管理员配置元存储，具体取决于治理模型。使用 Unity Catalog 的自动启用时，不会配置此角色。如果要在元存储级别管理 Unity 目录对象的存储，并且想要集中管理区域中多个工作区的数据，则元存储管理员角色是必需的。

在 集中式模型中，分配单个元存储管理员或指定组。
在 分散式模型中，通过自动化部署管道管理权限，而不是委派给单个管理员。

如果使用元存储管理员，强烈建议将角色分配给指定组而不是单个用户。

隔离机制

为了支持出于安全或组织原因进行企业级隔离，Unity 目录支持在多个级别进行隔离：

管理员隔离（管理委派）：数据应由指定人员或团队根据该数据的目的或所有权进行管理。
工作区绑定：只能在指定环境中访问数据，具体取决于该数据的目的。
- 一个目录（或其他 Unity 目录对象）可以绑定到多个工作区。
- 一个工作区可以与同一元存储下的多个目录、凭据和外部位置绑定。
存储隔离：数据应在存储中以物理方式分隔。
Unity 目录访问控制：用户应仅基于同意的访问规则获取对数据或元数据的访问权限。

使用这些隔离机制来隔离每个区域中单个元存储中的工作负荷、团队或业务部门。

Metastore设计模式

单云、单区域部署

对于在单个云区域中运行的组织，请在该区域部署一个元存储。该区域中的所有工作区都分配给此元存储。

单云、单区域元存储部署。

单云多区域部署

对于在同一云的多个区域中运行的组织，请为每个区域部署一个元存储。每个工作区都分配到其区域中的元存储。使用 Azure Databricks 管理的 Delta Sharing (D2D) 在跨区域的元存储之间共享数据。

单云、多区域元存储部署。

多云多区域部署

对于跨多个云提供商和区域运行的组织，请在每个云中为每个区域部署一个元存储。使用由 Azure Databricks 托管的 (D2D) Delta Sharing，在不同的云和区域的元存储之间共享数据。

多云多区域元存储部署。

替代模式

每个业务部门有一个元存储：当业务部门需要完全隔离且不共享数据时适用。
每个环境一个元存储：开发、暂存和生产使用单独的元存储进行严格的环境隔离的不太常见的模式。

多区域设计注意事项

如果多个区域使用Azure Databricks，则必须在每个区域中部署单个 Unity 目录元存储。用户可以在登录工作区所在的同一区域中使用元存储。若要访问另一个区域的元存储中定义的数据，建议使用Azure Databricks托管的（D2D）增量共享。

警告

请勿在多个元存储中将共享表注册为外部表。风险在于，由于写入元存储 A 而对架构、表属性和注释所做的任何更改都不会向元存储 B 注册。元存储 B 中的表必须重新创建才能具有正确的架构，并且表属性和注释将完全断开连接。这也可能导致 Delta 提交服务出现一致性问题。使用 D2D Delta Sharing 在数据存储系统之间共享数据。

多区域设计的最佳做法

将每个区域部署一个元存储作为默认模式。
使用 Azure Databricks 托管的 Delta Sharing 跨地区共享表。
评估跨云区域的数据访问频率和数量。如果成本过高，请考虑设置数据管道以在区域之间同步表。
对于跨区域设置，请将元存储根存储存储在与元存储相同的区域中，以提升性能。

元存储设计的最佳做法

将每个区域一个元存储用作操作简单性的默认模式。
将同一区域中的工作区分配给同一元存储。
使用元存储中的目录按环境或域分隔数据。
为每个区域创建一个管理工作区，用于管理 Unity 目录资源。
在 Runbook 中记录元存储的分配和区域的边界。

对于在 2023 年 11 月 9 日之后创建的新帐户，会自动创建和分配元存储。

有关 Unity 目录存储体系结构的详细信息，包括托管对象、外部对象和外来对象，请参阅阶段 4：设计存储体系结构。

设计目录结构

目录是元存储中的第一个组织层。它们包含模式，模式包含表、视图、卷和函数。目录设计确定数据资产的组织和访问方式。

目录设计模式

基于环境的目录

软件开发生命周期（SDLC）环境（例如开发、过渡和生产）的单独目录（例如， dev、 staging、 prod）。此模式支持环境升级工作流，并防止意外的生产环境更改。

在 Unity Catalog 提供的三级命名空间中，将环境隔离到目录层级：

dev 目录涵盖开发数据位置。
prod 目录涵盖生产数据位置。
目录可以是 SDLC 和业务或组织单位名称的组合，例如： sales_dev、 sales_prodengineering_dev

基于域的目录

为业务域或组织单位（例如，sales、marketing、finance、engineering）分隔目录。此模式与数据网格体系结构和域所有权保持一致。

混合目录

组合环境和域模式（例如，、sales_prodsales_dev、finance_prodfinance_dev）。这既提供隔离，又提供明确的所有权。

数据生命周期目录

为不同的数据成熟度阶段（例如，raw，curated，analytics）分隔目录。此模式遵循目录级别的奖牌体系结构原则。

沙盒和开发区域

许多团队需要沙盒区域来创建临时数据集供内部使用。提供个人或团队自己的沙盒架构，他们可以在其中添加表，但无法与团队外部的任何人共享，因为他们不拥有包含的架构和目录。

目录命名约定

为与某些配置相符的目录选择命名约定，例如，根据软件开发生命周期环境（开发、测试、生产）、奖牌层级（铜牌、银牌、黄金）或业务单元（计费、客户、销售）。体系结构团队应定义确切的命名约定。

目录设计的最佳做法

将基于环境的目录用作大多数组织的默认目录。
对数据网格或联合治理模型使用基于领域的目录。
限制目录数量以减少管理开销（通常每个元存储区有 3-10 个）。
在所有目录中使用一致的命名约定。
在目录注释中记录目录的用途和数据所有权。
使用目录授予来控制谁可以在每个目录中创建架构和表。
避免为单个团队或项目创建单独的目录（改用架构）。

设计存储凭据策略

存储凭据是身份验证对象，允许 Unity 目录代表用户访问云存储。他们提供了一种安全的方式来授予 Azure Databricks对客户管理的云存储的访问权限，而无需与最终用户共享长期凭据。

需要存储凭据时

创建指向云存储的外部位置（例如 S3、ADLS Gen2、GCS）。
访问外部表和卷的由客户管理的存储。
从不受 Unity 目录管理的云存储中读取数据。

不需要存储凭据时

访问 Unity 目录托管表和卷（Azure Databricks管理的存储）。
在无服务器工作区中使用默认存储。

Azure存储凭据体系结构

Azure存储凭据使用Microsoft Azure Databricks访问连接器，这些连接器是托管标识资源。必须使用 Azure RBAC 向访问连接器授予对存储帐户的适当权限（例如，存储 Blob 数据参与者角色）。

身份验证流：

Unity Catalog 使用访问连接器的托管身份验证
Azure验证托管标识和 RBAC 权限
Unity Catalog 代表用户访问存储
根据 Azure RBAC 角色授予或拒绝访问权限

存储凭据设计模式

为不同的存储帐户或数据域使用单独的访问连接器（例如，uc-prod-sales-connectoruc-dev-engineering-connector）。
使用 Azure RBAC 角色应用最低特权权限。
为每个环境创建一个存储凭据（例如开发、过渡、生产）。
需要数据隔离时，为每个业务部门创建一个存储凭据。

Azure存储凭据的最佳做法

为不同的存储帐户或数据域使用单独的访问连接器。
使用 Azure RBAC 角色应用最低特权权限。
使用存储防火墙和专用终结点限制网络访问。
启用Azure Monitor以审核对存储帐户的访问。

设计外部位置策略

外部位置将存储凭据映射到特定的云存储路径，使 Unity 目录能够控制对存储在 Unity 目录托管存储之外的数据的访问。每个外部位置将存储凭据与云存储 URL 前缀组合在一起。

外部位置用例

在云存储中访问建立在采用 Unity 目录之前的现有数据。
创建引用由其他系统管理的数据文件的外部表。
与需要直接文件访问的外部系统共享数据。
在 Unity 目录卷中存储大型非结构化数据（例如视频、图像、PDF）。

外部位置设计模式

在最常用路径前缀处创建外部位置，以最大程度地减少位置数。
使用与目录或架构边界对齐的外部位置（例如，每个目录有一个外部位置）。
按环境（例如开发环境、测试环境、生产环境）分隔外部位置。
根据需要按业务部门或数据域分隔外部位置。

外部位置的最佳做法

对必须保留在特定云存储路径中的数据使用外部位置。
尽可能使用 Unity Catalog 托管表而不是外部存储位置（更简单的治理和性能优化）。
使用描述性名称来指示存储路径和用途（例如，s3-sales-data-prodadls-finance-reports-dev）。
仅向需要创建外部表的用户授予对外部位置的访问权限。
记录外部位置用途和数据所有权。

设计权限模型

每个组织对数据访问控制有不同的要求。常见权限模型涉及定义具有特定权限的明确角色。

示例权限模型

数据策展人：管理所有数据资产（例如所有权、创建、修改、删除权限）。
数据使用者：对大多数数据资产的只读访问权限（选择特权）。
数据工程师：对开发和过渡环境的读写访问权限。
分析人员：对生产分析数据的只读访问权限。

权限委派

元存储管理员根据职责向用户或组分配和委派访问权限来建立并强制实施权限策略。例如：

数据策展人可以被授予管理数据集的所有权或写入权限。
使用者通过组成员身份接收读取级别权限。
此结构可确保一致的治理、简化维护并支持符合组织数据策略。

权限模型的最佳做法

向组而不是单个用户授予权限，以便更轻松地进行管理。
使用最低权限访问权限（仅授予所需的最低权限）。
记录访问控制策略，并定期与安全团队一起查看。
使用目录和模式权限进行粗粒度的访问控制。
使用表和视图的权限进行精细的访问控制。
对敏感数据使用动态视图和行/列筛选器。
使用系统表审计访问（system.access.audit）。

中心节点辐射设计模式

企业级 Unity Catalog 部署中的常见体系结构是枢纽辐射型设计模式。此模式集中中心目录中的共享数据资产，同时允许分支目录中特定于域的数据。

星型网络特征

中心目录：包含组织范围的共享数据资产（例如客户主数据、引用数据、集中策划的数据集）。
分支目录：包含业务部门拥有和管理的特定于域的数据（例如销售分析、市场营销活动）。
存储分离：中心和域目录使用专用的存储，并且为每个存储配备独立的存储凭据。
托管表首选项：在 Lakehouse 中处理结构化数据时，建议使用托管表。
原始数据的卷：使用卷访问入湖、原始或非结构化数据（这些数据可以位于 Lakehouse 外部，因为第三方通常需要直接访问这些存储位置）。
用于共享的外部表：使用外部表在湖仓之外共享数据（用于无法使用 Delta Sharing 或需要直接访问存储位置的其他系统）。

中心发散型设计示例

Metastore (region: us-east-1)
├── Hub Catalog (prod_hub)
│   ├── Storage credential: hub-prod-credential
│   ├── External location: s3://company-hub-prod/
│   └── Schemas: customers, products, reference_data
│
├── Sales Domain Catalog (sales_prod)
│   ├── Storage credential: sales-prod-credential
│   ├── External location: s3://company-sales-prod/
│   └── Schemas: transactions, forecasts, reports
│
└── Engineering Domain Catalog (engineering_prod)
    ├── Storage credential: engineering-prod-credential
    ├── External location: s3://company-engineering-prod/
    └── Schemas: telemetry, monitoring, logs

中心辐射型设计的最佳做法

使用集线器目录来管理在整个组织内共享的数据，供多个域使用。
使用从属目录来管理业务部门拥有的特定域数据。
为枢纽和每个分支单独存储凭证和外部位置。
使用 Azure Databricks 托管的 Delta 共享将数据从中心共享到分节点。
记录中心辐射目录的数据所有权和世系。
注意：元存储存储现在是可选的，不建议使用。

Unity 目录体系结构建议

阶段 3 结果

完成阶段 3 后，应具备：

根据组织结构（集中、分散、联合或混合）选择的治理模型。
元存储体系结构设计（通常是每个区域一个）。
Unity 目录存储体系结构设计（托管对象与外部对象与外来对象）。
使用基于环境的、基于域或混合模式定义的目录结构。
为不同环境或域设计了具有单独凭据的存储凭据策略。
针对需要 Unity 目录治理的现有云存储设计的外部位置策略。
设计有明确角色的权限模型（例如策展人、消费者、工程师、分析师）。
中心辐射设计被用于评估企业部署中的共享数据和特定域数据。

下一阶段：阶段 4：设计网络体系结构

实施指南：有关实现 Unity 目录设计的分步说明，请参阅什么是 Unity 目录？。

Last updated on 2026-04-20