30 апреля 2022 года вышел новый релиз Apache Airflow, который содержит более 700 коммитов с предыдущей версии 2.2.0 и включает 50 новых функций, 99 улучшений, 85 исправлений ошибок и несколько изменений в документации. Разбираемся, что особенно важно для дата-инженера в Apache Airflow 2.3.0.
ТОП-7 главных фич Apache AirFlow 2.3.0: краткий обзор
Наиболее значимыми нововведениями в свежем выпуске Apache Airflow можно назвать следующие:
- динамическое сопоставление задач позволяет запускать задачи на основе непредсказуемых входных условий;
- улучшение представления сетки вместо дерева;
- новый Kubernetes-исполнитель LocalKubenetesExecutor для баланса компромиссов между LocalExecutor и KubernetesExecutor;
- новая конечная точка REST API для массовых приостановок и возобновлений DAG;
- новый API-интерфейс Listener-плагина для отслеживания изменений состояния экземпляра задачи (TaskInstance);
- возможность хранить подключения Airflow в формате JSON вместо URI;
- возможность вызывать команду повторной сериализации DAG из CLI-интерфейса.
Из перечисленных новых фич стоит особенно отметить API динамического сопоставления задач. Это особенно полезно, когда заранее неизвестно, сколько файлов, кортежей, моделей и прочих единиц информации нужно обработать. Теперь дата-инженер может сопоставлять задачи с переменными, конфигурациями DAG и таблицами базы данных. Вместо того, чтобы вручную вызывать оператора для выполнения этих и подобных задач, Airflow динамически изменяет топологию пользовательского рабочего процесса во время выполнения.
Также важен локальный исполнитель Kubernetes, который позволяет пользователю выбирать, какие задачи отправить в новый под кластера Kubernetes . Можно использовать локальный исполнитель Airflow для запуска задач в службе планировщика или отправлять их к конкретному поду K8s. Это пригодится для исполнения легковесных задач в локальном исполнителе Airflow без запуска нового пода Kubernetes. Почему может возникнуть сбой задач DAG в кластере Kubernetes, и как с этим справиться, мы рассказываем здесь и здесь.
В целом можно отметить, что по мере развития этого ETL-инструмента в Airflow устраняется все больше рутинных работ, которую раньше выполняли дата-инженеры вручную. В частности, API динамического сопоставления задач формализует и интегрирует логику для конкретного сценария, что ранее пришлось бы программировать и поддерживать. Airflow упрощает для всех пользователей разработку своих задач по определенным шаблонам — ETL, ELT, продолжительные задачи, CDC-сбор измененных данных и пр. без необходимости писать и поддерживать собственный код для этих паттернов. Таким образом, Apache Airflow становится более интеллектуальным инструментом современного дата-инженера, позволяя ему сосредоточиться на оптимизации производительности и надежности практических бизнес-задач.
10 главных изменений нового релиза
Также отметим важные изменения в AirFlow 2.3:
- отменена передача параметра execute_date в методы set(), XCom.clear(), XCom.get_one() и XCom.get_many(). Теперь, согласно идее привязки TaskInstance к DagRun, записи XCom также привязаны к DagRun. Вместо параметра execute_date используется аргумент run_id, чтобы указать DagRun. XCom теперь определяется по run_id, а не по execute_date. Столбцы execute_date в XCom были удалены из базы данных и заменены полем прокси-ассоциации на уровне ORM. При обращении к базе данных метаданных Airflow напрямую следует переписать реализацию, чтобы использовать столбец run_id. При этом определение базы метаданных Airflow как на уровне базы данных, так и на уровне ORM считается деталью реализации без строгих гарантий обратной совместимости.
- Шаблоны логов задач считываются из базы метаданных вместо конфигурационного файла airflow.cfg. Раньше лог задачи динамически отображался из значений конфигураций [core] log_filename_template и [elasticsearch] log_id_template во время выполнения. Это приводило к неудачным характеристикам, поскольку изменять значение конфигурации после того, как экземпляр Airflow некоторое время работает, нецелесообразно, т.к. все существующие логии задач сохранены в предыдущем формате и не могут быть найдены с новым значением конфигурации. Для решения этой проблемы введена новая таблица log_template. Эта таблица синхронизируется с вышеупомянутыми значениями конфигурации каждый раз при запуске Airflow, и новое поле log_template_id добавляется к каждому запуску DAG, чтобы указать формат, используемый задачами. При этом значение NULL указывает на первую запись для совместимости. Изменены шаблоны по умолчанию для имен лог-файлов и elasticsearch log_id для поддержки динамического сопоставления задач. Теперь шаблоны задач с динамическим сопоставлением содержат {{ ti.map_index }}.
- Обновлена минимальная версия библиотеки kubernetes с 3.0.0 до 21.7.0. Важно, что речь идет только об изменении библиотеки kubernetes, а не кластера Kubernetes. Это было необходимо, чтобы воспользоваться обновлением токенов Kubernetes API с помощью EKS.
- Параметры, не поддерживающие сериализацию JSON, устарели. Ранее можно было использовать значения по умолчанию для параметров dag или task, которые не допускали сериализации JSON. Это вызывало проблемы с использованием типов set и datetime, которые не поддерживают сериализацию JSON и являлись неопределенными. Использование параметров, не поддерживающих сериализацию JSON, будет удалено в мажорном релизе Airflow 3.0, а пока их использование будет вызывать предупреждение во время синтаксического анализа. Также отменено обязательное представление файла Connection.extra в формате JSON.
- При использовании библиотеки SQLAlchemy 1.4.0+ теперь нужно использовать postgresql:// вместо postgres:// в качестве схемы в файле sql_alchemy_conn.
- Вместо параметра конфигурации auth_backend теперь используется auth_backends для поддержки нескольких серверных частей, разделенных пробелами. Каждый бэкэнд будет опробован по очереди, пока не будет возвращен успешный ответ. Параметр auth_backends теперь включает сеанс. Чтобы разрешить пользовательскому интерфейсу Airflow использовать API, предыдущий сервер авторизации по умолчанию api.auth.backend.deny_all изменен на airflow.api.auth.backend.session и автоматически добавляется в список серверов авторизации API, если задано значение не по умолчанию.
- Пустой класс airflow.models.base.Operator, ранее использующийся для подсказки типа данных, теперь удален. Вместо него рекомендуется применять BaseOperator для конкретных операторов, базовый класс models.abstractoperator.AbstractOperator или airflow.models.operator.Operator.
- Zip-файлы в папке DAG больше не могут иметь расширение .py. Теперь файлы .py будут загружаться как модули без проверки на сжатие, чтобы сократить количества операций ввода-вывода. Если файл .py в папке DAG представляет собой сжатый ZIP-архив, его синтаксический анализ завершится ошибкой с исключением.
- Метод get_link BaseOperatorLink() изменен, чтобы принимать аргумент ключевого слова ti_key для TaskInstanceKey, поскольку execute_date + task больше не является уникальным для сопоставления операторов из-за отмены параметра execute_date еще в Apache AirFlow версии 2.2.
- Класс ReadyToRescheduleDep теперь запускается, только если для изменения расписания установлено значение True. Теперь при запуске он проверяет, задан ли атрибут оператора reschedule, и сообщает о себе как о пройденном, если для него не установлено значение True. При использовании этого dep-класса в пользовательских операторах нужно добавить этот атрибут. Для поддержки сопоставления операторов атрибут deps в классе операторов должен быть установлен на уровне класса. Это означает, что если пользовательский оператор реализует это как переменную уровня экземпляра, его нельзя использовать для сопоставления операторов.
Код курса
ADH-AIR
Ближайшая дата курса
Продолжительность
ак.часов
Стоимость обучения
0 руб.
В следующий раз мы рассмотрим некоторые динамическое сопоставление задач Apache AirFlow 2.3. более подробно. А освоить все тонкости администрирования и эксплуатации этого инструмента дата-инженерии для организации ETL/ELT-процессов в аналитике больших данных вы можете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
