Перевод книги «Apache Airflow Best Practices, by Dylan Intorf, Dylan Storey, Kendrick van Doorn» Packt Publishing подготовлен автором сайта

Table of Contents

Глава 3 – Компоненты Airflow

Apache Airflow — это распределённая система с несколькими компонентами. Хотя распределённые системы по своей сути являются сложными, сами компоненты относительно просты. Важно понимать конкретную роль каждого компонента и ту роль, которую они играют в работе приложения Airflow. Понимание их настройки, работы и обслуживания поможет вам уверенно масштабироваться и стать экспертами в эксплуатации сред Airflow в продуктиве. В этой главе вы узнаете об ответственности и возможностях каждого компонента в рамках общего приложения, о том, как выбирать определённые конфигурации для конкретных компонентов и как определить, какие возможности вам понадобятся для достижения ваших бизнес-целей.

Важно сосредоточиться на понимании таких базовых компонентов, поскольку часто можно найти возможности для оптимизации и скрытого ресурса, когда общее количество задач и заданий, которые координирует Airflow, увеличивается.

В этой главе мы рассмотрим следующие основные темы:

Общая архитектура и ключевые компоненты
Какой Executor подходит для различных сценариев
Подробный взгляд на оптимизацию планировщика (Scheduler)

Технические требования

Как и в предыдущих главах, мы предполагаем, что у вас уже настроена среда Apache Airflow на вашем локальном компьютере, и вы знаете, как получить к ней доступ — будь то через пользовательский интерфейс или через интерфейс командной строки. Если вы не выполнили эти шаги, рекомендуем обратиться к предыдущим главам или перейти к руководству по быстрому старту (Quick Start), поддерживаемому сообществом с открытым исходным кодом, для получения самой актуальной информации.

Общее понимание таких понятий, как архитектура распределённого программного обеспечения, Kubernetes и проектирование систем, необходимо для получения максимальной пользы от этой информации.

Общая архитектура

Apache Airflow в своей основе представляет собой набор компонентов, работающих вместе, позволяющих вам строить и запускать рабочие процессы или ориентированные ациклические графы (DAG). Эти рабочие процессы выполняются поверх нескольких микросервисов, которые координируют выполнение задач рабочими по заданному расписанию.

Архитектура Apache Airflow включает в себя несколько ключевых компонентов, которые работают совместно для эффективной оркестрации пайплайнов данных. Основные компоненты включают:

Metadata Database (База метаданных): Хранит метаданные, связанные с запусками DAG, статусами экземпляров задач и другими ключевыми метаданными. Позволяет вашей инстанции Airflow отслеживать состояния задач, версии DAG и обеспечивает устойчивость данных.
Scheduler (Планировщик): Отвечает за запуск экземпляров задач на основе заданного времени или внешнего триггера. Постоянно проверяет DAG’и, чтобы определить, можно ли их запустить.
Triggerer: Отвечает за хранение и выполнение асинхронных функций, создаваемых из классов Trigger.
Executor (Исполнитель): Определяет, как задачи будут выполняться в Airflow.
Workers (Рабочие процессы): Подхватывают задачи, назначенные к выполнению, и непосредственно отвечают за «выполнение работы».
DAG Directory (Каталог DAG): Место, где Airflow ищет Python-файлы с определениями DAG. Используется многими компонентами через файловую систему.
Web Server (Веб-сервер): Обеспечивает веб-интерфейс для Apache Airflow.
User Interface (Пользовательский интерфейс): Через веб-сервер UI позволяет пользователям отслеживать DAG, просматривать успешные и неудачные выполнения задач, просматривать логи и управлять средой Airflow.

Каждый из этих компонентов выполняет уникальную роль в экосистеме Airflow, совместно обеспечивая гладкую оркестрацию и управление сложными рабочими процессами данных. Понимание этих основных элементов даёт прочную основу для работы с архитектурой Apache Airflow.

Рисунок 3.1: Общая архитектура компонентов Apache Airflow

Веб-сервер, планировщик (scheduler) и исполнитель (executor) являются процессами Airflow.

База метаданных (Metadata Database) или просто база данных — это отдельный сервис, который должен быть предоставлен Airflow для хранения метаданных от веб-сервера и планировщика. Каталог DAG или папка dags должна быть доступна для планировщика и часто включается в ту же рабочую директорию.

