选择Microsoft Fabric部署模式

部署 Microsoft Fabric 时，需要决定如何在整个组织中构建容量规划、工作区和项目。 正确的部署模式取决于治理、安全、性能隔离和成本管理的要求。 本指南可帮助架构师和平台团队评估四种部署模式，并了解每个部署模式的注意事项和权衡。

四级层次结构

下图显示了定义所有Fabric部署的四级层次结构。

下载此架构的Visio 文件

部署的层次结构是从 Microsoft 365 租户逐级向下到达各个项目的。 选择的部署模式决定了如何使用每个级别。

• 租户级别。 在顶部的是 Microsoft 365 租户，它为您的组织提供标识并充当管理边界。 Fabric租户存在于这个Microsoft 365租户中，所有Fabric资源都位于同一个租户的边界内。 租户级设置（包括 Microsoft Entra 条件访问、专用链接和 敏感度标签）适用于所有功能和工作区。

• 容量级别。 在 Microsoft 365 租户中设置至少一个 Fabric 容量。 每个容量都绑定到特定的Azure区域，并具有特定的 F SKU，用于确定以容量单位（OU）度量的可用计算资源。 容量控制数据驻留并提供计费边界。 单个容量可以托管多个工作区。

• 工作区级别。 每个容量包含一个或多个 工作区。 工作区是用于协作和管理的主要容器。 他们通过四个工作区角色（管理员、成员、贡献者和观察者）来定义访问控制，支持 Git 集成以实现版本控制，并作为部署管道的范围。 工作区一次属于一个容量。 同区域容量迁移非常简单。 必须删除并重新创建大多数的 Fabric 项目，包括湖区存储、数据仓库、笔记本和数据管道，但可以进行跨区域迁移。 因此，首选同一区域迁移。

• 项目级别。 工作区包含多种Fabric项，例如 lakehouses、数据仓库、笔记本、数据管道、语义模型、报表和仪表板。 默认情况下，项继承工作区权限。 Microsoft OneLake 安全角色在表、文件夹、列和行级别提供精细访问控制，但它们仅适用于查看器角色中的用户。 工作区管理员、成员和参与者不受 OneLake 安全角色的限制。

以下许可和工作区类型约束通常确定哪种部署模式最实用：

• 新的工作区会在共享容量上启动，除非你重新分配它们。 每个租户都有一个托管“我的工作区”的共享容量，可以托管 Power BI Pro 或 Premium Per User （PPU） 工作区。 若要为生产工作负荷实现受治理的Fabric部署模式，通常需要将工作区重新分配到租户中的专用Fabric容量。

• PPU 不能替代Fabric容量。 PPU 为每个用户提供 Power BI Premium 高级功能，但不包括 Fabric 计算容量。 若要创建或运行非 Power BI Fabric 项（如数据湖屋、数据仓库和笔记本），需要 F 容量。

• 工作区类型会影响模式可以承载的内容。 本文中的 Fabric 部署模式假设由 F SKU 支持的 Fabric 工作区。 A 和 EM SKU 仅支持 Power BI 项目，因此它们无法支持端到端的 Fabric 部署模式。

• Power BI查看器许可可能会更改模式的成本。 在 F64 和更大的容量上，具有查看器角色的用户可以使用免费许可证访问Power BI内容。 在较小的容量上，Power BI使用者需要 Pro、PPU 或试用许可证。 此阈值可降低大型读取器群体集中模式的成本效益。

• Power BI创作和共享至少需要一个 Pro 或 PPU 用户。 即使工作区使用了Fabric容量，组织仍然需要具有 Pro 或 PPU 许可证的用户来创建和共享 Power BI 内容。

组件

• Microsoft 365 tenant：组织的标识和管理边界。 它托管Microsoft Entra ID（以前Azure Active Directory）进行身份验证和授权。

• Fabric capacity：在特定的 Azure 区域中使用的计算和计费资源，例如美国东部或西欧。 若要降低成本，可以在不使用时暂停容量。

• Fabric workspace： Fabric 项目的协作容器。 它支持基于角色的访问控制（RBAC）、Git 集成和部署管道。 对于逻辑分组，可以将工作区分配到Fabric域。

