19 сентября 2022 года вышел очередной релиз Apache AirFlow, а через пару недель выпущены его минорные обновления. Что нового в выпуске 2.4, чем полезен новый класс Dataset, что такое наборы данных, какие триггеры позволят запускать задачи и DAG в стиле cron-соглашений, зачем убрали интеллектуальные датчики и другие важные фичи, исправления и улучшения самого популярного ETL-планировщика для дата-инженера.
Краткий обзор Apache AirFlow 2.4
Apache Airflow 2.4 содержит более 45 новых функций, 40 улучшений, 50 исправления ошибок и изменения в документации. Ключевыми изменениями являются следующие:
- новая функция, которая позволяет разработчикам DAG создавать более мелкие, автономные группы цепочки, которые объединяются в крупный рабочий процесс. Эти наборы данных представляют собой абстрактную концепцию и пока не имеют возможности прямого чтения или записи, но они ускоряют планирование ETL-конвейеров, работая быстрее ExternalTaskSensor и TriggerDagRunOperator.
- упрощение управления конфликтующими зависимостями Python с помощью нового ExternalPythonOperator. Его декоратор @task.external_python позволяет запускать функцию Python как задачу AirFlow в предварительно настроенной виртуальной среде или даже в совершенно другой версии Python.
- динамическое сопоставление задач теперь включает поддержку expand_kwargs, чтобы назначить несколько параметров оператору, отличному от TaskFlow и преобразовать параметры непосредственно перед запуском задачи. Также добавлена поддержка дополнительных типов ввода для использования с функцией динамического сопоставления задач.
- Новый триггер CronTriggerTimetable делает синтаксис планирования AirFlow более похожим на cron, привычный большинству дата-инженеров;
- Наконец, сделаны значительные улучшения пользовательского интерфейса, включая возможность детализировать файлы журналов из представления сетки.
Еще Apache AirFlow 2.4 включает следующие добавления:
- декораторы @task.short_circuit и @task.kubernetes;
- команда удаления ролей в CLI и поддержка TaskGroup в ExternalTaskSensor;
- экспериментальный parsing_context, чтобы включить оптимизацию динамической обработки DAG в рабочих процессах;
- отображение неконфиденциальных значений конфигурации во вкладке администрирования (Admin -> Configuration);
- имя оператора отдельно от класса, т.е. больше нет _PythonDecoratedOperator при использовании TaskFlow.
Рассмотрим некоторые из этих новинок более подробно.
Улучшения в планировании DAG
Главной новой функцией планирования в AirFlow 2.4 является новая управляемая данными логика на основе наборов данных. Это позволяет автоматически запускать подчиненные DAG после успешного завершения их восходящих зависимостей. Используя новый класс Dataset для определения зависимостей между конкретными восходящими задачами и нижестоящими DAG, можно разбить монолитные конвейеры и запустить вместо них несколько более мелких цепочек, которые проще разрабатывать и поддерживать. Такое планирование на основе данных взаимозаменяемо и его можно адаптировать ко многим сценариям использования, включая обслуживание ML-моделей. Это является ключевым преимуществом Apache AirFlow по сравнению со многими другими оркестраторами, что мы разбираем в нашей новой статье.
Ранее дата-инженерам, которые разрабатывали DAG, приходилось писать, отлаживать и поддерживать собственную логику для управления зависимостями данных. Для этого можно было использовать перекрестные зависимости DAG или вводить собственные внешние зависимости, а также применять сенсоры (датчики) – специальный тип операторов для запуска зависимых задач.
Другим распространенным решением было объединение всех зависимостей в единую монолитную DAG. Это гарантировало, что успешный запуск восходящей задачи автоматически вызовет подчиненные задачи в той же DAG, а в случае сбоя вышестоящей зависимости нижестоящие задачи не будут выполняться. Такой подход исключал разработку собственных датчиков задач для контроля, но монолитные DAG обычно трудны для отладки и обслуживания, а также подвержены сбоям, поскольку при отказе одной задачи происходит сбой всей DAG. Кроме того, крупные монолитные DAG обычно не подлежат повторному использованию и не дают визуализировать и отслеживать наборы данных в AirFlow.
Поэтому в релизе 2.4 представлен класс Dataset, который дополняет AirFlow встроенной логикой, необходимой для запуска и управления различными типами зависимостей, управляемых данными, предоставляя единый унифицированный интерфейс для передачи сигналов между задачами.
Планирование на основе данных работает на уровне задачи: следует создать класс Dataset и связать его с конкретной задачей, которая становится продюсером для одной или нескольких нижестоящих DAG-потребителей. Успешный запуск задачи-продюсера автоматически запускает запуск любого DAG-потребителя. Таким образом, восходящий DAG может состоять из сотен задач, из которых лишь одна создает набор данных, от чего зависит DAG-потребитель. Или вышестоящий DAG может содержать десятки задач-продюсеров, каждая из которых соответствует отдельному DAG-потребителю.
Запуская управляемые данными зависимости на уровне задач, потребительские DAG могут запускаться раньше, позволяя своевременно обновлять данные, используемые отчетами, информационными панелями, оповещениями и другими аналитическими данными.
Например, есть одна или несколько задач-продюсеров, которые обновляют таблицы измерений и фактов в хранилище данных. Как только эти задачи запускаются и успешно завершаются, AirFlow узнает о необходимости запуска любых DAG-потребителей, которые зависят от этих данных. По сути, объект класса Dataset — это любой результат задачи-продюсера, например, файл JSON или CSV, столбец в таблице Apache Iceberg, таблица или столбец таблицы базы данных и т.д. Такой набор данных обычно используется в качестве источника данных для одного или нескольких DAG-потребителей. DAG-потребитель может, например, сжать несколько исходных наборов данных в CSV-файлы, которые далее будут загружаться в инструменты визуализации данных или BI-системы. Или DAG-потребитель может извлекать данные из нескольких восходящих CSV-файлов, файлов Parquet и таблиц базы данных для создания обучающих датасетов для моделей машинного обучения. Примечательно, что новый класс Dataset поддержан пользовательским интерфейсом Apache AirFlow 2.4 благодаря вкладке «Наборы данных», где отображаются существующие объекты наборов данных.
На данный момент планирование на основе данных в AirFlow 2.4 имеет одно существенное ограничение: зависимости наборов данных пока не охватывают отдельные развертывания: не может быть запуска задачи-продюсера в одном развертывании, запускающего запуск DAG-потребителя в другом. Тем не менее, эта новая функция упрощает отслеживание и визуализацию наборов данных в Apache AirFlow, а также улучшает их управление и качество данных, используемых для их создания. Дата-инженер сможет быстрее выявлять избыточные, редко используемые или неполные наборы данных, а также те, которые содержат конфиденциальную информацию. Подробнее про наборы данных мы рассказываем в новом материале. А о другом инструменте обеспечения качества и надежности данных читайте в этой нашей статье.
Помимо наборов данных, в AirFlow 2.4 введен еще один полезный параметр консолидированного расписания запуска DAG. Ранее разработчикам DAG приходилось использовать schedule_interval и timetable, чтобы указать фреймворку, когда запускать конвейеры. В новой версии объединили функции нескольких параметров в один новый schedule_on: расписание, которое может принимать выражения cron, а также объекты timedelta, timetable и набора данных. Хотя schedule_interval и timetable теперь считаются официально устаревшими, фреймворк еще их поддерживает до выхода нового крупного релиза.
Еще одно изменение, связанное с планированием в AirFlow 2.4, это триггер CronTriggerTimetable. Это расписание cron, которое сообщает планировщику AirFlow использовать соглашения, подобные cron. Ранее фреймворк запускал экземпляры ежедневных задач через 24 часа после их указанного времени запуска. Например, если выполнение задачи запланировано на воскресенье в 12:00, она фактически запустится в понедельник в 12:00. Аналогичный интервал был по умолчанию для ежечасных задач: если задача запланирована с 9 до 10 утра, она фактически не запустится до 10 утра. Интервал задержки имел смысл для определенных типов пакетных заданий, таких как дневные отчеты, но часто становился источником путаницы для дата-инженеров и новых пользователей AirFlow. Теперь задачи могут выполняться в указанный вами пользователем день и время согласно соглашениям cron.
Также в Apache AirFlow 2.4 расширены возможности динамического сопоставления задач Airflow за счет поддержки расширенных типов ввода, а именно expand_kwargs и expand_zip. Эти дополнения помогают уменьшить объем кода, который необходимо писать и поддерживать разработчикам DAG, поскольку, как и ранее описанного нового класса Dataset, логика перенесена в сам фреймворк.
Дополнительным преимуществом новой версии стало улучшение пользовательского интерфейса, который теперь предоставляет больше информации о запланированных и выполняющихся конвейерах обработки данных. В частности, есть возможность повторного использования оформленных групп задач, что упрощает размещение повторяющихся шаблонов в DAG. Также появилась детализации журналов из представления сетки по умолчанию, что позволяет пользователям увидеть лог-файл сразу вместо перенаправления на другую страницу.
Гибкие отложенные операторы вместо интеллектуальных датчиков
В Airflow 2.4 устранены интеллектуальные датчики (сенсоры) – специальный тип операторов для выполнения только одной задачи, например, запуск в ответ на определенные события. Впервые они были представлены в версии 2.0 в декабре 2020 года в качестве экспериментальной функции, о чем мы писали здесь. Хотя в целом интеллектуальные датчики полезны, у них есть ряд недостатков: они работают только для ограниченного диапазона рабочих нагрузок и только в контексте пользовательской DAG. В версии 2.2 для решения этих проблем были представлены отложенные операторы для асинхронной работы, включая два новых асинхронных датчика, TimeSensorAsync и DateTimeSensorAsync. Отложенные операторы более гибки и надежны для запуска событий в стиле датчика, поддерживают широкий спектр сценариев и рабочих нагрузок. Функционально они намного превосходят возможности интеллектуальных датчиков, поэтому в AirFlow 2.2.4 поддержка интеллектуальных датчиков была официально прекращена. В версии 2.4 они больше не поддерживаются. Поэтому теперь дата-инженерам, которые использовали собственные интеллектуальные датчики в своих конвейерах обработки данных, следует переопределить их как отложенные операторы. О том, что нового появилось в релизе 2.5, читайте в нашей новой статье.
Больше полезных приемов администрирования и эксплуатации Apache AirFlow для дата-инженерии и аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
