Политика регулирования Fabric

Регулирование возникает, когда емкость клиента потребляет больше ресурсов емкости, чем она приобрела. Слишком много регулирования может привести к снижению производительности конечных пользователей. Клиент Fabric может создавать несколько емкостей и назначать рабочие области определенной емкости для выставления счетов и размера.

Регулирование применяется на уровне емкости, что означает, что хотя одна емкость или набор рабочих областей могут испытывать снижение производительности из-за перегрузки, другие емкости могут продолжать работать нормально. В случаях, когда такие функции, как артефакты OneLake, создаются в одной емкости и используются другой, регулирование состояния потребляемой емкости определяет, регулируются ли вызовы артефакта.

Баланс между производительностью и надежностью

Структура предназначена для обеспечения молниеносной производительности клиентам, позволяя операциям получать доступ к большему объему ресурсов CU (единиц емкости), чем выделено для емкости. Задачи, которые могут занять несколько минут, чтобы завершить работу на других платформах, можно всего за несколько секунд в Fabric. Чтобы избежать наказания пользователей при всплеске операционных загрузок, Структура сглаживает или среднее использование операции с накопительным пакетом обновления в течение не менее 5 минут и даже дольше для высокопроизводительных запросов cu, но коротких запросов во время выполнения. Это поведение гарантирует, что вы можете наслаждаться постоянно быстрой производительностью без регулирования.

Для фоновых операций, которые имеют длительные среды выполнения и потребляют тяжелые нагрузки cu, Fabric сглаживает использование cu в течение 24-часового периода. Сглаживание устраняет необходимость для специалистов по обработке и анализу данных и администраторов баз данных тратить время на создание расписаний заданий для распространения нагрузки cu в течение дня, чтобы предотвратить замораживание учетных записей. С 24-часовым сглаживание cu запланированные задания могут выполняться одновременно, не вызывая пиков в любое время в течение дня, и вы можете наслаждаться согласованно быстрой производительностью, не тратя время на управление расписаниями заданий.

Операции в полете не регулируются

Когда емкость входит в регулирование, она влияет только на операции, запрашиваемые после начала регулирования емкости. Все операции, включая длительные операции, отправленные до начала регулирования, могут выполняться до завершения. Это поведение гарантирует завершение операций даже во время всплесков cu.

Триггеры регулирования и этапы регулирования

После сглаживания некоторые учетные записи по-прежнему могут столкнуться с пиками использования cu во время пиковых отчетов. Чтобы помочь управлять этими пиками, администраторы могут настроить оповещения электронной почты, чтобы получать уведомления, когда емкость потребляет 100 % подготовленного накопительного пакета обновления. Этот шаблон означает, что емкость может воспользоваться балансировкой нагрузки, и администратор должен рассмотреть возможность увеличения размера SKU. Важно отметить, что для номеров SKU F можно вручную увеличивать и уменьшать их в любое время в параметрах администратора. Однако даже если емкость работает в полном потенциале cu, Fabric не применяет регулирование. Это гарантирует, что пользователи постоянно обеспечивают высокую производительность без каких-либо сбоев.

Первый этап регулирования начинается, когда емкость потребляет все доступные ресурсы CU в течение следующих 10 минут. Например, если вы приобрели 10 единиц cu, а затем потребляли 50 единиц в минуту, вы создадите перенос 40 единиц в минуту. Через две с половиной минуты вы бы накопили перенос из 100 единиц, заимствованных из будущих окон. На этом этапе, когда емкость уже исчерпала всю емкость в течение следующих 10 минут, Fabric инициирует свой первый уровень регулирования, и все новые интерактивные операции задерживаются на 20 секунд после отправки. Если перенос достигает полного часа, интерактивные запросы отклоняются, но фоновые запланированные операции продолжают выполняться. Если емкость накапливает полный 24 часа переноса вперед, все емкость заморожена до тех пор, пока не будет выплачена переноска.

Будущее сглаживание потребления