• Fabric 项目：Lakehouse、数据仓库、笔记本、管道、数据流、语义模型、报表和仪表板等数据和分析构件。

• Fabric 域：按业务部门或主题领域组织工作区的逻辑分组。 域支持委派的治理，并在 OneLake 目录中显示以便于发现和监督。

• OneLake： 租户包含工作区的统一分层数据湖，其中包含项。 Fabric在 OneLake 中存储数据。 OneLake 支持Azure Data Lake Storage API、外部存储的快捷方式以及与Data Lake Storage工具（如Azure 存储资源管理器和AzCopy）集成。

• OneLake catalog：一个集中接口，用于跨租户查找、治理和保护Fabric数据。 用户可以使用Microsoft Teams、Excel和Microsoft Copilot Studio等工具访问目录。

了解Fabric平台的部署级别

组织的结构、目标、安全要求、规模、治理模型和应用程序生命周期会影响每个部署级别的决策。 有关每个级别的详细信息，请参阅 四级层次结构。

• 容量控制数据驻留和地理分布。 在多个地理位置中运行的组织可以使用不同Azure区域中的容量来控制数据存储的位置。 每个容量都绑定到特定的Azure区域，该区域支持跨区域进行多地理部署。 为了支持集中式治理，Fabric域可以跨区域对工作区及其关联的容量进行分组。

• 工作区充当主要治理和安全边界。 每个工作区通过四个角色定义访问控制，支持通过 Git 集成进行版本控制，并充当部署管道的范围。 若要集中协作和内容发现，请使用 OneLake 目录针对租户的 OneLake 数据实现统一的发现和管理体验。 用户可以通过此目录查找并与 Teams 和 Excel 等工具中的内容进行交互。

• 每个级别都会影响应用程序生命周期选择。 部署管道和 生命周期管理 等功能在单工作区模式中不可用，因为它们需要单独的工作区。 使用域对工作区进行分组的组织可以委托域级管理，而无需租户管理员特权，这会影响团队如何跨业务部门管理发布和治理。

所有部署中的常见模式

所有Fabric部署模式共享以下基本特征：

• 工作区作为扩展、管理和安全性的界限。 部署模式使用Fabric工作区作为项目组织、权限和 DevOps 功能范围的主要单元。 无论选择哪种模式，工作区都会定义协作和访问控制的边界。

• Fabric域，用于跨多个工作区和业务部门进行委派。 使用 Fabric 域来进行委派。 可以管理可能属于同一业务部门的多个工作区，或管理属于业务域并跨越多个工作区的数据。 若要 管理和管理域级别的数据，可以调整租户级设置，并对这些设置使用特定于域的配置。

• 用于计算扩展的能力，每个工作区提供的专用容量可保证性能。 如果必须满足特定的性能级别，请使用Fabric容量来缩放计算资源，并为每个工作区提供专用容量。 需要对性能敏感作业进行工作负载隔离的组织可以将这些工作区分配给具有保证 CU 分配的单独容量。

• OneLake 目录用于资产发现，“安全”选项卡用于数据安全策略。 为促进您租户内数据资产的发现和使用，请使用 OneLake 目录。 若要查看、监视和配置跨工作区和项的安全角色，请使用 OneLake 目录中的“安全”选项卡。

• 如果本机Fabric功能不可用，则启用Microsoft Cloud的扩展功能。 如果本机功能不可用，则部署模式可以扩展到使用Microsoft Cloud中的等效功能，例如Azure和Microsoft 365。 例如，如果Fabric部署管道未涵盖跨工作区自动化要求，组织可以使用 Azure Pipelines 或 GitHub Actions进行持续集成和持续交付（CI/CD）编排。 组织还可以使用 Microsoft Purview 进行跨Fabric和非Fabric数据源的企业范围的数据管理。

选择部署模式

以下方案描述了常见的业务需求和解决它们的部署模式。 使用这些方案有助于确定最适合组织的模式。

• 方案 1：跨团队协作缩短上市时间。 如果你的组织希望更快地上市、跨团队协作和降低对数据使用的限制，则可以实施 整体 部署模式。 在此方案中，你的组织在一个工作区中运营和管理。

  使用 模式 1：整体部署。

