Отчёт открывается 30 секунд. Фильтр применяется с задержкой в несколько секунд. Обновление модели данных занимает полчаса, а иногда падает по таймауту. Знакомая ситуация? Хорошая новость: в 90% случаев дело не в «слабом железе» и не в объёме данных, а в том, как построена модель и написаны DAX-запросы. Правильная оптимизация способна ускорить отчёты Power BI в 5–10 раз без апгрейда лицензии и без сокращения функциональности.
В этой статье разберём, откуда берутся тормоза в Power BI и какие конкретные шаги дают наибольший прирост скорости.
Почему Power BI тормозит: три главные причины
Прежде чем оптимизировать, важно понять, где именно теряется время. Обычно это одна из трёх зон:
Модель данных — слишком широкие таблицы, лишние столбцы, неправильные типы данных, избыточная детализация.
DAX-вычисления — вычисляемые столбцы вместо мер, неоптимальные формулы, итерации по большим таблицам.
Визуальный слой — слишком много визуалов на одной странице, сложные срезы, избыточное количество взаимодействий между визуалами.
Разберём каждую зону подробно.
1. Оптимизация модели данных
Импорт вместо DirectQuery — там, где это возможно
DirectQuery отправляет запрос к источнику при каждом взаимодействии с отчётом. Это удобно для «живых» данных, но медленно по своей природе: каждый клик по фильтру — это новый SQL-запрос к базе. Режим Import, наоборот, загружает данные в оптимизированную колоночную модель VertiPaq, где запросы выполняются в разы быстрее.
Правило: если данные не требуют обновления в реальном времени, используйте Import. Если DirectQuery необходим (например, по требованиям безопасности), рассмотрите гибридный режим Composite с агрегатами в Import.
Убирайте лишние столбцы и строки
Каждый столбец в модели увеличивает объём данных, которые движок VertiPaq должен сжать и просканировать. Частая ошибка — тянуть в модель все столбцы «на всякий случай». Оставляйте только то, что реально используется в отчётах.
Также стоит агрегировать данные на уровне источника там, где детализация до секунды или до строки транзакции не нужна для анализа. Таблица с миллионом строк детализации, когда бизнесу нужны только дневные итоги, — прямой путь к медленной модели.
Правильные типы данных
Текстовые столбцы с высокой кардинальностью (например, ID транзакций или полные временные метки) сжимаются в VertiPaq гораздо хуже, чем числовые. Где возможно:
храните даты и время в отдельных столбцах, а не в одном DateTime;
используйте целочисленные ключи вместо текстовых идентификаторов;
отключайте автоматическое определение времени (Auto date/time) в настройках, если оно не используется — оно незаметно создаёт скрытые таблицы дат для каждого столбца дат в модели.
Схема «звезда» вместо «снежинки» и плоских таблиц
Разделяйте факты и измерения на отдельные таблицы, связанные простыми одно-направленными связями (star schema). Это не только упрощает модель, но и позволяет движку эффективнее строить план выполнения запроса, чем при работе с одной широкой денормализованной таблицей или сложной снежинкой с множеством уровней.
Отключайте лишние связи и избегайте двунаправленной фильтрации
Двунаправленные (bi-directional) связи между таблицами удобны, но резко увеличивают сложность вычислений и риск неоднозначных путей фильтрации. Используйте их только там, где это действительно необходимо, и предпочитайте однонаправленные связи по умолчанию.
2. Оптимизация DAX
Меры вместо вычисляемых столбцов
Вычисляемый столбец рассчитывается один раз для каждой строки и хранится в памяти, увеличивая размер модели. Мера вычисляется «на лету» в контексте текущего запроса и не хранится — но при правильном написании работает значительно быстрее на больших объёмах, чем кажется на первый взгляд, а главное, не раздувает модель.
Правило: если расчёт можно сделать на уровне меры (агрегации в контексте визуала), а не на уровне строки, — делайте меру.
Избегайте медленных функций-итераторов на больших таблицах
Функции вроде SUMX, FILTER, CALCULATE с вложенными таблицами построчно проходят по данным. На таблице в десятки миллионов строк это заметно. Там, где возможно, заменяйте построчную логику на предварительно агрегированные таблицы или используйте более эффективные паттерны (например, DIVIDE вместо ручной проверки деления на ноль через IF, или KEEPFILTERS вместо избыточных FILTER).
Проверяйте план запроса
Встроенный DAX Studio (бесплатный внешний инструмент) и Performance Analyzer в самом Power BI показывают, сколько времени уходит на формульный движок (Formula Engine) и на движок хранения (Storage Engine). Если формульный движок работает намного дольше движка хранения — это почти всегда сигнал, что DAX написан неоптимально и его стоит переписать.
3. Оптимизация визуального слоя
Меньше визуалов на странице
Каждый визуал на странице — это отдельный DAX-запрос при обновлении отчёта. Страница с 15 визуалами генерирует 15 параллельных запросов к модели. Разделяйте перегруженные дашборды на несколько страниц с более узкой навигацией, используйте закладки (bookmarks) вместо показа всего сразу.
Осторожно со срезами (slicers) и кросс-фильтрацией
Срезы с высокой кардинальностью (например, срез по ФИО клиента среди миллиона строк) — одна из самых частых причин зависаний. Замените их на иерархические фильтры, поиск с автодополнением или страницы с параметрами.
Отключайте лишние взаимодействия между визуалами
По умолчанию каждый визуал на странице фильтрует все остальные. Если часть визуалов не должна взаимодействовать друг с другом, отключите это в настройках Edit Interactions — это снижает число фоновых запросов при каждом клике.
Дополнительные приёмы для больших моделей
Инкрементальное обновление (Incremental Refresh) — обновляйте только новые или изменённые данные, а не всю таблицу целиком при каждом refresh.
Агрегированные таблицы — создавайте таблицы с предрасчитанными агрегатами для верхнеуровневых отчётов, а детализацию оставляйте только для узкого набора аналитических страниц.
Query folding — убедитесь, что преобразования в Power Query «сворачиваются» в запрос к источнику, а не выполняются построчно на стороне Power BI после загрузки.
Режим хранения Dual — для таблиц измерений в композитных моделях позволяет использовать данные и в режиме Import, и в DirectQuery, ускоряя запросы без дублирования логики.
С чего начать: короткий чек-лист
Замерьте текущую скорость через Performance Analyzer — зафиксируйте точку отсчёта.
Уберите неиспользуемые столбцы и таблицы из модели.
Переведите вычисляемые столбцы в меры там, где это возможно.
Проверьте типы связей — уберите лишние двунаправленные фильтры.
Сократите число визуалов и срезов с высокой кардинальностью на одной странице.
Настройте инкрементальное обновление для больших фактовых таблиц.
Повторите замер и сравните результат.
Уже эти семь шагов, применённые последовательно, обычно дают ускорение в 3–5 раз. Полная переработка модели данных и DAX-логики под конкретный кейс нередко выводит показатель на 10-кратный прирост.
Итог
Скорость Power BI — это не про мощность компьютера, а про архитектуру модели и качество DAX. Большинство «тормозящих» отчётов страдают от одних и тех же ошибок: DirectQuery там, где не нужен, вычисляемые столбцы вместо мер, плоские таблицы вместо схемы «звезда» и перегруженные страницы с десятками визуалов. Системный разбор модели по шагам выше почти всегда даёт кратный прирост производительности — и что немаловажно, эти навыки работы с моделью данных и DAX универсальны и переносятся на любой другой BI-инструмент и на аналитику данных в целом.