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

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

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

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

Таким образом, отделение провайдеров от ядра 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]. Как сделать это на практике, мы рассмотрим далее.

Как создать свой провайдер с блэкджеком и хуками: превращение локального 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].

Таким образом, новый 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