• 方案 2：具有中央基础结构管理的隔离团队环境。 如果你的组织想要提供独立的团队环境和中央基础结构管理团队，则可以实现使用共享容量或单独容量的 多个工作区 。 此方案也适用于想要实现数据网格体系结构的组织。

  使用 模式 2：多个工作区、单个容量 或 模式 3：多个工作区、单独的容量。

• 方案 3：数据平台的完全业务部门自治。 如果你的组织想要一个完全分散的模型，使业务部门或团队能够自由地控制和管理自己的数据平台，则可以实现一种部署模型，该模型使用具有专用容量的独立工作区或多个Fabric租户。

  使用 Pattern 3：多个工作区、独立的容量 或 Pattern 4：多个 Fabric 租户。

• 方案 4：合并多个模式的混合方法。 如果你的组织想要使用多个模式来满足其要求的混合解决方案，则可以实现混合方法。 例如，可为特定业务部门设置单个工作区，例如单一部署模式，并为其他业务部门设置单独的专用工作区和单独的容量。

模式 1：整体部署

在此部署模式中，为所有用例分配一个工作区。 所有业务部门在同一工作区中工作。

以下特征适用于此模式：

• Fabric项目共享相同的容量。 查询或作业所花费的时间因使用相同容量的其他工作负荷而异。

• 工作区最大 CU 限制为最大 F SKU。 对于数据工程和数据科学功能，容量管理员可以为 Apache Spark 配置自动缩放计费，以移动 Spark 引擎在分配的 CU 外部使用的计算容量。

• 限定为工作区的功能适用于共享工作区的所有业务部门。

• 所有工作区项和数据都在一个区域中。 不能将此模式用于多个地理方案。

• 依赖于多个工作区的功能不可用，例如 部署管道 和生命周期管理。

• 应用单工作区 限制 。

• 特定的 SKU 容量限制适用。

何时使用此模式

在以下情况中，可以实施此部署模式：

• 你的组织没有复杂的工程要求，它具有较小的用户群，或者它具有较小的语义模型。

• 组织只在一个地区运作。

• 您并不主要关注业务部门之间的组织分隔。

• 您的组织不需要以工作区为范围的功能，例如通过 Git 共享代码库。

• 你想实现一个湖屋奖牌体系结构。 如果您的组织使用单个工作区，您可以在该工作区内创建多个单独的 Lakehouses，以便管理青铜层、白银层和黄金层。

• 您组织的各业务部门之间共享角色，您可以在工作区内为用户设定相同的工作区级别权限。 例如，如果来自不同业务部门的多个用户是单个工作区的管理员，则他们对工作区中的所有项具有相同的权限。

• 你的组织可以容忍可变的作业完成时间。 如果共享容量，用户可以随时运行查询。 可用于运行作业的计算单元（CU）数量取决于在容量上运行的其他查询，从而导致作业完成时间不一致。

• 你的组织可以通过单个 Fabric 容量来满足其 CU 业务需求。

设计区域注意事项

下表显示了可能会影响你使用此部署模式的决定的注意事项。

模式 2：多个工作区，单个容量

在此部署模式中，你将在单个共享容量上分配多个工作区。 工作区共享该容量，因此并发工作负荷可能会影响作业和交互式查询的性能。

以下特征适用于此模式：

• Fabric项目共享相同的容量。 查询或作业所花费的时间因使用相同容量的其他工作负荷而异。

• 工作区最大 CU 限制为最大 F SKU。 对于数据工程和数据科学体验，容量管理员可以为 Spark 配置自动缩放计费，以将 Spark 引擎使用的计算容量移到分配的 OU 之外。

• 工作区范围内的功能适用于共享该工作区的所有业务部门。

• 所有工作区项和数据都在一个区域中。 不能将此模式用于多个地理方案。

• 可以使用需要单独工作区的 DevOps 功能，例如部署管道和 生命周期管理。

• 单一工作区的限制适用。

• 特定的 SKU 容量限制适用。

何时使用此模式

在以下情况中，可以实施此部署模式：

• 你希望中心辐射结构集中管理分析环境中的某些操作，并分散管理其他操作。

• 你希望操作和管理的去中心化具有可变性。 例如，你的组织可能会在一个工作区中托管奖牌体系结构的铜层和银层，并在单独的工作区中托管金层。 这种分离通常反映了不同的运营责任，例如，一个团队管理铜层和银层，另一个团队管理黄金层。

