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 и Apache Hadoop

Код курса
AIRF
Ближайшая дата курса
23 января, 2023
Длительность обучения
24 ак.часов
Стоимость обучения
60 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
Ближайшая дата курса
23 января, 2023
Длительность обучения
24 ак.часов
Стоимость обучения
60 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

Поиск по сайту