Поделиться через

Оценка и оптимизация емкости Microsoft Fabric

  • Статья

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

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

Важно уменьшить риск истощения общих ресурсов, Fabric в качестве управляемой службы— автоматически решает такие ситуации двумя способами.

  • Ускорение и сглаживание гарантирует, что интенсивное использование ЦП выполняется быстро, не требуя более высокого номера SKU (и может выполняться в любое время суток).
  • Регулирование задержек или отклонений операций, когда емкость поддерживает устойчивый и высокий спрос на ЦП (выше ограничения SKU).

Сглаживание снижает вероятность регулирования (хотя регулирование по-прежнему может произойти). Сглаживание заключается в том, как использование выделяется по ограничениям, но оно не зависит от выполнения заданий. Сглаживание не изменяет производительность, она просто распределяет учет потребляемых вычислений за более длительный период, поэтому для обработки пиковых вычислений не требуется больше SKU.

Дополнительные сведения о емкости Fabric см. в разделе "Основные понятия и лицензии Microsoft Fabric" и "Емкости Fabric" — все, что вам нужно знать о новых возможностях и новых возможностях.

Средства планирования и бюджетирования

Планирование размера емкости может быть проблемой. Это связано с тем, что необходимые вычислительные ресурсы могут значительно отличаться из-за выполняемых операций, их правильности (например, эффективности запроса DAX или кода Python в записной книжке) или уровня параллелизма.

Чтобы определить правильный размер емкости, можно подготовить пробные емкости или номера SKU по мере использования для измерения фактического размера емкости, необходимого перед покупкой зарезервированного экземпляра SKU F.

Совет

Это всегда хорошая стратегия, чтобы начать небольшое, а затем постепенно увеличить размер емкости по мере необходимости.

Мониторинг емкостей

Необходимо отслеживать использование, чтобы получить большую часть емкости. В первую очередь важно понимать, что операции Fabric являются интерактивными или фоновыми. Например, запросы DAX из отчета Power BI представляют собой запросы по запросу, которые являются интерактивными операциями, а обновления семантической модели — фоновые операции. Дополнительные сведения об операциях и способах использования ресурсов в Fabric см. в разделе "Операции Fabric".

Мониторинг может показать вам, что регулирование происходит. Регулирование может произойти, если существуют многочисленные или длительные интерактивные операции. Как правило, фоновые операции, связанные с интерфейсом SQL и Spark, сглаживаются, то есть они распределяются в течение 24-часового периода.

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

Администраторы могут использовать рабочую область мониторинга администратора, чтобы узнать о часто используемых элементах (и общем внедрении). Они также могут использовать центр мониторинга для просмотра текущих и недавних действий в клиенте. Дополнительные сведения о некоторых операциях также могут быть доступны из Log Analytics или журналов локального шлюза данных.

Управление высоким уровнем использования вычислительных ресурсов

Когда емкость очень используется и начинает отображать регулирование или отклонение, существует три стратегии для ее устранения: оптимизация, масштабирование и горизонтальное масштабирование.

Рекомендуется настроить уведомления, чтобы узнать, когда использование емкости превышает заданное пороговое значение. Кроме того, рекомендуется использовать параметры, относящиеся к рабочей нагрузке, чтобы ограничить размер операций (например, ограничения времени ожидания запросов Power BI или ограничения строк или параметры рабочей области Spark).

Оптимизация

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

Увеличение масштаба

Вы масштабируйте емкость, чтобы временно или постоянно увеличить размер номера SKU (с большей вычислительной емкостью). Масштабирование гарантирует наличие достаточных вычислительных ресурсов для всех элементов емкости и предотвращения регулирования.

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

Горизонтальное увеличение масштаба

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

Вы также можете перенести рабочие области Power BI в общую емкость, если у потребителей есть лицензии Power BI Pro , которые позволяют им продолжать доступ к содержимому.

Настройка защиты от всплесков

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

Если защита от всплеска активна, фоновые задания отклоняются. Это означает, что есть влияние на вашу емкость даже при включенной защите от перенапряжений. Используя защиту от всплесков, вы настраиваете емкость, чтобы оставаться в пределах диапазона использования, который лучше всего балансирует потребности в вычислительных ресурсах в пределах емкости. Чтобы полностью защитить критически важные решения, рекомендуется изолировать их в правильной емкости.

Оптимизация вычислений по интерфейсу Fabric

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