Веб-сервер визуально отображает информацию о текущем состоянии DAG’ов и пайплайнов, а также предоставляет пользователю возможность просматривать ключевую информацию в различных представлениях и вручную запускать DAG’и. Планировщик служит для парсинга файлов DAG из каталога DAG и определения задач для выполнения, после чего помещает их в очередь.

Для выполнения этих задач из очереди доступно несколько вариантов на выбор, в зависимости от бизнес-целей и требований. Apache Airflow может быть установлен и запущен по-разному: на локальной машине, на одном сервере или в распределённой сети из нескольких машин. Каждый из этих подходов предоставляет разные преимущества, уровень сложности и требует разного исполнителя (executor).

Исполнители (Executors)

Исполнители определяют, как экземпляры задач будут выполняться в среде Airflow. Они являются подключаемыми (pluggable), что позволяет командам менять исполнителей в зависимости от своих бизнес-целей и потребностей. Каждая среда Airflow может быть настроена только с одним исполнителем одновременно, и он может быть изменён в конфигурационном файле.

Вы можете увидеть исполнителей с названиями, такими как SequentialExecutor, в официальной документации и конфигурационных файлах. В этой главе мы будем разделять слова для удобства чтения и ссылаться на них по типу, например, Sequential вместо SequentialExecutor.

На момент написания доступно несколько типов исполнителей, и сообщество продолжает расширять доступные опции. Таблица 4.1 содержит список исполнителей, которые доступны в настоящее время, а также тех, которые были устаревшими. В следующей таблице мы рассмотрим дополнительные детали по наиболее распространённым исполнителям и лучшие варианты использования.

Таблица 3.1: Описание некоторых распространённых исполнителей, доступных в настоящее время для выполнения задач, их сложность и варианты использования в эксплуатации.

Executor	Удалённое выполнение	Параллелизм	Сложность установки и поддержки	Сценарии использования
SequentialExecutor	Нет	Нет	Очень простая	Демонстрация/тестирование
LocalExecutor	Нет	Да	Простой	Одна машина или среда разработки
CeleryExecutor	Да	Да	Средняя	Масштабирование на несколько машин и воркеров
CeleryKubernetesExecutor	Да	Да	Сложная	Как CeleryExecutor, но справляется с высокими нагрузками в пиковое время и обеспечивает изоляцию выполнения, как у KubernetesExecutor
Dask Executor	Да	Да	Средняя	Параллельные вычисления в распределённой архитектуре
Kubernetes Executor	Да	Да	Сложная	Масштабирование и запуск каждой задачи в отдельном pod’е Kubernetes-кластера
LocalKubernetes Executor	Да	Да	Сложная	Преимущества KubernetesExecutor с возможностью выполнения задач через LocalExecutor внутри сервера планировщика

Давайте рассмотрим примеры каждого типа и посмотрим на наилучшие применения каждого из них.

Локальные исполнители (Sequential и Local)

Если вы следовали инструкциям по быстрому старту для установки Apache Airflow и не вносили никаких изменений, по умолчанию используется исполнитель Sequential. Это единственный исполнитель, который может использоваться с SQLite, так как SQLite не поддерживает множественные подключения.

Sequential Executor работает, как следует из его названия: задачи выполняются последовательно, в логическом порядке. Локальные установки Apache Airflow часто имеют одного рабочего, поскольку Sequential Executor ограничивает выполнение одной задачи за раз.

Рисунок 3.2: Набор из трёх задач из примера базового DAG

Обратимся к базовому примеру DAG, рассмотренному в предыдущей главе — Sequential Executor является идеальным вариантом использования. DAG не является сложным, и каждая задача должна быть выполнена по порядку перед переходом к следующей. Sequential Executor — отличный инструмент для запуска примерных DAG’ов и рабочих нагрузок на локальной машине. По мере увеличения количества необходимых рабочих узлов производительность локальной машины будет снижаться из-за использования ресурсов.

Следующим шагом после Sequential Executor является Local Executor, который запускает экземпляры задач параллельно на той же машине, где работает планировщик. Он использует модуль multiprocessing Python для создания нескольких процессов, позволяя выполнять задачи параллельно. Чтобы изменить Sequential Executor на Local Executor, необходимо обновить конфигурационный файл (airflow.cfg), установив поле executor в значение LocalExecutor.

1 2	# в конфигурационном файле executor = LocalExecutor

Если вы хотите проверить, какой исполнитель используется в просматриваемой среде Airflow, вы можете выполнить следующую команду в интерфейсе командной строки:

