5 преимуществ разделения пакетов в Apache AirFlow 2.0 или как создать свой провайдер с блэкджеком и хуками

курсы по Airflow, Apache Airflow обучение, курсы дата-инженеров, обучение инженеров Big Data, инженерия больших данных, Apache AirFlow 2.0 providers

Чтобы добавить в наши обновленные авторские курсы для дата-инженеров по Apache AirFlow еще больше интересного, сегодня продолжим разбирать полезные дополнения релиза 2.0 и поговорим, почему разделение фреймворка на пакеты делает его еще удобнее. Также рассмотрим практический пример создания общедоступного провайдера из локального Python-пакета с собственными операторами, хуками и прочими компонентами.

Зачем вам разные провайдеры: ТОП-5 преимуществ разделения пакетов в версии 2.0

В 1-ой версии Apache Airflow представлял собой монолит, включающий основную систему планирования и все интеграции с внешними сервисами. Изначально все было упаковано в единый пакет apache-airflow. Но это не очень удобно в плане управления зависимостями и обновления отдельных модулей. Поэтому в Airflow версии 2.0 реализована другая организация внутренних компонентов – пакетов. Airflow 2.0 состоит из более чем 60 пакетов, включая как основное ядро фреймворка (core — apache-airflow), а также отделенные от него операторы Google, Amazon, AWS, Postgres, HTTP и пр., называемых провайдерами (provider). Каждый провайдер имеет свой собственный пакет и упакован в airflow.providers с полностью контролируемыми и задокументированными зависимостями. К примеру, есть пакет apache-airflow-provider-amazon или apache-airflow-provider-google [1].

Можно установить пакеты провайдеров отдельно или автоматически при наличии соответствующих дополнений. В частности, здесь мы рассказываем про открытый реестр провайдеров AirFlow от Astronomer – каталог пакетов для решения конкретных задач средствами этого фреймворка.

Некоторые версии пакетов провайдеров могут зависеть от конкретных версий Airflow, но в целом все новые версии провайдеров должны работать с последними версиями Airflow 2.x. Иначе ограничения зависимостей будут включены в пакет провайдера. Провайдеры могут содержать операторы, датчики (сенсоры), хуки (hooks) и прочие элементы DAG/задач, которые также могут расширять ядро ​​Airflow. Фреймворк автоматически обнаруживает, какие провайдеры добавляют эти дополнительные возможности, и после установки пакета и перезапуска Airflow они автоматически становятся доступными для пользователей. Это включает добавление дополнительных ссылок на операторов провайдера и настройку подключения с указанием его типов, расширением формы и обработкой поведения.

Напомним, в Airflow хуки – это точки подключения фреймворка к сторонним сервисам и библиотекам. К примеру, JiraHook откроет клиент для взаимодействия с Jira, а — SambaHook позволит отправить локальный файл на smb-точку [2]. Обширный список провайдеров в одном открытом и бесплатном реестре собрала компания Astronomer, которая занимается коммерциализирует Apache AirFlow. Подробнее об этом мы рассказываем здесь.

Таким образом, отделение провайдеров от ядра AirFlow дает пользователю следующие преимущества [1]:

  • упрощение развертывания, особенно при использовании конвейнеров на Docker, Kubernetes или другой контейнерной платформе. Кстати, официальный образ Airflow Production Reference версии 2.0 весит всего 200 МБ, в 2 раза меньше прежних релизов;
  • ранний доступ к последним интеграциям и гибкое обновление компонентов — не нужно ждать выхода следующей версии Airflow, если нужна самая последняя версия провайдера, например, Amazon или Google – можно поставить этот компонент отдельно в любой момент времени. Более того, можно обновить всего один провайдер, не затрагивая всю платформу. Это существенно снижает нагрузку на DevOps-инженеров, которым достаточно протестировать всего один небольшой пакет.
  • backport-провайдеры для AirFlow10, которые обеспечивают обратную совместимость последних операторов, датчиков и других компонентов с предыдущей версией. Важно отметить, что поддержка backport-провайдеров будет осуществляться в течение 3-х месяцев после выпуска Airflow 2.0 [3];
  • безопасная миграция на версию 2.0;
  • настраиваемые провайдеры сторонних поставщиков (Custom, 3rd-party providers), включая разработку собственного провайдера. По сути, это упаковка пользовательских операторов, датчиков и пр., которые также могут использовать те же механизмы для расширения Airflow Core с помощью настраиваемых подключений и дополнительных ссылок [3]. Как сделать это на практике, мы рассмотрим далее.

