Хранение данных в Power BI: Import, DirectQuery, Dual и Direct Lake

Обновлено 2 сентября 2026 года.

Режим хранения определяет, откуда Power BI получает данные для расчёта. Его выбирают вместе с допустимой задержкой, нагрузкой на источник, объёмом модели и правами доступа. Размер исходного CSV, размер PBIX и память модели — разные величины; сравнивать их с одним лимитом некорректно.

Import: копия данных в модели

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

Импорт подходит и для значительных объёмов, если модель, инфраструктура и время обновления укладываются в требования. Сокращение ненужных столбцов и детализации часто полезнее смены режима. Модель не обязана автоматически создавать отдельное хранилище предварительных агрегатов для всех показателей.

DirectQuery: запросы к источнику

DirectQuery обращается к источнику при выполнении запросов отчёта. Это уменьшает потребность в полной импортной копии, но переносит часть нагрузки на базу, сеть и шлюз. Возможны ограничения преобразований, расчётов и времени выполнения.

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

Dual, составная модель и гибридная таблица

• Dual позволяет таблице участвовать в запросах как импортной или как DirectQuery в зависимости от ситуации. Например, справочник может обслужить срез из кэша и участвовать в запросе вместе с фактом DirectQuery.
• Составная модель объединяет разные режимы или источники. Её связи и фильтры нужно проверять отдельно; объединение источников не гарантирует одинаковую свежесть данных.
• Гибридная таблица может сочетать импортные исторические партиции и DirectQuery-партицию свежих данных. Это разделение по партициям, а не определение режима Dual.

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

Direct Lake в Microsoft Fabric

Direct Lake работает с Delta-таблицами в OneLake и загружает необходимые данные в память семантической модели. Это отдельный сценарий Fabric, а не универсальный режим для любой базы PostgreSQL или Excel-файла.

У Direct Lake on OneLake и Direct Lake on SQL различаются возможности и ограничения. В частности, поведение перехода к DirectQuery нельзя обобщать на оба варианта. Перед проектированием проверяйте выбранный вариант, права и ограничения ёмкости по обзору Direct Lake.

Подключение к готовой семантической модели

Live connection к существующей модели Power BI или Analysis Services позволяет использовать её расчёты и права. Это не то же самое, что импортировать исходные таблицы. Если поверх существующей модели создаётся новая составная модель, появляются дополнительные правила подключения и управления. Режим следует определять по фактической модели, а не по названию источника в списке коннекторов.

Размер и лицензирование

Универсальная формула «Pro — 1 ГБ, Premium — 10 ГБ» неполна. В документации Microsoft указан базовый лимит 1 ГБ, но большие модели зависят от формата хранения, конкретной лицензии или Fabric capacity и настроек администратора. Возможность включить большой формат сама по себе не снимает лимиты среды. См. большие семантические модели.

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

Как выбрать режим

1. Определите допустимую задержку показателя и число одновременных зрителей.
2. Измерьте импорт и обновление на репрезентативных данных.
3. Если рассматриваете DirectQuery, измерьте типовые фильтры и нагрузку на источник при параллельном просмотре.
4. Проверьте изменение, удаление и позднее поступление данных, включая справочники.
5. Зафиксируйте время успешного обновления и владельца процесса, который заметит и устранит сбой.