Руководство по оптимизации Для Power BI
В этой статье содержатся рекомендации, позволяющие разработчикам и администраторам создавать и поддерживать оптимизированные решения Power BI. Решение можно оптимизировать на разных уровнях архитектуры. К уровням относятся:
- Источники данных
- Модель данных
- Визуализации, включая панели мониторинга, отчеты Power BI и отчеты с разбивкой на страницы Power BI
- Среда, включая емкости, шлюзы данных и сеть
Оптимизация модели данных
Модель данных поддерживает весь интерфейс визуализации. Модели данных размещаются в экосистеме Power BI или во внешней среде (с помощью DirectQuery или Live Connection), а в Power BI они называются семантической моделями. Важно понимать параметры и выбирать подходящий тип семантической модели для решения. Существует три режима хранения таблиц семантической модели: Импорт, DirectQuery и Составной. Дополнительные сведения см. в разделе "Семантические модели" в режимах служба Power BI и семантической модели в служба Power BI.
Инструкции по определенному режиму хранения таблиц семантической модели см. в следующей статье:
- Методы уменьшения объема данных для моделирования импорта
- Руководство по использованию модели DirectQuery в Power BI Desktop
- Руководство по составной модели в Power BI Desktop
Оптимизация для авторов отчетов и потребителей моделей
Семантическая модель является основой всех отчетов в Power BI. Потребители семантической модели могут создавать отчеты Power BI в Power BI Desktop, подключаясь к опубликованной семантической модели или подключаясь к данным и создавая локальную семантику. Семантическая модель также может использоваться для создания отчетов Power BI в браузере, создания исследований Power BI, создания отчетов с разбивкой на страницы, создания запросов DAX и создания отчетов в Excel с помощью анализа в Excel, подключения к Power BI в Excel или экспорта данных из визуального элемента отчета, а также многих других средств создания отчетов. Автор семантической модели может помочь потребителям семантической модели понять и использовать семантическую модель с тем, как они создают модель.
- Имена: таблицы, столбцы и меры в семантической модели с описательными именами. Например, "Магазин продаж" в качестве имени таблицы является более интуитивно понятным, чем Table1.
- Описание. Таблицы, столбцы и меры в модели могут содержать описания, добавляемые к ним, чтобы предоставить более подробную информацию, чем может соответствовать имени. Объясните не только то, что они включают, но и как они должны использоваться.
- Скрытие. Вы можете скрыть таблицы, столбцы и меры в модели, чтобы показать только то, что они будут использоваться в отчете. Например, столбцы связей могут быть идентификатором, который не нужен для создания отчетов и может быть скрыт, так как он не должен использоваться в отчете, или столбцы данных, имеющие меру для агрегирования столбца, можно скрыть, чтобы поощрять использование меры вместо этого. Скрытые объекты всегда могут быть незахвачены позже потребителем модели, поэтому они по-прежнему будут доступны, но скрытие может обеспечить фокус.
- Иерархии. Вы можете создавать иерархии для передачи иерархии между несколькими столбцами. Например, иерархия календаря может содержать столбцы "Год", "Месяц", "День", а иерархия "Продукт" может содержать столбцы "Категория", "Подкатеготь", "Продукт". Щелкните правой кнопкой мыши столбец, чтобы создать иерархию.
- Меры. Вы можете использовать меры для агрегирования столбцов данных в семантической модели для обеспечения согласованности между отчетами. Меры могут варьироваться от суммы столбца до индекса работоспособности, объединяющего несколько агрегатов определенным образом или сравнивая агрегаты между периодами времени, например в среднем в этом месяце, по сравнению с ежедневным средним в том же месяце в прошлом году. Меры также можно использовать в поиске Power BI и других функциях, таких как метрики и системы показателей.
- Форматы: по умолчанию можно указать способ отображения столбца или меры в визуальном элементе. Значения в визуальных элементах можно настроить далее в визуальном элементе. Параметры формата включают в себя, если он имеет тысячи запятой, сколько десятичных разрядов, как отображается дата и т. д. Можно также применять настраиваемые или динамические форматы.
- Категория данных: можно указать категорию данных столбца, например, страну или URL-адрес веб-сайта.
Это общие функции семантической модели 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) можно управлять параметрами емкости. Дополнительные сведения см. в разделе лицензий на емкость Microsoft Fabric и управление емкостями Premium.
Внимание
Иногда эта статья относится к Power BI Premium или ее подпискам на емкость (SKU). Обратите внимание, что корпорация Майкрософт в настоящее время объединяет варианты покупки и отставает от номера SKU емкости Power BI Premium. Новые и существующие клиенты должны рассмотреть возможность приобретения подписок на емкость Fabric (SKU) вместо этого.
Дополнительные сведения см. в разделе "Важные обновления", поступающие в лицензирование Power BI Premium и вопросы и ответы по Power BI Premium.
Размер шлюза
Шлюз требуется каждый раз, когда 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.
Связанный контент
Дополнительные сведения об этой статье см. в следующих ресурсах: