通过

Power BI Embedded 中多租户应用的服务主体配置文件

  • 项目

本文介绍拥有许多客户的 ISV 或任何其他 Power BI Embedded 应用所有者如何使用服务主体配置文件来映射和管理每个客户的数据，作为其 Power BI“为客户嵌入内容”解决方案的一部分。 服务主体配置文件允许 ISV 构建可缩放的应用程序，以实现更好的客户数据隔离并在客户之间建立更严格的安全边界。 本文讨论此解决方案的优点和局限。

注意

Power BI 中的租户一词有时可能指 Microsoft Entra ID 租户。 但本文使用术语多租户来描述一种解决方案，在该解决方案中软件应用程序的单个实例服务于需要物理和逻辑数据分离的多个客户或组织（租户）。 例如，Power BI 应用生成器可以为其每个客户（或租户）分配独立工作区，如下所示。 这些客户不一定是 Microsoft Entra 租户，因此请不要将此处所用的术语多租户应用程序与 Microsoft Entra 多租户应用程序混淆。

服务主体配置文件是由服务主体创建的配置文件。 ISV 应用使用服务主体配置文件调用 Power BI API，如本文中所述。

ISV 应用程序服务主体为每个客户或租户创建不同的 Power BI 配置文件。 当客户访问 ISV 应用时，该应用使用相应的配置文件来生成一个嵌入令牌，该令牌将用于在浏览器中呈现报表。

使用服务主体配置文件使 ISV 应用能够在单个 Power BI 租户上托管多个客户。 每个配置文件代表 Power BI 中的一个客户。 换言之，每个配置文件都会为一个特定客户的数据创建和管理 Power BI 内容。

SP 配置文件和多租户关系图。

注意

本文面向希望使用服务主体配置文件设置多租户应用的组织。 如果组织已有支持多租户的应用，并且你想要迁移到服务主体配置文件模型，请参阅迁移到服务主体配置文件模型。

设置 Power BI 内容涉及以下步骤：

上述所有步骤都可通过使用 Power BI REST API 自动完全。

先决条件

创建服务主体配置文件之前，需要：

  • 按照使用服务主体嵌入 Power BI 内容的前三个步骤设置服务主体。
  • 在 Power BI 租户管理员帐户中，可使用创建服务主体时使用的同一安全组在租户中创建配置文件。

管理门户开关的屏幕截图。

创建档案

可使用配置文件 REST API 创建、更新和删除配置文件。

例如，创建配置文件：

POST https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…UUPA
Content-Type: application/json; charset=utf-8

{"displayName":"ContosoProfile"}

服务主体还可调用获取配置文件 REST API 获取其配置文件的列表。 例如：

GET https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXA…UUPA

配置文件权限

授予用户对 Power BI 项目的权限的任何 API 也可授予配置文件对 Power BI 项目的权限。 例如，添加组用户 API 可用于授予配置文件对工作区的权限。

使用配置文件时需要了解以下几点：

  • 配置文件属于创建它的服务主体，并且只能由该服务主体使用。
  • 配置文件所有者在创建后无法更改。
  • 配置文件不是独立标识。 它需要服务主体 Microsoft Entra 令牌来调用 Power BI REST API。

ISV 应用通过在 Authorization 标头中提供服务主体 Microsoft Entra 令牌以及在 X-PowerBI-Profile-Id 标头中提供配置文件 ID 来调用 Power BI REST API。 例如：

  GET https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
  Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUz.....SXBwasfg
  X-PowerBI-Profile-Id: 5f1aa5ed-5983-46b5-bd05-999581d361a5

创建工作区

Power BI 工作区用于托管 Power BI 项，例如报表和语义模型。

每个配置文件都需要：

  • 创建至少一个 Power BI 工作区

    POST https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
Authorization: Bearer eyJ0eXA…ZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "name": "ContosoWorkspace"
}

  • 授予该工作区访问权限。 服务主体配置文件必须具有工作区的管理员访问权限。

  • 将工作区分配到容量

    POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/AssignToCapacity HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…wNkZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "capacityId": "13f73071-d6d3-4d44-b9de-34590f3e3cf6"
}