• 你并不主要关注性能管理和工作负荷隔离。

• 组织不需要跨不同的地理区域部署工作负荷。 所有数据必须驻留在一个区域中。

• 你的组织可能需要单独的工作区，因为：

  • 负责工作负荷的团队成员位于不同的工作区中。

  • 你希望为每种类型的工作负载创建单独的工作区。 例如，可以创建用于数据引入的工作区，例如数据管道、数据流或数据工程，以及用于通过数据仓库使用的单独工作区。 如果单独的团队负责每个工作负荷，则此设计效果良好。

  • 你希望实现一个数据网格体系结构，该体系结构在 Fabric 域中将一个或多个工作区组合在一起。

• 你的组织可能会基于数据分类部署单独的工作区。

设计区域注意事项

下表显示了可能会影响你使用此部署模式的决定的注意事项。

模式 3：多个工作区，单独的容量

在此部署模式中，你将跨单独的Fabric容量分配多个工作区，从而在业务部门之间提供治理和性能隔离。

以下特征适用于此模式：

• 附加到工作区的最大可能 F SKU 或 P SKU 决定了工作区可以使用的最大 CU 数。

• 独立的工作区创造了组织和管理的去中心化。

• 组织可以通过在不同地理区域中使用容量和工作区来实现跨区域扩展。

• 您可以充分利用 Fabric 的所有功能，因为业务部门可以在不同容量中拥有多个工作区，并通过 Fabric 域将其组合在一起。

• 单个工作区的工作区限制适用，但可以创建新的工作区，以超出这些限制。

• 特定的 SKU 容量限制适用，但可以通过使用独立的容量来扩展 CU。

• 可以使用 OneLake 目录来查找和发现 Fabric 项目及其认证状态。

• 域可以将工作区分组在一起，以便单个业务部门可以操作和管理多个工作区。

• OneLake 快捷方式 消除了数据的物理副本，以减少数据移动。 OneLake 快捷方式还提供通过 OneLake 进行受控的跨工作区访问，并且不会转移基础数据的所有权。

何时使用此模式

在以下情况中，可以实施此部署模式：

• 组织希望部署体系结构框架，如数据网格或数据结构。

• 你希望在构建容量和工作区时优先考虑灵活性。

• 你在不同的地理区域开展业务。 在这种情况下，请创建单独的容量和工作区，以走向多容量和多工作区部署模式。

• 您运营大规模系统，并且有需求需要扩展超越单一容量SKU或单个工作区的限制。

• 工作负载必须始终在特定时间内完成，或者需要满足基于性能的 SLO。 可以设置一个独立的由Fabric容量支持的工作区，以满足工作负荷的服务水平协议 (SLO)。

设计区域注意事项

下表显示了可能会影响你使用此部署模式的决定的注意事项。

模式 4：多个 Fabric 租户

在此部署模式中，Fabric的所有实例都是与治理、管理、管理、缩放和存储相关的单独实体。

以下特征适用于此模式：

• 租户资源被严格隔离。

• 租户之间的管理平面是分开的。

• 租户是单独的实体，每个实体都有自己的治理和管理过程，每个实体都独立管理。

• 可以使用 数据管道 或 数据工程 功能在 Fabric 租户之间共享或访问数据。

何时使用此模式

在以下情况中，可以实施此部署模式：

• 由于一项业务收购，您的组织因此拥有多个 Fabric 租户。

• 组织计划专门为业务部门或较小的子公司设置一个Fabric租户。

评估替代平台

如果组织的要求与基于Fabric的部署模型不一致，请考虑以下受约束的替代方法：

• 具有 Data Lake Storage 或 OneLake 的 Azure 数据工厂，包含混合数据工厂和 Fabric 架构

  需要显式编排控制或分阶段现代化的组织可以使用 Data Factory 进行数据引入和管道编排，并使用 Data Lake Storage 作为存储基础。 在混合模型中，数据工厂管理的数据管道可以将数据加载到 OneLake 中，同时Fabric管理分析数据资产的创建。 此方法支持增量采用Fabric并保留已建立的集成模式。

