Microsoft Fabric 部署模式

Microsoft Fabric

本文介绍在部署 Microsoft Fabric 时可以选择的四种部署模式。 了解每个部署模式的注意事项、建议和潜在的不可逆决策。

下面列出了每个 Fabric 部署模式的设计领域：

• 治理
• 安全性
• 管理
• DevOps
• 可用性
• 性能和规模
• 计费和成本管理

Fabric 部署中的级别

Fabric 部署有四个级别：租户、容量、工作区和项目。 顶层是 Fabric 租户。 每个租户可以具有一个或多个容量，每个容量可以包含一个或更多个工作区，每个工作区可以包含零个或多个 Fabric 项目。

组织在安全性、规模、治理和应用程序生命周期方面的结构或目标可能会影响其部署模式的选择。 不同的部署模式在部署级别上提供了不同的灵活性和重点。

例如，组织可以使用域对 Fabric 中的工作区进行分组。 同样，如果一个组织必须有一个可用于协作和查找内容的集中式选项，Fabric 中的 OneLake Data Hub 提供了一个集中式访问点，并与其他熟悉的产品（如 Microsoft Teams 和 Excel）集成。

在 Fabric 中，在不同地理位置拥有业务部门的大型组织可以使用容量来控制其数据驻留的位置。 它可以使用 Fabric 域将在不同地理位置运行的业务部门作为一个单元进行管理，因为域可以跨越不同区域中的工作区。

有关 Fabric 级别及其在选择部署模式中的作用的更多信息，请参阅 Microsoft Fabric 概念和许可证。

Fabric 部署模式如何协调

所有 Fabric 部署模式：

• 使用 Fabric 工作区作为规模、治理和安全性的边界。
• 使用 Fabric 域进行委派，以管理可能属于同一业务部门的多个工作区，或者当属于业务域的数据跨越多个工作区时。 可以在域级别设置一些租户级别的设置来管理和管理数据，并对这些设置使用特定于域的配置。
• 当必须满足特定的性能级别时，使用 Fabric 容量扩展计算资源，同时为每个工作区预配专用容量。
• 当 Fabric 中没有功能时，扩展以使用来自 Microsoft 云（Microsoft Azure、Microsoft 365 和其他应用程序）的等效功能。
• 使用 OneLake Data Hub 来促进数据资产的发现和使用。
• 使用 OneSecurity 为数据资产设置数据安全策略。

基于业务需求的方案

本文使用以下方案来介绍每个部署模式如何满足各种业务需求：

• 方案 1：适用于希望通过组织可以交叉协作的团队来更快（或更慢）进入市场的组织，对数据使用的限制更低。 在该方案下，组织可以通过使用整体部署模式而受益。 组织在单个工作区中运行和管理。 有关详细信息，请参阅模式 1：整体部署。
• 方案 2：适用于希望为团队提供独立工作环境的组织，有一个负责提供和管理基础结构的中心团队。 此方案也适用于希望实现数据网格的组织。 在此方案中，组织可以实现多个工作区，这些工作区要么使用共享容量，要么具有单独的容量。 有关更多信息，请参阅模式 2：由单个 Fabric 容量支持的多个工作区和模式 3：由单独容量支持的多个工作区。
• 方案 3：适用于需要一个完全分散式模型的组织，让业务部门或团队可以自由地控制和管理自己的数据平台。 在此方案中，组织可以选择使用独立工作区的部署模型，其中每个工作区具有专用容量，或者可能具有多个 Fabric 租户。 有关详细信息，请参阅模式 3：由单独容量支持的多个工作区和模式 4：多个 Fabric 租户。
• 方案 4：一个组织可能会选择使用一种混合方法，将多种模式结合起来以实现其需求。 例如，一个组织可能为特定的业务部门设置一个单独的工作区（整体部署模式），同时为其他业务部门使用单独的专用工作区和单独的容量。

模式 1：整体部署