1	$ airflow config get-value core executor

Основные варианты использования Local Executor:

Среда разработки: благодаря своей простоте и отсутствию внешних зависимостей, Local Executor часто используется в средах разработки. Разработчики могут уверенно запускать DAG’и и задачи без необходимости в более сложных исполнителях.
Малые и средние рабочие нагрузки: для рабочих сред с ограниченными требованиями к параллельности (в среднем менее пяти одновременных DAG’ов/задач) или слабыми SLA, Local Executor может быть достаточным решением для команды.

Local Executor предлагает множество преимуществ по сравнению с Sequential Executor и удалёнными исполнителями:

Параллельность: этот исполнитель позволяет запускать несколько экземпляров задач одновременно. Уровень параллельности определяет, сколько задач может быть выполнено одновременно в данный момент времени. Этот инструмент крайне полезен при работе с длительными задачами. Параллельность — это параметр конфигурации, который можно настроить до максимального значения, поддерживаемого машиной, на которой работает Local Executor.
Простота: Local Executor прост в использовании и не требует настройки дополнительных компонентов инфраструктуры, таких как брокеры сообщений для Celery Executor или кластер Kubernetes для Kubernetes Executor. Мы рассмотрим оба этих исполнителя позже в этой главе. Это делает его проще в настройке, особенно для новых пользователей или небольших установок.
Локальная разработка: он предоставляет более реалистичную среду для тестирования по сравнению с Sequential Executor, который выполняет задачи по одной. Разработчики могут тестировать параллельное выполнение задач без необходимости обслуживания и настройки более сложных исполнителей.
Использование ресурсов: так как он запускает задачи на той же машине, что и планировщик, он подходит для сценариев, где вы хотите максимально использовать ресурсы машины без распределения задач между различными узлами или контейнерами.
Низкие издержки: отсутствие внешних систем для отправки задач на выполнение снижает сетевую задержку, и нет дополнительных систем, которые нужно мониторить или обслуживать.
Переход к продакшену: для небольших и средних развёртываний Airflow переход от среды разработки с использованием Local Executor к производственной среде с тем же исполнителем происходит легко.

Однако важно отметить ограничения Local Executor. Как следует из названия, задачи выполняются «локально», поэтому, если рабочие процессы требуют значительной параллельности или есть необходимость распределить нагрузку выполнения между несколькими машинами для масштабируемости или отказоустойчивости, то могут подойти другие исполнители.

Параллелизм

Давайте подробнее рассмотрим тему параллелизма и то, насколько он эффективен для выполнения экземпляров задач. Local Executor предоставляет возможность выполнять несколько экземпляров задач одновременно. По сравнению с Sequential Executor, который ограничивается одной задачей за раз, параллелизм может значительно ускорить процесс. Например, на следующем изображении мы можем визуализировать, как Sequential Executor может выполнять три отдельные задачи. Каждая задача обозначена разным цветом и не зависит от других для выполнения.

Рисунок 3.3: Визуализация одного рабочего, выполняющего три задачи с течением времени

Sequential Executor возьмёт первую задачу, зелёную, на выполнение, требующее трёх циклов для завершения. Хотя вторая задача, синяя, не зависит от зелёной для начала выполнения, она должна ждать завершения зелёной задачи, поскольку имеется только один доступный рабочий. Третья задача, фиолетовая, проходит тот же процесс ожидания завершения первой и второй задач перед началом выполнения. Этот процесс может быть приемлем для некоторых бизнес-кейсов и представляет собой быстрый способ начать работу.

Local Executor предлагает возможность реализации многопроцессности или параллелизма для выполнения задач одновременно. В следующем примере по-прежнему имеются три задачи, и каждая из них не зависит от других. Executor настроен с двумя рабочими для выполнения экземпляров задач.

Рисунок 3.4: Пример Local Executor с параллелизмом

В этом примере мы видим, что задача один, зелёная, и задача два, синяя, выполняются одновременно, поскольку каждый рабочий обрабатывает их независимо. После завершения задачи один, задача три, фиолетовая, может быть запущена Рабочим №1. Если вас интересуют дополнительные оптимизации, мы рассмотрим пулы рабочих и очереди в следующих главах, которые могут быть крайне полезны с точки зрения затрат и времени.

