Power BI: большие данные и аналитика в реальном времени

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

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

Начните с требования к задержке: нужны итоги к утру, изменения за последние 15 минут или реакция на событие за несколько секунд? Эти задачи требуют разной архитектуры и ресурсов.

Что именно должно обновляться

Учебный пример: заказ создан в 10:00, доставлен в 10:02, обновление Import началось в 10:10 и закончилось в 10:12, а визуализация показала его в 10:12:05. Полная задержка — 12 минут 5 секунд. Ускорение доставки до 10:00:10 не устранит ожидание обновления модели.

Интерактивный срез меняет контекст запроса, но не гарантирует получение новой версии исходных данных. Слово Live в live connection означает подключение к существующей модели, а не обещание нулевой задержки.

Режимы хранения и подключения

Общее описание — в справке Microsoft по storage mode. Direct Lake не является универсальным прямым подключением к любой базе; его устройство описано в документации Fabric.

Если достаточно периодического обновления: Import

Для многих управленческих отчётов подходит Import с согласованным расписанием. Сначала ограничьте историю и набор полей, приведите таблицы к понятной модели и измерьте полное обновление. Не загружайте все технические поля источника только потому, что коннектор их показывает.

Большой CSV и большой размер модели — разные характеристики. Сжатие зависит от типов и числа уникальных значений. Длинные уникальные строки, лишняя детализация времени и неиспользуемые столбцы могут существенно увеличивать модель. Универсальный предел в количестве строк здесь мало полезен.

По текущей документации больших моделей базовый предел составляет 1 ГБ, а превышение зависит от ёмкости и настроек Large semantic model storage format. Ограничение загрузки из Desktop и размер модели, выросшей при обновлении в сервисе, различаются. Сначала проверьте условия конкретной рабочей области, затем оценивайте размер и пиковую память обновления.

Инкрементное обновление и изменения старых данных

Инкрементная политика позволяет хранить длительную историю, перечитывая выбранные периоды. Для неё используют параметры RangeStart/RangeEnd и фильтр времени. Проверьте, что границы разделов не пересекаются и фильтрация эффективно применяется на источнике. Правила incremental refresh.

Пример: хранится три года, ежедневно перечитываются последние семь дней. Исправление заказа двухмесячной давности может не попасть в модель. Нужно определить, как система получает такие изменения: расширенное окно, отдельный пересчёт раздела или другой процесс подготовки данных. Инкрементное обновление не заменяет CDC и не гарантирует обнаружение физических удалений.

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

Если нужны частые запросы к источнику: DirectQuery

1. Выберите источник, который поддерживает DirectQuery. Поддержка Import у коннектора не означает поддержку DirectQuery.
2. Подготовьте таблицы, связи и запросы в источнике. Проверьте планы выполнения и необходимые индексы или агрегаты.
3. Создайте простой отчёт и измерьте время каждого визуала.
4. Проверьте одновременную работу ожидаемого числа зрителей и влияние запросов на другие задачи базы.
5. Только после этого уменьшайте интервал обновления страницы.

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

Automatic page refresh

Автоматическое обновление страницы повторяет запросы визуализаций. В текущей документации оно описано для поддерживаемых сценариев DirectQuery и Direct Lake, а также некоторых смешанных подключений. Оно не выполняет обновление данных обычной модели Import.

На общей ёмкости минимальный интервал составляет 30 минут, а change detection недоступен. На выделенных ёмкостях и в соответствующих сценариях PPU действуют настройки администратора. Установленный в Desktop короткий интервал не гарантирует такой же интервал после публикации. Сверяйте конфигурацию с таблицей возможностей automatic page refresh.

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

Потоковые модели: важное изменение срока поддержки

Создание потоковых моделей Power BI остаётся доступным до 31 октября 2027 года. После этой даты создание новых push, streaming, PubNub-моделей и потоковых плиток больше не будет поддерживаться. Microsoft отдельно указывает, что существующие потоковые модели этим изменением не затрагиваются. Источник — актуальная справка real-time streaming.

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

Потоковая аналитика в Microsoft Fabric

Real-Time Intelligence объединяет инструменты для работы с событиями: Eventstreams для приёма и маршрутизации, Eventhouse для хранения и анализа, Real-Time Dashboards для оперативного представления и Activator для правил и действий. Power BI может использовать подготовленные данные для отчётов.

Это отдельная архитектура Fabric с требованиями к доступу и ресурсам, а не кнопка «включить потоковую аналитику» в любом отчёте Desktop. Выбирайте, где нужна оперативная панель, где — управленческий отчёт, а где — обработчик событий.

В учебной схеме датчик отправляет события в поток, обработчик проверяет формат и сохраняет их, панель показывает значения, а правило реагирует на превышение порога. Для рабочего решения дополнительно определяют уникальный ID события, повторную доставку, поздние события, хранение истории и поведение при отсутствии данных. Передача события сама по себе не гарантирует однократный учёт.

Как измерить производительность

Тестируйте рабочие запросы и распределение данных, а не только удобную небольшую выборку. Зафиксируйте количество строк, число уникальных значений, размер модели, число зрителей и набор фильтров. Отдельно измерьте первое открытие, повторное открытие и время ответа при одновременной нагрузке.

Используйте Performance Analyzer, чтобы найти медленные визуализации, и диагностику источника, чтобы понять стоимость запросов. Показатель p95 времени ответа поможет увидеть медленные запросы, которые скрываются за средним значением.

• Контрольные суммы и число уникальных ключей до и после загрузки должны совпадать с выбранными бизнес-правилами.
• Повторная доставка одного пакета не должна увеличивать итог дважды.
• Запоздавшее исправление должно появляться в нужном периоде.
• Остановка источника должна давать состояние «данные устарели» или ошибку, а не выглядеть как нормальный нулевой результат.
• Проверьте возвращение к нормальной работе после восстановления связи и возможность повторить неуспешную загрузку.

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

Доступ и публикация

Опубликуйте отчёт в рабочую область Power BI, настройте подключения и права зрителей. RLS ограничивает строки; для ограничений объектов модели есть OLS. Скрытый столбец, срез и фильтр страницы не заменяют эти механизмы. Проверяйте результат под ролью обычного зрителя, а не администратора рабочей области.

Power Query отвечает за запросы и преобразования, семантическая модель — за таблицы, связи и вычисления, визуализации — за представление. Power View и Power Map из старых материалов про Excel не являются современными модулями «реального времени» в Desktop. Dashboard сервиса также не является просто первой страницей отчёта.

Что изучить для такого проекта

Начните с подготовки данных в Power Query, моделирования, DAX и диагностики источника. Для больших и часто обновляемых систем особенно важны ключи, время события, правила изменения истории и измерение задержки.

Актуальная профильная сертификация Microsoft — Power BI Data Analyst Associate с экзаменом PL-300. Старые сочетания DA-100, DP-100, DP-900 и название «Power BI Fundamentals» из прежней версии статьи не описывают текущий путь этой сертификации. Доступность экзамена и условия регистрации проверяйте на странице Microsoft.

Решение готово к использованию, когда известны его задержка, стоимость, контроль полноты данных и поведение при сбоях. Обещание «любые данные автоматически в реальном времени» этих проверок не заменяет.