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

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

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

Общей ошибкой является нефильтрованное представление таблицы по умолчанию, т. е. все миллионы строк. Данные для этих строк должны быть загружены в память и несжаты при каждом обновлении. Это создало огромные нагрузки на память. Решение: уменьшите максимальное количество элементов, отображаемых в таблице с помощью фильтра «Top N». Максимальный элемент может быть намного больше, чем то, что потребуется пользователям, например, 10 000. В результате, опыт конечного пользователя не изменился, но использование памяти в отчете снизилось на несколько порядков, и соответственно улучшилась производительность. Аналогичный подход к вышесказанному настоятельно рекомендуется для всех визуальных эффектов в ваших отчетах. Спросите себя, нужны ли все данные в этом визуальном виде? Существуют ли способы отфильтровать объем данных, отображаемых на визуальном уровне, с минимальным воздействием на конечного пользователя? Обратите внимание, что таблицы, в частности, могут быть очень дорогими.

Ограничьте отображения на страницах отчетов

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

Оптимизируйте свою модель

Некоторые рекомендации:

• Таблицы или столбцы, которые не используются, должны быть удалены, если это возможно.
• Избегайте четкого учета полей с высокой мощностью, то есть миллионов различных значений.
• Примите меры, чтобы избежать полей с ненужной точностью и высокой мощностью. Например, вы можете разделить очень уникальные значения даты и времени на отдельные столбцы - например. месяц, год, дату и т. д. Или, если это возможно, используйте округление на высокоточных полях для уменьшения мощности - (например, 13.29889 -> 13.3).
• Если возможно, используйте целые числа вместо строк.
• Будьте осторожны с функциями DAX, которые должны проверять каждую строку в таблице - например, RANKX - в худшем случае эти функции могут экспоненциально увеличивать требования времени выполнения и памяти при линейном увеличении размера таблицы.
• При подключении к источникам данных через DirectQuery рассмотрите столбцы индексирования, которые обычно фильтруются или нарезаются снова - это значительно улучшит отчетность.

DirectQuery и Live-соединение: уясните базовую производительность источника данных

В случае DirectQuery или активного подключения, когда пользователи посещают отчет Power BI, Power BI отправляет запросы в режиме реального времени в базовый источник данных. Когда источник данных возвращается с данными запроса, отображается отчет. В результате производительность вашего отчета в этих случаях во многом зависит от производительности базового источника данных. В этих случаях важно понять производительность вашего базового источника данных.  Различные источники данных будут иметь разные инструменты для понимания производительности запросов. Например, SQL Server и Azure SQL предоставляют Query Store, который захватывает историю запросов и их статистику времени выполнения. При развертывании отчетов Power BI, построенных на DirectQuery и в реальном времени, проверьте, что ваши конечные пользователи будут делать в Power BI Desktop. Если отчет медленно загружается в Power BI Desktop, он почти наверняка будет медленно загружаться в службу для ваших конечных пользователей.

Лучшие практики DirectQuery

В следующем разделе описаны общие рекомендации по подключению через DirectQuery.

Руководство по проектированию БД

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

Руководство по моделированию

• Запустите панель Power BI.
• Избегайте сложных запросов в редакторе запросов.
• Не используйте относительную фильтрацию даты в редакторе запросов.
• Сначала выполняйте простые измерения и постепенно добавляйте сложность.
• Избегайте отношений на вычисленных столбцах и столбцах уникального идентификатора.
• Попробуйте установить «Assume Referential Integrity» для отношений - во многих случаях это может значительно повысить производительность запросов

Общее руководство

• Сначала применяйте фильтры.
• Рассмотрите возможность отключения взаимодействия между отображениями - это уменьшит нагрузку на запрос, когда пользователи сделают перекрестное выделение.
• Ограничьте количество отображений и данных на отображения, как описано выше.
• Включение безопасности на уровне строк может привести к существенным изменениям производительности. Обязательно проверьте различные роли безопасности на уровне строк, которые будут использоваться вашими пользователями.
• Обратите внимание, что время ожидания запросов на уровне запросов выполняется службой, чтобы гарантировать, что долговременные запросы не могут монополизировать системные ресурсы. Запросы, длина которых превышает 225 секунд, выйдут из строя и приведут к ошибке визуального уровня.

Понимание информационных панелей и кешей запросов

