В конце 2020 года вышел мажорный релиз Apache AirFlow, основные фишки которого мы рассмотрим в этой статье. Читайте далее про 10 главных обновлений Apache AirFlow 2.0, благодаря которым этот DataOps-инструмент для пакетных заданий обработки Big Data стал еще лучше.
10 главных обновлений Apache AirFlow 2.0
Напомним, разработанный в 2014 году в компании Airbnb, через 2 года AirFlow был передан в фонд Apache Software Foundation. С 2019 года этот фреймворк официально стал проектом Apache 1-го уровня. Об основных функциональных возможностях Apache Airflow с примерами практического использования мы рассказывали здесь, а разбору основных достоинств и недостатков этого DataOps-инструмента автоматизации повторяющихся batch-задач обработки больших данных посвятили эту статью.
Полный список изменений в новой версии Airflow, вышедшей в декабре 2020 года, составил около 3000 строк кода, добавлено множество новых функций и исправлены сотни ошибок. Из всех этих дополнений наиболее важными можно назвать следующие.
Новый планировщик заданий
Scheduler с низкой задержкой и высокой доступностью, который поддерживает одновременный запуск нескольких экземпляров в активной модели. В сочетании с сериализацией DAG это значительно ускоряет работу и обеспечивает неограниченное горизонтальное масштабирование через запуск дополнительных реплик для увеличения пропускной способности системы. А в случае сбоя задачи восстанавливаются мгновенно с нулевым временем простоя. Также версия 2.0 облегчает работу Data-инженера, позволяя пользователям вносить изменения в отдельные планировщики, без простоев и влияния на остальные. Примечательно, что один из тестов показал 10-кратное ускорение синтаксического анализа DAG, значительно увеличив общую производительность Airflow. Разумеется, такое повышение скорости работы планировщика не означает 10-кратного сокращения длительности выполнения всех задач [2].
Data Pipeline на Apache Airflow
Код курса
AIRF
Ближайшая дата курса
27 ноября, 2024
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
Комплексный RESTful API
На нем основан новый пользовательский интерфейс и CLI-интерфейс Airflow. Это обеспечивает легкий доступ третьим лицам для CRUD-операций над всеми ресурсами Airflow и включает возможности авторизации. Теперь пользователи могут программно устанавливать соединения и переменные, отображать ошибки импорта, создавать пулы и отслеживать состояние базы данных метаданных и планировщика [1].
Умные датчики (smart sensor)
Это особый вид операторов, цель которого в ожидании определенного триггера, например, успешного завершения внешней задачи. Хотя датчики простаивают большую часть времени выполнения, они держат «рабочий слот», который потребляет ресурсы ЦП и памяти. Smart Sensor в Airflow 2.0 играет роль функции раннего доступа, которая выполняется как одна длительная задача, проверяет статус пакета задач Sensor и сохраняет информацию о состоянии датчика в базе данных метаданных. Эта возможность была предложена и реализована Airbnb на основе их опыта масштабного развертывания Airflow с десятками тысяч DAG. По результатам тестирования в Airbnb, Smart Sensors сократил количество занятых рабочих слотов более чем на 50% для одновременных нагрузок при пиковом трафике [1]. Подробнее, как работают интеллектуальные датчики, читайте в нашей новой статье.
API TaskFlow
Он упрощает создание групп DAG, абстрагируя уровень управления задачами и зависимостями от пользователей. Основным механизмом здесь по-прежнему является XCom (cross-communication), технология обмена сообщениями между задачами в одном DAG’е, которая определяется парой ключ-значение и названием задачи, откуда XCom отправили. XCom создаётся в PythonOperator’е на основании возвращаемого им значения. Можно создать XCom вручную с помощью функции xcom_push. После выполнения задачи значение сохраняется в контексте, и любая последующая задача может принять XCom функцией xcom_pull() в другом Python-операторе или из шаблона jinja внутри любой предобработанной строки [3]. Данные по-прежнему хранятся в базе данных метаданных Airflow, но в 2.0 сама операция XCom скрыта внутри PythonOperator и полностью абстрагируется от разработчика DAG. Теперь пользователи Airflow могут передавать информацию и управлять зависимостями между задачами стандартным Python-способом с использованием декораторов для более чистого и эффективного программного кода. В частности, написав DAG-задачи как вызовы функций, можно подключить ввод и вывод оператора, как в любом Python-скрипте. Такой подход с использованием декоратора обеспечивает более краткий и понятный способ определения DataOps-конвейеров, экономя до 50% усилий инженера Big Data за счет фокуса на бизнес-логике, а не на оркестровке кода. Это обеспечивает возможность повторного использования, позволяя пользователю легко распределять задачи между разными группами DAG. Decorated Flows обеспечивает более чистый, лаконичный и интуитивно понятный способ построения ETL-pipeline’ов [2]. Кроме того, Airflow 2.0 включает поддержку нового параметра xcom_backend, который позволит пользователям передавать еще больше объектов между задачами. В ближайшее время ожидается готовая поддержка AWS S3, Apache Hadoop HDFS и других хранилищ Big Data [1].
Группы задач (Task Groups)
Эта конструкция пользовательского интерфейса, которая не влияет на поведение при выполнении задач, но выполняет основную задачу вложенных файлов DAG. Это дает автору DAG преимущества управления, позволяя группировать логический набор задач друг с другом без необходимости обрабатывать их по-разному. Ожидается, что группы задач в будущем заменят оператор SubDAG, задачи которого могут выполняться только последовательным исполнителем, независимо от того, что используется для всех других задач, усложняя работу пользователя и снижая надежность [1]. Подробнее о том, как работать с группами задач в AirFlow, читайте в нашей новой статье.
Код курса
ADH-AIR
Ближайшая дата курса
по запросу
Продолжительность
ак.часов
Стоимость обучения
0 руб.
Независимые провайдеры (Independent Providers)
Они обеспечивают интеграцию с различными облачными источниками данных (AWS, GCP, Microsoft Azure, Snowflake, Slack и пр.) В Airflow 2.0 провайдеры выделены в отдельный каталог airflow/provider, чтобы их можно было выпускать и управлять версиями независимо от основного дистрибутива системы. Благодаря этому можно устанавливать самые последние версии пакетов Provider независимо от основных выпусков Airflow. Справедливости ради стоит отметить, что некоторые операторы, в том числе Bash и Python, остаются в основном дистрибутиве, учитывая их широкое использование [1]. Подробнее о том, что представляет собой это новинка, чем она особенно полезна дата-инженеру и как создать свой собственный провайдер, читайте в нашей новой статье.
Упрощение развертывания в Kubernetes
Это касается архитектуры KubernetesExecutor и KubernetesPodOperator, которые позволяют пользователям гибко настраивать и динамически запускать задачи как отдельные модули Kubernetes для оптимизации общего потребления ресурсов. Теперь имеется доступ к полному API Kubernetes для создания yaml «podtemplatefile» вместо ограничений частичного набора конфигураций в файле airflow.cfg. Также словарь executor_config заменен параметром pod_override, который принимает объект Kubernetes V1Pod для понятной настройки [1].
Визуальное обновление пользовательского интерфейса
Одним из наиболее полезных функций которого является возможность мониторинга выполнения задачи в режиме реального времени без необходимости вручную обновлять страницу. Также улучшены UI/UX-характеристики значков, цветов, типографики и навигации верхнего уровня, повышена доступность и удобочитаемость, разделены действия и ссылки в навигации по DAG, добавлена кнопка сброса представления DAG после выполнения поиска [1].
Безопасность
Повышение безопасности и сокращение зон воздействия, например, в новом REST API все операции теперь требуют авторизации. Аналогично, в настройках конфигурации теперь нужно указывать ключ Fernet [4].
Оптимизация настроек
Конфигурация файла airflow.cfg была дополнительно рационализирована в отдельных разделах, в частности, вокруг ядра (core). Устранены устаревшие конфигурационные параметры, а некоторые перемещены в отдельные файлы конфигурации для конкретных компонентов, например, файл шаблона pod для конфигурации, связанной с выполнением Kubernetes [4].
Об особенностях перехода на новую версию AirFlow 2.0 на практическом примере мы расскажем завтра. О новинках релиза 2.2.0 читайте здесь.
А освоить тонкости инженерии больших данных на примерах практического использования и администрирования Apache Airflow вы сможете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
