Почему отчёт тормозит и как ускорить

«Отчёт открывается полминуты», «срез думает вечно» — почти всегда лечится. Но чтобы лечить, надо понимать, как Power BI хранит и считает данные. Разберём движок VertiPaq, главные причины тормозов и порядок диагностики. Опираемся на VertiPaq в SQLBI и материалы по оптимизации.

Как Power BI хранит данные: VertiPaq

Power BI держит данные не как таблицы, а как столбцовое сжатое хранилище в памяти (VertiPaq). Каждый столбец сжимается отдельно. Ключевой фактор сжатия — кардинальность: число уникальных значений в столбце.

Практические следствия:

• Дробите datetime. Один столбец «дата-время» с секундами имеет гигантскую кардинальность. Разбейте на Дата (низкая кардинальность) и Время отдельно — обе части сожмутся в разы лучше.
• Убирайте лишние знаки. Хранить сумму с 6 знаками после запятой там, где нужны 2, — лишняя кардинальность. Округляйте на загрузке.
• Выкидывайте ненужные столбцы. Технические ID, поля, которые не используются ни в связях, ни в мерах, ни в визуалах, — удалите. Каждый лишний столбец занимает память и время обновления.

Модель: звезда, а не снежинка/плоскость

• Звезда. Факты в центре, справочники по краям — оптимально для VertiPaq и DAX (см. базовый курс).
• Одна плоская таблица. Кажется проще, но раздувает кардинальность (текст повторяется в каждой строке) и ломает гибкость. Хуже звезды.
• Снежинка/много уровней. Лишние переходы по связям замедляют. Денормализуйте справочники в звезду, где можно.

Три места, где живут тормоза

Когда отчёт медленный, узкое место одно из трёх:

1. Модель — раздутые столбцы, плохая схема, двунаправленные связи везде.
2. DAX-меры — тяжёлые формулы: FILTER по всему факту, лишние итераторы, контекст-транзишн в цикле.
3. Визуалы и страница — слишком много визуалов на странице (каждый = отдельный запрос), таблицы на сотни тысяч строк, лишние взаимодействия.

Типичные DAX-тормоза

• FILTER(БольшойФакт, …) вместо фильтра-предиката в CALCULATE. Часто заменяется на простое CALCULATE([Мера], Столбец = …).
• Контекст-транзишн в большом итераторе — SUMX по миллионам строк, где внутри вызывается мера. Иногда переписывается без меры внутри.
• Меры, возвращающие текст/SVG в больших таблицах — дорого на каждую ячейку.
• DISTINCTCOUNT по столбцу высокой кардинальности на большом факте — тяжёлая операция.

Визуалы и страница

• Меньше визуалов на странице. 20 визуалов = 20 параллельных запросов при каждом действии. Разбейте на страницы, используйте drill-through.
• Не кладите факт «как есть» в таблицу. Таблица на 500k строк — это не отчёт, а выгрузка; она душит рендер.
• Отключайте лишние взаимодействия (Edit interactions), чтобы клик по одному визуалу не пересчитывал все.
• Срезы с высокой кардинальностью (поиск по тексту с тысячами значений) — дороги; подумайте об иерархии.

Aggregations — для очень больших моделей

На миллиардах строк применяют агрегации: заранее посчитанные сводные таблицы (например, продажи по дням/регионам). Запросы на верхнем уровне бьют в маленькую агрегатную таблицу, а в детальный факт (DirectQuery) спускаются, только когда нужна детализация. Прозрачно для пользователя, кратно быстрее.

Что дальше

Модель ускорена. Дальше — calculation groups: как не плодить десятки почти одинаковых мер (PY, YTD, %рост) и собрать их в один переключаемый набор. Следующий урок.