Airbyte и Power BI: два уровня инкрементального обновления

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

Инкрементальная загрузка Airbyte и Incremental Refresh в Power BI — два независимых механизма. Первый переносит изменения источника в PostgreSQL, второй обновляет часть импортированной модели BI. Корректная работа одного не гарантирует полноту другого.

Уровень 1: источник → Airbyte → PostgreSQL

Начните с проверки конкретного коннектора: какие сущности и режимы он поддерживает, как определяет изменения и передаёт удаления. Если готового подходящего коннектора нет, потребуется разработка через Connector Builder или CDK. Универсального переключателя, который превращает любой REST API в корректный CDC-источник, нет.

Для сделок Битрикс24 стабильным ключом может быть ID сделки, а курсором — время изменения, если загрузчик правильно применяет соответствующий фильтр REST. Нужны пагинация, сохранение состояния, обработка ошибок и повторное чтение пограничных значений времени.

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

Уровень 2: PostgreSQL → модель Power BI

В Power Query задайте параметры RangeStart и RangeEnd типа Date/Time и фильтр согласованного столбца даты: нижняя граница включается, верхняя исключается. Политику хранения и обновления настройте для таблицы, затем опубликуйте модель и выполните первое обновление в сервисе. Механизм описан в документации Microsoft.

Проверьте, что фильтр реально ограничивает запрос к PostgreSQL. Если Power Query получает всю таблицу, а фильтрует её локально, экономия от инкрементального обновления может исчезнуть.

Главная ловушка: изменяемая дата партиции

Предположим, сделка создана в январе, а её сумма изменена в сентябре. Если партиции построены по DATE_MODIFY, строка перемещается из январского диапазона в сентябрьский. При обновлении только свежего окна старая копия в архивной партиции может остаться. Microsoft рассматривает дубли из-за изменения дат отдельно.

Читай также: Debezium и Kafka → PostgreSQL → Superset: как устроен CDC

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

Как проверить, что история не искажена

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

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

Эксплуатация

Разворачивайте Airbyte по актуальному руководству выбранной редакции; одиночный вымышленный образ в Compose не заменяет установку платформы. Для Power BI настройте поддерживаемое подключение к PostgreSQL и при необходимости шлюз. Доступность порта 443 сама по себе не означает доступность протокола PostgreSQL.

Инкрементальный Import и дополнительная DirectQuery-партиция имеют разные условия использования. Проверяйте лицензию и ёмкость под выбранный режим, не переносите старые цены и лимиты из обзорной статьи в бюджет проекта.