Визуализация и интерпретация диагностики запросов в Power BI

Введение

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

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

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

Как упоминалось в нашей статье по записи диагностики, я работаю с трассировками OData и SQL для той же таблицы (или почти той же) — таблицы Customers из базы данных Northwind. В частности, я собираюсь сосредоточиться на общем запросе от наших клиентов и одном из более легко интерпретируемых наборов трассировок: полное обновление модели данных.

Создание визуализаций

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

• Id
• Время начала
• Запрос
• Step
• Запрос источника данных
• Эксклюзивная длительность (%)
• Количество строк
• Категория
• Это запрос пользователя?
• Путь

Для второй визуализации один из вариантов — использовать столбчатую диаграмму с накоплением. В параметре "Ось" может потребоваться использовать 'Id' или шаг. Если мы смотрим на обновление, так как оно не связано с этапами в самом редакторе, то, вероятно, просто хотим посмотреть на Идентификатор. Для параметра "Условные обозначения" следует задать "Категория" или "Операция" (в зависимости от детализации, которую требуется). В поле "Значение" задайте значение "Эксклюзивная длительность" (и убедитесь, что это не %, чтобы получить необработанное значение длительности). Наконец, для подсказки задайте значение "Самое раннее время начала".

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

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

Интерпретация визуализаций

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

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

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

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

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

Если выполнять все одни и те же операции и создавать аналогичные визуализации, но с трассировками SQL вместо ODATA, мы можем увидеть, как сравниваются два источника данных!

Если выбрать таблицу источника данных, так же, как и при диагностике ODATA, мы можем увидеть, что первая оценка (2.3 на этом изображении) выдает запросы метаданных, а вторая оценка фактически извлекает нужные данные. Поскольку в данном случае мы извлекаем небольшие объемы данных, процесс извлечения занимает немного времени (менее десяти доли секунды для всей второй оценки, и менее двадцатой доли секунды для самого извлечения данных), но это не будет справедливо во всех случаях.

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

Анализ данных

Глядя на пути

При просмотре этого, если кажется, что время потрачено странно, например, в запросе OData может появиться запрос источника данных со следующим значением:

Request:
https://services.odata.org/V4/Northwind/Northwind.svc/Customers?$filter=ContactTitle%20eq%20%27Sales%20Representative%27&$select=CustomerID%2CCountry HTTP/1.1
Content-Type: application/json;odata.metadata=minimal;q=1.0,application/json;odata=minimalmetadata;q=0.9,application/atomsvc+xml;q=0.8,application/atom+xml;q=0.8,application/xml;q=0.7,text/plain;q=0.7

<Content placeholder>

Response:
Content-Type: application/json;odata.metadata=minimal;q=1.0,application/json;odata=minimalmetadata;q=0.9,application/atomsvc+xml;q=0.8,application/atom+xml;q=0.8,application/xml;q=0.7,text/plain;q=0.7
Content-Length: 435

<Content placeholder>

Этот запрос источника данных связан с операцией, которая занимает, скажем, только 1% эксклюзивной длительности. Между тем, есть аналогичный:

Request:
GET https://services.odata.org/V4/Northwind/Northwind.svc/Customers?$filter=ContactTitle eq 'Sales Representative'&$select=CustomerID%2CCountry HTTP/1.1

Response:
https://services.odata.org/V4/Northwind/Northwind.svc/Customers?$filter=ContactTitle eq 'Sales Representative'&$select=CustomerID%2CCountry
HTTP/1.1 200 OK

Этот запрос источника данных связан с операцией, которая занимает почти 75% эксклюзивной длительности. Если включить Путь, вы обнаружите, что последний на самом деле является подчинённым первым. Это означает, что первый запрос сам по себе добавил небольшое количество времени, в то время как основное извлечение данных отслеживается внутренним запросом.

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