Fabric 限制策略

  • 项目

当租户的容量消耗比购买的容量资源更多时，就会发生限制。 过多限制可能会导致最终用户体验下降。 Fabric 租户可以创建多个容量，并将工作区分配给特定容量以进行计费和大小调整。

限制在容量级别应用，这意味着，尽管一个容量或一组工作区可能会因过载而降低性能，但其他容量可能会正常运行。 如果 OneLake 项目等功能在一个容量中产生并被另一个容量消耗，则消耗容量的限制状态决定了对项目的调用是否受到限制。

性能和可靠性之间的平衡

Fabric 旨在通过允许操作访问比分配给容量更多的 CU（容量单位）资源来为客户提供闪电般的性能。 在其他平台上可能需要几分钟才能完成的任务在 Fabric 上只需几秒钟即可完成。 为了避免在操作负载激增时惩罚用户，Fabric 在至少 5 分钟内平滑或平均操作的 CU 使用量，对于 CU 较高但运行时间较短的请求，甚至更长。 此行为可确保在不遇到限制的情况下获得一致的快速性能。

对于运行时间长且消耗大量 CU 负载的后台操作，Fabric 会在 24 小时内平滑其 CU 使用量。 有了平滑，数据科学家和数据库管理员不需要花时间创建作业计划来在一天中分散 CU 负载，以便防止帐户冻结。 通过 24 小时的 CU 平滑处理，计划作业都可以同时运行，而不会在一天中的任何时间造成任何峰值，并且你可以享受一致的快速性能，而无需浪费时间管理作业计划。

未限制正在进行的操作

当容量进入限制状态时，它只会影响容量开始限制后请求的操作。 允许所有操作（包括在限制开始之前提交的长时间运行的操作）运行直至完成。 此行为保证即使在 CU 激增期间，操作也已完成。

限制触发器和限制阶段

平滑处理后，某些帐户在高峰报告时间可能仍会出现 CU 使用量激增的情况。 为了帮助管理这些高峰，管理员可以设置电子邮件警报，以在容量消耗其预配 CU 的 100% 时收到通知。 此模式表明容量可能受益于负载均衡，管理员应考虑增加 SKU 大小。 请务必注意，对于 F SKU，可以随时在管理员设置中手动增加和减少它们。 但是，即使某个容量在充分发挥 CU 潜力的情况下运行，Fabric 也不会应用限制。 这可确保用户始终保持快速性能，而不会遇到任何中断。

当容量在接下来的 10 分钟内消耗其所有可用 CU 资源时，将开始第一阶段的限制。 例如，如果购买了 10 个 CU 单位，然后每分钟消耗 50 个单位，则会创建每分钟 40 个单位的结转。 两分半钟后，你将累积 100 个单位的结转（从未来的时段借来）。 此时，如果容量在接下来的 10 分钟内已经耗尽了所有容量，Fabric 将启动其第一级限制，所有新的交互式操作在提交后将延迟 20 秒。 如果结转达到一个完整的小时，则交互请求将被拒绝，但后台计划的操作将继续运行。 如果容量累积了整整 24 小时的结转，则整个容量将被冻结，直到结转付清。

未来的平滑消耗

注意

Microsoft 尝试提高客户使用服务的灵活性，同时平衡管理客户容量使用率的需求。 因此，Microsoft 可能会更改或更新 Fabric 限制策略。

使用情况 策略限制 平台策略体验影响
使用 <= 10 分钟 超额保护 作业可以消耗 10 分钟的未来容量使用，而无需限制。
10 分钟 < 使用 <= 60 分钟 交互式延迟 提交时，用户请求的交互式作业延迟 20 秒。
60 分钟 < 使用 <= 24 小时 交互式拒绝 用户请求的交互式作业被拒绝。
使用 > 24 小时 后台拒绝 所有请求均被拒绝。

结转容量使用减少

每当容量具有空闲容量时，系统会即时交付结转水平。

如果你有 100 CU 分钟以及 200 CU 分钟结转，并且没有任何正在运行的操作，则需要两分钟才能还清结转。 在此示例中，系统不受限制，因为有 2 分钟的结转。 直到结转 10 分钟，限制延迟才会开始。

如果需要更快地支付结转，则可以暂时增加 SKU 大小，以生成应用于结转的更多空闲容量。

限制行为特定于 Fabric

虽然大多数 Fabric 产品遵循前面提到的限制规则，但有一些例外。

例如，Fabric 事件流有许多操作可以在启动后运行数年。 限制新的事件流操作是没有意义的，因此，分配给保持流打开的 CU 数量会减少，直到容量再次处于良好状态。

另一个例外是实时分析，如果操作延迟 20 秒，它就不会是实时的。 因此，实时分析忽略了在 10 分钟结转时延迟 20秒 的第一阶段限制，并等待直到 60 分钟结转的拒绝阶段才开始限制。 此行为可确保用户即使在高需求期间也能继续享受实时性能。

同样，仓库类别中的几乎所有操作都会被报告为后台，以利用 24 小时的活动平滑，从而实现最灵活的使用模式。 将所有数据仓库分类为“后台”可防止 CU 利用率峰值太快触发限制。 某些请求可能会触发以不同方式限制的操作字符串。 这可能会使后台操作作为交互式操作受到限制。

用于限制和平滑的交互式和后台分类

一些管理员可能会注意到，操作有时归类为交互式操作，并作为后台平滑处理，反之亦然。 之所以发生这种区别，是因为 Fabric 的限制系统必须在请求开始运行之前应用限制规则。 在作业开始运行并且可以测量 CU 消耗之后，将进行平滑处理。

限制系统尝试在提交时准确对操作进行分类，但有时应用限制后，操作的分类可能会更改。 当操作开始运行时，有关请求的更多详细信息将变为可用。 在模棱两可的情况下，限制系统试图将操作分类为后台，这符合用户的最大利益。

跟踪拒绝的操作

Microsoft Fabric 容量指标应用向下钻取允许管理员查看在限制事件期间被拒绝的操作。 有关这些操作的信息有限，因为它们从未被允许启动。 管理员可以查看提交请求的产品、用户、操作 ID 和时间。 当请求被拒绝时，最终用户会收到一条错误消息，要求他们稍后再试。

相关内容