Уровень параллелизма, по сути, определяет, сколько экземпляров задач может быть выполнено одновременно в любой момент времени. Этот инструмент крайне полезен при работе с длительными задачами. Параллелизм — это параметр конфигурации, который можно настроить до наивысшего предела, поддерживаемого машиной, на которой работает Local Executor.

Celery Executor (Удалённый Executor)

Celery Executor — один из удалённых исполнителей, доступных в Apache Airflow. Он использует Celery — распределённую систему очередей задач, которая позволяет выполнять задачи параллельно на нескольких машинах-воркерах. В этой конфигурации Celery использует брокер, такой как RabbitMQ или Redis, для обработки коммуникации между основной инстанцией Airflow и машинами-воркерами.

Основные случаи использования Celery Executor включают:

Масштабируемость: Подходит для крупных развёртываний Airflow, когда задачи нужно распределять между несколькими машинами из-за большого объёма экземпляров задач или ресурсоёмких задач.
Распределённое выполнение: Когда вы хотите выполнять задачи на разных машинах с разными конфигурациями или возможностями.
Высокая доступность: При наличии нескольких узлов-воркеров, если один воркер выходит из строя, другие всё ещё могут обрабатывать задачи, обеспечивая устойчивость системы к сбоям.
Разделение ресурсов: Если определённые задачи требуют специфических системных ресурсов или конфигураций, их можно направлять на специально настроенные воркеры.

Celery Executor предлагает множество преимуществ по сравнению с локальными и удалёнными исполнителями:

Горизонтальная масштабируемость: По мере роста нагрузки можно просто добавить больше узлов-воркеров для обработки увеличенного объёма задач без изменения существующей инфраструктуры.
Гибкость: Можно настроить разные узлы-воркеры для разных типов задач на основе требований к ресурсам, обеспечивая оптимальное использование ресурсов.
Разделение компонентов: Разделённая архитектура означает, что веб-сервер и планировщик Airflow отделены от машин-воркеров, выполняющих задачи. Это разделение гарантирует, что ресурсоёмкие задачи не замедлят работу планировщика или веб-интерфейса.
Параллелизм: За счёт распределения задач между несколькими машинами можно достичь высокой степени параллелизма, позволяя множеству задач выполняться одновременно, тем самым сокращая общее время выполнения для больших рабочих процессов.

По мере изучения разных исполнителей, сложность настройки и управления возрастает по сравнению с базовым Sequential Executor. Для Celery Executor следует учитывать следующее:

Сложность настройки: По сравнению с LocalExecutor или SequentialExecutor, настройка CeleryExecutor требует дополнительных компонентов, таких как брокер сообщений (RabbitMQ или Redis) и backend для хранения результатов, что делает начальную настройку более сложной.
Операционные издержки: Мониторинг и обслуживание нескольких компонентов (Airflow, Celery, воркеры) могут создать операционные сложности.
Задержки: Могут возникать небольшие задержки из-за передачи сообщений между основной инстанцией Airflow, брокером и узлами-воркерами.
Ограничения брокера: Выбор брокера сообщений связан с его собственными ограничениями, особенностями и сложностями обслуживания.
Стоимость: Запуск нескольких узлов-воркеров может увеличить затраты на инфраструктуру, особенно если они недозагружены.
Синхронизация версий: Обеспечение того, чтобы все узлы-воркеры работали на одной версии Airflow и имели все необходимые зависимости, может быть сложной задачей в распределённой системе.

Хотя Celery Executor предоставляет возможности масштабируемости и распределённого выполнения, необходимые для крупномасштабных развёртываний Airflow, он также влечёт за собой увеличение сложности и операционных трудностей. Важно сопоставлять преимущества и ограничения, исходя из конкретных требований ваших рабочих процессов.

Kubernetes Executor (Удалённый Executor)

Kubernetes Executor — это удалённый и динамический исполнитель для Apache Airflow, который запускает экземпляры задач в отдельных pod’ах Kubernetes. Этот исполнитель был введён для использования возможностей Kubernetes, позволяя по запросу создавать pod’ы для выполнения задач и удовлетворять растущие потребности корпоративных команд с высоко сложными и крупными рабочими нагрузками.

Основные случаи использования Kubernetes Executor включают:

