Airflow → PostgreSQL → dbt → Superset: надёжная загрузка

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

В этой архитектуре Airflow управляет порядком работ, загрузчик получает данные источника, PostgreSQL хранит их, dbt формирует модели, Superset показывает витрины. Разделение полезно, когда есть несколько источников, зависимые преобразования и необходимость повторить неудачный запуск без искажения показателей.

Что входит в поток

Рабочая последовательность: извлечение → проверка полноты → загрузка текущего состояния → построение моделей dbt → контроль показателей → готовность витрин для BI. Отчёт не должен получать частично загруженный набор только потому, что первый шаг завершился успешно.

Для каждого запуска сохраняйте период, версию кода, число строк и контрольную точку источника. В рекомендациях Airflow отдельно рассматриваются повторяемость задач, UPSERT и передача больших данных через внешнее хранилище. В XCom достаточно передать путь к файлу или идентификатору загрузки; большой JSON со всеми сделками усложняет работу служебной базы.

Начните с контракта данных

Учебный пример — текущие сделки CRM. Пусть загрузчик уже создал raw.deals_current с полями deal_id, stage_id, amount, currency_id, created_at и updated_at. Эти имена — контракт нашего примера, а не обещание о названиях таблиц любого коннектора.

В sources.yml опишите источник raw и таблицу deals_current. Первую модель можно сделать обычным представлением:

{{ config(materialized='view') }}

select
  deal_id,
  stage_id,
  amount::numeric(18,2) as amount,
  currency_id,
  created_at,
  updated_at
from {{ source('raw', 'deals_current') }}

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

Когда добавлять инкрементальные модели

Переходите к incremental после измерения времени полного построения. Проверьте поддержку выбранной стратегии адаптером PostgreSQL и задайте существующий уникальный ключ результата. Если колонка называется deal_id, настройка unique_key='id' ей не соответствует.

Используйте документированный механизм is_incremental(). Макрос incremental_clause() не является универсальной встроенной функцией dbt. Продумайте пустую целевую таблицу, поздние изменения и удаления: фильтра по максимальной дате часто недостаточно.

Как организовать проверки и доступ

• Проверяйте уникальность и заполненность ключа, типы дат, наличие валюты и допустимые значения статусов.
• Сверяйте число сделок и суммы за один период с источником. Разделяйте текущую воронку и историю переходов.
• Выдавайте Superset чтение готовых витрин. Роль PostgreSQL и правила доступа зрителей Superset решают разные задачи.
• При неудаче преобразования сохраняйте предыдущую согласованную витрину и показывайте её фактическую свежесть.

Airflow, dbt и Superset разворачивайте по документации закреплённых совместимых версий. Неполный Compose с одним контейнером Airflow не описывает все его необходимые сервисы; число задач в сутки само по себе не определяет необходимость Kubernetes.

Что эта архитектура не обещает

Airflow не заменяет потоковый обработчик с гарантированной секундной задержкой. dbt Core не включает автоматически все облачные AI-функции. Superset не импортирует произвольный проект dbt только из-за номера версии. Ускорение на фиксированные 30% без измерений вашего запроса также обещать нельзя.

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