详细了解 Power BI 工作区。

导入报表和语义模型

使用 Power BI Desktop 准备连接到客户数据或示例数据的报表。 然后，可使用导入 API 将内容导入到创建的工作区中。

POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/imports?datasetDisplayName=ContosoSales HTTP/1.1
Authorization: Bearer eyJ...kZUiIsg
Content-Type: multipart/form-data; boundary="8b071895-b380-4769-9c62-7e586d717ed7"
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306
Fiddler-Encoding: base64

LS04YjA3MTg5NS1iMzgwLTQ3...Tg2ZDcxN2VkNy0tDQo=

使用数据集参数创建可连接到不同客户的数据源的语义模型。 然后，使用更新参数 API 定义语义模型要连接到哪个客户的数据。

设置语义模型连接

ISV 通常通过以下两种方式之一存储其客户的数据：

无论哪种情况，都应在 Power BI 中使用单租户语义模型（每个客户一个语义模型）。

每个客户的独立数据库

如果 ISV 应用程序针对每个客户都使用单独的数据库，请在 Power BI 中创建单一租户语义模型。 为每个语义模型提供指向其匹配的数据库的连接详细信息。 使用以下方法之一来避免创建具有不同连接详细信息的多个相同报表：

  • 语义模型参数：使用连接详细信息（例如 SQL Server 名称、SQL 数据库名称）中的参数创建语义模型。 然后，将报表导入客户的工作区并更改参数以匹配客户的数据库详细信息。

  • 更新数据源 API：创建一个指向包含示例内容的数据源的 .pbix。 然后，将该 .pbix 导入客户的工作区并使用更新数据源 API 更改连接详细信息。

单个多租户数据库

如果 ISV 应用程序为其所有客户使用一个数据库，请在 Power BI 中将客户分成不同的语义模型，如下所示：

使用仅检索相关客户数据的参数创建报表。 然后，将报表导入客户的工作区并更改参数以仅检索相关客户的数据。

嵌入报表

设置完成后，可使用嵌入令牌将客户报表和其他项嵌入到你的应用程序中。

当客户访问你的应用程序时，使用相应的配置文件调用 GenerateToken API。 使用生成的嵌入令牌在客户的浏览器中嵌入报表或其他项。

生成嵌入令牌：

POST https://api.powerbi.com/v1.0/myorg/GenerateToken HTTP/1.1
Authorization: Bearer eyJ0eXAiOi…kZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "datasets": [
    {
      "id": "3b1c8f74-fbbe-45e0-bf9d-19fce69262e3"
    }
  ],
  "reports": [
    {
      "id": "3d474b89-f2d5-43a2-a436-d24a6eb2dc8f"
    }
  ]
}

设计方面

在设置基于配置文件的多租户解决方案之前，应注意以下问题：

伸缩性

通过为每个客户将数据分成单独的语义模型，可最大限度地减少对大型语义模型的需求。 容量过载时，可以收回未使用的语义模型，为活动语义模型释放内存。 对于单个大型语义模型，无法实现这种优化。 如果需要，还可使用多个语义模型将租户划分为多个 Power BI 容量。

如果没有配置文件，服务主体将被限制为 1,000 个工作区。 要克服此限制，服务主体可以创建多个配置文件，其中每个配置文件最多可以访问/创建 1,000 个工作区。 通过多个配置文件，ISV 应用程序可以使用不同的逻辑容器隔离每个客户的内容。

一旦服务主体配置文件有权访问工作区，就可删除其父服务主体对工作区的访问以避免可伸缩性问题。

即使有这些优势，你也应考虑应用程序的潜在规模。 例如，配置文件可访问的工作区项的数量是有限的。 目前，配置文件与普通用户具有相同的限制。 如果 ISV 应用程序允许最终用户保存其嵌入式报表的个性化副本，则客户的配置文件将有权访问其所有用户创建的所有报表。 该模型最终可能会超出限制。

自动化和操作复杂性

