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

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

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

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

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

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

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

Для второй визуализации используйте гистограмму с накоплением. В параметре Оси используйте идентификатор или шаг. Если вы рассматриваете Refresh, то, поскольку это никак не связано с шагами в самом редакторе, вам, вероятно, нужно просто обратить внимание на Id. Для параметра Legend задайте Category или Operation (в зависимости от желаемого уровня детализации). Для параметра Value задайте исключительную длительность и убедитесь, что выбрано не значение в %, чтобы получить исходное значение длительности. Наконец, для параметра Tooltip укажите самое раннее значение Start Time.

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

Снимок экрана: диагностика запросов с таблицами трассировок и гистограммой длительности по категориям и идентификаторам.

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

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

Как упоминалось ранее, диагностика запросов поможет вам ответить на многие вопросы. Два самых распространённых вопроса: как расходуется время и какой запрос отправляется к источнику.

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

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

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

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

Снимок экрана: диагностика запросов OData с подробной таблицей трассировки и диаграммой длительности, в котором выделено время источника данных.

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

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

Если выбрать таблицу источника данных, например диагностику 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% монопольного времени выполнения. Если включить Путь, вы обнаружите, что последний на самом деле является подчинённым первым. Это означает, что первый запрос сам по себе добавляет лишь небольшую задержку, а фактическое извлечение данных отслеживается запросом inner.

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