Хранилище данных Fabric

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

Все операции хранилища данных являются фоновыми операциями, и они сглаживаются в течение 24-часового периода.

Конечная точка аналитики SQL предназначена для обеспечения производительности по умолчанию . Для этого по сравнению с SQL Server или выделенными пулами SQL Server или Azure Synapse Analytics доступны меньше параметров настройки запросов.

Ниже приведены некоторые моменты, которые помогут свести к минимуму вычислительные ресурсы.

  • Напишите запросы с помощью наиболее оптимальной возможности T-SQL. По возможности ограничьте количество столбцов, вычислений, агрегатов и других операций, которые могут ненужно увеличить использование ресурсов запросов.
  • Создайте таблицы для использования наименьших типов данных. Выбор типа данных может сильно повлиять на планы запросов, созданные подсистемой SQL. Например, уменьшение VARCHAR длины поля от 500 до 25 или изменение DECIMAL(32, 8)DECIMAL(10, 2) может привести к значительному сокращению ресурсов, выделенных для запроса.
  • Используйте схему звездочки, чтобы уменьшить количество строк, считываемых и свести к минимуму соединения запросов.
  • Убедитесь, что статистика существует и что они актуальны. Статистика играет важную роль в создании наиболее оптимального плана выполнения. Они создаются автоматически во время выполнения, но может потребоваться вручную обновить их, особенно после загрузки или обновления данных. Рекомендуется создавать статистику с помощью FULLSCAN параметра, а не полагаться на автоматически созданную статистику, которая использует выборку.
  • Используйте встроенные представления для мониторинга запросов и использования, особенно при устранении неполадок.
    • В sys.dm_exec_requests динамическом административном представлении (DMV) содержатся сведения обо всех активно выполняемых запросах, но они не хранят историческую информацию. Панель элементов Fabric предоставляет запрос, который использует это динамическое административное представление и делает результат запроса понятным, присоединяясь к другим представлениям для предоставления сведений, таких как текст запроса.
    • Аналитика запросов, которая является функцией хранения данных Fabric, предоставляет целостное представление об активности исторических запросов в конечной точке аналитики SQL. В частности, в представлении queryinsights.exec_requests_history содержатся сведения о каждом полном SQL-запросе. В нем представлены все соответствующие сведения для каждого выполнения запроса, которые можно сопоставить с идентификаторами операций, найденными в приложении метрик емкости. Наиболее важными столбцами для мониторинга использования емкости являются: distributed_statement_id, команда (текст запроса), start_time и end_time.

Инжиниринг данных Fabric и Fabric Обработка и анализ данных

Интерфейсы Инжиниринг данных и Обработка и анализ данных используют вычисления Spark для обработки, анализа и хранения данных в lakehouse Fabric. Вычисления Spark настраиваются и измеряются с точки зрения виртуальных ядер. Однако Fabric использует ЦС в качестве меры вычислений, потребляемых различными элементами, включая записные книжки Spark, определения заданий Spark и задания Lakehouse.

В Spark один накопительный пакет обновления преобразуется в два виртуальных ядра spark вычислений. Например, когда клиент приобретает номер SKU F64, 128 spark v-core доступны для возможностей Spark.

Все операции Spark — это фоновые операции, и они сглаживаются в течение 24-часового периода.

Дополнительные сведения см. в отчетах о выставлении счетов и использовании в Fabric Spark.

Ниже приведены некоторые моменты, которые помогут свести к минимуму вычислительные ресурсы.

  • Всегда старайтесь писать эффективный код Spark. Дополнительные сведения см. в статье Оптимизация заданий Apache Spark в Azure Synapse Analytics и необходимость оптимизации записи в Apache Spark.
  • Зарезервируйте необходимых исполнителей для заданий Spark, чтобы освободить ресурсы для других заданий Spark или рабочих нагрузок. В противном случае вы увеличиваете вероятность сбоя заданий Spark с состоянием HTTP 430, что означает слишком много запросов для емкости. Вы можете просмотреть количество исполнителей, выделенных записной книжке в центре мониторинга Fabric, где можно также определить фактическое количество исполнителей, используемых записной книжкой. Задания Spark резервирует только необходимые узлы и разрешают параллельные отправки в пределах SKU.
  • Пул Spark можно настроить только для использования максимального количества виртуальных ядер, поддерживаемых номером SKU. Однако вы можете масштабировать рабочие нагрузки инженерии данных, принимая параллельные задания Spark в пределах SKU. Этот подход обычно называется коэффициентом ускорения и включен по умолчанию для рабочих нагрузок Spark на уровне емкости. Дополнительные сведения см. в разделе регулирование параллелизма и очереди.
  • Активные сеансы Spark могут начислять использование cu в емкости. По этой причине важно остановить активные сеансы Spark, если они не используются. Обратите внимание, что срок действия сеанса Spark по умолчанию имеет значение 20 минут. Пользователи могут изменить время ожидания сеанса в записной книжке или определении задания Spark.

