Инкрементальное обновление Power BI: как не пропустить поздний возврат
Инкрементальное обновление Power BI перечитывает выбранное окно истории. Позднее изменение старого заказа может остаться вне него, если политика настроена слишком узко.
Содержание статьи
Отчёт магазина ускорили: Power BI теперь обновляет только последние дни вместо всей истории. Затем пришёл возврат по старому заказу, а итог закрытого месяца не изменился. При такой схеме важно проверять не только скорость, но и то, какие исторические изменения модель ещё способна увидеть.
Как устроено окно обновления
Инкрементальная политика разделяет данные на обновляемые и исторические части. Параметры RangeStart и RangeEnd задают границы по дате; после публикации сервис управляет ими согласно политике. Периоды сдвигаются, а старые разделы перестают регулярно перечитываться. История за пределами заданного хранения со временем удаляется из модели.
Microsoft описывает начальную загрузку как отдельный тяжёлый этап, после которого последующие обновления обычно работают с меньшим объёмом. Поэтому сравнивать длительность первого и обычного запуска напрямую не стоит. Экономия времени не означает, что произвольная правка любой старой записи будет обнаружена.
Определить, какая дата управляет данными
В операциях магазина могут быть дата заказа, дата возврата и момент изменения записи. Сначала выясните, какой столбец используется для разделения. Если возврат приходит новой операцией с текущей датой, его обработка отличается от изменения старой строки заказа. Это свойство вашего источника, которое нужно подтвердить на реальных документах.
Составьте контрольный сценарий: сохранённый месяц, поздний возврат и ожидаемая корректировка выбранного показателя. Укажите, должен ли пересчитаться исходный месяц или текущий период. Без этого технически успешная загрузка может скрывать методологическое расхождение.
Выбрать достаточный период
Не назначайте окно только по желаемой скорости. Оцените, насколько далеко назад источник реально корректирует операции, и договоритесь о процедуре повторного расчёта более старых периодов. Опция обнаружения изменений использует отдельный столбец времени изменения, но не превращает любую историческую область в постоянно перечитываемую.
Также проверьте, что отбор по датам выполняется на источнике там, где это необходимо для производительности. Если все строки сначала загружаются, а потом фильтруются локально, ожидаемого выигрыша может не быть. Этот вопрос связан со свёртыванием запросов Power Query, но не заменяет выбор корректного окна истории.
Принять результат на событиях
Проверьте новый заказ, возврат внутри окна и изменение за его пределами. Сверьте суммы по каждому сценарию с контрольной выгрузкой. Зафиксируйте часовой пояс расчёта границ: смена дня может влиять на включение операций около полуночи.
Сохраните исходную модель и порядок изменения политики. По документации повторная публикация модели из Desktop может удалить существующие разделы и данные; это не безобидная кнопка обновления отчёта. Отдельно подтвердите доступность нужного режима для лицензии: обычное инкрементальное обновление и получение данных в реальном времени имеют разные требования.
Материал отражает сведения на указанную дату. Правила и условия работы площадок могут измениться. Редакционные принципы