通过

评估和优化 Microsoft Fabric 容量

本文介绍如何评估和优化 Microsoft Fabric 容量的负载。 此外，本文还介绍解决重载情况的策略，并为你提供指南，帮助你优化每个 Fabric 体验的计算。

虽然 Fabric 容量模型可以简化设置，但有很可能会消耗容量的共享计算资源。 也有可能是你为不必要的更多资源付钱。 当某些 Fabric 体验的设计不遵循最佳做法时，可能会出现上述情况。

一定要降低消耗共享资源的风险。作为一款托管服务，Fabric 会采用两种方法来解决此类情况。

  • 突发和平滑可确保在不需要更高 SKU 的情况下，快速完成 CPU 密集型活动（可在当天的任何时间运行）。
  • 当容量遇到限制且 CPU 需求高（于 SKU 上限）时，会出现限制延迟或拒绝操作。

平滑可减少发生限制的可能性（虽然仍然会发生限制）。 虽然平滑是根据限制如何分配使用情况，但独立于作业执行。 平滑不会改变性能，只是将消耗的计算计帐分布到更长时间段内，这样就不需要更大的 SKU 来处理峰值计算。

若要了解有关 Fabric 容量的详细信息，请参阅 Microsoft Fabric 概念和许可证以及 Fabric 容量 - 需要了解的一切，了解新增功能和即将推出的内容。

规划和预算工具

规划容量大小并非易事。 这是因为，需要的计算量会由于执行的操作、如何执行操作（例如，DAX 查询或 Python 代码在笔记本中的效率），或并发水平等因素而千差万别。

为了帮助确定合适的容量大小，可以预配试用版容量或即用即付 F SKU，在购买 F SKU 预留实例之前度量所需的实际容量大小。

提示

一个不错的策略是：先从小容量开始，然后再根据需要逐渐增加容量大小。

监视容量

应监视利用率以充分利用容量。 一定要了解 Fabric 操作是交互式操作还是后台操作。 例如，Power BI 报表中的 DAX 查询是按需请求的交互式操作，而语义模型刷新则是后台操作。 有关操作及其如何使用 Fabric 中的资源的详细信息，请参阅 Fabric 操作。

监视可让你了解正在发生的限制。 当有很多交互式操作或者长时间运行交互式操作时，就会发生限制。 通常，与 SQL 和 Spark 体验相关的后台操作都很平滑，即会分布在 24 小时时间段内。

Fabric 容量指标应用是监视和可视化最近利用率的最佳方式。 该应用可细分项类型（语义模型、笔记本、管道和其他），并能帮助识别使用大量计算的项或操作（以便对其进行优化）。

管理员可以使用管理员监视工作区了解常用项（以及整体采用）。 还可以使用监视中心查看租户中当前和最近的活动。 也可以通过日志分析或本地数据网关日志了解一些操作的详细信息。

管理高计算使用率

当容量利用率高并开始显现限制或拒绝时，可使用以下三种策略解决此问题：优化、纵向扩展和横向扩展。

不错的做法是设置通过，了解何时容量利用率超过设置的阈值。 此外，请考虑使用特定于工作负载的设置限制操作的大小（例如，Power BI 查询超时限制或 Spark 工作区设置）。

优化

内容创作者应该始终优化 Fabric 项的设计，以确保其高效并使用最可能少的计算资源。 本文后面提供针对每个 Fabric 体验的特定指南。

纵向扩展

纵向扩展容量是指临时或永久增加 SKU 大小（拥有更多计算容量）。 纵向扩展可确保容量上的所有项都有足够多的计算资源可以使用，以避免发生限制。

还可以根据消耗模式调整大小、暂停和继续 Fabric F SKU。

横向扩展

横向扩展是指将一部分工作区或项迁移到其他 Fabric 容量来分散工作负载。 当需要不同的容量策略、设置或管理员时，这是一个不错的选项。 此外，预配多个容量也是不错的策略，有助于高优先级项，以及自助服务或开发内容的隔离计算。 例如，企业高管层需要反应敏捷的报表和仪表板。 这些报表和仪表板可驻留在专为高管报表使用的单独的容量。