使用基于 Power BI 配置文件的分离，你可能需要管理数百或上千的项目。 因此，请务必要定义在应用程序生命周期管理中经常发生的流程，并确保你有正确的工具集来大规模执行这些操作。 其中的一些操作包括：

  • 添加新租户
  • 为部分或所有租户更新报表
  • 为部分或所有租户更新语义模型架构
  • 针对特定租户的未计划自定义
  • 语义模型刷新的频率

例如，为新租户创建配置文件和工作区是一项常见任务，可使用 Power BI REST API 实现完全自动化。

多地理位置需要

Power BI Embedded 的 Multi-Geo 支持意味着，对于使用 Power BI Embedded 构建应用程序并将分析嵌入其应用程序的 ISV 和组织，现在可以在全球不同地区部署其数据。 要在不同区域中支持不同客户，请将客户的工作区分配给所需区域中的容量。 这个任务操作简单，不涉及额外的成本。 但是，如果你的客户需要来自多个区域的数据，则租户配置文件应将所有项复制到分配给不同区域容量的多个工作区中。 这种重复可能会增加成本和管理复杂性。

出于合规性原因，你可能仍希望在不同区域创建多个 Power BI 租户。 阅读有关 multi-geo 的详细信息。

成本效益

使用 Power BI Embedded 的应用程序开发人员需要购买 Power BI Embedded 容量。 基于配置文件的分离模型非常适用于容量，原因如下：

  • 可独立分配给容量的最小对象是工作区（例如，你不能分配报表）。 通过按配置文件分隔客户，你可以获得不同的工作区（每个客户一个工作区）。 通过这种方式，你可完全灵活地根据每个客户的实际需求来管理他们，并通过纵向扩展或缩减来优化容量利用率。 例如，你可在单独的容量中管理具有大容量和高波动性的大型基本客户，以确保一致的服务水平，同时将小型客户分组到另一个容量中以优化成本。

  • 分隔工作区还意味着在租户之间分隔语义模型，以便数据模型可以位于较小区块中，而不是在单个大型语义模型中。 这些较小的模型能够更有效地管理内存使用。 为了维持良好的性能，对于长时间未使用的小型语义模型，可能会将其逐出。

购买容量时，需要考虑并行刷新的数量限制，因为有多个语义模型时，刷新进程可能需要额外的容量。

行级安全性

本文介绍了如何使用配置文件为每个客户创建单独的语义模型。 或者，ISV 应用程序可以将所有客户的数据存储在一个大型语义模型中，并使用行级安全 (RLS) 来保护每个客户的数据。 这种方法对于客户相对较少且语义模型为中小型的 ISV 来说很方便，因为：

  • 只需要维护一个报表和一个语义模型
  • 可以简化新客户的加入过程

但在使用 RLS 之前，请确保了解其限制。 所有客户的所有数据都存储在一个大型 Power BI 语义模型中。 此语义模型以单容量运行，具有自己的缩放和其他限制。

即使使用服务主体配置文件来分离客户的数据，仍然可以在单个客户的语义模型中使用 RLS 来让不同的组访问数据的不同部分。 例如，可使用 RLS 阻止一个部门的成员访问同一组织中另一个部门的数据。

注意事项和限制

  • 仅当使用 Analysis Services 客户端库版本 16.0.139.27 或更高版本时，才会通过 Power BI REST API、Power BI .NET SDK以及 XMLA 终结点和表格对象模型 (TOM) 支持服务主体配置文件。 Power BI 不支持通过 XMLA 终结点或带有较旧客户端库的表格对象模型 (TOM) 使用服务主体配置文件。
  • 实时连接模式下的 Azure Analysis Services (AAS) 不支持服务主体配置文件。
  • 单个服务主体可以拥有的最大配置文件数量为 100,000。

Power BI 容量限制

管理服务主体

更改服务主体