• Data Lake Storage、Azure Databricks 和 Power BI

  首选平台即服务（PaaS）体系结构而不是统一软件即服务（SaaS）平台的组织可能会使用用于存储的Data Lake Storage、用于数据工程和分析的 Azure Databricks，以及用于语义建模和报告的 Power BI构建数据资产。 此方法提供最大的控制和灵活性，但需要增加集成工作量，并提高操作复杂性和治理开销。

注意事项

这些考虑因素贯彻了良好架构框架的支柱，这是一组指导原则，可用于提升工作负载的质量。 有关详细信息，请参阅 Well-Architected 框架。

本文前面的每个模式表使用了特定于Fabric部署决策的领域，包括治理、安全、管理、DevOps、可用性、性能和计费等。 以下小节提供由 Well-Architected 框架支柱组织的补充指导。 使用按模式分类的表格来比较不同的模式。 使用这些子部分用于跨领域的体系结构指导，无论选择哪种模式，这些指导适用。

可靠性

可靠性有助于确保应用程序能够履行对客户的承诺。 有关详细信息，请参阅 可靠性设计评审清单。

• 内置区域复原能力。 Fabric通过支持的可用性区域提供内置的区域复原能力。 Fabric无需客户配置即可自动跨多个区域分配资源。 可用性区域支持因Azure区域而异。 若要验证目标区域是否支持Fabric的可用性区域，请参阅 Fabric 区域可用性。

• 选择加入灾难恢复（DR）是必要的，并带有一些限制。 跨区域恢复可通过容量设置页上的“自选灾难恢复”设置获得。 启用灾难恢复容量设置，以使用异步复制将 OneLake 数据复制到跨 Azure 配对区域。

  重要

  某些 Azure 区域没有与支持 Fabric 的区域配对，这可能会在即使数据复制的情况下损害 DR 功能。 由于数据复制是异步的，因此在发生区域性灾难之前立即写入的数据可能会丢失。 有关详细信息，请参阅 Fabric 的可靠性。

• 单容量模式将风险集中在一个区域中。 在模式 1 和 2 中，工作负荷位于一个Azure区域中。 如果区域遇到中断，则所有工作区都会同时受到影响。 若要防止区域故障，请将容量设置配置为将 OneLake 数据复制到配对区域。 规划在配对区域中还原服务所需的恢复时间。

• 多容量模式提供自然的区域隔离。 在模式 3 和 4 中，不同区域中的容量意味着区域性中断仅影响该区域中的容量。 其他区域中的负载继续运作。 这些模式支持数据驻留要求，并为主动-被动或主动-主动区域策略提供基础。

• 容量暂停会影响可靠性。 如果为了降低成本而暂停Fabric容量，那么该容量上的所有工作负荷将不可用。 在暂停支持生产工作负荷的容量之前，请考虑可靠性效果。

• OneLake 快捷方式引入了外部依赖项。 使用外部数据源的快捷方式会导致对数据源可用性的依赖。 如果外部源不可用，依赖快捷方式的项目可能会失败。 监视外部数据源的运行状况，并计划正常降级。

安全性

安全性保障您重要的数据和系统免受故意攻击和滥用。 有关详细信息，请参阅 安全设计评审清单。

• 分层安全模型跨越三个级别。 Fabric实现跨租户、工作区和项级别的分层安全模型。 选择的部署模式决定了如何划分安全边界。 单工作区模式（如模式 1）强制实施统一访问。 多工作空间模式（如模式 2、3 和 4）支持每个团队或每个业务部门的安全边界。

身份验证和访问控制

• 使用条件访问强制实施租户级身份验证策略。 使用 条件访问 强制实施租户级身份验证策略，例如多重身份验证、设备符合性和基于位置的限制。 条件访问需要 Microsoft Entra ID P1 许可证。

• 使用工作区角色控制项访问。 分配 工作区角色 来控制谁可以在工作区中创建、编辑和使用项。 在多工作区模式（如模式 2、3 和 4）中，使用单独的工作区在业务部门之间强制实施角色边界。

• 使用 OneLake 安全角色应用精细的数据级访问。 使用OneLake 安全角色，可以对查看者角色中的用户应用表、文件夹、列和行级别的精细访问控制。 工作区管理员、成员和参与者将绕过这些角色。