还可以考虑将 Power BI 工作区迁移到共享容量，仅当消费者具有让其可继续访问内容的 Power BI Pro 许可证。

配置激增保护

激增保护 通过限制计算后台作业消耗总量来帮助限制过度使用容量。 这减少了总计算，因此交互式延迟或拒绝的可能性较低。 如果出现一段时间的限流或拒绝，它还能帮助容量更快地恢复。 为每个容量配置浪涌保护。 激增保护有助于防止限流和拒绝，但不能替代容量优化、纵向扩展和横向扩展。

当激增保护处于活动状态时，将拒绝后台作业。 这意味着即使启用了激增保护，容量也会受到影响。 通过使用浪涌保护，你可以优化容量，以保持在使用量的适当范围内，从而优化计算需求与容量之间的平衡。 为了完全保护关键解决方案，建议将它们隔离在适当大小的容量中。

按 Fabric 体验进行计算优化

Fabric 中的体验和项的工作方式不同，因此不一定以相同方式对其进行优化。 本部分根据经验列出 Fabric 项，以及可以执行哪些优化操作。

Fabric Data Warehouse

数据仓库使用无服务器体系结构，其节点由服务自动管理。 容量使用情况是根据活动每查询容量单位秒计算的，而不是预配前端和后端节点的时间量。

所有数据仓库操作都是后台操作，并在 24 小时内顺利进行。

SQL 分析终结点旨在提供性能默认体验。 为此，与 SQL Server 或 Azure Synapse Analytics 专用 SQL 池相比，可用的查询优化选项更少。

优化最小计算时，应考虑到以下几点。

  • 尽可能使用最佳的 T-SQL 编写查询。 情况允许时，请限制可能增加查询资源使用量的列数、计算、聚合和其他操作数。
  • 设计表要尽可能使用最小的数据类型。 选择的数据类型会严重影响 SQL 引擎生成的查询计划。 例如，将 VARCHAR 字段的长度从 500 缩减到 25，或是将 DECIMAL(32, 8) 更改为 DECIMAL(10, 2) 会导致分配给某查询的资源大幅减少。
  • 使用星型架构设计可减少行读取次数，最大限制减少查询加入。
  • 确保统计信息存在并且是最新的。 统计信息在生成最佳执行计划方面发挥着重要作用。 虽然是在运行时自动创建的，但可能需要手动更新，尤其是在加载或更新数据之后。 请考虑使用 FULLSCAN 选项而不是依赖于自动生成的使用采样的统计信息来创建统计信息。
  • 使用内置视图监视查询和使用情况，尤其是在排查问题时。
    • sys.dm_exec_requests 动态管理视图 (DMV) 提供关于所有正在执行的查询的相关信息，但并不存储任何历史信息。 Fabric 工具箱提供使用此 DMV 的查询，并通过加入其他视图来提供查询文本等详细信息，使查询结果易于使用。
    • 查询见解是 Fabric 数据仓库的一项功能，可提供 SQL 分析终结点上历史查询活动的整体视图。 具体而言，queryinsights.exec_requests_history 视图提供与每个完整 SQL 请求相关的信息。 它可呈现可与容量指标应用中找到的操作 ID 进行关联的每个查询执行的所有相关详细信息。 用于监视容量使用情况的最重要的列包括：distributed_statement_id、command (query text)、start_time 和 end_time。

Fabric 数据工程和 Fabric 数据科学

数据工程师和数据科学体验使用 Spark 计算在 Fabric Lakehouse 中处理、分析和存储数据。 Spark 计算按 vCore 进行设置和度量。 但是，Fabric 使用 OU 作为各种项使用的计算的度量值，包括 Spark 笔记本、Spark 作业定义和 Lakehouse 作业。

在 Spark 中，一个 CU 转换为两个 spark vCore 计算。 例如，当客户购买 F64 SKU 时，其 Spark 体验可以使用 128 个 Spark v-core。

所有 Spark 操作都是后台操作，并在 24 小时内顺利进行。

有关详细信息，请参阅 Fabric Spark 中的计费和利用率报告。

