Преимущества Airflow 2.0 по сравнению с предыдущими версиями
Пользовательский интерфейс
Интерфейс Airflow 2.0 выглядит свежим и современным по сравнению с предыдущими версиями. Его основное преимущество заключается в функции автоматического обновления. Вам больше не придется постоянно обновлять браузер, чтобы получить статус рабочего процесса — теперь это происходит автоматически. Отключить эту функцию можно всего одним кликом, как показано на изображении ниже.
Производительность планировщика
Вам больше не придется делать перерыв на кофе после запуска DAG, чтобы увидеть прогресс в рабочем процессе. Производительность обновленного планировщика в десятки раз выше, чем в предыдущих версиях Airflow. Согласно тесту производительности от Astronomer, в зависимости от случая использования планировщик работает до 17 раз быстрее. Кроме того, он автоматически перезапускается, если не получает обновления более 100 секунд.
Полноценный REST API
Предыдущие версии Airflow предоставляли лишь экспериментальный API с ограниченными функциями. В релизе 2.0 доступен полный REST API, который можно использовать для создания, чтения, обновления и удаления DagRuns, переменных, соединений и пулов.
Если Airflow запущен локально, получить доступ к интерфейсу Swagger можно через следующий URL-адрес: http://localhost:8080/api/v1/ui/. Он предоставляет подробную документацию, которая поможет создавать дополнительные функции поверх Airflow, используя различные языки программирования, а не только Python.
Умные сенсоры
Сенсоры — очень коварная функция, так как они постоянно отслеживают статус и иногда потребляют много ресурсов. Обновленный релиз Airflow внес изменения в логику сенсоров, благодаря которой они стали не только экономичнее, но и “умнее”.
И хотя для некоторых действий сенсоры можно заменить на событийно-ориентированные функции AWS Lambda, эта возможность все же пригодится тем, кто хочет сохранить все рабочие процессы в одном месте.
Структура проекта
Airflow окружает приветливое сообщество, которое до этого момента позволяло вносить дополнения в библиотеку операторов, сенсоров и хуков, не задумываясь об их структуре. Со временем airflow.contrib стал настолько большим, что управление зависимостями, а также планирование и тестирование новых релизов, значительно усложнилось.
В Airflow 2.0 структура модулей была изменена в соответствии с внешними системами, которые могут использоваться с Airflow. Если вы хотите использовать операторы, связанные с AWS, но не с GCP и Kubernetes, то сможете установить Airflow только с подпакетом Amazon.
pip install apache-airflow[amazon]
Это изменение позволит разделить ответственности, ускорить циклы выпуска отдельных компонентов и значительно очистить организационную структуру. Убедитесь, что используете правильные импорты при переносе рабочих процессов из предыдущих версий. Например, вместо данного кода:
from airflow.contrib.operators.aws_athena_operator import AWSAthenaOperator
Стоит использовать следующий:
from airflow.providers.amazon.aws.operators.athena import AWSAthenaOperator
Сомнительные обновления
С первого взгляда некоторые из новых абстракций кажутся очень полезными, но, возможно, к ним стоит относиться с осторожностью.
Функция TaskGroup
Эта новая абстракция позволяет работать с группой задач как с одной задачей. Причиной ее создания стало снижение эффективности и ошибки, с которыми сталкивались многие инженеры данных при использовании SubDags. Даже несмотря на то, что эта функция отлично выглядит в пользовательском интерфейсе, она, кажется, не решает реальную проблему разделения ответственностей, которую специалисты пытались решить с помощью SubDags.
Обмен данными между задачами через абстракцию TaskFlow
Абстракция TaskFlow предоставляет возможность обмена данными и позволяет писать простые функции Python вместо операторов Airflow. Это довольно интересная функция, однако трудно назвать ее как преимуществом, так и недостатком новой версии Airflow, поскольку она вызывает больше вопросов, чем дает ответов.
Недостатки Airflow, которые не были устранены в новом релизе
Запутанная логика планирования
Airflow по-прежнему запускает планирование рабочих процессов в конце планировочного интервала. Это означает, что DAG не запустится сразу, а только когда execution_date достигнет start_date + schedule_interval.
Что это значит для конечного пользователя? Если вы видите дату (2020–12–28) последнего запуска (Last Run), установленного на час ночи, как показано на изображении ниже, это не всегда означает, что рабочий процесс был запущен именно в этот период. Это лишь дата выполнения задачи, которая является стартовой отметкой времени запланированного периода рабочего процесса. Само выполнение запускается в конце этого периода. В данном примере задача на самом деле была реализована на день позже. Только у выполняемых вручную задач поле Last Run будет отражать реальное время запуска процесса.
Отсутствие управления версиями конвейеров данных
В Airflow 2.0 вы по-прежнему не можете отслеживать историю версий рабочих процессов. Будем надеяться, что эта возможность появится в следующих релизах.
Перегрузка конфигурации
Airflow разработан для удовлетворения потребностей множества различных групп людей. Он пригодится как для организации контейнерных рабочих процессов в Kubernetes, так и для применения нескольких технологий в качестве предпочтительного брокера сообщений. И все эти возможности объединяются в одном продукте.
Недостатком этого гибкого подхода является дополнительная сложность и большое число параметров, которые необходимо настроить, чтобы подготовить инструмент для своих нужд. Поэтому новым пользователям приходится изучать множество компонентов и обширную терминологию Airflow, чтобы использовать его должным образом.
Например, вам потребуется узнать все нюансы вышеупомянутой логики планирования, синтаксис Airflow, логику исполнителей, брокеров сообщений и очередей Celery. Кроме того, необходимы знания операторов, хуков, XComs, базы данных метаданных, а также способов объединения и поддержки всех этих компонентов.
В некотором смысле это касается любого инструмента. Но в Airflow слишком много специфической терминологии и различных компонентов, что значительно повышает барьер входа. Однако без всех этих знаний не получится эффективно использовать инструмент, а на их получение могут потребоваться временные и денежные затраты. Потенциально всего этого можно избежать, если применять другую платформу с более интуитивными абстракциями.
Исправить эти проблемы помогло бы абстрагирование некоторых внутренних компонентов, не имеющих значения для конечного пользователя. Например, дата начала и выполнения процесса. Гораздо удобнее было бы определить график и развернуть DAG, а остальные задачи предоставить платформе планирования.
Трудности в самостоятельной настройке архитектуры Airflow для производства
Чтобы управлять архитектурой такой сложной платформы, как Airflow, требуются постоянные ресурсы DevOps. Это является недостатком для тех, кто хочет внедрить версию с открытым исходным кодом в системы производства.
Тем не менее некоторые компании могут обеспечить вас необходимыми возможностями, если вы готовы вложиться в их коммерческие предложения Airflow. Организации, принимающие финансовое участие в этом проекте, предоставляют как полностью управляемый сервис для Airflow, так и проводят консультации и обучение. В некоторых случаях все эти услуги предоставляются вместе.
- Astronomer предлагает управляемый сервис с дополнительными функциями поверх версии с открытым исходным кодом, поддержку предприятий, обучение и консультирование. Также среди сотрудников компании есть несколько членов комитета Airflow PMC, вносящих вклад в open-source проект.
- В Polidea также работают несколько членов PMC, но они, похоже, в основном занимаются поддержкой базы кода и предлагают консалтинговые услуги.
- Google предлагает полностью управляемый сервис: Cloud Composer на GCP.
- Amazon предоставляет полностью управляемый сервис, а также гибкость (автоматическое масштабирование) рабочего узла: Managed Workflows для Apache Airflow.
Локальная разработка
Локальная разработка с использованием версии Airflow с открытым исходным кодом вызывает трудности. Как правило, локальная среда полностью отличается от производственной.
CLI astro от Astronomer значительно упрощает работу. С его помощью можно с легкостью инициализировать локальную среду Airflow, поддерживающую контейнеры Docker, включая базу данных Postgres. Кроме того, коммерческое предложение от Astronomer позволяет развернуть DAG в производственной среде, используя простую команду CLI. Поддержка контейнеров поможет обеспечить соответствие среды разработки и производства, а также избежать неприятных сюрпризов при переносе DAG.
Читайте также:
- Об Apache Spark - интересно и со вкусом!
- Apache Spark: гайд для новичков
- Разработка инфраструктуры и торговых ботов для ИИ-трейдинга
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Anna Anisienia: Is Apache Airflow 2.0 good enough for current data engineering needs?