在此部署模式中，预配一个工作区来满足所有用例的需要。 所有业务部门都在同一个单一的工作区中工作。

当调配单个 Fabric 容量，并将单个工作区连接到该容量时，以下几点是正确的：

• 所有 Fabric 项共享相同的已预配容量。 由于其他工作负载使用相同的容量，完成查询或作业所需的时间各不相同。
• 工作区最大容量单位 (CU) 限制为最大可能的 F SKU 或 P SKU。 对于数据工程经验，可以预配单独的 Spark 池，以将 Fabric Spark 所需的计算容量移动到所预配的 CU 之外。
• 工作区范围内的功能适用于共享该工作区的所有业务部门。
• 所有工作区项和数据都在一个区域中。 不能将此模式用于多地域方案。
• 依赖于多个工作区的功能（如部署管道和生命周期管理）不可用。
• 限制与单个工作区相关联。
• 容量限制与特定 SKU 相关联。

出于以下一个或多个原因，可以选择实现此部署模式：

• 组织没有复杂的工程需求，用户基数很小，或者语义模型也很小。
• 组织只在一个地区运作。
• 并不主要关注业务部门之间的组织分离。
• 组织不需要工作区范围的功能，例如与 Git 共享代码存储库。
• 你想实现一个湖屋奖牌体系结构。 当组织仅限于一个工作区时，可以通过在工作区内创建单独的湖屋来实现 Bronze、Silver 和 Gold 层之间的分离。
• 组织的业务部门共享角色，工作区中的用户可以具有相同的工作区级别权限。 例如，当属于不同业务单位的多个用户是单个工作区的管理员时，他们对工作区中的所有项具有相同的权限。
• 组织可以容忍可变的工作完成时间。 如果一个组织对性能保证没有任何要求（例如，一项作业必须在特定的时间段内完成），则可以跨业务部门共享单个预配的容量。 共享容量时，用户可以随时运行查询。 可用于运行作业的 CU 数量因容量上运行的其他查询而异。 这可能导致作业完成时间的变化。
• 组织可以通过使用单个 Fabric 容量来实现其所有业务需求（从 CU 的角度来看）。

下表给出了可能影响你决定采用此部署模式的注意事项：

方面	注意事项
治理	- 需要降低平台上的治理要求和限制。 - 适合更倾向于更早上市的小型组织。 - 如果治理需求变得更加复杂，可能会出现挑战。
安全 - 数据平面	- 数据可以跨团队共享，因此无需对团队之间的数据进行限制。 - 团队对语义模型拥有所有权。 他们可以在 OneLake 中读取、编辑和修改数据。
安全 - 控制平面	- 所有用户都可以在同一个工作区中进行协作。 - 项目没有限制。 所有用户都可以阅读和编辑所有项目。
管理	组织有： - 降低管理成本。 - 不需要严格地跟踪和监视每个团队的访问和使用情况。 - 跨团队的 Fabric 工作负载监控不那么严格。
DevOps	DevOps 受益于： - 整个平台的单一版本。 - 更简单的发布管道。
可用性 - 管理员	- 管理员更容易管理，因为他们需要管理的项目更少。 - 不需要其他资源预配，也不需要处理团队对新容量或工作区的请求。 - 容量管理员可以是租户管理员，因此不需要创建或管理其他组或团队。
可用性 - 其他角色	- 与其他用户共享工作区是可以接受的。 - 鼓励用户之间的协作。
“性能”	- 工作负载的隔离不是强制性的。 - 不需要满足严格的性能服务级别协议 (SLA)。 - 节流不可能。
计费和成本管理	- 一个单个团队可以处理成本。 - 没有必要向不同的团队收费。

模式 2：由单个 Fabric 容量支持的多个工作区

在此部署模式中，使用单独的工作区。 由于单个容量跨工作区共享，因此在任何时候并发运行的工作负载都可能影响作业和交互式查询的性能。

