Управление кодом Airflow
Один из принципов Apache Airflow — пайплайны описываются кодом. Это позволяет относиться к пайплайнам как к любому другому ПО и применять практики вроде версионирования и CI/CD. По мере роста использования Airflow в организации важно организовать код так, чтобы его было удобно поддерживать и масштабировать.
В этом руководстве вы узнаете, как организовать проекты Airflow, когда имеет смысл разносить DAG по разным проектам, как управлять кодом, используемым в нескольких проектах, и как устроен типичный поток разработки.
В руководстве под проектом понимается любой набор DAG и вспомогательных файлов, развёрнутых в одно окружение Airflow (один Airflow Deployment). Например, у команды финансов и команды data science могут быть свои деплойменты и свои проекты Airflow со своим кодом.
Совет. В зависимости от того, как вы запускаете Airflow, можно настроить несколько DAG bundle и подтягивать DAG из нескольких источников в одно окружение. Подробнее: Версионирование DAG и DAG bundles.
Необходимая база
Чтобы получить максимум от руководства, нужно понимать:
- Основные концепции Airflow. См. Введение в Apache Airflow.
Структура проекта
Единообразная структура проекта помогает держать все DAG и вспомогательный код в порядке и упрощает горизонтальное масштабирование Airflow в организации.
Оптимально иметь один каталог и один репозиторий на проект. Тогда всё можно упаковать вместе с помощью системы версионирования (GitHub, Bitbucket и т.д.).
У Astronomer принята такая структура проекта:
.
├── dags # Каталог для всех DAG
│ ├── example-dag.py
│ └── redshift_transforms.py
├── Dockerfile # Образ Docker и переопределения runtime для Astronomer
├── include # Скрипты и файлы, к которым обращаются DAG
│ └── sql
│ └── transforms.sql
├── packages.txt # Пакеты на уровне ОС
├── plugins # Кастомные и community-плагины Airflow
│ └── example-plugin.py
└── requirements.txt # Python-пакеты
Чтобы автоматически создать проект с такой структурой, установите Astro CLI и выполните astro dev init.
Если вы не используете Docker или у организации другие требования, структура может отличаться. Выберите подходящую структуру и придерживайтесь её, чтобы люди, работающие с Airflow, могли легко переключаться между проектами без необходимости привыкать к новой структуре.
Когда выносить DAG в отдельные проекты
Чаще всего весь код одного деплоймента хранится в одном репозитории. Но иногда DAG имеет смысл разделить по разным проектам. В таких случаях хорошая практика — отдельный Airflow Deployment на каждый проект. Разделение может быть оправдано по следующим причинам:
- Управление зависимостями: если у DAG конфликтующие Python- или системные зависимости, один из вариантов — вынести их в отдельные проекты, чтобы изолировать окружения.
- Инфраструктура: если одни DAG лучше подходят под Kubernetes executor, а другие — под Celery executor, их можно разнести по двум проектам с разной инфраструктурой. См. Configure Deployment resources.
- Контроль доступа: разграничение по ролям (RBAC) задаётся на уровне Airflow Deployment, а не на уровне отдельных DAG. Если команда A и команда B должны видеть только свои DAG, логично разделить их на два проекта и два деплоймента.
Иногда нужно разворачивать DAG из нескольких проектов в один и тот же Airflow Deployment. Такой вариант встречается реже и не рекомендуется для организации проектов, если для этого нет явной необходимости. В этом случае сборку файлов из разных репозиториев в один деплоймент нужно реализовать в CI/CD. При использовании Astro Private Cloud для такого сценария потребуются NFS или Git-Sync.
Переиспользование кода
Код, который используется в нескольких проектах (кастомные хуки, операторы, шаблоны DAG), лучше хранить в отдельном репозитории, а не в репозиториях отдельных проектов. Тогда изменения в общем коде делаются один раз и распространяются на все проекты, где этот код используется. Подробнее о структуре и настройке общего кода: Sharing code across projects.
Подключать код из отдельных репозиториев в проекты Airflow можно. При работе с Astronomer см. Install Python packages from private sources. В зависимости от настройки репозиториев это также можно реализовать в CI/CD.
Поток разработки
Описанную структуру проекта можно использовать для разработки DAG и продвижения кода по средам dev, QA и production. Часто для этого используют ветки: один проект и один репозиторий, при этом создаются ветки dev и qa для кода в разработке и тестировании. Ветка main соответствует коду, развёрнутому в production. CI/CD затем управляет продвижением кода между этими тремя ветками.
Реализовать поток разработки для кода Airflow можно по-разному. Например, можно использовать feature-ветки вместо отдельной ветки dev. Выбор подхода зависит от потребностей организации; описанный здесь вариант — хорошая отправная точка, если вы пока не используете CI/CD с Airflow.