在 Power BI 中，配置文件属于创建它的服务主体。 这意味着，不能与其他主体共享配置文件。 由于此限制，如果你出于任何原因想要更改服务主体，则需要重新创建所有配置文件并提供对相关工作区的新配置文件访问权限。 通常，ISV 应用程序需要保存配置文件 ID 和客户 ID 之间的映射，以便在需要时选择正确的配置文件。 如果更改服务主体并重新创建配置文件，ID 也会更改，因此可能需要更新 ISV 应用程序数据库中的映射。

删除服务主体

警告

删除服务主体时要非常小心。 否则可能会意外丢失所有相关配置文件中的数据。

如果删除 Active Directory 中的服务主体，则该服务主体在 Power BI 中的所有配置文件都将被删除。 但 Power BI 不会立即删除内容，因此租户管理员仍然可以访问工作区。 删除生产系统中使用的服务主体时要小心，特别是使用此服务主体在 Power BI 中创建过配置文件的情况。 如果确实要删除已创建有配置文件的服务主体，请注意，你将需要重新创建所有配置文件，提供对相关工作区的新配置文件访问权限，并更新 ISV 应用程序数据库中的配置文件 ID。

数据分离

当数据由服务主体配置文件分隔时，配置文件和客户之间的简单映射会阻止一个客户看到另一个客户的内容。 使用单个服务主体要求服务主体有权访问所有配置文件中的所有不同工作区。

要添加额外的分隔，可为每个租户分配单独的服务主体，而不是让单个服务主体使用不同的配置文件访问多个工作区。 分配独立服务主体有多个优点，包括：

  • 人为错误或凭据泄漏不会导致多个租户的数据被公开。
  • 可为每个租户单独执行证书轮换。

但是，使用多个服务主体会产生高昂的管理成本。 因此，请仅需要额外分隔时才选择此路径。 请记住，显示最终用户的数据的配置是在生成嵌入令牌（这是一个仅后端进程，最终用户无法看到或更改）期间定义的。 如果使用特定于租户的配置文件请求嵌入令牌，则需要为该特定配置文件生成一个嵌入令牌，这将使你从使用上分离客户。

一个报表，多个语义模型

通常，每个租户都有一个报表和一个语义模型。 如果你有数百个报表，那么你将拥有数百个语义模型。 有时，你可能有一种报表格式，但有各种语义模型（例如，不同的参数或连接详细信息）。 每次有新版本的报表时，你都需要更新所有租户的所有报表。 虽然可自动执行此操作，但如果只有一个报表副本，那么管理起来会更容易。 创建包含待嵌入报表的工作区。 在会话运行时，将报表绑定到特定于租户的语义模型。 有关更多详细信息，请参阅动态绑定。

自定义和创作内容

创建内容时，请仔细考虑有权编辑该内容的用户。 如果允许每个租户中的多个用户进行编辑，则很容易超出语义模型限制。 如果你决定为用户提供编辑功能，请密切监视他们的内容生成，并根据需要进行纵向扩展。 出于相同原因，不建议将此功能用于内容个性化，那样每个用户都可以对报表稍作更改并将其保存为自己的报表。 如果 ISV 应用程序支持对内容进行个性化设置，请考虑针对用户特定内容引入工作区保留策略。 保留策略可让用户在调换到新职位、离开公司或停止使用平台时更轻松地删除内容。

系统托管标识

你可使用用户分配或系统分配的托管标识（而不是服务主体）来创建配置文件。 托管标识减少了对机密和证书的需求。

使用系统托管标识时要小心，因为：

  • 如果系统分配的托管标识意外关闭，你将无法访问配置文件。 这种情况类似于删除服务主体的情况。
  • 系统分配的托管标识连接到 Azure 中的资源（Web 应用）。 如果删除该资源，标识也将被删除。
  • 如果使用多个资源（不同地区的不同 Web 应用），则需要单独管理多个标识（每个标识都有自己的配置文件）。

由于上述注意事项，建议你使用用户分配的托管标识。

示例

如需如何使用服务主体配置文件通过 Power BI 和“应用拥有数据”嵌入来管理多租户环境的示例，请从 Power BI Dev Camp（第三方站点）下载“应用拥有数据”多租户存储库。

相关内容