Примечание.

Корпорация Майкрософт пытается повысить гибкость клиентов в использовании службы, при этом балансируя потребность в управлении потреблением емкости клиента. По этой причине корпорация Майкрософт может изменить или обновить политику регулирования Fabric.

Использование Ограничения политики Влияние на взаимодействие с политикой платформы
Использование <= 10 минут Защита от перебора Задания могут использовать 10 минут использования емкости в будущем без регулирования.
10 минут < использования <= 60 минут Интерактивная задержка Запрашиваемые пользователем интерактивные задания задерживаются на 20 секунд при отправке.
60 минут < использования <= 24 часа Интерактивное отклонение Запрашиваемые пользователем интерактивные задания отклоняются.
Использование > 24 часа Фоновое отклонение Все запросы отклоняются.

Сокращение использования емкости

В любой момент, когда емкость неактивна, система оплачивает уровни перенаправки.

Если у вас есть 100 минут CU и перенос на 200 минут CU, и у вас нет операций, это займет две минуты, чтобы вы окупить свой перенос вперед. В этом примере система не регулируется, так как есть 2 минуты переноса вперед. Задержки регулирования не начнутся до 10 минут переноса вперед.

Если вам нужно быстрее платить за перенос, вы можете временно увеличить размер номера SKU, чтобы создать больше простой емкости, которая применяется к вашему переносу.

Поведение регулирования зависит от Структуры

Хотя большинство продуктов Fabric следуют ранее упоминание правилам регулирования, существуют некоторые исключения.

Например, потоки событий Fabric имеют множество операций, которые могут выполняться в течение многих лет после запуска. Регулирование новых операций потока событий не имеет смысла, поэтому вместо этого объем накопительного пакета обновления, выделенного для поддержания открытого потока, уменьшается до тех пор, пока емкость не будет в хорошем положении.

Другим исключением является аналитика в режиме реального времени, которая не будет в режиме реального времени, если операции были отложены на 20 секунд. В результате аналитика в режиме реального времени игнорирует первый этап регулирования с 20-секундной задержкой в 10 минут переноса вперед и ожидает, пока этап отклонения на 60 минут перенесите, чтобы начать регулирование. Такое поведение гарантирует, что пользователи могут продолжать пользоваться производительностью в режиме реального времени даже в периоды высокого спроса.

Аналогичным образом, почти все операции в категории хранилища сообщаются в качестве фона , чтобы воспользоваться преимуществами 24-часового сглаживания действий, чтобы обеспечить наиболее гибкие шаблоны использования. Классификация всех хранилищ данных в качестве фона предотвращает пики использования cu от активации регулирования слишком быстро. Некоторые запросы могут активировать строку операций, которые регулируются по-разному. Это может сделать фоновую операцию подверженной регулированию в виде интерактивной операции.

Интерактивные и фоновые классификации для регулирования и сглаживания

Некоторые администраторы могут заметить, что операции иногда классифицируются как интерактивные и сглаживаются как фоновые или наоборот. Это различие происходит из-за того, что системы регулирования Структуры должны применять правила регулирования перед началом выполнения запроса. Сглаживание происходит после запуска задания и измерения потребления cu.

Системы регулирования пытаются точно классифицировать операции при отправке, но иногда классификация операций может измениться после применения регулирования. Когда операция начнет выполняться, более подробные сведения о запросе становятся доступными. В неоднозначных сценариях регулирование систем пытается отрегулировать на стороне классифицирования операций как фон, который находится в интересах пользователя.

Отслеживание отклоненных операций

Детализация приложения метрик емкости Microsoft Fabric позволяет администраторам видеть операции, отклоненные во время события регулирования. Существует ограниченная информация об этих операциях, так как они никогда не были разрешены начать. Администратор может просмотреть продукт, пользователь, идентификатор операции и время отправки запроса. Конечные пользователи получают сообщение об ошибке при отклонении запроса, которое просит их повторить попытку позже.