{"id":13505,"url":"\/distributions\/13505\/click?bit=1&hash=ca3734639136826288c9056e5c8fa03a05e87c4060ae84df200f2c90f5262470","title":"\u0412\u044b \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a? \u0410 \u043f\u043e\u043d\u0438\u043c\u0430\u0435\u0442\u0435 \u0447\u0442\u043e-\u0442\u043e \u0432 \u0438\u0441\u043a\u0443\u0441\u0441\u0442\u0432\u0435 \u043a\u043e\u0434\u0430?","buttonText":"\u041f\u0440\u043e\u0432\u0435\u0440\u0438\u0442\u044c","imageUuid":"f5f0e11f-fefd-52f5-8712-82164a59b7ce","isPaidAndBannersEnabled":false}
IQBI

Измерение производительности DirectQuery в Power BI

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

Для начала вспомним: чем отличается получение данных Import от DirectQuery. При импорте мы загружаем данные прямо в файл, при этом локальный pbix будет иметь большой размер, но быстрее загружать данные. Также при таком подключении придётся вручную настраивать таблицы, их взаимодействия и связи между ними. При подключении DirectQuery данные подгружаются порционно, по необходимости, файл имеет малый размер, так как идёт прямое подключение к Вашей базе данных. За счёт этого связи настраивать не нужно, так как учитываются взаимодействия данных в базе данных, но подключение к таким большим данным может занять много времени и так будет каждый раз, когда Вы будете приступать к работе с отчётом.

И так, у нас есть доступ к некоторым известным данным такси Нью-Йорка в базе данных Snowflake, и там есть таблица с данными о поездках, содержащая 173 миллиона строк, из которых можно создать набор данных Power BI. Используемые данные и база данных здесь не особо важны - важно то, что это DirectQuery и большой объем данных. Вот страница отчета с единственной визуальной таблицей, показывающей количество пассажиров, агрегированных по полю лицензии:

Естественно, эта таблица будет медленной, но насколько? Вот, что показывает анализатор производительности, при обновлении таблицы:

Запрос DAX занимает 5,4 секунды, но время прямого запроса составляет всего 3,3 секунды и цифры не складываются. Вот, что фиксирует Profiler для того же обновления, что и в Performance Analyzer:

Это показывает, что между событием DirectQuery End и событием Query End есть промежуток в 2 секунды. Что, если вставить запрос в DAX Studio? Вот, что показывает вкладка Server Timings:

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

Ответ заключается в понимании того, что на самом деле измеряет событие DirectQuery End Profiler: это количество времени между обработчиком служб Analysis Services, передающим запрос механизму Power Query, и обработчиком служб Analysis Services, получающим обратно первую строку в наборе результатов, включая время, используемое для механизма Power Query, чтобы свернуть запрос.

К сожалению, по событиям Profiler невозможно узнать, сколько времени это займет, но есть другой способ. Возвращаясь к Performance Analyzer, если вы экспортируете данные из него в JSON (нажав кнопку «Экспорт») и загрузите их в Power Query, вы сможете увидеть более подробную информацию о выполнении запроса DirectQuery. Вот данные из первого выполнения выше:

Глядя на запись в столбце метрик для события «Выполнить прямой запрос», вы можете увидеть ту же продолжительность 3,2 секунды, показанную выше в Profiler. Обратите внимание, что здесь также есть два других показателя: RowsRead - общее количество строк, возвращаемых набором результатов; и DataReadDuration, который представляет собой количество времени для чтения этих строк после получения первой строки, а также некоторые другие операции Analysis Services Engine, такие как кодирование значений столбцов, объединение с невымещенными полусоединениями, проекции агрегатов, таких как Среднее, и сохранение набора результатов в кэш в памяти. В этом случае запрос SQL возвратил 43191 строку, и это занимает 1,95 секунды, что объясняет разрыв между концом события «Выполнить прямой запрос» и концом запроса.

Последний вопрос: почему этот SQL-запрос возвращает так много строк, когда запрос DAX запрашивает только верхние 502 строки?

Причина в том, что, по крайней мере, на момент написания, подсистема служб Analysis Services может только подтолкнуть верхнюю (n) операцию к запросу DirectQuery SQL только в очень простых сценариях, где нет мер и агрегации - и в этом случае мы подводим итоги. В результате, если вы используете режим DirectQuery и имеете такой визуальный элемент, который потенциально может отображать большое количество строк и включает меру или агрегированные значения, производительность может снизиться.

0
Комментарии
Читать все 0 комментариев
null