当预配单个 Fabric 容量并为其附加多个工作区时，以下几点是正确的：

• 所有 Fabric 项共享相同的已预配容量。 由于其他工作负载使用相同的容量，完成查询或作业所需的时间各不相同。
• 工作区可以使用的最大 CU 限制为最大可能的 F SKU 或 P SKU。 对于数据工程经验，可以预配单独的 Spark 池，以将 Fabric Spark 所需的计算容量移动到所预配的 CU 之外。
• 工作区范围内的功能适用于共享该工作区的所有业务部门。
• 所有工作区项和数据都在一个区域中。 不能将此模式用于多地域方案。
• 可以使用需要单独工作区的 DevOps 功能，例如用于部署管道和生命周期管理。
• 限制与单个工作区相关联。
• 容量限制与特定 SKU 相关联。

出于以下一个或多个原因，可以选择实现此部署模式：

• 需要一个中心辐射型体系结构，在该体系结构中，组织将分析环境的某些方面集中起来，并将其他方面分散开来。
• 你希望从运营和管理方面进行分散，但程度不同。 例如，你可能选择将一个奖牌体系结构的 Bronze 层和Silver 层部署到一个工作区，而将 Gold 层部署到另一个工作区。 你的理由可能是一个团队负责 Bronze 层、Silver 层，而另一个团队则负责 Gold 层的运营和管理。
• 你并不主要关心性能管理和从性能角度隔离工作负载。
• 从湖屋奖牌体系结构的角度来看，你组织可以创建单独的工作区来实现 Bronze、Silver 和 Gold 层。
• 组织不需要跨不同的地理区域部署工作负载（所有数据必须位于一个区域）。
• 由于以下一个或多个原因，组织可能需要分隔工作区：
  • 负责工作负载的团队成员位于不同的工作区。
  • 你希望为每种类型的工作负载创建单独的工作区。 例如，可以为数据摄取（数据管道、数据流 Gen2 或数据工程）创建一个工作区，并为通过数据仓库的消费创建一个单独的工作区。 当不同的团队负责每个工作负载时，这种设计效果很好。
  • 你希望实现一种数据网格体系结构，其中一个或多个工作区被分组在 Fabric 域中。
• 组织可以选择根据数据分类部署单独的工作区。

下表列出了可能影响你选择此部署模式的决定的注意事项：

方面	注意事项
治理	- 需要对平台进行中等治理授权和限制。 - 组织需要更精细的控制来管理部门、团队和角色。
安全 - 数据平面	- 需要对数据进行限制，需要根据对部门、团队和成员的访问控制提供数据保护。
安全 - 控制平面	- 为了避免意外损坏或恶意用户的操作，可能需要按角色提供对 Fabric 项目的受控访问。
管理	- 不需要管理容量，因为这是一个单一容量模型。 - 可以使用工作区来隔离部门、团队和用户。
DevOps	- 可以为每个部门、团队或工作负载进行独立发布。 - 当提供多个工作区来处理每个发布环境时，满足团队的开发、测试、验收和生产 (DTAP) 需求会更容易。
可用性 - 管理员	- 不需要预配多个容量。 - 租户管理员通常管理容量，因此你不需要管理其他组或团队。
可用性 - 其他角色	- 每个奖牌层都有可用的工作区。 - Fabric 项按工作区进行隔离，这有助于防止意外损坏。
“性能”	- 不需要满足严格的性能 SLA。 - 在高峰期可以进行节流。
计费和成本管理	- 没有对每支团队收费的具体要求。 - 中心团队承担所有费用。 - 基础架构团队是组织中 Fabric 能力的所有者。

模式 3：由单独容量支持的多个工作区

在此部署模式中，可以实现治理和性能业务部门之间的分离。

当为多个 Fabric 容量预配各自的工作区时，以下几点是正确的：

