В предыдущей статье мы разобрали, как разделять процесс на изолированные задачи и управлять ими с помощью DAGa в Apache Airflow. Теперь наступает этап бизнес-трансформации (T в ELT-пайплайне).

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

В чем основная проблема? Существует два распространенных сценария, которые ведут к техническому долгу:

1. SQL-запросы внутри PostgresOperator. Логика становится непрозрачной, ее сложно тестировать изолированно от оркестратора.

2. Обработка через PythonOperator и pandas в памяти Airflow. Опасный сценарий с высоким риском падения планировщика из-за ошибки нехватки памяти (Out-of-Memory / OOM Killer).

Инженерный подход: разделение функционала

Чтобы система оставалась стабильной и масштабируемой, рекомендую строго разделить зоны ответственности:

• Airflow — это координатор и диспетчер. Он отвечает за расписание, проверку внешних триггеров, контроль технической доставки данных и запуск внешних инструментов. Его задача — управлять потоком, а не крутить тяжелые запросы.

• Движок трансформации — это база данных под управлением dbt (data build tool).

В проекте за трансформацию и загрузку данных по слоям DWH отвечают три последовательных этапа, управляемых через dbt:

1. Staging — выполняет первичную распаковку, очистку и типизацию данных в модели stg. 2. Core — формирует архитектуру Data Vault (Hub, Link, Satellite), обеспечивая историчность через SCD2. 3. Marts — денормализует данные в классическую «звезду» Кимбалла (факты и измерения), подготавливая их для удобной аналитики и BI-инструментов.

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

1. Стабильность: Airflow отправляет команду dbt run и просто ждет ответа. Вся нагрузка по вычислениям ложится на СУБД.

2. Встроенное тестирование: dbt позволяет «из коробки» проверять загруженные данные на уникальность, отсутствие NULL значений и корректность связей.

3. Масштабирование: Код трансформации полностью изолирован. Если завтра потребуется перенести расчеты из PostgreSQL в ClickHouse или Greenplum, не придется переписывать DAG-и в Airflow — достаточно просто изменить профиль подключения в dbt.

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

Ссылки на dbt-модели и репозиторий проекта — в первом комментарии.

#DataEngineering #Airflow #dbt #Architecture #SQL #дата_инженерия