Data Pipeline на Apache Airflow

Код курса
AIRF
Ближайшая дата курса
22 мая, 2024
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.

Как создать свой провайдер с блэкджеком и хуками: превращение локального Python-Пакета в общедоступный компонент Apache AirFlow

Поскольку в основе провайдера лежит Python-пакет, то для его превращения в единый упакованный компонент со всеми зависимости, необходимо выполнить следующие шаги [3]:

  • добавить точку входа apache_airflow_provider в конфигурационный файл установщика setup.cfg, чтобы сообщить ArFlow, где взять нужные метаданные провайдера;
  • создать функцию, на которую идет ссылка в предыдущем шаге, как часть пакета – она возвращает словарь, содержащий все корректно отформатированные метаданные;
  • при этом словарь с полями дополнительных ссылок и имен классов должен соответствовать спецификации JSON-схемы airflow/provider_info.schema.json;
  • после этого любой пользователь, который запускает AirFlow в среде, в где установлен этот пакет Python, сможет использовать его в качестве провайдера.

JSON-схема airflow/provider_info.schema.json выглядит следующим образом [3]:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "package-name": {
      "description": "Package name available under which the package is available in the PyPI repository.",
      "type": "string"
    },
    "name": {
      "description": "Provider name",
      "type": "string"
    },
    "description": {
      "description": "Information about the package in RST format",
      "type": "string"
    },
    "hook-class-names": {
      "type": "array",
      "description": "Hook class names that provide connection types to core",
      "items": {
        "type": "string"
      }
    },
    "extra-links": {
      "type": "array",
      "description": "Operator class names that provide extra link functionality",
      "items": {
        "type": "string"
      }
    }
  },
  "required": [
    "name",
    "description"
  ]
}

К примеру, вы собрали собственный пакет myproviderpackage, который не зависит от apache-airflow и может быть локальным пакетом Python, установленным с помощью pip. В этом пакете myproviderpackage добавлена точка входа и предоставлены соответствующие метаданные, как описано выше. Пример конфигурационного файла setup.cfg:

[options.entry_points]
# the function get_provider_info is defined in myproviderpackage.somemodule
apache_airflow_provider=provider_info=myproviderpackage.somemodule:get_provider_info

Во время выполнения для каждого пакета, если в файле setup.cfg есть раздел [options.entry_points] и в нем заданы значения для apache_airflow_provider, вы получите значение для provider_info, например, myproviderpackage.somemodule: get_provider_info. Это работает как оператор импорта, когда импортируемое значение get_provider_info является вызываемой функцией. Эта функция возвращает словарь с метаданными.

Для рассмотренного примера myproviderpackage/somemodule.py может выглядеть так:

def get_provider_info():
    return {
        "package-name": "my-package-name",
        "name": "name",
        "description": "a description",
        "hook-class-names": [
            "myproviderpackage.hooks.source.SourceHook",
        ],
    }

Это означает, что при наличии пользовательских типов подключения как части пакета, эти метаданные включают поле с именем hook-class-names — список строк пользовательских hook’ов. Эти строки должны быть в формате, подобном импорту. К примеру, myproviderpackage.hooks.source.SourceHook означает, что в myproviderpackage/hooks/source.py есть класс SourceHook. Airflow импортирует эти хуки и ищет функции get_ui_field_behaviour и get_connection_form_widgets, а также атрибуты conn_type и hook_name для создания настраиваемого типа подключения в пользовательском интерфейсе фреймворка [3].

Data Pipeline на Apache AirFlow и Arenadata Hadoop

Код курса
ADH-AIR
Ближайшая дата курса
по запросу
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.

Таким образом, новый Airflow стал еще удобнее – теперь дата-инженер может строить на нем различные ETL-процессы и прочие конвейеры сбора и обработки больших данных еще быстрее и эффективнее. Освойте все возможности Apache AirFlow для простой разработки сложных конвейеров аналитики больших данных с Hadoop и Spark на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Источники

  1. https://medium.com/apache-airflow/airflow-2-0-providers-1bd21ba3bd93
  2. https://habr.com/ru/post/512386/#soedineniya-huki-i-prochie-peremennye
  3. https://airflow.apache.org/docs/apache-airflow-providers/index.html
Поиск по сайту