Отображения, прикрепленные к панелям мониторинга, обслуживаются кешем запросов при загрузке приборной панели. И наоборот, при посещении отчета запросы выполняются «на лету» к источнику данных - либо службе Power BI (в случае импорта), либо указанному источнику данных (в случае DirectQuery или прямого подключения).

Обратите внимание

Когда вы привязываете живые отчетные плитки к панели управления, они не обслуживаются из кеша запросов - вместо этого они ведут себя как отчеты и делают запросы на базовые ядра «на лету».

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

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

Понимание производительности пользовательских отображений

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

Тщательный анализ производительности запросов с помощью SQL Profiler и Power BI Desktop

Для более глубокого анализа отображений , которые занимают больше всего времени и ресурсов, вы можете подключить SQL Profiler к Power BI Desktop, чтобы получить полное представление о производительности запросов.

Обратите внимание

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

Инструкции следующие:

1. Установите SQL Server Profiler и запустите Power BI Desktop

SQL Server Profiler доступен как часть SQL Server Management Studio.

2. Определите порт, используемый Power BI Desktop

Запустите командную строку или PowerShell с правами администратора и используйте netstat для поиска порта, который Power BI Desktop использует для анализа:

> netstat -b -n

Результатом должен быть список приложений и их открытых портов, например:

TCP [::1]:55786         [::1]:55830         ESTABLISHED

[msmdsrv.exe]

Найдите порт, используемый msmdsrv.exe, и напишите его для последующего использования. В этом случае вы можете использовать порт 55786.

3. Подключите SQL Server Profiler к Power BI Desktop

• Запустите SQL Server Profiler из меню Start
• File > New Trace
• Тип сервера: Analysis Services
• Имя сервера: localhost:[port number found above]
• На следующем экране выберите Run.
• Теперь SQL Profiler активен и интенсивно профилирует запросы, которые посылает Power BI Desktop.
• По мере выполнения запросов вы можете увидеть их длительность и время ЦП - используя эту информацию, вы можете определить, какие запросы являются ограничивающими.

Через SQL Profiler вы можете идентифицировать запросы, которые занимают больше всего времени процессора, что, в свою очередь, вероятно, является узким местом производительности. Отображения, которые выполняют эти запросы, должны быть затем областью непрерывной оптимизации.

Рекомендации по работе со шлюзом

Локальный шлюз данных - отличный инструмент для подключения службы Power BI к вашим локальным данным. В то же время, при плохом планировании, он также может стать фактором, снижающим эффективность отчета. Это особенно актуально для наборов данных DirectQuery / live connection, где все запросы и ответы запросов проходят через шлюз. Ниже приведены некоторые рекомендации по обеспечению высокопроизводительных шлюзов:

• Используйте режим Enterprise вместо персонального режима.
• Рекомендуемые аппаратные спецификации для ядра шлюза - 8, 16 ГБ оперативной памяти.
• Настройте мониторинг - настройте мониторинг производительности на машине со шлюзом, чтобы отслеживать, становится ли шлюз перегруженным и как он влияет на производительность.
• Увеличьте или уменьшите масштаб - если шлюз действительно станет понижать производительность, подумайте о вертикальном масштабировании (т. е. перемещении шлюза к более мощной машине с большим количеством ядер процессора и оперативной памяти) или горизонтальном масштабировании (например, разделение наборов данных на разные шлюзы).
• Отделите импорт и DirectQuery - при масштабировании рассмотрите возможность разделения шлюзов, ответственных за импорт, и тех, кто отвечает за DirectQuery.

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

Задержка в сети может влиять на производительность отчета за счет увеличения времени, необходимого для запросов на доступ к службе Power BI, а также для ответов, которые должны быть доставлены. Клиентом в Power BI присваивается определенный регион. Вы можете просмотреть «домашний» регион своего клиента, перейдя на powerbi.com, выбрав знак ? в верхнем правом углу, а затем О Power BI. Когда пользователи получают доступ к службе Power BI из клиента, их запросы всегда направляются в этот регион. Как только запросы достигнут службы Power BI, служба может затем отправить дополнительные запросы - например, к базовому источнику данных или шлюзу, которые также подвержены сетевой задержке.

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

Чтобы еще сильнее снизить латентность сети, рассмотрите возможность использования Azure ExpressRoute, которая способна создавать более быстрые и надежные сетевые соединения между вашими клиентами и центрами данных Azure.

No Comments