• 附加到工作区的最大可能 F SKU 或 P SKU 决定了工作区可以使用的最大 CU。
• 组织和管理的分散化是通过提供单独的工作区来实现的。
• 组织可以通过在不同的地理区域提供容量和工作区来扩展到一个区域之外。
• 可以使用 Fabric 的全部功能，因为业务部门可以有一个或多个工作区，这些工作区具有不同的容量，并通过 Fabric 域分组在一起。
• 限制与单个工作区相关联，但是可以通过创建新的工作区来扩展这些限制。
• 容量限制与特定 SKU 相关联，但可以通过预配单独的容量来扩展 CU。
• 租户中所有工作区中的所有 Fabric 项目及其证书状态都可以通过使用 OneLake Data Hub 来发现。
• 域可以将工作区分组在一起，以便单个业务部门可以操作和管理多个工作区。
• OneLake 快捷方式减少了数据移动，也降低了工作区中的数据可用性。

出于以下一个或多个原因，可以选择实现此部署模式：

• 组织希望部署体系结构框架，如数据网格或数据结构。
• 你希望在构建容量和工作区时优先考虑灵活性。
• 你在不同的地理区域开展业务。 在这种情况下，预配一个单独的容量和工作区是朝着这种多容量和多工作区部署模式发展的驱动力。
• 你的运营规模很大，并且需要扩展到单个容量 SKU 或单个工作区之外。
• 工作负载必须始终在特定时间内完成或满足特定的性能 SLA。 可以预配由 Fabric 容量支持的单独工作区，以满足这些工作负载的性能保证。

下表列出了可能影响你选择此部署模式的决定的注意事项：

方面	注意事项
治理	- 你具有高度的治理和管理能力，并且每个工作区都需要独立性。 - 可以管理每个部门或业务部门的使用情况。 - 需要遵守数据驻留要求。 - 需要根据法规要求隔离数据。
安全 - 数据平面	- 数据访问可以按部门、团队或用户进行控制。 - 可以根据 Fabric 项类型隔离数据。
安全 - 控制平面	- 可以按角色提供对 Fabric 项的受控访问，以避免意外损坏或恶意用户的操作。
管理	- 精细的管理员功能仅限于部门、团队或用户。 - 可以访问有关工作负载使用或模式的详细监控要求。
DevOps	- 可以通过使用不同的容量来隔离 DTAP 环境。 - 基于部门、团队或工作负载独立发布。
可用性 - 管理员	- 可以按部门或团队获得对使用情况的精细可见性。 - 你已将容量权限委派给每个部门或团队的容量管理员，这有助于扩展和细化配置。
可用性 - 其他角色	- 每个奖牌层和容量都有可用的工作区。 - Fabric 项按工作区进行隔离，这有助于防止意外损坏。 - 你有更多的选择来防止由共享容量激增引起的节流。
“性能”	- 性能要求很高，工作负载需要满足更高的 SLA 要求。 - 可以灵活地扩展每个部门或团队的单个工作负载。
计费和成本管理	- 通过向组织实体（部门、团队或项目）分配专用容量，可以轻松满足交叉收费要求。 - 成本管理可以委托给各个团队进行管理。

模式 4：多个 Fabric 租户

当部署独立的 Fabric 租户时，Fabric 的所有实例在治理、管理、监管、规模和存储方面都是独立的实体。

当使用多个 Fabric 租户时，以下几点是正确的：

• 租户资源被严格隔离。
• 租户之间的管理平面是分开的。
• 租户是独立的实体，可以有自己的治理和管理流程，但是可以单独管理它们。
• 可以使用数据管道或数据工程功能在 Fabric 租户之间共享或访问数据。

你可能会选择实现此部署模式，原因如下：

• 由于业务收购，组织可能最终拥有多个 Fabric 租户。
• 组织可以选择专门为业务部门或较小的子公司设置 Fabric 租户。

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

• Holly Kelly | 首席项目经理
• Gabi Muenster | 高级项目经理
• Sarath Sasidharan | 高级项目经理
• Amanjeet Singh | 首席项目经理

本文介绍在部署 Microsoft Fabric 时可以选择的四种部署模式。 了解每个部署模式的注意事项、建议和潜在的不可逆决策。

下面列出了每个 Fabric 部署模式的设计领域：

• 治理
• 安全性
• 管理
• DevOps
• 可用性
• 性能和规模
• 计费和成本管理

Fabric 部署中的级别

Fabric 部署有四个级别：租户、容量、工作区和项目。 顶层是 Fabric 租户。 每个租户可以具有一个或多个容量，每个容量可以包含一个或更多个工作区，每个工作区可以包含零个或多个 Fabric 项目。

组织在安全性、规模、治理和应用程序生命周期方面的结构或目标可能会影响其部署模式的选择。 不同的部署模式在部署级别上提供了不同的灵活性和重点。

例如，组织可以使用域对 Fabric 中的工作区进行分组。 同样，如果一个组织必须有一个可用于协作和查找内容的集中式选项，Fabric 中的 OneLake Data Hub 提供了一个集中式访问点，并与其他熟悉的产品（如 Microsoft Teams 和 Excel）集成。

在 Fabric 中，在不同地理位置拥有业务部门的大型组织可以使用容量来控制其数据驻留的位置。 它可以使用 Fabric 域将在不同地理位置运行的业务部门作为一个单元进行管理，因为域可以跨越不同区域中的工作区。

有关 Fabric 级别及其在选择部署模式中的作用的更多信息，请参阅 Microsoft Fabric 概念和许可证。

Fabric 部署模式如何协调

所有 Fabric 部署模式：

• 使用 Fabric 工作区作为规模、治理和安全性的边界。
• 使用 Fabric 域进行委派，以管理可能属于同一业务部门的多个工作区，或者当属于业务域的数据跨越多个工作区时。 可以在域级别设置一些租户级别的设置来管理和管理数据，并对这些设置使用特定于域的配置。
• 当必须满足特定的性能级别时，使用 Fabric 容量扩展计算资源，同时为每个工作区预配专用容量。
• 当 Fabric 中没有功能时，扩展以使用来自 Microsoft 云（Microsoft Azure、Microsoft 365 和其他应用程序）的等效功能。
• 使用 OneLake Data Hub 来促进数据资产的发现和使用。
• 使用 OneSecurity 为数据资产设置数据安全策略。

基于业务需求的方案

本文使用以下方案来介绍每个部署模式如何满足各种业务需求：

• 方案 1：适用于希望通过组织可以交叉协作的团队来更快（或更慢）进入市场的组织，对数据使用的限制更低。 在该方案下，组织可以通过使用整体部署模式而受益。 组织在单个工作区中运行和管理。 有关详细信息，请参阅模式 1：整体部署。
• 方案 2：适用于希望为团队提供独立工作环境的组织，有一个负责提供和管理基础结构的中心团队。 此方案也适用于希望实现数据网格的组织。 在此方案中，组织可以实现多个工作区，这些工作区要么使用共享容量，要么具有单独的容量。 有关更多信息，请参阅模式 2：由单个 Fabric 容量支持的多个工作区和模式 3：由单独容量支持的多个工作区。
• 方案 3：适用于需要一个完全分散式模型的组织，让业务部门或团队可以自由地控制和管理自己的数据平台。 在此方案中，组织可以选择使用独立工作区的部署模型，其中每个工作区具有专用容量，或者可能具有多个 Fabric 租户。 有关详细信息，请参阅模式 3：由单独容量支持的多个工作区和模式 4：多个 Fabric 租户。
• 方案 4：一个组织可能会选择使用一种混合方法，将多种模式结合起来以实现其需求。 例如，一个组织可能为特定的业务部门设置一个单独的工作区（整体部署模式），同时为其他业务部门使用单独的专用工作区和单独的容量。

模式 1：整体部署

