Факт продаж за пять лет — десятки миллионов строк. Но меняются обычно только последние дни: вчерашние отгрузки, правки за текущий месяц. Перегружать всю историю каждую ночь — долго, дорого и хрупко. Инкрементальное обновление грузит только свежий хвост, а старое не трогает. Разбираем по документации Microsoft.
Учебный набор мал, поэтому смысл — на проде: Продажи за 5 лет, обновляем только последние 10 дней, а историю храним «как есть».
Что это даёт
- Быстро. Обновляются минуты свежих данных, а не часы всей истории.
- Дёшево. Меньше нагрузка на источник и на ёмкость Power BI.
- Надёжно. Сбой грузит маленький кусок — его легко повторить, не перезаливая годы.
- Автоматический архив. Старые партиции хранятся в модели, новые подмешиваются.
Как это устроено: партиции
Power BI режет таблицу на партиции по датам. Историю он держит в «архивных» партициях и не перезапрашивает. Свежий диапазон — в «инкрементальных» партициях, которые обновляются. Вы задаёте два окна:
- Store rows in the last… — сколько хранить всего (например, 5 лет): за этой границей данные выпадают из модели.
- Refresh rows in the last… — сколько обновлять каждый раз (например, 10 дней): только этот хвост перезапрашивается.
Два обязательных параметра
Настройка начинается в Power Query с двух параметров со строго такими именами:
RangeStart (тип Date/Time)
RangeEnd (тип Date/Time)На таблице факта ставим фильтр по дате между RangeStart и RangeEnd. Power BI будет сам подставлять в них границы для каждой партиции при обновлении.
= Table.SelectRows(
Источник,
each [Дата] >= RangeStart and [Дата] < RangeEnd
)Затем в модели: ПКМ по таблице → Инкрементальное обновление → задать окна хранения и обновления → опубликовать.
Это «ручки», за которые Power BI дёргает источник для каждой партиции. Имена фиксированы — по ним движок понимает, какой период грузить. Фильтр на факте >= RangeStart and < RangeEnd (строго меньше End, чтобы не задвоить границу) — обязательное условие; без него инкрементальное обновление не включится.
Query folding — критично
Чтобы инкремент работал, фильтр по дате должен «свернуться» (fold) в запрос к источнику — то есть превратиться в WHERE Дата >= … AND Дата < … на стороне SQL. Тогда источник отдаёт только нужный период.
Если шаги Power Query ломают folding (например, добавлен пользовательский шаг, который БД не умеет транслировать), Power BI скачает всю таблицу, а потом отфильтрует в памяти. Внешне «работает», но смысл инкремента — не дёргать всю историю — потерян. Проверяйте: ПКМ по шагу → Просмотреть исходный запрос (View Native Query) должен быть доступен и содержать ваш WHERE по дате.
Detect data changes
Можно умнее: обновлять день, только если он реально изменился. Указываете столбец вроде ДатаИзменения (max по партиции) — Power BI сверяет его и пропускает партиции без правок. Меньше лишней работы.
Тонкости и ограничения
- Первое обновление — полное. Первый refresh в Service строит все партиции (долго, один раз). Дальше — только хвост.
- Источник должен поддерживать folding. SQL, и другие реляционные — да; «плоские» файлы/некоторые API — проблемно.
- Только Service. Партиции живут в Power BI Service, не в Desktop. Локально вы видите лишь срез по
RangeStart/RangeEnd, который задали для разработки (берите маленький — пару дней). - Изменение схемы. Поменяли структуру — иногда нужно пересоздать партиции (полное обновление).
Что дальше
Большие факты обновляются быстро. Но даже свежая модель может тормозить на открытии и фильтрах. Дальше — оптимизация: почему отчёт медленный и как его ускорить. Следующий урок.