Запуск задач, требующих доступа к большому количеству ресурсов: KubernetesExecutor может использоваться для запуска задач, которым необходим доступ к большим объёмам ресурсов, таким как CPU, память и GPU. Это возможно благодаря тому, что Kubernetes может динамически выделять ресурсы pod’ам по мере необходимости.
Запуск задач, которые должны выполняться в определённой среде: KubernetesExecutor может использоваться для запуска задач, которые должны выполняться в определённой среде, например, с определённой версией Python или набором библиотек. Это возможно, потому что Kubernetes может запускать pod’ы с разными контейнерами, каждый из которых может содержать свою собственную среду.
Запуск задач, которым требуется отказоустойчивость: KubernetesExecutor может использоваться для запуска задач, которым нужна отказоустойчивость. Это возможно, потому что Kubernetes может перезапускать завершившиеся сбоем pod’ы и переназначать задачи другим pod’ам.
Масштабируемость: Этот исполнитель подходит для сред, в которых нагрузка по задачам значительно варьируется. Kubernetes может быстро масштабироваться вверх или вниз в зависимости от спроса.
Распределённое выполнение: Полезен, когда задачи нужно распределить по кластеру Kubernetes — как в облачной среде, так и на собственных серверах.
Эфемерные среды: Для задач, которым требуется чистая среда при каждом запуске, создание нового pod’а обеспечивает временное окружение.

С введением Kubernetes Executor были отмечены многочисленные преимущества по сравнению с локальными и другими удалёнными исполнителями:

Динамическая масштабируемость: В отличие от статических конфигураций, где ресурсы выделяются заранее, с Kubernetes Executor ресурсы выделяются только тогда, когда задачи нуждаются в выполнении, что оптимизирует использование ресурсов.
Интеграция с облаком: Многие облачные провайдеры предлагают управляемые сервисы Kubernetes (например, GKE, EKS, AKS). Kubernetes Executor интегрируется с этими сервисами и может быть развёрнут с помощью таких инструментов, как Helm, предоставляя облачную масштабируемость и управление.
Автоматическое восстановление и избыточность: Kubernetes изначально предоставляет такие функции, как автоматические перезапуски, замена вышедших из строя pod’ов и распределение pod’ов по узлам, что повышает надёжность выполнения задач.
Настраиваемость: Каждый pod может быть настроен с использованием примитивов Kubernetes. Это позволяет задавать специфические конфигурации, секреты, тома и другие необходимые параметры для задач в индивидуальном порядке.

С дополнительными возможностями и контролем над экземплярами задач и воркерами, которые выполняют задачи, растёт и сложность обслуживания. Для Kubernetes Executor важно учитывать следующее:

Сложность настройки: Развёртывание и управление кластером Kubernetes, особенно если он ещё не используется, может быть сложным и требует экспертных знаний в Kubernetes, облачной архитектуре и распределённых сетях.
Накладные расходы: Для очень лёгких или быстрых задач накладные расходы на запуск нового pod’а могут быть значительными по сравнению с фактическим временем выполнения задачи.
Стоимость: Хотя динамическое масштабирование может быть экономически эффективным, всё же существует базовая стоимость поддержки кластера Kubernetes. Кроме того, частое создание и удаление pod’ов может привести как к увеличению расходов, так и к экономии в некоторых случаях.
Постоянные данные: Pod’ы являются эфемерными, и хранение постоянных данных может быть проблематичным. Хотя существуют способы решения этой проблемы с использованием постоянных томов, это добавляет дополнительную сложность.
Кривая обучения: Для команд, незнакомых с Kubernetes, может быть крутая кривая обучения как в понимании концепций Kubernetes, так и в отладке проблем, специфичных для платформы.
Сетевые задержки: Запуск pod’ов может вызывать сетевые задержки, особенно если образы нужно загружать из реестра или если в pod’е есть начальные задачи настройки.
Задержка запуска: Образы необходимо загрузить из реестра (если они не закэшированы), а контейнеры проходят процесс запуска для каждой задачи. В зависимости от архитектуры образа время запуска контейнера может быть значительным.
Совместимость версий: Обеспечение совместимости между версиями Airflow и Kubernetes, а также отслеживание изменений API Kubernetes может быть задачей обслуживания.

В заключение, KubernetesExecutor предлагает высоко динамичную и масштабируемую среду выполнения задач Airflow, используя сильные стороны Kubernetes. Однако он может ввести сложность и накладные расходы, особенно для команд, незнакомых с Kubernetes, или для рабочих процессов с лёгкими задачами. Как всегда, выбор исполнителя должен основываться на конкретных требованиях и контексте развёртывания.