网络安全

• 对入站流量使用专用链接。 使用 专用链接通过 Microsoft 主干网而非公共互联网来路由入站流量。 租户级专用链接适用于所有工作区。 工作区级专用链接提供每个工作区的细粒度。

• 将托管专用终结点用于出站 Spark 连接。 使用 托管的专用终结点保护从 Spark 工作负载到受防火墙保护的数据源（如 Data Lake Storage 和 Azure SQL 数据库）的出站连接。

• 当租户级专用链接阻止本地网关时，请使用虚拟网络数据网关。 启用租户级专用链接时，本地数据网关无法注册。 使用 虚拟网络数据网关 而不是连接本地或受虚拟网络保护的数据源的网桥。

数据保护

• 为端到端数据分类应用敏感度标签。 对于数据分类和保护，请将 敏感度标签 从 Microsoft Purview 信息保护 应用到流经 Fabric 的数据。 标签遵循从源到报表的数据。

• 使用审核日志和合规性工具进行策略执行。 若要检测和响应策略冲突，请查看 audit 日志并使用 Microsoft Purview 合规性管理器。

成本优化

成本优化侧重于减少不必要的开支和提高运营效率的方法。 有关详细信息，请参阅 成本优化的设计评审清单。

• 部署前的模型成本。 部署模式会影响成本结构。 使用 Fabric 定价和 Fabric 容量估算器对您的方案进行成本建模。

• 对容量 SKU 进行权限化。 根据工作负荷需求对 F SKU 进行权限化。 从较小的 SKU 开始，并根据需要纵向扩展。 使用 Fabric 容量指标应用监视消耗量并识别预配不足或预配不足的容量。

• 自动化暂停非生产环境的容量。 通过在不使用时暂停 F SKU 容量来降低成本。 在开发/测试环境中，在工作时间之外暂停容量。 暂停会使所有工作负荷不可用，因此请考虑通过 Azure 资源管理器 Fabric API 或计划管道实现自动化。

• 单容量模式（如模式 1 和 2）集中计费，但限制退款。 一个容量代表一张账单。 成本管理是集中的，但无法向单个业务部门退款，因为所有工作负荷共享相同的容量。

• 多容量模式（如模式 3 和 4）支持每团队退款。 每个能力生成其自己的 Azure 计费表。 可以向负责每个容量的业务部门收取费用。 可以根据支持工作负荷独立地对每个容量进行权限化或暂停。

• 独立管理 OneLake 存储成本。 OneLake 存储按每 GB 即用即付费率计费，不会消耗 OU。 定期删除未使用的数据，包括软删除的数据，并通过Fabric容量指标应用监视存储。

• 单独监视 Spark 计算。 对于数据工程工作负荷，可以使用单独的 Spark 池将计算移到 CU 预算之外。 若要避免意外成本，请监视 Spark CU 消耗。

卓越运营

卓越运营涵盖部署应用程序并使其在生产环境中运行的运营流程。 有关详细信息，请参阅 卓越运营的设计评审清单。

• 使用部署管道进行分阶段升级。 使用 Fabric 部署管道通过开发/测试和生产阶段推广内容。 部署管道需要单独的工作区，因此它们在模式 1 中不可用。 在模式 2、3 和 4 中，为每个 DTAP 阶段创建专用工作区。 容量策略因模式而异。

  • 在模式 2 中，所有 DTAP 工作区共享相同的容量，这是经济高效的，但不在环境之间提供性能隔离。

  • 在模式 3 中，可以使用每个环境的专用容量进行完全隔离，也可以通过使用具有单独生产能力的开发/测试共享容量来平衡成本和隔离。

• 将预生产环境规划为工作区级设计决策。 模式 1 不提供预生产分离，因为开发/测试发生在生产工作区中。 模式 2 支持在一个共享容量上单独开发、测试和生产工作区，该工作区适用于功能验证，但不适用于生产般的性能或复原测试。 模式 3 通过容量级隔离的环境一致工作区，支持类似于生产环境的预生产验证。 模式 4 涉及单独的租户，而不是工作区级别的决策。 每个租户都可以独立选择自己的环境拓扑，不需要与其他租户匹配。