优化最小计算时，应考虑到以下几点。

  • 始终努力编写高效的 Spark 代码。 有关详细信息，请参阅 Azure Synapse Analytics 中的优化 Apache Spark 作业，以及 优化 Apache Spark 上的写入需求。
  • 为 Spark 作业保留所需执行程序，以释放资源供其他 Spark 作业或工作负载使用。 否则会增加 Spark 作业失败，出现 HTTP 430 状态的机率，即容量要处理的请求数量过多。 可以在 Fabric 监视中心查看分配给笔记本的执行程序数量，还可以在这里确定笔记本要使用的执行程序的实际数量。 Spark 作业仅保留所需节点，并允许在 SKU 限制内并行提交。
  • Spark 池只能配置为使用 SKU 支持的最大 vCore 数。 但是，可以通过在 SKU 限制内接受并行 Spark 作业来横向扩展数据工程工作负载。 此方法称为“突发因素”，在容量级别默认为 Spark 工作负载启用。 有关详细信息，请参阅并发限制和队列。
  • 活动 Spark 会话会在容量上累积 CU 利用率。 因此，在不使用时一定要停止活动的 Spark 会话。 请注意：此默认 Spark 会话过期时间设置为 20 分钟。 用户可以更改笔记本或 Spark 作业定义中的会话超时。

实时智能

根据数据库处于活动状态的秒数以及使用的 vCore 数量来计算 KQL 数据库 CU 消耗。 例如，如果数据库在 10 分钟内处于活动状态，并且使用了 4 个 vCore，则将会消耗 2,400 (4 x 10 x 60) 秒的 CU。

所有 KQL 数据库操作都是交互式操作。

自动缩放机制用于确定 KQL 数据库的大小。 可确保根据使用模式实现成本优化和最佳性能。

为了让数据可供其他 Fabric 引擎使用，KQL 数据库与 OneLake 同步。 根据 KQL 数据库执行的读取和写入事务数，从容量利用 OU。 它利用 OneLake 读取和写入计量，相当于在 Azure Data Lake Storage (ADLS) Gen2 帐户上读取和写入操作。

数据工厂

本部分介绍数据工厂中数据流和数据管道的优化。

所有操作都是后台操作，并在 24 小时内顺利进行。

优化最小计算时，应考虑到以下几点。

  • 避免低效的 Power Query 逻辑来最小化和优化昂贵的数据转换，例如合并和排序。
  • 尽量实现查询折叠。 它可以通过减少需要在数据源和目标之间传输的数据量来提高数据流的性能。 如果不实现查询折叠，Power Query 会检索数据源中的所有数据并在本地执行转换，此过程效率低下且速度缓慢。
  • 使用小型数据卷和/或执行简单转换时禁用过渡。 某些情况下可能需要过渡，例如加载 Data Warehouse 时。
  • 避免比数据源更频繁地刷新数据。 例如，如果数据源每 24 小时仅更新一次，则每小时刷新数据不会再提供任何值。 相反，请考虑以适当频率刷新数据，确保数据准确且是最新的。

Power BI

Power BI 操作要么属于交互式操作，要么属于后台操作。

以下交互式操作通常会导致计算使用率高。

  • 不遵循最佳做法的语义模型。 例如，它们可能不采用具有一对多关系的星型架构设计。 或者可能包括复杂且昂贵的行级别安全性 (RLS) 筛选器。 请考虑使用表格编辑器和最佳做法分析器来确定是否遵循最佳做法。
  • DAX 度量值效率低下。
  • 报表页包含过多的视觉对象，这可能会导致视觉对象刷新缓慢。
  • 报表视觉对象显示高基数结果（行或列数量过多），或是包含过多度量。
  • 容量出现高并发，因为用户数量过多，容量大小无法应对。 请考虑启用查询横向扩展以提升高并发语义模型的用户体验（但不会导致总计计算增加）。

以下后台操作通常会导致计算使用率高。

  • Power Query 逻辑中效率低下或过于复杂的数据转换。
  • 大型事实数据表缺少查询折叠或增量刷新。
  • 报表突发，即同时生成大量 Power BI 报表或分页报表。

相关内容

更多问题？ 尝试咨询 Fabric 社区。