Dask Executor (Удалённый Executor)

DaskExecutor — это исполнитель для Apache Airflow, использующий Dask, гибкую библиотеку параллельных вычислений для аналитических расчётов. Dask может использоваться для построения параллельных распределённых вычислительных систем, масштабируемых от одной машины до кластера машин. При использовании в Airflow, DaskExecutor направляет выполнение задач в кластер Dask.

Основные случаи использования Dask Executor включают:

Машинное обучение: Dask Executor хорошо подходит для задач машинного обучения, таких как обучение и оценка моделей. Это связано с тем, что Dask может распределять эти задачи между несколькими воркерами, что может значительно ускорить процесс обучения.
Data science: Dask Executor также может использоваться для задач data science, таких как предварительная обработка и анализ данных. Это связано с тем, что Dask может распределять эти задачи между несколькими воркерами, что помогает повысить производительность и масштабируемость.
Другие ресурсоёмкие вычислительные задачи: Dask Executor также может использоваться для других ресурсоёмких вычислительных задач, таких как обработка видео и научные вычисления.

Dask Executor предлагает несколько преимуществ по сравнению с локальными и удалёнными исполнителями:

Общая инфраструктура: Для команд или организаций, которые уже используют Dask для распределённых вычислений, DaskExecutor позволяет использовать ту же инфраструктуру для выполнения задач Airflow, обеспечивая оптимизацию ресурсов.
Гибкость: Dask предоставляет гибкую платформу, которую можно запускать как на одной машине (в многопоточном или многопроцессном режиме), так и в распределённом кластере. Такая гибкость полезна при разном масштабе развёртывания.
Python-ориентированная экосистема: Dask тесно интегрирован с экосистемой Python, что делает его естественным выбором для ориентированных на данные рабочих процессов, написанных на Python.

Так как Dask Executor является относительно новой опцией в сообществе, важно учитывать следующее:

Сложность настройки: Если у вас ещё нет настроенного Dask, внедрение Dask-кластера и обеспечение его стабильной работы может быть сложным, и в некоторых случаях может быть более целесообразно использовать другой исполнитель.
Операционные накладные расходы: Управление и мониторинг кластера Dask, особенно в продуктивной среде, может вызвать дополнительные операционные сложности.
Управление зависимостями: Обеспечение того, чтобы все воркеры Dask имели правильную и согласованную среду и зависимости, может быть затруднительным, особенно когда выполняются разнообразные задачи с разными требованиями.
Потенциальное конкурирование за ресурсы: Если кластер Dask используется также для других вычислительных задач, помимо Airflow, может возникнуть конкуренция за ресурсы, что приведёт к снижению производительности.
Сетевые накладные расходы: В зависимости от конфигурации кластера Dask могут возникать сетевые накладные расходы при передаче задач и получении результатов, особенно если задачи зависят от ввода-вывода.

В заключение, DaskExecutor предоставляет возможность распределённого выполнения задач в Apache Airflow, особенно для команд, уже использующих Dask или работающих с ресурсоёмкими рабочими процессами на Python. Однако, как и другие распределённые исполнители, он добавляет сложности в настройке, управлении и оптимизации производительности. Решение об использовании DaskExecutor должно основываться на конкретных потребностях рабочего процесса, существующей инфраструктуре и уровне знакомства с Dask.

Kubernetes Local Executor (гибридный исполнитель)

Kubernetes Local Executor — это более новый исполнитель для Apache Airflow, который позволяет запускать задачи локально с использованием Local Executor или в Kubernetes с использованием Kubernetes Executor, в зависимости от очереди экземпляра задачи. Это может быть полезно для задач с разными требованиями к ресурсам или задач, которым необходимо выполняться в определённой среде.

Основные случаи использования Kubernetes Local Executor включают:

Разработка и тестирование DAG-файлов Airflow локально: Kubernetes Local Executor можно использовать для разработки и тестирования DAG-файлов Airflow локально без необходимости развертывания их в кластере Kubernetes. Это может быть полезно для отладки DAG-файлов и для быстрой итерации новых функций.
Запуск DAG-файлов Airflow в кластере Kubernetes в продуктивной среде: Kubernetes Local Executor также может использоваться для запуска DAG-файлов Airflow в кластере Kubernetes в продуктивной среде. Это может быть полезно для задач с высокими требованиями к ресурсам или задач, которые должны выполняться в масштабируемой и отказоустойчивой среде.

