Руководство по оптимизации Для Power BI

  • Статья

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

  • Источники данных
  • Модель данных
  • Визуализации, включая панели мониторинга, отчеты Power BI и отчеты с разбивкой на страницы Power BI
  • Среда, включая емкости, шлюзы данных и сеть

Оптимизация модели данных

Модель данных поддерживает весь интерфейс визуализации. Модели данных размещаются в экосистеме Power BI или во внешнем режиме (с помощью DirectQuery или Live Подключение ion), а в Power BI они называются семантической моделями, ранее известными как наборы данных. Важно понимать параметры и выбирать подходящий тип семантической модели для решения. Существует три режима семантической модели: импорт, DirectQuery и составной. Дополнительные сведения см. в разделе "Семантические модели" в режимах служба Power BI и семантической модели в служба Power BI.

Инструкции по определенному режиму семантической модели см. в статье:

Оптимизация визуализаций

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

Панели мониторинга

Важно понимать, что Power BI поддерживает кэш для плиток панели мониторинга, за исключением плиток динамического отчета и потоковой передачи плиток. Если семантическая модель обеспечивает динамическую безопасность на уровне строк (RLS), обязательно понять, что плитки кэшируются на основе каждого пользователя.

При закреплении плиток динамического отчета на панели мониторинга они не обслуживаются из кэша запросов. Вместо этого они ведут себя как отчеты и делают запросы к виртуальным ядрам на лету.

Как предполагается, получение данных из кэша обеспечивает более высокую и согласованную производительность, чем использование источника данных. Одним из способов воспользоваться этой функцией является наличие панелей мониторинга в качестве первой целевой страницы для пользователей. Закрепление часто используемых и высоко запрошенных визуальных элементов на панелях мониторинга. Таким образом, панели мониторинга становятся ценными "первой линией обороны", которая обеспечивает согласованную производительность с меньшей нагрузкой на емкость. Пользователи по-прежнему могут щелкнуть отчет для анализа сведений.

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

Отчеты Power BI

Существует несколько рекомендаций по оптимизации макетов отчетов Power BI.

Примечание.

Если отчеты основаны на семантической модели DirectQuery, дополнительные оптимизации проектирования отчетов см. в руководстве по модели DirectQuery в Power BI Desktop (оптимизация проектов отчетов).

Применение самых строгих фильтров

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

Распространенная ошибка заключается в том, чтобы оставить представление таблицы нефильтрованным по умолчанию, т. е. все строки 100M+ . Данные для этих строк загружаются в память и распаковкуются при каждом обновлении. Эта обработка создает огромные потребности в памяти. Решение: используйте фильтр "Top N", чтобы уменьшить максимальное количество элементов, отображаемых в таблице. Можно задать максимальный размер элемента, превышающего количество необходимых пользователей, например 10 000. Результатом является взаимодействие с конечным пользователем, но использование памяти значительно снижается. И самое главное, производительность улучшается.

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

Ограничение визуальных элементов на страницах отчетов

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

Оценка пользовательской производительности визуальных элементов

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

Отчеты с разбивкой на страницы Power BI

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

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

Оптимизация среды

Вы можете оптимизировать среду Power BI, настроив параметры емкости, размер шлюзов данных и уменьшая задержку в сети.

Параметры емкости

При использовании емкостей с лицензиями Power BI Premium (SKU), Premium на пользователя (PPU) или Power BI Embedded (SKU, A4-A6) можно управлять параметрами емкости. Дополнительные сведения см. в разделе Управление премиум-емкостью.

Размер шлюза

Шлюз требуется каждый раз, когда Power BI должен получать доступ к данным, недоступным непосредственно через Интернет. Локальный шлюз данных можно установить на локальном сервере или на виртуальной машине, размещенной в инфраструктуре как услуга (IaaS).

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

Задержка в сети

Задержка в сети может повлиять на производительность отчета, увеличив время, необходимое для получения запросов к служба Power BI, а также для доставки ответов. Клиенты в Power BI назначаются конкретному региону.

Совет

Чтобы определить расположение клиента, см. статью "Где находится мой клиент Power BI"?

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

Такие средства, как Azure Speed Test , предоставляют сведения о задержке сети между клиентом и регионом Azure. Как правило, чтобы свести к минимуму влияние задержки в сети, старайтесь сохранить источники данных, шлюзы и емкость Power BI как можно ближе. Предпочтительно, они находятся в одном регионе. Если задержка в сети является проблемой, попробуйте найти шлюзы и источники данных ближе к емкости Power BI, разместив их в облачных виртуальных машинах.

Мониторинг производительности

Вы можете отслеживать производительность для выявления узких мест. Медленные запросы (или визуальные элементы отчета) должны быть фокусом на непрерывной оптимизации. Мониторинг можно выполнять во время разработки в Power BI Desktop или в рабочих нагрузках в емкостях Power BI Premium. Дополнительные сведения см. в разделе "Мониторинг производительности отчета" в Power BI.

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

Дополнительные сведения об этой статье проверка следующих ресурсов: