Урок 06 · 10 мин чтения

Композитные модели и DirectQuery

Когда импорт не подходит: режимы хранения Import / DirectQuery / Dual, композитные модели и их компромиссы.

Три режима хранения таблицы

У каждой таблицы есть storage mode:

Import — данные копируются в модель (VertiPaq), сжимаются, считаются молниеносно. Минус: размер и обновление по расписанию (не «онлайн»).

DirectQuery — данные остаются в источнике, Power BI шлёт в него SQL-запросы на лету при каждом действии. Плюс: свежесть и любой объём. Минус: медленнее, нагрузка на источник, часть DAX недоступна.

Dual — таблица может работать и так, и так: импортируется для скорости, но умеет участвовать и в DirectQuery-запросах. Типичный режим для справочников в композитной модели.

Import vs DirectQuery — главный компромисс

Import = быстро, но это снимок на момент обновления и всё лежит в модели. DirectQuery = всегда свежо и без копирования, но каждый клик уходит запросом в источник (медленнее и нагружает БД). Выбор — это всегда обмен «скорость и автономность» ↔ «свежесть и объём».

Композитная модель

Композитная модель — это когда в одной модели уживаются таблицы с разными режимами: гигантский факт в DirectQuery + справочники в Import/Dual. Раньше так было нельзя — модель была либо вся Import, либо вся DirectQuery.

Типовой расклад:

большой факт Продажи → DirectQuery (не копируем миллиарды строк);

справочники Товары, Регионы, Календарь → Dual (импортированы для скорости срезов, но готовы к DirectQuery-джойнам).

Зачем Dual для справочников

Если справочник оставить чистым Import, а факт — DirectQuery, то срез по справочнику всё равно потащит запрос в источник через границу режимов. Dual позволяет справочнику отвечать локально (быстрые срезы) и одновременно «спускаться» в DirectQuery-запрос к факту, когда нужно. Это стандартный приём оптимизации композитных моделей.

Подключение к другим моделям (DirectQuery to AS)

Особый вид композитной модели — DirectQuery к уже опубликованной семантической модели / Analysis Services. Вы строите свою модель поверх корпоративной, добавляя локальные таблицы и меры, не копируя её. Так аналитик расширяет «общую правду» (см. урок про SSAS в экспертном курсе) под свою задачу.

Чем платим за DirectQuery

Скорость. Каждый визуал = запрос(ы) в источник. Источник должен быть быстрым и хорошо проиндексированным.

Ограничения DAX/Power Query. Часть функций и преобразований в DirectQuery недоступна или дорога.

Нагрузка на источник. Много пользователей = много запросов в боевую БД.

Сложность. Кросс-режимные связи и «limited relationships» ведут себя тоньше обычных.

DirectQuery — не «ускоритель», а компромисс

Частое заблуждение: «возьмём DirectQuery, чтобы было быстрее». Наоборот — Import почти всегда быстрее для пользователя, потому что данные уже сжаты в памяти. DirectQuery берут не ради скорости, а когда данные нельзя или не нужно копировать: слишком большой объём, требование свежести «здесь и сейчас», запрет на выгрузку из источника. По умолчанию — Import; DirectQuery — осознанно под конкретное ограничение.

Что дальше

Режимы хранения и композитные модели закрыли. Дальше — частый бизнес-запрос и DAX-паттерн под него: сопоставимые продажи (like-for-like). Следующий урок.

Когда оправдан DirectQuery вместо импорта данных?

Import почти всегда быстрее для пользователя — данные уже сжаты в памяти. DirectQuery берут не ради скорости, а под ограничение: факт слишком велик для копирования, нужна свежесть «здесь и сейчас» или источник нельзя выгружать. По умолчанию — Import.