Интеграция Apache Airflow с инструментами CI/CD является одной из лучших практик современной дата-инженерии, о чем мы недавно писали. Читайте далее, зачем нужно управлять кодом DAG с помощью популярных систем управления версиями и как это сделать на примере GitLab CI/CD.
Сложности управления DAG в разных средах AirFlow
Apache Airflow считается наиболее популярным open-source инструментом современной инженерии данных для программного управления и оркестрации пакетных процессов. Однако, при запуске масштабных и сложных ETL-процессов на Airflow дата-инженер может столкнуться со следующими проблемами:
- сложности принятия решений о процессах развертывания для разных сред (разработки, тестирования и производства);
- трудности определения структуры разработки рабочего процесса на всех этапах.
Кроме того, несмотря на популярный Python для разработки кода задач и операторов в Airflow, этот фреймворк требует тщательной настройки для идеальной интеграции в любую заданную цепочку процессов. Он представляет собой инженерную платформу для пользователей, которые умеют программировать на Python. Отсутствие пользовательского интерфейса для создания рабочих процессов в виде направленных ациклических графов (DAG) повышает порог входа в технологию. Для работы нужно не только написать код на Python, определяющий DAG, но и поместить этот файл в соответствующий каталог Airflow, чтобы он был распознан и исполнен. Кроме того, не рекомендуется помещать пользовательский код в файл определения DAG. В частности, при разработке собственного оператора или сенсора следует поместить этот код в особое место в среде Python, которая управляет Airflow, чтобы запустить его в DAG.
Все это быстро и просто реализуется на одном компьютере, где все компоненты Airflow запускаются в виде Docker-контейнеров. Но все становится намного сложнее, когда процессы должны выполняться в нескольких средах, управляемыми разными командами. В частности, возникают следующие вопросы:
- как разработчики DAG взаимодействуют с Airflow?
- как тестируются DAG?
- как и когда следует развертывать DAG и плагины?
- кто отвечает за разные аспекты конвейера развертывания?
Как ответить на эти вопросы и решить возникающие проблемы в рамках интеграции AirFlow с CI/CD-инструментами, мы рассмотрим далее.
Подходы реализации CI/CD для DAG AirFlow
Популярные DevOps-термины «непрерывная интеграция» и «непрерывная поставка» (CI/CD) обобщают методы и стратегии повышения качества разработки ПО за счет автоматического тестирования и запуска кода в целевой среде. Фреймворки CI/CD позволяют выполнять все виды автоматизированных этапов процесса на основе изменений, происходящих в базе исходного кода. Поскольку Airflow и все его компоненты определены в исходном коде, этот DevOps-подход можно использовать для создания надежной среды разработки и развертывания с помощью инструментов CI/CD.
Сегодня на рынке есть множество CI/CD-движков: GitLab CI/CD, Azure Pipelines, AWS Code Pipelines, Bitbucket Pipelines, Jenkins, Drone, Woodpecker CI, Travis CI и пр. Выбор того или иного варианта зависит от используемого репозитория кода и инфраструктуры, но принцип работы для всех CI/CD-решений будет примерно одинаковым.
Например, при использовании Gitlab CI/CD общий план модели Git-ветки для управления DAG Airflow выглядит следующим образом: создается ветвь разработки, в которой код DAG итеративно тестируется этапами задания CI/CD и развертывается в промежуточной среде. Свежеразработанный код DAG развертывается в производственной среде после слияния с основной веткой.
При этом следует решить, насколько сильно или слабо будет связано развертывание платформы Airflow с процессом разработки DAG. Слабой связи можно добиться, создав собственный Docker-образ Airflow, который содержит все пользовательские DAG и их зависимости. В этом случае всю систему необходимо повторно развертывать при изменении в любом DAG. Слабая связь может быть достигнута за счет строгого разделения платформы Airflow и разработки DAG. Измененный код DAG будет доставлен в работающую базовую систему без запуска полного повторного развертывания. Выбор слабой или сильной связи зависит от множества факторов: количество DAG, которые надо запустить, количество команд или людей, разрабатывающих DAG, сложности самих рабочих процессов и количество зависимостей пользовательских модулей Python.
В целом слабая связанность лучше масштабируется с большим количеством DAG и разработчиков или когда ответственность за рабочие процессы распределяется между несколькими командами. Чем слабее связь, тем более независима разработка DAG от операций системы Airflow. Сильная связь может уменьшить сложность общей структуры, поскольку задачи централизованы в одном месте. Ни один из подходов полностью не отделяет работу платформы от разработки DAG, но выбор влияет на фактическую реализацию конвейера CI/CD и взаимодействие между разными конвейерами.
Рассмотрим особенности слабосвязанного развертывания на примере GitLab CI/CD. Конвейеры разработки DAG должны предоставлять разработчикам простой способ создания новых DAG, их автоматического изолированного тестирования (модульные тесты) и прогон интеграционных тестов. После этого Airflow берет на себя функции оркестровки и запускает задачи по расписанию. Четко определенный CI/CD-конвейер может сократить фактическую ответственность разработчиков до простого предоставления нового исходного кода DAG и тестовых определений в нужном месте, то есть в правильном репозитории Git.
Код курса
ADH-AIR
Ближайшая дата курса
по запросу
Продолжительность
ак.часов
Стоимость обучения
0 руб.
Выстраивание конвейера CI/CD зависит от того, как развертываются системы Airflow и как артефакты на основе кода должны распространяться в системе. Это может означать доставку файлов DAG в правильный каталог в файловой системе хост-сервера или загрузку файлов в службу хранилища объектов типа AWS S3 при использовании соответствующего облачного сервиса Airflow, управляемого Amazon. Как это реализовано в немецкой консалтинговой компании NextLytics, мы рассмотрим далее.
Практический пример c GitLab
Дата-инженеры NextLytics используют GitLab в качестве системы управления версиями исходного кода и интегрированную среду GitLab CI/CD для автоматизации тестирования и развертывания. В рамках слабо связанного подхода развертывание и эксплуатация базовой системы Airflow отделено от процесса разработки DAG. Airflow запускается на удаленном хост-сервере с использованием Docker. Модули Python, DAG, операторы и подключаемые модули Airflow распространяются в работающей системе путем размещения/обновления файлов в определенных каталогах файловой системы на удаленном хосте, которые монтируются в Docker-контейнеры. Опция отложенной загрузки (lazy loading) Airflow отключена, чтобы система регулярно проверяла измененные или обновленные модули.
Все DAG для экземпляра Airflow разрабатываются в едином Git-репозитории проекта в GitLab. Проверка исходного кода обеспечивается настройками GitLab: изменения могут быть объединены в основную ветку только через запрос на слияние (Merge Request), который требует кросс-проверки несколькими разработчиками. После успешной проверки и слияния, а также прохождения всех этапы тестирования CI-конвейер продвигается дальше.
Исходный код разделен на подкаталоги для DAG, операторов AirFlow и пользовательских модулей Python. Их содержимое копируется в соответствующие каталоги, смонтированные в среде выполнения Airflow на этапе развертывания конвейера CI/CD.
Тестирование новых разработанных DAG проходит в 3 этапа:
- проверка синтаксиса Python-кода и успешное прохождение всех модульных тестов;
- проверка отсутствия ошибок при импорте DAG в Airflow;
- проверка безошибочного запуска DAG в Airflow.
Первый из этих этапов является автономным в том смысле, что он зависит только от измененного кода и связанных с ним тестов, реализованных разработчиком. Второй и третий этапы требуют среды Airflow для выполнения теста, которую можно создать «на лету» во время выполнения конвейера. Одноразовая среда Airflow будет создана, использована для двух тестов, а затем снова полностью утилизирована с помощью команд Docker, указанных в манифесте CI/CD.
Некоторые детали реализации этапа развертывания конвейера снова нужно настроить, выбрав один из нескольких вариантов, предлагаемых GitLab CI/CD. Удаленное выполнение кода на хост-сервере можно включить, настроив выделенную службу «GitLab Runner» или удаленно войдя с помощью SSH-протокола. Доставка измененных файлов может быть достигнута путем явной отправки в удаленную файловую систему или через проверку всего репозитория Git на удаленном хосте. Выбор варианта зависит от многих факторов, включая корпоративные особенности или предпочтения дата-инженеров. Впрочем, внедрение полноценных тестов по-прежнему сильно зависит от разработчиков, а создание необходимой единовременной среды для полного интеграционного тестирования требует более глубоких знаний CI/CD-инфраструктуры и сторонних сервисов, с которыми должны взаимодействовать DAG.
Все подробности администрирования и эксплуатации Apache AirFlow для организации ETL/ELT-процессов в аналитике больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
