本文介绍如何评估和优化 Microsoft Fabric 容量的负载。 此外，本文还介绍解决负载过重情况的策略，并为你提供指南，帮助你优化每个 Fabric 体验的计算资源。
虽然 Fabric 容量模型可以简化设置并促进协作，但有可能会耗尽容量的共享计算资源。 也有可能是你为不必要的更多资源付钱。 当某些 Fabric 体验的设计不遵循最佳做法时，可能会出现上述情况。
一定要降低消耗共享资源的风险。作为一款托管服务，Fabric 会采用两种方法来解决此类情况。
平滑可减少发生限流的可能性（虽然限流依然会发生）。 平滑是一个在限制范围内分配使用情况的过程，并且独立于作业的执行。 平滑处理不会改变性能，只是将用来计帐的计算能力消耗分摊到更长的时间段内，这样就不需要更大规格的 SKU 来应对峰值计算。
若要了解有关 Fabric 容量的详细信息，请参阅 Microsoft Fabric 概念和许可证和 Fabric 容量——您需要了解的新增功能和即将推出的全部内容。
规划和预算工具
规划容量大小并非易事。 这是因为所需的计算因执行的操作、执行的方式（例如 DAX 查询的效率或笔记本中的 Python 代码的效率）以及并发程度而异。
为了帮助确定合适的容量大小，可以预配试用版容量或即用即付 F SKU，在购买 F SKU 预留实例之前度量所需的实际容量大小。
提示
一个不错的策略是：先从小容量开始，然后再根据需要逐渐增加容量大小。
监控容量
应监视利用率以充分利用容量。 首先，重要的是要了解 Fabric 操作是交互式操作还是后台操作。 例如，来自 Power BI 报表的 DAX 查询是按需交互式操作请求，而语义模型刷新是后台操作。 有关操作及其如何使用 Fabric 中的资源的详细信息，请参阅 Fabric 操作。
监视可以让你了解到正在发生的限流。 当存在众多或运行时间较长的交互式操作时，可能会发生节流。 通常，与 SQL 和 Spark 体验相关的后台操作都很平滑，即会分布在 24 小时时间段内。
Fabric 容量指标应用是监视和可视化最近利用率的最佳方式。 该应用可细分项类型（语义模型、笔记本、管道和其他），并能帮助识别使用大量计算的项或操作（以便对其进行优化）。
管理员可以使用管理员监视工作区以此来了解常用项（以及整体采用）。 还可以使用监视中心查看租户中当前和最近的活动。 还可以从 Log Analytics 或 本地数据网关日志 获取有关某些操作的更多信息。
管理高计算使用率
当容量被高度利用并开始显现限速或拒绝时，可使用以下三种策略来解决：优化、扩容和横向扩展。
良好的做法是设置通知，以便了解何时容量利用率超过设定的阈值。 此外，请考虑使用特定于工作负荷的设置来限制作的大小（例如，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 数据库执行的读取和写入事务数，从容量中利用 CUs。 它利用 OneLake 读取和写入计费，这相当于对 Azure Data Lake Storage（ADLS）Gen2 帐户执行读取和写入操作。
数据工厂
所有操作都是后台操作，并在 24 小时内顺利进行。
优化最小计算时，应考虑到以下几点。
- 避免效率低下Power Query逻辑，以最大程度地减少和优化昂贵的数据转换，例如合并和排序。
- 力争在可能的情况下实现查询折叠。 它可以通过减少需要在数据源和目标之间传输的数据量来提高数据流的性能。 当查询折叠未发生时，Power Query从数据源检索所有数据，并在本地执行转换，这可能效率低下且速度缓慢。
- 使用小型数据卷和/或执行简单转换时禁用分阶段处理。 在某些情况下可能需要进行过渡，例如加载数据仓库时。
- 避免进行超过数据源需求频率的数据刷新。 例如，如果数据源每 24 小时仅更新一次，则每小时刷新数据不会再提供任何值。 相反，请考虑以适当频率刷新数据，确保数据准确且是最新的。
Power BI
Power BI操作要么是交互式的，要么是后台的。
以下交互式操作通常会导致计算使用率高。
- 不遵循最佳做法的语义模型。 例如，它们可能不采用具有一对多关系的星型架构设计。 或者可能包括复杂且昂贵的行级安全筛选器 (RLS)。 请考虑使用表格编辑器和最佳做法分析器来确定是否遵循最佳做法。
- DAX 度量值效率低下。
- 报表页包含过多的视觉对象，这可能会导致视觉对象刷新缓慢。
- 报表视觉对象显示高基数结果（行或列数量过多），或是包含过多度量。
- 容量因太多用户而导致高并发，容量大小不足以应对这种情况。 请考虑启用查询横向扩展以提升高并发语义模型的用户体验（但不会导致总计计算增加）。
以下后台操作通常会导致计算使用率高。
- Power Query逻辑中数据转换效率低下或过于复杂。
- 大型事实数据表缺少查询折叠或增量刷新。
- 报表突发是指同时生成大量 Power BI 报表或分页报表。
相关内容
更多问题？ 尝试咨询 Fabric 社区。