Взаимосвязь ресурсов в Managed Service for Apache Airflow™
Сервис Managed Service for Apache Airflow™ помогает разворачивать и поддерживать кластеры серверов Apache Airflow™ в инфраструктуре Yandex Cloud.
Об Apache Airflow™
Apache Airflow™ — это платформа с открытым исходным кодом для создания, планирования и мониторинга пакетно ориентированных воркфлоу. Воркфлоу определяет взаимосвязь задач и последовательность их выполнения и представлен в виде направленного ациклического графа — DAG (Directed Acyclic Graph). Направленные ациклические графы в Apache Airflow™ можно применять для автоматизации и запуска по расписанию любых процессов, например обработки данных в Apache Spark™.
В Apache Airflow™ используется подход Workflows as code
. Он подразумевает, что каждый воркфлоу реализуется с помощью скрипта на Python 3. Файл с таким скриптом называется DAG-файлом. В нем описываются задачи, расписание их запуска и зависимости между ними. Такой подход позволяет хранить воркфлоу в системе контроля версий, запускать тесты и подключать нужные технологии для воркфлоу.
Apache Airflow™ не применяется для потоковой и непрерывной обработки данных. Если она нужна, можно создать решение на основе сервиса Yandex Managed Service for Apache Kafka®.
Более подробная информация приведена в документации Apache Airflow™.
Архитектура Managed Service for Apache Airflow™
Архитектура сервиса Managed Service for Apache Airflow™ представлена на схеме:
Каждый кластер Apache Airflow™ запускается в отдельной группе узлов Kubernetes, которая включает в себя необходимую сетевую инфраструктуру: виртуальную сеть, группу безопасности и сервисный аккаунт. Группы узлов изолированы друг от друга как средствами виртуальных сетей, так и средствами самого Kubernetes. Группы узлов управляются общим Kubernetes-мастером, а кластеры Apache Airflow™ используют для хранения данных общий кластер PostgreSQL.
Чтобы обеспечить изолированное хранение данных, использование кластера PostgreSQL в сервисе ограничено:
-
Для каждого кластера Apache Airflow™ в кластере PostgreSQL создается отдельная база данных. Кластер может подключаться только к своей базе данных.
-
Кластер Apache Airflow™ может работать только с теми таблицами, которые созданы средствами самого Apache Airflow™. Произвольное создание и изменение схем, таблиц, функций, процедур и триггеров запрещено.
-
Скорость чтения и записи данных, а также объем хранимой в базе информации ограничены.
Важно
Злонамеренный обход этих ограничений приведет к блокировке кластера согласно пункту 7 правил допустимого использования сервисов.
Кластер Apache Airflow™
Основная сущность, которой оперирует сервис Managed Service for Apache Airflow™, — кластер. В нем развернуты компоненты Apache Airflow™. Ресурсы кластера могут находиться в разных зонах доступности. Подробнее о географии Yandex Cloud см. в разделе Обзор платформы.
Воркфлоу, запущенный в кластере, может обращаться к любому ресурсу Yandex Cloud в пределах облачной сети, в которой находится кластер. Например, воркфлоу может отправлять запросы виртуальной машине Yandex Cloud или кластеру управляемой базы данных (БД). Так можно построить воркфлоу с использованием нескольких ресурсов. Например, воркфлоу забирает данные из одной БД, обрабатывает их и отправляет в другую БД или Yandex Data Processing.
Основные компоненты Apache Airflow™
Основные компоненты Apache Airflow™ представлены на схеме:
Компоненты Apache Airflow™:
-
Веб-сервер — сервер в Yandex Cloud, на котором размещается экземпляр Apache Airflow™. Веб-сервер получает команды от пользователей, отправленные через веб-интерфейс Apache Airflow™, проверяет, запускает и отлаживает Python-скрипты в DAG-файлах.
Подробнее о работе с веб-интерфейсом см. в документации Apache Airflow™.
-
Планировщик — сервер в Yandex Cloud, который управляет расписанием запуска задач. Планировщик получает информацию о расписании из DAG-файлов. По этому расписанию он сообщает воркерам, что пора запустить DAG-файл.
-
Воркеры — исполнители задач, указанных в DAG-файлах. Воркеры выполняют задачи по расписанию от планировщика.
-
Triggerer — служба, которая освобождает воркер в случае его простоя при выполнении задания с длительным ожиданием события (опциональный компонент).
-
Хранилище DAG-файлов — бакет Yandex Object Storage, в котором хранятся DAG-файлы. К этому хранилищу имеют доступ веб-сервер, планировщик, воркеры и Triggerer.
Чтобы обеспечить отказоустойчивость и повысить производительность, веб-серверы, планировщики и Triggerer могут существовать в нескольких экземплярах. Их количество определяется во время создания кластера.
Для воркеров задается минимальное и максимальное количество экземпляров также при создании кластера. Их количество будет масштабироваться динамически. Эта функциональность обеспечивается благодаря использованию в сервисе контроллера KEDA.
Конфигурации компонентов Apache Airflow™
Конфигурация определяет вычислительные мощности, которые выделяются для веб-сервера, планировщика, воркеров и службы Triggerer. Доступны два типа конфигураций:
-
standard — с соотношением количества гигабайт RAM к количеству vCPU 4:1.
- 1 vCPU, 4 ГБ RAM.
- 2 vCPU, 8 ГБ RAM.
- 4 vCPU, 16 ГБ RAM.
- 8 vCPU, 32 ГБ RAM.
-
cpu-optimized — с уменьшенным соотношением количества гигабайт RAM к количеству vCPU (2:1). Такие конфигурации могут быть полезны для кластеров с повышенными требованиями к производительности процессора.
- 1 vCPU, 2 ГБ RAM.
- 2 vCPU, 4 ГБ RAM.
- 4 vCPU, 8 ГБ RAM.
- 8 vCPU, 16 ГБ RAM.
Конфигурации можно выбрать при создании кластера или изменить при его редактировании.
Triggerer
Служба Triggerer позволяет сократить время простоя воркеров.
В графах DAG могут быть задачи, которые отправляют запрос во внешнюю систему (например, кластер Apache Spark™) и ожидают ответ от нее в течение некоторого времени. Если использовать стандартные операторы, задача занимает воркер, пока ожидает ответа. В результате воркер простаивает. Когда такое происходит с большим количеством воркеров, образуются очереди задач, и скорость их запуска и выполнения снижается.
Избежать такой ситуации позволяют отложенные операторы (deferrable operators). С их помощью задача приостанавливается, освобождается воркер, и опрос внешней системы выделяется в отдельный процесс — триггер (trigger). Все триггеры независимо друг от друга (асинхронно) обрабатываются службой Triggerer, для которой в кластере выделены отдельные ресурсы. При получении ответа от внешней системы триггер срабатывает, и планировщик возвращает задачу воркеру.
Процесс работы со службой Triggerer представлен на схеме:
Подробнее об отложенных операторах, триггерах и службе Triggerer см. в документации Apache Airflow™.