Аналитика в режиме реального времени

Использование cu базы данных KQL вычисляется на основе количества секунд, в течение которых база данных активна, и количество используемых виртуальных ядер. Например, если база данных использует четыре виртуальных ядра и активна в течение 10 минут, вы будете использовать 2400 (4 x 10 x 60) в cu.

Все операции базы данных KQL являются интерактивными операциями.

Для определения размера базы данных KQL используется механизм автомасштабирования. Это гарантирует, что наиболее оптимизированная для затрат и оптимальная производительность достигается на основе шаблонов использования.

Чтобы разрешить доступ к данным другим ядрам Fabric, база данных KQL синхронизируется с OneLake. В зависимости от количества операций чтения и записи, выполняемых базой данных KQL, используются из емкости. Он использует счетчики чтения и записи OneLake, которые эквивалентны операциям чтения и записи в учетных записях Azure Data Lake Storage (ADLS) 2-го поколения.

Фабрика данных

В этом разделе описывается оптимизация потоков данных и конвейеров данных в фабрике данных.

Все операции являются фоновыми операциями, и они сглаживаются в течение 24-часового периода.

Ниже приведены некоторые моменты, которые помогут свести к минимуму вычислительные ресурсы.

  • Избегайте неэффективной логики Power Query для минимизации и оптимизации дорогостоящих преобразований данных, таких как слияние и сортировка.
  • По возможности старайтесь добиться свертывания запросов. Это может повысить производительность потоков данных, уменьшая объем данных, которые необходимо передать между источником данных и назначением. Если свертывание запросов не происходит, Power Query извлекает все данные из источника данных и выполняет преобразования локально, что может быть неэффективным и медленным.
  • Отключите промежуточное выполнение при работе с небольшими томами данных и (или) выполнением простых преобразований. Промежуточное хранение может потребоваться в некоторых случаях, например при загрузке хранилища данных.
  • Избегайте более частого обновления данных, чем требуется источник данных. Например, если источник данных обновляется только каждые 24 часа, обновление данных почасово не будет предоставлять никакого значения. Вместо этого рассмотрите возможность обновления данных на соответствующей частоте, чтобы обеспечить актуальность и точность.

Power BI

Операции Power BI являются интерактивными или фоновыми.

Следующие интерактивные операции обычно приводят к высокой вычислительной нагрузке.

  • Семантические модели, которые не соответствуют рекомендациям. Например, они могут не применять схему звезд с отношениями "один ко многим". Кроме того, они могут включать сложные и дорогие фильтры безопасности на уровне строк (RLS). Рассмотрите возможность использования табличного редактора и анализатора рекомендаций, чтобы определить, следует ли следовать рекомендациям.
  • Меры DAX неэффективны.
  • Страницы отчетов содержат слишком много визуальных элементов, что может привести к медленному обновлению визуального элемента.
  • Визуальные элементы отчета отображают результаты высокой кратности (слишком много строк или столбцов) или содержат слишком много мер.
  • Емкость имеет высокий уровень параллелизма, так как для размера емкости слишком много пользователей. Рекомендуется включить горизонтальное масштабирование запросов, чтобы улучшить взаимодействие с пользователем для семантических моделей семантики высокой параллелизма (но это не приводит к большему общему объему вычислений).

Следующие фоновые операции обычно приводят к высокому использованию вычислительных ресурсов.

  • Неэффективные или слишком сложные преобразования данных в логике Power Query.
  • Отсутствие свертывания запросов или добавочного обновления для больших таблиц фактов.
  • Ускорение отчета, которое происходит при одновременном создании большого количества отчетов Power BI или отчетов с разбивкой на страницы.

Связанный контент

Есть еще вопросы? Попробуйте запросить сообщество Fabric.