Kubernetes Local Executor является важным дополнением к списку исполнителей, так как он обеспечивает гибкость в том, как запускать задачи Airflow, в зависимости от конкретных требований задачи. Это может быть полезно для разработки, тестирования и запуска DAG-файлов Airflow в различных средах.

Вот несколько дополнительных моментов, которые следует учитывать при использовании Kubernetes Local Executor:

Убедитесь, что имеется достаточно ресурсов по памяти и CPU для поддержки количества pod’ов Kubernetes, которые может потребоваться создать Kubernetes Local Executor.
Учитывайте возросшую нагрузку на базу данных при использовании Kubernetes Local Executor.
Помните, что использование Kubernetes Local Executor может привести к параллельному выполнению задач, что может вызвать условия гонки. Чтобы этого избежать, возможно, потребуется реализовать механизмы синхронизации.

Планировщик (Scheduler)

В предыдущих разделах рассматривалось, как выполняются задачи и как лучше всего обеспечивать выполнение различных вариантов экземпляров задач. Чтобы определить, когда эти задачи должны быть запланированы для выполнения, необходимо подробнее рассмотреть планировщик (Scheduler) и его многочисленные обязанности:

Разбор DAG-файлов (DAG Parsing): Планировщик непрерывно разбирает файлы DAG в каталоге DAG, чтобы найти новые задачи для планирования. Он определяет порядок выполнения на основе зависимостей, установленных в DAG-файлах.
Механизм heartbeat: Планировщик работает в цикле, часто называемом «heartbeat», где он постоянно проверяет наличие задач для выполнения, планирует их, а затем делает короткую паузу перед следующей проверкой.
Динамическое планирование задач (Dynamic Task Scheduling): В отличие от традиционных cron-настроек, где задания фиксированы, планировщик Airflow динамически определяет, какие задачи должны быть запущены, на основе их зависимостей и состояния. Это позволяет создавать более сложные рабочие процессы с условными путями выполнения.

Некоторые ключевые настройки планировщика, которые мы считаем наиболее полезными для оптимизации продуктивных сред, включают следующее:

Управление параллелизмом (Concurrency Controls): Планировщик учитывает различные настройки параллелизма, которые можно настроить в конфигурационном файле:
dag_concurrency: количество экземпляров задач, разрешённых к одновременному выполнению планировщиком для конкретного DAG.
parallelism: глобальный параллелизм, то есть общее количество экземпляров задач, которые могут выполняться одновременно во всех DAG-файлах.
Обработка сбоев (Handling Failures): Если задача завершается с ошибкой, планировщик может повторить её выполнение, исходя из параметра retries, заданного в задаче. Он соблюдает настройку retry_delay, определяющую время между повторными попытками.
Backfill и Catch-up: Планировщик может выполнять backfill исторических данных, запуская пропущенные DAG-запуски за заданный диапазон дат. Кроме того, если для DAG задан catchup=True, и запуск DAG был пропущен (например, из-за простоя), планировщик выполнит этот DAG-запуск, когда Airflow снова будет доступен.
Управление ресурсами и пулы (Resource Management and Pools): Планировщик обеспечивает планирование задач на основе доступности ресурсов. Используя концепцию пулов в Airflow, можно ограничить количество одновременных задач, использующих определённый ресурс, чтобы избежать его перегрузки. Мы подробнее рассмотрим очереди задач и пулы в следующих главах.

Ключевая характеристика планировщика заключается в том, что он отвечает за экземпляры задач до тех пор, пока они не будут помещены в состояние очереди. После того, как задача помещена в очередь, ответственность за её выполнение переходит к выбранному исполнителю (executor).

Резюме по 3 главе

В заключение, понимание компонентов Apache Airflow, их отдельных ролей и того, как они взаимодействуют, имеет решающее значение для эффективной настройки, эксплуатации и оптимизации среды Airflow. Эти знания позволяют вам выбирать правильные конфигурации, обеспечивать эффективное выполнение задач и масштабировать систему в соответствии с целями бизнеса. Овладев этими элементами, вы будете хорошо подготовлены к управлению Airflow в продуктивной среде, открывая возможности для оптимизации и использования скрытого потенциала по мере роста ваших потребностей в оркестрации задач и заданий.

В следующей главе мы начнем использовать эти компоненты, рассмотрев основы создания DAG-файлов.

Airflow Best Practices Перевод 3 главы «Компоненты Airflow»