在此部署模式中，预配一个工作区来满足所有用例的需要。 所有业务部门都在同一个单一的工作区中工作。

当调配单个 Fabric 容量，并将单个工作区连接到该容量时，以下几点是正确的：

• 所有 Fabric 项共享相同的已预配容量。 由于其他工作负载使用相同的容量，完成查询或作业所需的时间各不相同。
• 工作区最大容量单位 (CU) 限制为最大可能的 F SKU 或 P SKU。 对于数据工程经验，可以预配单独的 Spark 池，以将 Fabric Spark 所需的计算容量移动到所预配的 CU 之外。
• 工作区范围内的功能适用于共享该工作区的所有业务部门。
• 所有工作区项和数据都在一个区域中。 不能将此模式用于多地域方案。
• 依赖于多个工作区的功能（如部署管道和生命周期管理）不可用。
• 限制与单个工作区相关联。
• 容量限制与特定 SKU 相关联。

出于以下一个或多个原因，可以选择实现此部署模式：

• 组织没有复杂的工程需求，用户基数很小，或者语义模型也很小。
• 组织只在一个地区运作。
• 并不主要关注业务部门之间的组织分离。
• 组织不需要工作区范围的功能，例如与 Git 共享代码存储库。
• 你想实现一个湖屋奖牌体系结构。 当组织仅限于一个工作区时，可以通过在工作区内创建单独的湖屋来实现 Bronze、Silver 和 Gold 层之间的分离。
• 组织的业务部门共享角色，工作区中的用户可以具有相同的工作区级别权限。 例如，当属于不同业务单位的多个用户是单个工作区的管理员时，他们对工作区中的所有项具有相同的权限。
• 组织可以容忍可变的工作完成时间。 如果一个组织对性能保证没有任何要求（例如，一项作业必须在特定的时间段内完成），则可以跨业务部门共享单个预配的容量。 共享容量时，用户可以随时运行查询。 可用于运行作业的 CU 数量因容量上运行的其他查询而异。 这可能导致作业完成时间的变化。
• 组织可以通过使用单个 Fabric 容量来实现其所有业务需求（从 CU 的角度来看）。

下表给出了可能影响你决定采用此部署模式的注意事项：

方面	注意事项
治理	- 需要降低平台上的治理要求和限制。 - 适合更倾向于更早上市的小型组织。 - 如果治理需求变得更加复杂，可能会出现挑战。
安全 - 数据平面	- 数据可以跨团队共享，因此无需对团队之间的数据进行限制。 - 团队对语义模型拥有所有权。 他们可以在 OneLake 中读取、编辑和修改数据。
安全 - 控制平面	- 所有用户都可以在同一个工作区中进行协作。 - 项目没有限制。 所有用户都可以阅读和编辑所有项目。
管理	组织有： - 降低管理成本。 - 不需要严格地跟踪和监视每个团队的访问和使用情况。 - 跨团队的 Fabric 工作负载监控不那么严格。
DevOps	DevOps 受益于： - 整个平台的单一版本。 - 更简单的发布管道。
可用性 - 管理员	- 管理员更容易管理，因为他们需要管理的项目更少。 - 不需要其他资源预配，也不需要处理团队对新容量或工作区的请求。 - 容量管理员可以是租户管理员，因此不需要创建或管理其他组或团队。
可用性 - 其他角色	- 与其他用户共享工作区是可以接受的。 - 鼓励用户之间的协作。
“性能”	- 工作负载的隔离不是强制性的。 - 不需要满足严格的性能服务级别协议 (SLA)。 - 节流不可能。
计费和成本管理	- 一个单个团队可以处理成本。 - 没有必要向不同的团队收费。

模式 2：由单个 Fabric 容量支持的多个工作区

在此部署模式中，使用单独的工作区。 由于单个容量跨工作区共享，因此在任何时候并发运行的工作负载都可能影响作业和交互式查询的性能。

当预配单个 Fabric 容量并为其附加多个工作区时，以下几点是正确的：

• 所有 Fabric 项共享相同的已预配容量。 由于其他工作负载使用相同的容量，完成查询或作业所需的时间各不相同。
• 工作区可以使用的最大 CU 限制为最大可能的 F SKU 或 P SKU。 对于数据工程经验，可以预配单独的 Spark 池，以将 Fabric Spark 所需的计算容量移动到所预配的 CU 之外。
• 工作区范围内的功能适用于共享该工作区的所有业务部门。
• 所有工作区项和数据都在一个区域中。 不能将此模式用于多地域方案。
• 可以使用需要单独工作区的 DevOps 功能，例如用于部署管道和生命周期管理。
• 限制与单个工作区相关联。
• 容量限制与特定 SKU 相关联。

出于以下一个或多个原因，可以选择实现此部署模式：

• 需要一个中心辐射型体系结构，在该体系结构中，组织将分析环境的某些方面集中起来，并将其他方面分散开来。
• 你希望从运营和管理方面进行分散，但程度不同。 例如，你可能选择将一个奖牌体系结构的 Bronze 层和Silver 层部署到一个工作区，而将 Gold 层部署到另一个工作区。 你的理由可能是一个团队负责 Bronze 层、Silver 层，而另一个团队则负责 Gold 层的运营和管理。
• 你并不主要关心性能管理和从性能角度隔离工作负载。
• 从湖屋奖牌体系结构的角度来看，你组织可以创建单独的工作区来实现 Bronze、Silver 和 Gold 层。
• 组织不需要跨不同的地理区域部署工作负载（所有数据必须位于一个区域）。
• 由于以下一个或多个原因，组织可能需要分隔工作区：
  • 负责工作负载的团队成员位于不同的工作区。
  • 你希望为每种类型的工作负载创建单独的工作区。 例如，可以为数据摄取（数据管道、数据流 Gen2 或数据工程）创建一个工作区，并为通过数据仓库的消费创建一个单独的工作区。 当不同的团队负责每个工作负载时，这种设计效果很好。
  • 你希望实现一种数据网格体系结构，其中一个或多个工作区被分组在 Fabric 域中。
• 组织可以选择根据数据分类部署单独的工作区。

下表列出了可能影响你选择此部署模式的决定的注意事项：

方面	注意事项
治理	- 需要对平台进行中等治理授权和限制。 - 组织需要更精细的控制来管理部门、团队和角色。
安全 - 数据平面	- 需要对数据进行限制，需要根据对部门、团队和成员的访问控制提供数据保护。
安全 - 控制平面	- 为了避免意外损坏或恶意用户的操作，可能需要按角色提供对 Fabric 项目的受控访问。
管理	- 不需要管理容量，因为这是一个单一容量模型。 - 可以使用工作区来隔离部门、团队和用户。
DevOps	- 可以为每个部门、团队或工作负载进行独立发布。 - 当提供多个工作区来处理每个发布环境时，满足团队的开发、测试、验收和生产 (DTAP) 需求会更容易。
可用性 - 管理员	- 不需要预配多个容量。 - 租户管理员通常管理容量，因此你不需要管理其他组或团队。
可用性 - 其他角色	- 每个奖牌层都有可用的工作区。 - Fabric 项按工作区进行隔离，这有助于防止意外损坏。
“性能”	- 不需要满足严格的性能 SLA。 - 在高峰期可以进行节流。
计费和成本管理	- 没有对每支团队收费的具体要求。 - 中心团队承担所有费用。 - 基础架构团队是组织中 Fabric 能力的所有者。

模式 3：由单独容量支持的多个工作区

在此部署模式中，可以实现治理和性能业务部门之间的分离。

当为多个 Fabric 容量预配各自的工作区时，以下几点是正确的：