• 将工作区连接到 Git 存储库 进行源代码管理。 在模式 2 和 3 中，每个团队或工作负荷的不同工作区与标准分支策略保持一致。 在模式 1 中，所有团队共享一个存储库，这可能会导致合并争用。

• 监控容量和工作负荷健康状况。 使用 Fabric Capacity Metrics 应用程序来监控容量消耗，例如 CU 使用情况、限制和超额。 可以使用 工作区监视访问有关单个工作负荷的详细遥测数据。 在多容量模式（如模式 3 和 4）中，可以将监视委托给负责每个容量的团队。

• 通过Fabric域委托管理。 在模式 2 和 3 中，使用 Fabric 域将租户设置和工作区管理委托给没有租户管理员权限的域级管理员。 模式 1 无法使用域，因为所有项都在一个工作区中。

• 使用基础设施即代码（IaC）来管理资源容量。 使用 Bicep 或 Terraform 创建和管理 Fabric 容量。 将基础结构定义与应用程序代码一起存储在源代码管理中。

性能效率

性能效率是指工作负荷能够高效地缩放以满足用户需求。 有关详细信息，请参阅性能效率设计评审核对清单。

• 了解容量大小调整和限制行为。 每种容量的 CU 配额都是由其 SKU 决定的。 如果需求超过可用的计算单元，Fabric将应用throttling并将请求排队。 使用 Fabric 容量指标应用监视节流事件，并根据需要扩展 SKU 或跨多个容量分配工作负荷。

• 将性能敏感的工作负荷隔离在专用资源上。 在模式1和2中，所有工作负载都争用相同的计算单元。 昂贵的查询或数据管道可能会降低其他用户的交互式查询性能。 在模式 3 和 4 中，您可以将性能敏感的负载隔离在具有保证 CU 分配的专用容量上。

• 为数据工程工作负荷配置 Spark 资源池。 对于数据工程工作负荷，请使用 自定义 Spark 池 来控制最小和最大节点计数，并支持自动缩放。 托管虚拟网络禁用启动器池或预热共享群集，这会将会话开始时间从秒增加到 3 到 5 分钟。

• 将容量放置在靠近数据生成者和使用者的位置。 在模式 3 中，可以使用靠近数据生成者或使用者的区域中的容量，从而减少跨区域延迟。 OneLake 快捷方式 可以引用其他区域中的数据，但跨区域读取会产生延迟和出口成本。

• 应用特定于工作负荷的优化技术。 使用 Lakehouses 的 Z 排序和 V 排序 来提高扫描性能。 对于仓库，请优化查询模式以读取较小的批次。 使用 Power BI 报表的 Direct Lake 模式减少与导入模式相比的容量负载。

功能矩阵

下表总结了每种模式功能的主要差异。

治理和管理

¹ 个工作区提供一定程度的隔离，但所有工作区共享单个容量，从而限制了使用情况跟踪和管理的粒度。

² 模式 4 使用单独的租户而不是域。 每个租户都有自己的管理模型。

安全性

DevOps 和生命周期管理

³ 部署管道需要单独的工作区，而这些工作区在单一（整体性）工作区模式下是不可用的。

⁴ Git 集成可用，但所有团队共享单个存储库，该存储库可以创建合并争用。

性能和规模

如果工作负荷处于专用容量上，则限流风险较小，但如果需求超过可用容量单元，则限流仍可在单个容量内发生。

计费和成本管理

⁶ 每个容量生成自己的计费计量，因此计费分布在各个容量中，而不是集中式的。

供稿人

Microsoft维护本文。 以下贡献者撰写了本文。

主要作者：

• Amanjeet Singh |首席项目经理

其他参与者：

• 洛林·费迪南德 |首席顾问
• Holly Kelly | 首席项目经理
• Gabi Muenster | 高级项目经理
• Sarah Sasidharan |高级项目经理

若要查看非公开领英个人资料，请登录领英。

后续步骤

• Fabric 概念和许可证
• Fabric工作区
• Fabric 域
• 什么是 OneLake？
• Fabric部署管道
• Fabric 中的可靠性
• Fabric安全概述

相关资源

• 技术选择概述
• 使用 Fabric 实现端到端分析
• 使用 Fabric 实现企业商业智能
• 使用 Fabric