• 附加到工作区的最大可能 F SKU 或 P SKU 决定了工作区可以使用的最大 CU。
• 组织和管理的分散化是通过提供单独的工作区来实现的。
• 组织可以通过在不同的地理区域提供容量和工作区来扩展到一个区域之外。
• 可以使用 Fabric 的全部功能，因为业务部门可以有一个或多个工作区，这些工作区具有不同的容量，并通过 Fabric 域分组在一起。
• 限制与单个工作区相关联，但是可以通过创建新的工作区来扩展这些限制。
• 容量限制与特定 SKU 相关联，但可以通过预配单独的容量来扩展 CU。
• 租户中所有工作区中的所有 Fabric 项目及其证书状态都可以通过使用 OneLake Data Hub 来发现。
• 域可以将工作区分组在一起，以便单个业务部门可以操作和管理多个工作区。
• OneLake 快捷方式减少了数据移动，也降低了工作区中的数据可用性。

出于以下一个或多个原因，可以选择实现此部署模式：

• 组织希望部署体系结构框架，如数据网格或数据结构。
• 你希望在构建容量和工作区时优先考虑灵活性。
• 你在不同的地理区域开展业务。 在这种情况下，预配一个单独的容量和工作区是朝着这种多容量和多工作区部署模式发展的驱动力。
• 你的运营规模很大，并且需要扩展到单个容量 SKU 或单个工作区之外。
• 工作负载必须始终在特定时间内完成或满足特定的性能 SLA。 可以预配由 Fabric 容量支持的单独工作区，以满足这些工作负载的性能保证。

下表列出了可能影响你选择此部署模式的决定的注意事项：

方面	注意事项
治理	- 你具有高度的治理和管理能力，并且每个工作区都需要独立性。 - 可以管理每个部门或业务部门的使用情况。 - 需要遵守数据驻留要求。 - 需要根据法规要求隔离数据。
安全 - 数据平面	- 数据访问可以按部门、团队或用户进行控制。 - 可以根据 Fabric 项类型隔离数据。
安全 - 控制平面	- 可以按角色提供对 Fabric 项的受控访问，以避免意外损坏或恶意用户的操作。
管理	- 精细的管理员功能仅限于部门、团队或用户。 - 可以访问有关工作负载使用或模式的详细监控要求。
DevOps	- 可以通过使用不同的容量来隔离 DTAP 环境。 - 基于部门、团队或工作负载独立发布。
可用性 - 管理员	- 可以按部门或团队获得对使用情况的精细可见性。 - 你已将容量权限委派给每个部门或团队的容量管理员，这有助于扩展和细化配置。
可用性 - 其他角色	- 每个奖牌层和容量都有可用的工作区。 - Fabric 项按工作区进行隔离，这有助于防止意外损坏。 - 你有更多的选择来防止由共享容量激增引起的节流。
“性能”	- 性能要求很高，工作负载需要满足更高的 SLA 要求。 - 可以灵活地扩展每个部门或团队的单个工作负载。
计费和成本管理	- 通过向组织实体（部门、团队或项目）分配专用容量，可以轻松满足交叉收费要求。 - 成本管理可以委托给各个团队进行管理。

模式 4：多个 Fabric 租户

当部署独立的 Fabric 租户时，Fabric 的所有实例在治理、管理、监管、规模和存储方面都是独立的实体。

当使用多个 Fabric 租户时，以下几点是正确的：

• 租户资源被严格隔离。
• 租户之间的管理平面是分开的。
• 租户是独立的实体，可以有自己的治理和管理流程，但是可以单独管理它们。
• 可以使用数据管道或数据工程功能在 Fabric 租户之间共享或访问数据。

你可能会选择实现此部署模式，原因如下：

• 由于业务收购，组织可能最终拥有多个 Fabric 租户。
• 组织可以选择专门为业务部门或较小的子公司设置 Fabric 租户。

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

• Holly Kelly | 首席项目经理
• Gabi Muenster | 高级项目经理
• Sarath Sasidharan | 高级项目经理
• Amanjeet Singh | 首席项目经理