Лучшие практики по работе с Apache Airflow 3

Создание нового Dag — это процесс из трёх шагов:

• написание Python-кода для создания объекта Dag,
• проверка того, что код соответствует вашим ожиданиям,
• настройка зависимостей окружения для запуска вашего Dag

В этом руководстве представлены лучшие практики для этих трёх шагов.

Написание Dag

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

Создание пользовательского Operator/Hook

Пожалуйста, следуйте нашему руководству по пользовательским (custom) Operator’ам.

Создание задачи

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

Airflow может повторно запускать задачу в случае её сбоя. Следовательно, задачи должны выдавать одинаковый результат при каждом повторном запуске. Некоторые способы избежать получения различного результата:

• Не используйте INSERT при повторном запуске задачи — оператор INSERT может привести к появлению дублирующихся строк в базе данных. Замените его на UPSERT.
• Читайте и записывайте данные в конкретный партицию. Никогда не читайте самые последние доступные данные в задаче. Кто-то может обновить входные данные между повторными запусками, что приведёт к разным результатам. Лучший подход — читать входные данные из конкретного партициона. В качестве партициона можно использовать data_interval_start. Этот же метод партиционирования следует применять и при записи данных в S3/HDFS.
• Функция Python datetime now() возвращает текущий объект datetime. Эту функцию никогда не следует использовать внутри задачи, особенно для выполнения критических вычислений, так как это приводит к разным результатам при каждом запуске. Допустимо использовать её, например, для генерации временного лога.

Совет

Следует определять повторяющиеся параметры, такие как connection_id или пути S3, в default_args, а не объявлять их для каждой задачи. default_args помогают избежать ошибок, таких как опечатки. Кроме того, большинство типов соединений имеют уникальные имена параметров в задачах, поэтому вы можете объявить соединение только один раз в default_args (например, gcp_conn_id), и оно будет автоматически использоваться всеми операторами, которые работают с данным типом соединения.

Удаление задачи

Будьте осторожны при удалении задачи из Dag. После удаления вы не сможете увидеть эту задачу в Graph View, Grid View и других представлениях, что усложнит проверку логов данной задачи через Webserver. Если такое поведение нежелательно, пожалуйста, создайте новый Dag.

Коммуникация

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

По возможности используйте XCom для передачи небольших сообщений между задачами, а для передачи больших объёмов данных используйте удалённое хранилище, такое как S3 или HDFS. Например, если у вас есть задача, которая сохраняет обработанные данные в S3, эта задача может положить путь к выходным данным в S3 в XCom, а downstream-задачи смогут получить этот путь из XCom и использовать его для чтения данных.

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

Код верхнего уровня Python

Следует избегать написания кода верхнего уровня, который не требуется для создания Operator’ов и построения связей Dag между ними. Это связано с архитектурным решением планировщика Airflow и влиянием скорости парсинга кода верхнего уровня на производительность и масштабируемость Airflow.

Планировщик Airflow выполняет код вне методов execute операторов с минимальным интервалом min_file_process_interval секунд. Это делается для того, чтобы обеспечить динамическое планирование Dag’ов — когда расписание и зависимости могут со временем изменяться и влиять на следующий запуск Dag. Планировщик Airflow постоянно старается убедиться, что то, что описано в Dag’ах, корректно отражено в запланированных задачах.

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

Одним из важных факторов, влияющих на время загрузки Dag, который часто упускают из виду Python-разработчики, является то, что импорты на верхнем уровне могут занимать неожиданно много времени и создавать значительные накладные расходы. Этого легко избежать, переместив такие импорты в локальные импорты внутри Python-callable, например.

Рассмотрим два примера ниже. В первом примере Dag будет парситься на дополнительные 1000 секунд дольше, чем функционально эквивалентный Dag во втором примере, где expensive_api_call выполняется в контексте своей задачи.

Неизбежание кода верхнего уровня Dag:

import pendulum

from airflow.sdk import DAG
from airflow.sdk import task


def expensive_api_call():
    print("Hello from Airflow!")
    sleep(1000)


my_expensive_response = expensive_api_call()

with DAG(
    dag_id="example_python_operator",
    schedule=None,
    start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
    catchup=False,
    tags=["example"],
) as dag:

    @task()
    def print_expensive_api_call():
        print(my_expensive_response)

Избегание кода верхнего уровня Dag:

import pendulum

from airflow.sdk import DAG
from airflow.sdk import task


def expensive_api_call():
    sleep(1000)
    return "Hello from Airflow!"


with DAG(
    dag_id="example_python_operator",
    schedule=None,
    start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
    catchup=False,
    tags=["example"],
) as dag:

    @task()
    def print_expensive_api_call():
        my_expensive_response = expensive_api_call()
        print(my_expensive_response)

В первом примере expensive_api_call выполняется каждый раз при парсинге файла Dag, что приводит к неоптимальной производительности при обработке Dag-файла. Во втором примере expensive_api_call вызывается только во время выполнения задачи и, таким образом, Dag может быть распарсен без потери производительности. Чтобы проверить это самостоятельно, реализуйте первый Dag и посмотрите, как строка «Hello from Airflow!» выводится в логах планировщика.

Обратите внимание, что операторы import также считаются кодом верхнего уровня. Поэтому, если у вас есть import, который выполняется долго, или импортируемый модуль сам выполняет код на верхнем уровне, это также может негативно сказаться на производительности планировщика. Следующий пример показывает, как работать с дорогостоящими импортами.

# It's ok to import modules that are not expensive to load at top-level of a Dag file
import random
import pendulum

# Expensive imports should be avoided as top level imports, because Dag files are parsed frequently, resulting in top-level code being executed.
#
# import pandas
# import torch
# import tensorflow
#

...


@task()
def do_stuff_with_pandas_and_torch():
    import pandas
    import torch

    # do some operations using pandas and torch


@task()
def do_stuff_with_tensorflow():
    import tensorflow

    # do some operations using tensorflow

Как проверить, является ли мой код «кодом верхнего уровня»

Чтобы понять, является ли ваш код «кодом верхнего уровня» или нет, необходимо разбираться во многих тонкостях того, как работает парсинг Python. В общем случае, когда Python парсит файл, он выполняет весь код, который видит, за исключением (как правило) внутреннего кода методов, который он не выполняет.

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

Однако есть простой способ проверить, является ли ваш код «кодом верхнего уровня» или нет. Достаточно распарсить ваш код и посмотреть, выполняется ли данный фрагмент кода.

Представьте следующий код:

from airflow.sdk import DAG
from airflow.providers.standard.operators.python import PythonOperator
import pendulum


def get_task_id():
    return "print_array_task"  # <- is that code going to be executed?


def get_array():
    return [1, 2, 3]  # <- is that code going to be executed?


with DAG(
    dag_id="example_python_operator",
    schedule=None,
    start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
    catchup=False,
    tags=["example"],
) as dag:
    operator = PythonOperator(
        task_id=get_task_id(),
        python_callable=get_array,
        dag=dag,
    )

Чтобы это проверить, вы можете добавить несколько операторов print в код, который хотите проверить, а затем выполнить команду python <my_dag_file>.py.

from airflow.sdk import DAG
from airflow.providers.standard.operators.python import PythonOperator
import pendulum


def get_task_id():
    print("Executing 1")
    return "print_array_task"  # <- is that code going to be executed? YES


def get_array():
    print("Executing 2")
    return [1, 2, 3]  # <- is that code going to be executed? NO


with DAG(
    dag_id="example_python_operator",
    schedule=None,
    start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
    catchup=False,
    tags=["example"],
) as dag:
    operator = PythonOperator(
        task_id=get_task_id(),
        python_callable=get_array,
        dag=dag,
    )

При выполнении этого кода вы увидите:

[Breeze:3.10.19] root@cf85ab34571e:/opt/airflow# python /files/test_python.py
Executing 1

Это означает, что get_array не выполняется как код верхнего уровня, а get_task_id — выполняется.

Качество кода и линтинг

Поддержание высокого качества кода имеет ключевое значение для надёжности и сопровождаемости ваших workflow в Airflow. Использование инструментов линтинга помогает выявлять потенциальные проблемы и обеспечивать соблюдение стандартов кодирования. Одним из таких инструментов является ruff — быстрый линтер для Python, который теперь включает специальные правила для Airflow.

ruff помогает выявлять устаревшие возможности и паттерны, которые могут повлиять на миграцию на Airflow 3.0. Например, он включает правила с префиксом AIR, предназначенные для обнаружения потенциальных проблем.

Полный список этих правил описан в разделе Airflow (AIR).

Установка и использование ruff

ruff — это очень быстрый линтер и автоформаттер для Python, написанный на Rust (в десятки раз быстрее flake8, isort, pylint).

Установка: установите ruff с помощью pip:

pip install "ruff>=0.14.10"

Запуск ruff: выполните ruff для проверки ваших Dag’ов на наличие потенциальных проблем:

ruff check dags/ --select AIR3

Эта команда проанализирует ваши Dag’и, расположенные в директории dags/, и сообщит о проблемах, связанных с указанными правилами.

Пример

Рассмотрим legacy Dag, определённый следующим образом:

from airflow import dag
from airflow.datasets import Dataset
from airflow.sensors.filesystem import FileSensor


@dag()
def legacy_dag():
    FileSensor(task_id="wait_for_file", filepath="/tmp/test_file")

Запуск ruff приведёт к следующему выводу:

dags/legacy_dag.py:7:2: AIR301 Dag should have an explicit schedule argument
dags/legacy_dag.py:12:6: AIR302 schedule_interval is removed in Airflow 3.0
dags/legacy_dag.py:17:15: AIR302 airflow.datasets.Dataset is removed in Airflow 3.0
dags/legacy_dag.py:19:5: AIR303 airflow.sensors.filesystem.FileSensor is moved into ``standard`` provider in Airflow 3.0

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

Динамическая генерация Dag

Иногда написание Dag’ов вручную нецелесообразно. Возможно, у вас есть большое количество Dag’ов, которые делают одно и то же, отличаясь лишь параметрами. Или вам нужен набор Dag’ов для загрузки таблиц, но вы не хотите вручную обновлять Dag’и каждый раз при изменении этих таблиц. В этих и других случаях может быть полезно динамически генерировать Dag’и.

Избегание избыточной обработки в коде верхнего уровня, описанное в предыдущей главе, особенно важно в случае динамической конфигурации Dag’ов, которая, по сути, может быть реализована одним из следующих способов:

• через переменные окружения (не путать с Airflow Variables)
• через внешне предоставляемый, сгенерированный Python-код, содержащий метаданные в папке Dag’ов
• через внешний, сгенерированный файл конфигурационных метаданных в папке Dag’ов

Некоторые случаи динамической генерации Dag’ов описаны в разделе Dynamic Dag Generation.

Переменные Airflow

Использование переменных Airflow приводит к сетевым вызовам и обращениям к базе данных, поэтому их применение в коде Python верхнего уровня для DAG-ов следует по возможности избегать, как упоминалось в предыдущей главе Python-код верхнего уровня. Если переменные Airflow всё же необходимо использовать в коде DAG верхнего уровня, их влияние на парсинг DAG можно снизить, включив экспериментальный кэш, настроенный с разумным значением ttl.

Вы можете свободно использовать переменные Airflow внутри методов execute() операторов, а также передавать переменные Airflow в существующие операторы через Jinja-шаблоны, что откладывает чтение значения до момента выполнения задачи. Синтаксис шаблона для этого следующий:

{{ var.value.<variable_name> }}

или, если требуется десериализовать JSON-объект из переменной:

{{ var.json.<variable_name> }}

В коде верхнего уровня переменные, использующие Jinja-шаблоны, не выполняют запрос до момента запуска задачи, тогда как Variable.get() выполняет запрос каждый раз, когда файл DAG парсится планировщиком, если кэширование не включено. Использование Variable.get() без включённого кэширования приводит к неоптимальной производительности при обработке файлов DAG.

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

Плохой пример:

from airflow.sdk import Variable

foo_var = Variable.get("foo")  # AVOID THAT
bash_use_variable_bad_1 = BashOperator(
    task_id="bash_use_variable_bad_1", bash_command="echo variable foo=${foo_env}", env={"foo_env": foo_var}
)

bash_use_variable_bad_2 = BashOperator(
    task_id="bash_use_variable_bad_2",
    bash_command=f"echo variable foo=${Variable.get('foo')}",  # AVOID THAT
)

bash_use_variable_bad_3 = BashOperator(
    task_id="bash_use_variable_bad_3",
    bash_command="echo variable foo=${foo_env}",
    env={"foo_env": Variable.get("foo")},  # AVOID THAT
)

Хороший пример:

bash_use_variable_good = BashOperator(
    task_id="bash_use_variable_good",
    bash_command="echo variable foo=${foo_env}",
    env={"foo_env": "{{ var.value.get('foo') }}"},
)

@task
def my_task():
    var = Variable.get("foo")  # This is ok since my_task is called only during task run, not during Dag scan.
    print(var)

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

Расписания (Timetables)

Избегайте использования переменных/подключений Airflow или обращения к базе данных Airflow на верхнем уровне кода расписаний. Доступ к базе данных должен быть отложен до момента выполнения DAG. Это означает, что не следует получать переменные/подключения в качестве аргументов при инициализации класса расписания, а также использовать Variable/Connection на верхнем уровне вашего пользовательского модуля расписания.

Плохой пример:

from airflow.sdk import Variable
from airflow.timetables.interval import CronDataIntervalTimetable


class CustomTimetable(CronDataIntervalTimetable):
    def __init__(self, *args, something=Variable.get("something"), **kwargs):
        self._something = something
        super().__init__(*args, **kwargs)

Хороший пример:

from airflow.sdk import Variable
from airflow.timetables.interval import CronDataIntervalTimetable


class CustomTimetable(CronDataIntervalTimetable):
    def __init__(self, *args, something="something", **kwargs):
        self._something = Variable.get(something)
        super().__init__(*args, **kwargs)

Запуск DAG-ов после изменений

Избегайте запуска DAG-ов сразу после их изменения или изменения любых сопутствующих файлов в папке DAG-ов.

Необходимо дать системе достаточно времени для обработки изменённых файлов. Этот процесс включает несколько этапов. Сначала файлы должны быть доставлены планировщику — обычно через распределённую файловую систему или Git-Sync, затем планировщик должен распарсить Python-файлы и сохранить их в базе данных. В зависимости от вашей конфигурации, скорости распределённой файловой системы, количества файлов, количества DAG-ов, числа изменений в файлах, размеров файлов, количества планировщиков, скорости CPU, этот процесс может занимать от нескольких секунд до нескольких минут, а в крайних случаях — многие минуты. Вам следует дождаться появления DAG-а в UI, прежде чем пытаться его запустить.

Если вы наблюдаете большие задержки между обновлением DAG-а и моментом, когда он становится доступен для запуска, вы можете обратить внимание на следующие параметры конфигурации и настроить их в соответствии с вашими потребностями (подробности по каждому параметру см. по ссылкам):

• scheduler_idle_sleep_time — Управляет временем ожидания планировщика между циклами, но если в цикле ничего не нужно делать, то есть если что-то запланировано, то следующая итерация цикла начнется немедленно.
• min_file_process_interval — Количество секунд, по истечении которых происходит разбор DAG-файла. Разбор DAG-файла происходит каждые несколько секунд. Обновления DAG-файлов отражаются после этого интервала. Низкое значение этого параметра приведет к увеличению загрузки ЦП.
• refresh_interval — Как часто (в секундах) следует обновлять или искать новые файлы в пакете DAG.
• parsing_processes — Процессор DAG может запускать несколько процессов параллельно для анализа DAG. Это определяет, сколько процессов будет запущено.
• file_parsing_sort_mode — Один из вариантов modified_time, random_seeded_by_host и alphabetical. Процессор DAG перечислит и отсортирует файлы DAG, чтобы определить порядок их анализа.
  • modified_time — Сортировка файлов по времени изменения. Это полезно в больших масштабах для предварительной обработки недавно измененных DAG-графов.
  • random_seeded_by_host — Произвольная сортировка файлов несколькими процессорами DAG, но в одном и том же порядке на одном и том же хосте, что позволяет каждому процессору обрабатывать файлы в разном порядке.
  • alphabetical — Сортировка по имени файла

Пример паттерна watcher с правилами триггеров

Паттерн watcher — это способ организации DAG-а с задачей, которая «наблюдает» за состояниями других задач. Его основное назначение — пометить запуск DAG-а как failed, если любая другая задача завершилась с ошибкой. Необходимость в этом возникла в системных тестах Airflow, которые представляют собой DAG-и с разными задачами (аналогично тесту, состоящему из шагов).

Обычно, когда любая задача завершается с ошибкой, все остальные задачи не выполняются, и весь запуск DAG-а также получает статус failed. Однако при использовании правил триггеров можно нарушить стандартный поток выполнения задач, и весь DAG может получить статус, отличный от ожидаемого. Например, можно иметь задачу очистки ресурсов (teardown task) с правилом триггера TriggerRule.ALL_DONE, которая будет выполняться независимо от состояния других задач (например, для освобождения ресурсов). В такой ситуации DAG всегда выполнит эту задачу, и запуск DAG-а получит статус именно этой задачи, в результате чего можно потерять информацию о задачах, завершившихся с ошибкой. Если требуется гарантировать, что DAG с задачей очистки завершится с ошибкой при падении любой задачи, необходимо использовать паттерн watcher.

Задача watcher — это задача, которая всегда завершается с ошибкой при выполнении, но она должна запускаться только в том случае, если любая другая задача завершилась с ошибкой. Для неё необходимо установить правило триггера TriggerRule.ONE_FAILED, а также сделать её downstream-задачей для всех остальных задач в DAG-е. Благодаря этому, если все остальные задачи завершатся успешно, watcher будет пропущена, а если произойдёт ошибка, задача watcher выполнится и завершится с ошибкой, что приведёт к статусу failed у всего запуска DAG-а.

Примечание

Следует учитывать, что правила триггеров опираются только на непосредственные upstream-задачи (родительские). Например, TriggerRule.ONE_FAILED будет игнорировать любые задачи со статусом failed (или upstream_failed), которые не являются прямыми родителями параметризуемой задачи.

Проще понять концепцию на примере. Предположим, у нас есть следующий DAG:

from datetime import datetime

from airflow.sdk import DAG
from airflow.sdk import task
from airflow.exceptions import AirflowException
from airflow.providers.standard.operators.bash import BashOperator
from airflow.utils.trigger_rule import TriggerRule


@task(trigger_rule=TriggerRule.ONE_FAILED, retries=0)
def watcher():
    raise AirflowException("Failing task because one or more upstream tasks failed.")


with DAG(
    dag_id="watcher_example",
    schedule="@once",
    start_date=datetime(2021, 1, 1),
    catchup=False,
) as dag:
    failing_task = BashOperator(task_id="failing_task", bash_command="exit 1", retries=0)
    passing_task = BashOperator(task_id="passing_task", bash_command="echo passing_task")
    teardown = BashOperator(
        task_id="teardown",
        bash_command="echo teardown",
        trigger_rule=TriggerRule.ALL_DONE,
    )

    failing_task >> passing_task >> teardown
    list(dag.tasks) >> watcher()

Визуальное представление этого DAG-а после выполнения выглядит следующим образом:

В нём есть несколько задач, выполняющих разные роли:

• failing_task — всегда завершается с ошибкой;
• passing_task — всегда завершается успешно (если выполняется);
• teardown — всегда запускается (независимо от состояний других задач) и должна всегда завершаться успешно;
• watcher — является downstream-задачей для всех остальных задач, то есть запускается, когда любая задача завершается с ошибкой, и тем самым переводит весь запуск DAG-а в состояние failed, так как является листовой задачей.

Важно отметить, что без задачи watcher весь запуск DAG-а получит состояние success, поскольку единственная задача, завершающаяся с ошибкой, не является листовой, а задача teardown завершится успешно. Если мы хотим, чтобы watcher отслеживала состояние всех задач, необходимо сделать её зависимой от каждой из них по отдельности. Благодаря этому мы можем перевести запуск DAG-а в состояние failed, если любая из задач завершится с ошибкой. Обратите внимание, что для задачи watcher установлено правило триггера «one_failed».

С другой стороны, без задачи teardown задача watcher не понадобилась бы, поскольку failing_task передала бы свой статус failed downstream-задаче passing_task, и весь запуск DAG-а также получил бы статус failed.

Использование исключения AirflowClusterPolicySkipDag в кластерных политиках для пропуска определённых DAG-ов

Добавлено в версии 2.7.

DAG-и Airflow обычно разворачиваются и обновляются из конкретной ветки Git-репозитория с помощью git-sync. Однако, когда по операционным причинам требуется запускать несколько кластеров Airflow, поддержка нескольких Git-веток становится крайне неудобной. Особенно это усложняется, когда необходимо периодически синхронизировать две отдельные ветки (например, prod и beta) с использованием корректной стратегии ветвления.

• cherry-pick слишком трудоёмок для сопровождения Git-репозитория;
• hard-reset не является рекомендуемым подходом в GitOps.

Вместо этого можно рассмотреть вариант подключения нескольких кластеров Airflow к одной и той же ветке Git (например, main) и управления ими с помощью разных переменных окружения и различных конфигураций подключений с одинаковым connection_id. При необходимости также можно выбрасывать исключение AirflowClusterPolicySkipDag в кластерной политике, чтобы загружать определённые DAG-и в DagBag только в конкретном развертывании Airflow.

def dag_policy(dag: DAG):
    """Пропуск DAG-а с тегом `only_for_beta`."""

    if "only_for_beta" in dag.tags:
        raise AirflowClusterPolicySkipDag(
            f"Dag {dag.dag_id} is not loaded on the production cluster, due to `only_for_beta` tag."
        )

Приведённый выше пример показывает фрагмент кода dag_policy, который пропускает DAG в зависимости от тегов, указанных у него.

Снижение сложности DAG-ов

Хотя Airflow хорошо справляется с обработкой большого количества DAG-ов с множеством задач и зависимостей между ними, при наличии большого числа сложных DAG-ов их сложность может негативно сказаться на производительности планирования. Одним из способов поддерживать высокую производительность и эффективное использование экземпляра Airflow является стремление к упрощению и оптимизации DAG-ов везде, где это возможно. Следует помнить, что процесс парсинга и создания DAG-а — это всего лишь выполнение Python-кода, и именно от вас зависит, насколько производительным он будет. Не существует «волшебных рецептов» для того, чтобы сделать DAG «менее сложным» — поскольку это Python-код, именно автор DAG-а контролирует сложность своего кода.

Не существует метрик «сложности DAG-а», и в частности нет метрик, которые могли бы однозначно сказать, является ли DAG «достаточно простым». Однако, как и в случае с любым Python-кодом, можно определить, что код DAG-а стал «проще» или «быстрее», если он оптимизирован. Если вы хотите оптимизировать свои DAG-и, можно предпринять следующие действия:

• Сделайте загрузку DAG-а быстрее:
  Это единственная рекомендация по улучшению, которая может быть реализована разными способами, но именно она оказывает наибольшее влияние на производительность планировщика. Если у вас есть возможность ускорить загрузку DAG-а — делайте это, если ваша цель — повышение производительности. Обратитесь к разделу Python-код верхнего уровня для получения советов, а также к Dag Loader Test, чтобы оценить время загрузки DAG-а.
• Генерируйте более простую структуру DAG-а:
  Каждая зависимость между задачами добавляет дополнительную нагрузку на планирование и выполнение. DAG с простой линейной структурой A → B → C будет испытывать меньшие задержки при планировании задач, чем DAG с глубоко вложенной древовидной структурой, например с экспоненциально растущим числом зависимых задач. Если вы можете сделать свои DAG-и более линейными — так, чтобы в каждый момент времени было как можно меньше потенциальных задач-кандидатов на запуск, — это, как правило, улучшит общую производительность планирования.
• Уменьшите количество DAG-ов в одном файле:
  Хотя Airflow 2 оптимизирован для сценария, при котором в одном файле описано несколько DAG-ов, в системе есть компоненты, из-за которых такой подход иногда менее производителен или приводит к большим задержкам по сравнению с разбиением DAG-ов по нескольким файлам. Уже сам факт того, что один файл может быть обработан только одним FileProcessor, делает этот подход менее масштабируемым. Если у вас много DAG-ов, генерируемых из одного файла, рассмотрите возможность их разделения, особенно если вы замечаете, что изменения в файлах DAG-ов долго отражаются в UI Airflow.
• Пишите эффективный Python-код:
  Необходимо соблюдать баланс между меньшим количеством DAG-ов в файле (как указано выше) и общим объёмом кода. Файлы Python, описывающие DAG-и, должны следовать лучшим практикам программирования и не должны рассматриваться как конфигурационные файлы. Если ваши DAG-и используют схожий код, не следует копировать его снова и снова в большое количество почти идентичных исходных файлов, так как это приведёт к ненужным повторным импортам одних и тех же ресурсов. Вместо этого следует стремиться к минимизации повторяющегося кода во всех DAG-ах, чтобы приложение работало эффективно и было проще в отладке.
  См. раздел Dynamic Dag Generation о том, как создавать несколько DAG-ов с похожей логикой.

Тестирование DAG-а

Пользователям Airflow следует относиться к DAG-ам как к коду промышленного уровня, и у DAG-ов должны быть различные связанные тесты, чтобы гарантировать получение ожидаемых результатов. Для DAG-а можно написать широкий спектр тестов. Рассмотрим некоторые из них.

Тест загрузки DAG-а (Dag Loader Test)

Этот тест должен гарантировать, что ваш DAG не содержит кода, который вызывает ошибку во время загрузки. Для запуска этого теста пользователю не требуется писать дополнительный код.

python your-dag-file.py

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

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

Существует множество способов измерить время выполнения, один из них в Linux — использование встроенной команды time. Обязательно запускайте её несколько раз подряд, чтобы учесть эффекты кэширования. Сравнивайте результаты до и после оптимизации (в одинаковых условиях — на той же машине, в том же окружении и т. д.), чтобы оценить влияние оптимизации.

time python airflow/example_dags/example_python_operator.py

Результат:

real    0m0.699s
user    0m0.590s
sys     0m0.108s

Важной метрикой является «real time», которая показывает, сколько времени заняла обработка DAG-а. Обратите внимание, что при таком способе загрузки файла каждый раз запускается новый интерпретатор, поэтому присутствует начальное время инициализации, которого нет при парсинге DAG-а самим Airflow. Оценить время инициализации можно, выполнив:

time python -c ''

Результат:

real    0m0.073s
user    0m0.037s
sys     0m0.039s

В данном случае начальное время запуска интерпретатора составляет примерно ~0,07 с, что составляет около 10% времени, необходимого для парсинга example_python_operator.py выше, поэтому фактическое время парсинга для примера DAG-а составляет примерно ~0,62 с.

Подробности о том, как тестировать отдельные операторы, см. в разделе Testing a Dag.

Юнит-тесты

Юнит-тесты гарантируют отсутствие некорректного кода в вашем DAG-е. Вы можете писать юнит-тесты как для отдельных задач, так и для самого DAG-а.

Юнит-тест загрузки DAG-а:

import pytest

from airflow.models import DagBag

@pytest.fixture()
def dagbag():
    return DagBag()

def test_dag_loaded(dagbag):
    dag = dagbag.get_dag(dag_id="hello_world")
    assert dagbag.import_errors == {}
    assert dag is not None
    assert len(dag.tasks) == 1

Юнит-тест структуры DAG-а:

Это пример теста, предназначенного для проверки структуры DAG-а, сгенерированного кодом, путём сравнения с объектом типа dict.

def assert_dag_dict_equal(source, dag):
    assert dag.task_dict.keys() == source.keys()
    for task_id, downstream_list in source.items():
        assert dag.has_task(task_id)
        task = dag.get_task(task_id)
        assert task.downstream_task_ids == set(downstream_list)

def test_dag():
    assert_dag_dict_equal(
        {
            "DummyInstruction_0": ["DummyInstruction_1"],
            "DummyInstruction_1": ["DummyInstruction_2"],
            "DummyInstruction_2": ["DummyInstruction_3"],
            "DummyInstruction_3": [],
        },
        dag,
    )

Юнит-тест для пользовательского оператора:

import pendulum

from airflow.sdk import DAG, TaskInstanceState

def test_my_custom_operator_execute_no_trigger(dag):
    TEST_TASK_ID = "my_custom_operator_task"
    with DAG(
        dag_id="my_custom_operator_dag",
        schedule="@daily",
        start_date=pendulum.datetime(2021, 9, 13, tz="UTC"),
    ) as dag:
        MyCustomOperator(
            task_id=TEST_TASK_ID,
            prefix="s3://bucket/some/prefix",
        )

    dagrun = dag.test()
    ti = dagrun.get_task_instance(task_id=TEST_TASK_ID)
    assert ti.state == TaskInstanceState.SUCCESS
    # Assert something related to tasks results: ti.xcom_pull()

Самопроверки (Self-Checks)

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

Аналогично, если у вас есть задача, которая запускает микросервис в Kubernetes или Mesos, следует проверить, был ли сервис успешно запущен, используя airflow.providers.http.sensors.http.HttpSensor.

task = PushToS3(...)
check = S3KeySensor(
    task_id="check_parquet_exists",
    bucket_key="s3://bucket/key/foo.parquet",
    poke_interval=0,
    timeout=0,
)
task >> check

Staging-окружение

По возможности поддерживайте staging-окружение для тестирования полного выполнения DAG-а перед деплоем в production. Убедитесь, что ваш DAG параметризован и позволяет изменять переменные, например путь вывода при работе с S3 или базу данных, используемую для чтения конфигурации. Не хардкодьте значения внутри DAG-а и не изменяйте их вручную в зависимости от окружения.

Для параметризации DAG-а вы можете использовать переменные окружения.

import os

dest = os.environ.get("MY_DAG_DEST_PATH", "s3://default-target/path/")

Мокирование переменных и подключений

При написании тестов для кода, использующего переменные или подключения, необходимо убедиться, что они существуют во время выполнения тестов. Очевидное решение — сохранить эти объекты в базе данных, чтобы их можно было прочитать во время выполнения кода. Однако чтение и запись объектов в базу данных сопровождаются дополнительными временными затратами. Чтобы ускорить выполнение тестов, имеет смысл имитировать наличие этих объектов без сохранения их в базе данных. Для этого можно создать переменные окружения, замокировав os.environ с помощью unittest.mock.patch.dict().

Для переменных используйте AIRFLOW_VAR_{KEY}.

with mock.patch.dict("os.environ", AIRFLOW_VAR_KEY="env-value"):
    assert "env-value" == Variable.get("key")

Для подключений используйте AIRFLOW_CONN_{CONN_ID}.

conn = Connection(
    conn_type="gcpssh",
    login="cat",
    host="conn-host",
)
conn_uri = conn.get_uri()
with mock.patch.dict("os.environ", AIRFLOW_CONN_MY_CONN=conn_uri):
    assert "cat" == Connection.get_connection_from_secrets("my_conn").login

Обслуживание metadata DB

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

Для очистки старых данных можно использовать Airflow CLI с командой airflow db clean.

Подробности см. в разделе использования db clean.

Обновления и откаты версий

Резервное копирование базы данных

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

Отключение планировщика

Во время проведения такого обслуживания можно рассмотреть отключение кластера Airflow.

Один из способов — установить параметр [scheduler] > use_job_schedule в значение False и дождаться завершения всех выполняющихся DAG-ов; после этого новые запуски DAG-ов не будут создаваться, если только они не будут запущены извне.

Лучший способ (хотя и более ручной) — использовать команду dags pause. Вам потребуется заранее зафиксировать список DAG-ов, которые не находятся в состоянии паузы, чтобы затем знать, какие из них нужно вернуть в активное состояние после завершения обслуживания. Сначала выполните airflow dags list и сохраните список не приостановленных DAG-ов. Затем используйте этот же список для выполнения dags pause для каждого DAG-а перед обслуживанием и dags unpause после его завершения. Преимущество такого подхода в том, что после обновления можно попробовать снять с паузы только один или два DAG-а (например, специальные тестовые DAG-и), чтобы убедиться, что всё работает корректно, прежде чем включать все DAG-и обратно.

Добавление DAG-ов для интеграционного тестирования

Полезно добавить несколько DAG-ов для «интеграционного тестирования», которые используют все основные сервисы вашей экосистемы (например, S3, Snowflake, Vault), но с тестовыми ресурсами или «dev»-аккаунтами. Эти тестовые DAG-и можно запускать первыми после обновления, поскольку в случае их сбоя это не приведёт к негативным последствиям, и вы сможете откатиться к резервной копии. Если же они выполняются успешно, это подтвердит, что кластер способен выполнять задачи с использованием необходимых библиотек и сервисов.

Например, если вы используете внешний secrets backend, убедитесь, что у вас есть задача, которая извлекает подключение. Если вы используете KubernetesPodOperator, добавьте задачу, выполняющую sleep 30; echo "hello". Если требуется запись в S3 — реализуйте это в тестовой задаче. А если нужен доступ к базе данных, добавьте задачу, выполняющую select 1 на сервере.

Очистка данных перед обновлением (Prune data)

Некоторые миграции базы данных могут занимать значительное время. Если база метаданных имеет очень большой размер, перед выполнением обновления стоит рассмотреть возможность очистки части старых данных с помощью команды db clean. Используйте с осторожностью.

Работа с конфликтующими и сложными Python-зависимостями

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

Если вы используете предопределённые Operator’ы Airflow для взаимодействия с внешними сервисами, выбор обычно невелик, однако такие операторы, как правило, имеют зависимости, не конфликтующие с базовыми зависимостями Airflow. Airflow использует механизм constraints, что означает наличие «зафиксированного» набора зависимостей, с которым сообщество гарантирует корректную установку Airflow (включая все community-провайдеры) без возникновения конфликтов. При этом вы можете обновлять провайдеры независимо, и их constraints вас не ограничивают, поэтому вероятность конфликтов зависимостей ниже (хотя такие зависимости всё равно необходимо тестировать). Таким образом, при использовании предопределённых операторов вероятность столкнуться с конфликтующими зависимостями минимальна или отсутствует вовсе.

Однако при более «современном» подходе к использованию Airflow — когда вы применяете TaskFlow API и большинство операторов реализуете с помощью собственного Python-кода, либо когда вы пишете собственные Custom Operator’ы — вы можете столкнуться с ситуацией, когда зависимости, требуемые вашим кастомным кодом, конфликтуют с зависимостями Airflow, или даже когда зависимости нескольких ваших Custom Operator’ов конфликтуют между собой.

Существует несколько стратегий, которые можно использовать для смягчения этой проблемы. И хотя работа с конфликтами зависимостей в кастомных операторах может быть сложной, она значительно упрощается при использовании airflow.providers.standard.operators.python.PythonVirtualenvOperator или airflow.providers.standard.operators.python.ExternalPythonOperator — как при прямом использовании классического подхода с Operator’ами, так и при использовании задач, декорированных @task.virtualenv или @task.external_python, если вы применяете TaskFlow.

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

Использование PythonVirtualenvOperator

Это самая простая в использовании и одновременно наиболее ограниченная стратегия. PythonVirtualenvOperator позволяет динамически создавать virtualenv, в котором будет выполняться ваш Python-callable. В современном подходе TaskFlow, описанном в разделе Pythonic Dags with the TaskFlow API, это также можно сделать, задекорировав callable декоратором @task.virtualenv (рекомендуемый способ использования оператора). Каждая задача airflow.providers.standard.operators.python.PythonVirtualenvOperator может иметь собственный независимый Python virtualenv (динамически создаваемый при каждом запуске задачи) и задавать детальный набор зависимостей, которые необходимо установить для выполнения этой задачи.

Оператор берёт на себя:

• создание virtualenv на основе вашего окружения,
• сериализацию вашего Python-callable и передачу его на выполнение Python-интерпретатору внутри virtualenv,
• выполнение callable, получение результата и передачу его через XCom, если это указано.

Преимущества оператора:

• Нет необходимости заранее подготавливать virtualenv. Он динамически создаётся перед запуском задачи и удаляется после её завершения, поэтому для использования нескольких виртуальных окружений не требуется ничего особенного (кроме наличия пакета virtualenv в зависимостях Airflow).
• Вы можете запускать задачи с разными наборами зависимостей на одних и тех же воркерах — таким образом, ресурсы памяти переиспользуются (хотя см. ниже про накладные расходы на CPU при создании virtualenv).
• В крупных инсталляциях авторам Dag’ов не нужно просить кого-то создавать virtualenv за них. Как автор Dag’а, вам достаточно иметь установленную зависимость virtualenv, и вы можете задавать и изменять окружения по своему усмотрению.
• Не требуется изменений в требованиях к деплою — независимо от того, используете ли вы локальный virtualenv, Docker или Kubernetes, задачи будут работать без добавления чего-либо в окружение развертывания.
• Автору Dag’ов не нужно изучать контейнеры или Kubernetes. Для такого подхода к написанию Dag’ов достаточно знания Python-зависимостей.

У данного оператора есть определённые ограничения и накладные расходы:

• Ваш Python-callable должен быть сериализуемым. Существует множество Python-объектов, которые не сериализуются стандартной библиотекой pickle. Часть этих ограничений можно обойти с помощью библиотеки dill, однако и она не решает всех проблем сериализации.
• Все зависимости, отсутствующие в окружении Airflow, должны импортироваться локально внутри используемого callable, а код верхнего уровня Dag не должен импортировать или использовать эти библиотеки.
• Virtualenv запускаются в рамках одной и той же операционной системы, поэтому они не могут иметь конфликтующие системные зависимости (устанавливаемые через apt или yum). Независимо могут устанавливаться только Python-зависимости.
• Оператор добавляет накладные расходы на CPU, сеть и общее время выполнения каждой задачи — Airflow вынужден пересоздавать virtualenv с нуля для каждого запуска задачи.
• Воркеры должны иметь доступ к PyPI или приватным репозиториям для установки зависимостей.
• Динамическое создание virtualenv подвержено временным сбоям (например, если репозиторий недоступен или возникают сетевые проблемы при подключении к нему).
• Легко попасть в ситуацию «слишком» динамичного окружения — устанавливаемые зависимости могут обновляться, а их транзитивные зависимости могут получать независимые обновления, в результате чего задача может перестать работать из-за выхода новой версии зависимости или вы можете стать жертвой атаки на цепочку поставок, когда новая версия зависимости оказывается вредоносной.
• Задачи изолированы друг от друга только за счёт выполнения в разных окружениях. Это означает, что выполняющиеся задачи всё ещё могут влиять друг на друга — например, последующие задачи, выполняемые на том же воркере, могут быть затронуты предыдущими задачами, которые создавали или изменяли файлы и т. п.

Подробные примеры использования airflow.providers.standard.operators.python.PythonVirtualenvOperator приведены в соответствующем разделе руководства по TaskFlow API.

Использование ExternalPythonOperator

Добавлено в версии 2.4.

Более сложным в использовании, но при этом значительно менее накладным с точки зрения ресурсов, безопасности и стабильности вариантом является использование airflow.providers.standard.operators.python.ExternalPythonOperator. В современном подходе TaskFlow, описанном в разделе Pythonic Dags with the TaskFlow API, этого также можно добиться, задекорировав ваш callable декоратором @task.external_python (рекомендуемый способ использования оператора). Однако для этого требуется заранее подготовленное, неизменяемое Python-окружение. В отличие от airflow.providers.standard.operators.python.PythonVirtualenvOperator, вы не можете добавлять новые зависимости в такое предсуществующее окружение. Все необходимые зависимости должны быть добавлены заранее и быть доступны на всех воркерах, если Airflow работает в распределённом окружении.

Таким образом, вы избегаете накладных расходов и проблем, связанных с пересозданием virtualenv, однако такие окружения необходимо подготовить и задеплоить вместе с установкой Airflow. Обычно в этот процесс вовлечены специалисты, отвечающие за установку Airflow, и в крупных инсталляциях это, как правило, другие люди, нежели авторы Dag’ов (DevOps/System Admins).

Такие virtualenv могут быть подготовлены разными способами: при использовании LocalExecutor их достаточно установить на машине, где запускается планировщик; при использовании распределённой установки Celery должна существовать пайплайн, который устанавливает эти virtualenv на нескольких машинах; наконец, если вы используете Docker-образы (например, в Kubernetes), создание virtualenv должно быть добавлено в пайплайн сборки вашего кастомного образа.

Преимущества оператора:

• Отсутствие накладных расходов при запуске задачи. Virtualenv уже готов в момент начала выполнения задачи.
• Вы можете запускать задачи с разными наборами зависимостей на одних и тех же воркерах — таким образом, все ресурсы переиспользуются.
• Воркерам не требуется доступ к PyPI или приватным репозиториям. Меньше вероятность временных сбоев, связанных с сетью.
• Зависимости могут быть заранее проверены администраторами и командой безопасности, и никакой новый, неожиданный код не будет динамически добавляться. Это полезно как с точки зрения безопасности, так и стабильности.
• Минимальное влияние на деплой — вам не нужно переходить на Docker-контейнеры или Kubernetes, чтобы эффективно использовать оператор.
• Автору Dag’ов не нужно изучать контейнеры или Kubernetes. Для написания Dag’ов таким способом достаточно знания Python и работы с requirements.

Недостатки:

• Окружения должны быть подготовлены заранее. Обычно это означает, что вы не можете менять их «на лету»: добавление новых зависимостей или изменение существующих требует как минимум повторного деплоя Airflow, а время итераций при разработке новых версий может увеличиться.
• Ваш Python-callable должен быть сериализуемым. Существует множество Python-объектов, которые не сериализуются стандартной библиотекой pickle. Часть этих ограничений можно смягчить с помощью библиотеки dill, однако она также не решает всех проблем сериализации.
• Все зависимости, отсутствующие в окружении Airflow, должны импортироваться локально внутри используемого callable, а код верхнего уровня Dag не должен импортировать или использовать эти библиотеки.
• Virtualenv запускаются в рамках одной и той же операционной системы, поэтому они не могут иметь конфликтующие системные зависимости (устанавливаемые через apt или yum). Независимо могут устанавливаться только Python-зависимости.
• Задачи изолированы друг от друга только за счёт выполнения в разных окружениях. Это означает, что выполняющиеся задачи всё ещё могут влиять друг на друга — например, последующие задачи, выполняемые на том же воркере, могут быть затронуты предыдущими задачами, которые создавали или изменяли файлы и т. п.

PythonVirtualenvOperator и ExternalPythonOperator можно рассматривать как взаимодополняющие инструменты, которые упрощают переход от этапа разработки к продакшену. Как автор Dag’ов, вы обычно будете итерироваться с зависимостями и разрабатывать Dag, используя PythonVirtualenvOperator (декорируя задачи @task.virtualenv), а после завершения итераций и внесения изменений, для продакшена, скорее всего, переключитесь на ExternalPythonOperator (и @task.external_python) после того, как команды DevOps/System Admin развернут новые зависимости в предсуществующих virtualenv в продакшене. Преимущество такого подхода в том, что вы в любой момент можете вернуть декоратор обратно и продолжить «динамическую» разработку с PythonVirtualenvOperator.

Подробные примеры использования airflow.providers.standard.operators.python.ExternalPythonOperator приведены в разделе TaskFlow External Python example.

Использование DockerOperator или KubernetesPodOperator

Ещё одной стратегией является использование airflow.providers.docker.operators.docker.DockerOperator и airflow.providers.cncf.kubernetes.operators.pod.KubernetesPodOperator. Для этого требуется, чтобы Airflow имел доступ к Docker Engine или кластеру Kubernetes.

Аналогично Python-операторам, декораторы TaskFlow удобны в случае, если вы хотите использовать эти операторы для выполнения вашего Python-callable.

Однако этот подход значительно сложнее — вам необходимо понимать, как работают Docker-контейнеры и Kubernetes Pod’ы, если вы хотите его использовать. Зато задачи полностью изолированы друг от друга, и вы даже не ограничены выполнением только Python-кода. Вы можете писать задачи на любом языке программирования. Кроме того, ваши зависимости полностью независимы от зависимостей Airflow (включая системные зависимости), поэтому если вашей задаче требуется принципиально иное окружение, это подходящий вариант.

Добавлено в версии 2.2:
Начиная с версии Airflow 2.2, вы можете использовать декоратор @task.docker для запуска функций с помощью DockerOperator.

Добавлено в версии 2.4:
Начиная с версии Airflow 2.2, вы можете использовать декоратор @task.kubernetes для запуска функций с помощью KubernetesPodOperator.

Преимущества использования этих операторов:

• Вы можете запускать задачи с разными наборами как Python-, так и системных зависимостей, а также задачи, написанные на совершенно другом языке программирования или даже под другую архитектуру процессора (x86 vs. arm).
• Окружение, в котором выполняются задачи, использует оптимизации и неизменяемость контейнеров. Похожие наборы зависимостей эффективно переиспользуют закешированные слои образов, поэтому окружение хорошо оптимизировано для случаев, когда у вас есть несколько похожих, но разных окружений.
• Зависимости могут быть заранее проверены администраторами и командой безопасности, и никакой новый, неожиданный код не будет динамически добавляться. Это полезно как с точки зрения безопасности, так и стабильности.
• Полная изоляция между задачами. Они не могут влиять друг на друга иначе, чем через стандартные механизмы Airflow XCom.

Недостатки:

• Существует накладной расход на запуск задач. Обычно он меньше, чем при динамическом создании virtualenv, но всё равно заметен (особенно для KubernetesPodOperator).
• В случае использования декораторов TaskFlow весь вызываемый метод должен быть сериализован и передан в Docker-контейнер или Kubernetes Pod, при этом существуют системные ограничения на размер метода. Сериализация, передача и последующая десериализация на удалённой стороне также добавляют накладные расходы.
• Присутствуют накладные расходы по ресурсам, связанные с необходимостью нескольких процессов. При использовании этих операторов для выполнения задач требуется как минимум два процесса: один процесс (в Docker-контейнере или Kubernetes Pod), выполняющий задачу, и процесс-наблюдатель в воркере Airflow, который отправляет задание в Docker/Kubernetes и отслеживает его выполнение.
• Контейнерные образы должны быть подготовлены заранее. Обычно это означает, что вы не можете изменять их «на лету». Добавление системных зависимостей, изменение или обновление Python-зависимостей требует пересборки и публикации образа (как правило, в приватном реестре). Время итераций при работе с новыми зависимостями обычно больше и требует от разработчика сборки и использования собственных образов во время разработки. Наличие корректного пайплайна деплоя здесь критически важно для надёжного сопровождения системы.
• Если вы хотите запускать Python-callable через декораторы, он должен быть сериализуемым. Также в этом случае все зависимости, отсутствующие в окружении Airflow, должны импортироваться локально внутри используемого callable, а код верхнего уровня Dag не должен импортировать или использовать эти библиотеки.
• Вам необходимо глубже понимать, как работают Docker-контейнеры или Kubernetes. Абстракции, предоставляемые этими технологиями, являются «протекающими», поэтому для написания Dag’ов с использованием этих операторов нужно разбираться в ресурсах, сетях, контейнерах и других аспектах.

Подробные примеры использования airflow.providers.docker.operators.docker.DockerOperator приведены в разделе TaskFlow Docker example, а airflow.providers.cncf.kubernetes.operators.pod.KubernetesPodOperator — в разделе TaskFlow Kubernetes example.

Использование нескольких Docker-образов и очередей Celery

Существует возможность (хотя она требует глубокого понимания деплоя Airflow) запускать задачи Airflow с использованием нескольких независимых Docker-образов. Это можно реализовать путём назначения разных задач разным очередям (Queues) и настройки Celery-воркеров на использование разных образов для разных очередей. Однако такой подход (по крайней мере на данный момент) требует большого объёма ручной конфигурации деплоя и глубоких знаний того, как работают Airflow, Celery и Kubernetes. Кроме того, он вносит существенные накладные расходы при выполнении задач — снижается возможность переиспользования ресурсов, а также становится значительно сложнее точно настраивать стоимость потребляемых ресурсов без негативного влияния на производительность и стабильность.

Одним из возможных способов сделать этот подход более полезным является реализация AIP-46 (Runtime isolation for Airflow tasks and Dag parsing) и завершение AIP-43 (Dag Processor Separation). До реализации этих инициатив преимуществ у данного подхода крайне мало, и он не рекомендуется к использованию.

Однако после реализации этих AIP откроется возможность более мультиарендного (multi-tenant) подхода, при котором несколько команд смогут иметь полностью изолированные наборы зависимостей, используемые на протяжении всего жизненного цикла Dag — от парсинга до выполнения.

Создание пользовательского оператора (custom Operator)

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

Вы можете создать любой оператор, унаследовавшись от публичного базового класса SDK — BaseOperator.

В производном классе необходимо переопределить два метода:

• Конструктор (__init__) — определить параметры, необходимые для оператора. Нужно указывать только аргументы, специфичные для вашего оператора. default_args можно задать в файле Dag.
• Execute — код, который будет выполнен при вызове оператора раннером. Метод принимает контекст Airflow в качестве параметра, который можно использовать для чтения конфигурационных значений.

Примечание

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

Реализуем пример HelloOperator в новом файле hello_operator.py:

from airflow.sdk import BaseOperator


class HelloOperator(BaseOperator):
    def __init__(self, name: str, **kwargs) -> None:
        super().__init__(**kwargs)
        self.name = name

    def execute(self, context):
        message = f"Hello {self.name}"
        print(message)
        return message

Примечание

Чтобы импорты работали корректно, файл должен находиться в директории, присутствующей в переменной окружения PYTHONPATH. Airflow по умолчанию добавляет директории dags/, plugins/ и config/ из домашнего каталога Airflow в PYTHONPATH. В нашем примере файл размещён в директории custom_operator/.

Теперь вы можете использовать созданный пользовательский оператор следующим образом:

from custom_operator.hello_operator import HelloOperator

with dag:
    hello_task = HelloOperator(task_id="sample-task", name="foo_bar")

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

from hello_operator import HelloOperator

Если оператор взаимодействует с внешним сервисом (API, база данных и т. п.), рекомендуется реализовать слой взаимодействия через Hooks. Это позволит повторно использовать реализованную логику в других операторах. Такой подход обеспечивает лучшее разделение ответственности и более эффективное использование интеграции по сравнению с созданием CustomServiceBaseOperator для каждого внешнего сервиса.

Ещё один аспект — временное состояние. Если операция требует хранения состояния в памяти (например, job id, который должен использоваться в методе on_kill для отмены запроса), это состояние должно храниться в операторе, а не в hook. Таким образом, hook сервиса остаётся полностью stateless, а вся логика операции сосредоточена в одном месте — в операторе.

Hooks

Hooks выступают интерфейсом для взаимодействия с внешними общими ресурсами в Dag. Например, нескольким задачам в Dag может потребоваться доступ к базе данных MySQL. Вместо создания отдельного подключения для каждой задачи можно получить подключение через hook и использовать его повторно.

Hook также помогает избежать хранения параметров аутентификации подключения непосредственно в Dag.

Расширим предыдущий пример и получим имя из MySQL:

class HelloDBOperator(BaseOperator):
    def __init__(self, name: str, mysql_conn_id: str, database: str, **kwargs) -> None:
        super().__init__(**kwargs)
        self.name = name
        self.mysql_conn_id = mysql_conn_id
        self.database = database

    def execute(self, context):
        hook = MySqlHook(mysql_conn_id=self.mysql_conn_id, schema=self.database)
        sql = "select name from user"
        result = hook.get_first(sql)
        message = f"Hello {result['name']}"
        print(message)
        return message

Когда оператор выполняет запрос через объект hook, создаётся новое подключение, если оно ещё не существует. Hook получает параметры аутентификации (например, имя пользователя и пароль) из backend Airflow и передаёт их в airflow.hooks.base.BaseHook.get_connection().

Создавать hook следует только в методе execute или в методах, вызываемых из execute. Конструктор вызывается каждый раз при парсинге Dag (а это происходит часто), и создание hook в нём приведёт к множеству ненужных подключений к базе данных. Метод execute вызывается только во время запуска Dag.

Пользовательский интерфейс

Airflow позволяет разработчику управлять отображением оператора в интерфейсе Dag.

• Переопределите ui_color, чтобы изменить цвет фона оператора в UI.
• Переопределите ui_fgcolor, чтобы изменить цвет текста.

Переопределите custom_operator_name, чтобы изменить отображаемое имя (отличное от имени класса).

class HelloOperator(BaseOperator):
    ui_color = "#ff0000"
    ui_fgcolor = "#000000"
    custom_operator_name = "Howdy"
    # ...

Шаблонизация (Templating)

Вы можете использовать шаблоны Jinja для параметризации оператора. Airflow применяет шаблонизацию к полям, указанным в template_fields, во время рендеринга оператора.

class HelloOperator(BaseOperator):
    template_fields: Sequence[str] = ("name",)

    def __init__(self, name: str, world: str, **kwargs) -> None:
        super().__init__(**kwargs)
        self.name = name
        self.world = world

    def execute(self, context):
        message = f"Hello {self.world} it's {self.name}!"
        print(message)
        return message

Использование шаблона:

with dag:
    hello_task = HelloOperator(
        task_id="task_id_1",
        name="{{ task_instance.task_id }}",
        world="Earth",
    )

В этом примере Jinja найдёт параметр name и заменит {{ task_instance.task_id }} на task_id_1.

Параметр также может содержать имя файла, например bash-скрипта или SQL-файла. В этом случае нужно указать расширение файла в template_ext. Если поле из template_fields содержит строку, заканчивающуюся расширением из template_ext, Jinja прочитает содержимое файла и заменит шаблоны на реальные значения.

Обратите внимание: Jinja подставляет значения в атрибуты оператора, а не в аргументы функции.

class HelloOperator(BaseOperator):
    template_fields: Sequence[str] = ("guest_name",)
    template_ext = ".sql"

    def __init__(self, name: str, **kwargs) -> None:
        super().__init__(**kwargs)
        self.guest_name = name

В этом примере template_fields должен быть ['guest_name'], а не ['name'].

Дополнительно вы можете указать template_fields_renderers — словарь, определяющий, в каком формате значение шаблонного поля будет отображаться в веб-интерфейсе. Например:

class MyRequestOperator(BaseOperator):
    template_fields: Sequence[str] = ("request_body",)
    template_fields_renderers = {"request_body": "json"}

    def __init__(self, request_body: str, **kwargs) -> None:
        super().__init__(**kwargs)
        self.request_body = request_body

В ситуации, когда template_field сам по себе является словарём, также можно указать путь к ключу через точку, чтобы извлекать и корректно отображать отдельные элементы. Например:

class MyConfigOperator(BaseOperator):
    template_fields: Sequence[str] = ("configuration",)
    template_fields_renderers = {
        "configuration": "json",
        "configuration.query.sql": "sql",
    }

    def __init__(self, configuration: dict, **kwargs) -> None:
        super().__init__(**kwargs)
        self.configuration = configuration

Использование этого шаблона:

with dag:
    config_task = MyConfigOperator(
        task_id="task_id_1",
        configuration={"query": {"job_id": "123", "sql": "select * from my_table"}},
    )

В результате в UI поле configuration будет отображаться в формате JSON, а значение, находящееся по пути configuration.query.sql, будет подсвечено с использованием SQL-лексера.

В настоящее время доступны следующие лексеры:

• bash
• bash_command
• doc
• doc_json
• doc_md
• doc_rst
• doc_yaml
• doc_md
• hql
• html
• jinja
• json
• md
• mysql
• postgresql
• powershell
• py
• python_callable
• rst
• sql
• tsql
• yaml

Если вы укажете несуществующий лексер, значение шаблонного поля будет отображено как красиво отформатированный (pretty-printed) объект.

Ограничения

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

1. Параметры конструктора, соответствующие шаблонным полям, должны называться точно так же, как и сами поля.

Следующий пример некорректен, так как имя параметра конструктора не совпадает с именем шаблонного поля:

class HelloOperator(BaseOperator):
    template_fields = "foo"

    def __init__(self, foo_id) -> None:  # должно быть def __init__(self, foo) -> None
        self.foo = foo_id  # должно быть self.foo = foo

2. Атрибуты экземпляра, соответствующие шаблонным полям, должны быть явно присвоены из соответствующих параметров конструктора — либо напрямую, либо через вызов конструктора родительского класса (где эти поля определены как template_fields) с явной передачей параметров.

Следующий пример некорректен, так как атрибут self.foo вообще не присваивается, несмотря на то, что он объявлен как шаблонное поле:

class HelloOperator(BaseOperator):
    template_fields = ("foo", "bar")

    def __init__(self, foo, bar) -> None:
        self.bar = bar

Следующий пример также некорректен, так как self.foo в MyHelloOperator инициализируется неявно через kwargs, переданные в конструктор родителя:

class HelloOperator(BaseOperator):
    template_fields = "foo"

    def __init__(self, foo) -> None:
        self.foo = foo


class MyHelloOperator(HelloOperator):
    template_fields = ("foo", "bar")

    def __init__(self, bar, **kwargs) -> None:  # должно быть def __init__(self, foo, bar, **kwargs)
        super().__init__(**kwargs)  # должно быть super().__init__(foo=foo, **kwargs)
        self.bar = bar

3. Нельзя применять преобразования к параметру при его присваивании в конструкторе.

Любые действия над значением должны выполняться в методе execute().

Следующий пример некорректен:

class HelloOperator(BaseOperator):
    template_fields = "foo"

    def __init__(self, foo) -> None:
        self.foo = foo.lower()  # должно быть только self.foo = foo

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

Следующий пример корректен:

class HelloOperator(BaseOperator):
    template_fields = "foo"

    def __init__(self, foo) -> None:
        self.foo = foo


class MyHelloOperator(HelloOperator):
    template_fields = "foo"

Эти ограничения проверяются pre-commit hook’ом с именем validate-operators-init.

Добавление шаблонных полей через наследование

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

Предположим, у вас есть ранее определённый HelloOperator:

class HelloOperator(BaseOperator):
    template_fields: Sequence[str] = ("name",)

    def __init__(self, name: str, world: str, **kwargs) -> None:
        super().__init__(**kwargs)
        self.name = name
        self.world = world

    def execute(self, context):
        message = f"Hello {self.world} it's {self.name}!"
        print(message)
        return message

Допустим, вы хотите динамически параметризовать аргумент world.

Поскольку template_fields гарантированно является Sequence[str] (списком или кортежем строк), можно легко создать подкласс и расширить список шаблонных полей:

class MyHelloOperator(HelloOperator):
    template_fields: Sequence[str] = (*HelloOperator.template_fields, "world")

Теперь можно использовать MyHelloOperator следующим образом:

with dag:
    hello_task = MyHelloOperator(
        task_id="task_id_1",
        name="{{ task_instance.task_id }}",
        world="{{ var.value.my_world }}",
    )

В этом примере аргумент world будет динамически установлен в значение переменной Airflow с именем my_world через Jinja-выражение.

Определение дополнительной ссылки (Extra Link) для оператора

Для своего оператора вы можете определить дополнительную ссылку (extra link), которая будет перенаправлять пользователей во внешние системы. Например, можно добавить ссылку, ведущую на документацию или руководство по использованию оператора.

Sensors

Airflow предоставляет специальный тип оператора — Sensor, предназначенный для регулярной проверки (polling) некоторого состояния (например, наличия файла) до тех пор, пока не будет выполнено условие успешного завершения.

Вы можете создать собственный сенсор, унаследовавшись от airflow.sensors.base.BaseSensorOperator и реализовав метод poke, который будет опрашивать внешнее состояние и проверять критерий успешности.

Режим reschedule

У сенсоров есть мощная возможность — режим reschedule, который позволяет задаче сенсора быть перепланированной, вместо того чтобы занимать слот воркера между проверками.

Это полезно, если:

• вы можете позволить себе более длинный интервал опроса,
• ожидается длительное ожидание выполнения условия.

Ограничение режима reschedule

Режим reschedule имеет важное ограничение: сенсор не может сохранять внутреннее состояние между перепланированными запусками.

Если ваш сенсор хранит внутреннее состояние, его следует декорировать с помощью airflow.sensors.base.poke_mode_only(). Это даст пользователям понять, что сенсор не подходит для использования в режиме reschedule.

Пример сенсора с внутренним состоянием

Примером сенсора, который хранит внутреннее состояние и не может использоваться в режиме reschedule, является:

airflow.providers.google.cloud.sensors.gcs.GCSUploadSessionCompleteSensor

Этот сенсор:

• опрашивает количество объектов по заданному префиксу (это количество является его внутренним состоянием),
• считается успешно завершённым, если в течение определённого времени количество объектов не меняется.

Сообщение Best Practices — Airflow 3 Документация появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

Глава 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: Описание некоторых распространённых исполнителей, доступных в настоящее время для выполнения задач, их сложность и варианты использования в эксплуатации.

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

Локальные исполнители (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.

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

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

$ 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» появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

Глава 2. Основные концепции Airflow

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

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

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

• Запуск Apache Airflow на вашей локальной машине с помощью airflowctl
• Строительные блоки DAG’ов
• Как максимально эффективно использовать группы задач и организовывать DAG’и

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

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

Установка Airflow локально требует ряда технологий и предварительных условий. В частности, мы рекомендуем установить актуальную версию Python, так как старые версии не имеют долгосрочной поддержки. Кроме того, для запуска Airflow требуется как минимум 4 ГБ оперативной памяти, хотя это требование зависит от размера развертывания и сложности DAG’ов.

Интерфейс командной строки (CLI) — это текстовый пользовательский интерфейс, используемый для взаимодействия с программным обеспечением и операционными системами. Через CLI пользователи вводят текстовые команды для выполнения определённых задач или операций, напрямую взаимодействуя с системой. Такой интерфейс позволяет эффективно выполнять команды, автоматизировать задачи с помощью скриптов и получать доступ к широкому спектру системных функций. CLI особенно ценятся разработчиками и системными администраторами за точность, возможность скриптования и низкое потребление ресурсов по сравнению с графическими интерфейсами (GUI).

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

Самый простой и быстрый способ начать работу с Airflow — использовать команду Airflow CLI в вашем терминале или командной строке:

$ airflowctl

Первичный запуск команды проверит, установлена ли она уже на вашей локальной машине. Если вы получите следующий запрос, выполните приведённые далее инструкции по установке:

Рисунок 2.1: настройка airflowctl

Использование airflowctl (https://github.com/kaxil/airflowctl) позволяет выполнить начальную установку вне Docker-контейнеров или Kubernetes.
Рекомендуется устанавливать CLI с помощью pip. Если у вас не установлен pip, вы можете установить его, следуя этим инструкциям: https://pip.pypa.io/en/stable/installation/. С помощью pip следующая команда установит CLI:

$ pip install airflowctl

Если во время установки не возникло ошибок, следующим шагом будет запуск команды инициализации. При выполнении этой команды создаётся каталог проекта с названием my_airflow_project в вашей текущей папке и запускается веб-сервер Airflow:

$ airflowctl init my_airflow_project --build-start

Сразу после запуска этой команды в верхней части командного терминала вы увидите расположение папки проекта и другую информацию об инициализации:

Рисунок 2.2: Инициализация проекта Airflow

В этом примере папка проекта расположена по пути /Users/kendrickvandoorn/my_airflow_project\ x, и она была инициализирована с предустановленной организацией папок и файлов, необходимых для запуска первого проекта. Обратите внимание, что имя my_airflow_project, заданное в команде CLI, совпадает с именем папки проекта, но его можно изменить в соответствии с вашими потребностями.

По мере продолжения работы CLI airflowctl веб-сервер, триггер и планировщик будут запускаться, а их задачи будут отмечены в начале каждой строки. Например, ознакомьтесь со следующим снимком экрана, отображающим логотип Airflow, который показывает, что триггер и планировщик активны, а следующие действия относятся к различным серверам.

Рисунок 2.3: Командная строка Airflow

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

Рисунок 2.4: Успешная инициализация Airflow

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

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

Рисунок 2.5: Сигналы веб-сервера

Чтобы перейти к веб-серверу, откройте браузер и введите в адресной строке следующее:

http://localhost:8080

Перейдя на localhost, при условии, что веб-сервер Airflow продолжает работать в терминале, вам будет предложено войти в систему с именем пользователя и паролем. Используйте имя пользователя admin и пароль, который был показан в терминале.

Завершив процесс входа в систему, вы попадёте на домашнюю страницу, которая должна выглядеть следующим образом:

Рисунок 2.6: Домашняя страница DAG

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

С работающей средой Airflow давайте рассмотрим основные компоненты Airflow на примере DAG, который уже предоставлен.

DAG-и

DAG-и (направленные ациклические графы) — это основной способ оркестровки пайплайнов данных. Они создаются с использованием Python и опираются на широкий спектр вспомогательных библиотек. Следуя предыдущим шагам по инициализации локальной среды разработки, вы загрузили пример example_dag_basic, который мы рассмотрим в этом разделе.

В своей основе DAG-и состоят из задач (tasks), операторов (operators) и сенсоров (sensors). За последние годы были также введены новые подходы, такие как группы задач (task groups) и откладываемые операторы (deferrable operators), которые мы также рассмотрим в этой главе.

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

Рисунок 2.7: Конфигурация DAG

Чтобы просмотреть визуализированное представление этого первоначального примера DAG, выберите опцию Graph из списка опций в верхней части области DAG. Это отобразит графическое представление DAG.

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

Рисунок 2.8: Сопоставление триггеров

Если example_dag_basic не был включён при инициализации, вы можете найти полный блок рабочего кода в конце этой главы или перейти на GitHub-страницу книги курса (https://github.com/PacktPublishing/Apache-Airflow-Best-Practices).

Цель этого примера DAG — выполнить простую функцию извлечения, преобразования и загрузки данных (extract, transform, load — ETL). В конечном итоге мы покажем ожидаемый результат и то, как подтвердить завершение выполнения.

Декораторы и определение DAG

Первым шагом в любом Python-файле является импорт необходимых библиотек и вспомогательных функций. DAG в Airflow не является исключением. Мы начинаем с импорта json и декораторов Airflow:

import json
from airflow.decorators import (
    dag,
    task,
)

Импорт декораторов dag и task позволяет нам объявить DAG проще, чем раньше. Такой подход устраняет необходимость объявления конструкции with DAG as, как это требовалось ранее. Давайте объявим DAG и определим некоторые из необходимых полей, таких как расписание:

@dag(
    schedule="@daily",
    start_date=datetime(2023,1,1),
    catchup=False,
    default_args={
        "retries": 2,
    },
    tags=["example"],
)

В приведённом выше фрагменте кода мы объявили schedule интервал, start_date, catchup, default_args и tags. Давайте кратко рассмотрим каждый из них.

Планирование с Apache Airflow и отказ от CRON

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

Таблица 2.1: Интервалы расписания для даты и времени

• Далее указывается start_date. Важно задать дату начала, так как вы можете захотеть, чтобы конвейер выполнялся в тот же день, в будущем или в прошлом. Если start_date установлена в прошлом и catchup задан как True, тогда DAG будет выполняться столько раз, сколько предусмотрено расписанием. В приведённом примере catchup установлен как False, поэтому DAG не будет выполняться за предыдущие дни, начиная с 1 января 2023 года. Если бы мы установили catchup равным True, то следовало бы ожидать, что Airflow выполнит столько заданий, сколько дней прошло с 1 января 2023 года по настоящее время.
• default_args — это значения по умолчанию, которые мы хотим изменить. В этом примере мы изменяем retries, установив его равным 2. Это количество попыток повторного выполнения задач DAG в случае их неудачи. Это полезный инструмент, если DAG пытается подключиться к базе данных, в которой часто возникают проблемы с подключением или обновлением, так как задачи будут пытаться выполниться снова позже, не влияя на другие задачи.
• Наконец, мы применяем tags (теги) к DAG, чтобы начать их группировку. Тег отображается в интерфейсе Airflow и может быть полезен для пометки различных DAG для разных систем, команд или пользователей в будущем.

Задачи / Tasks

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

Прежде чем приступить к анализу этого простого примера DAG и связанных с ним задач, нам нужно рассмотреть операторы и как они используются.

Операторы задач

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

Airflow поставляется с большим набором операторов для различных задач, что позволяет пользователям сразу использовать широкий спектр возможностей. Некоторые из часто используемых типов включают:

• BashOperator: выполняет bash-команду
• PythonOperator: запускает Python-функцию
• SqlOperator: выполняет SQL-команду
• DockerOperator: запускает Docker-контейнер
• HttpOperator: отправляет HTTP-запрос

Операторы также могут быть настроены и расширены в соответствии с конкретными требованиями, обеспечивая гибкость в том, как задачи выполняются внутри DAGов Airflow. Такая архитектура позволяет пользователям создавать сложные конвейеры обработки данных, которые легко понимать, сопровождать и масштабировать. Большинство операторов являются с открытым исходным кодом и доступны для ознакомления — их можно найти, выполнив поиск по названию на GitHub.

Первая задача — определение DAG и извлечение данных

Мы создадим три задачи для выполнения этого базового примера DAG. Задачи извлечения, преобразования и загрузки будут выполнять разные функции. Первая задача — задача извлечения.

Следующий фрагмент кода взят из базового примера DAG:

def example_dag_basic():
    @task()
    def extract():
        data_string = '{"1001": 301.27, "1002": 433.21,\
                        "1003":502.22}'
        order_data_dict = json.loads(data_string)
        return order_data_dict

Мы начинаем с объявления @task, чтобы указать, что следующая функция будет задачей, используемой в Airflow. В этой первой задаче мы определяем функцию extract, которая не принимает аргументов или переменных. Внутри extract() мы определяем простую строку data_string, которая затем преобразуется в словарь данных. В конце функция возвращает полученную информацию.

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

Определение задачи преобразования (transform task)

В следующей задаче мы выполним простое действие по преобразованию. Эта задача принимает словарь данных и вычисляет общую сумму заказов:

@task(multiple_outputs=True)
def transform(order_data_dict: dict):
    total_order_value = 0
    for value in order_data_dict.values():
        total_order_value += value
    return {"total_order_value": total_order_value}

Задача преобразования принимает order_data_dict в качестве входных данных для выполнения задачи преобразования. Далее мы задаём переменную total_order_value, равную 0, чтобы подготовить её для использования в следующем цикле. Создаётся цикл for, который рассчитывает общую сумму заказов путём суммирования значений. В конце мы возвращаем общую сумму заказов для использования в следующей задаче.

В этой задаче мы видим новый аргумент, передаваемый в @task — multiple_outputs. Его использование разворачивает словарь данных в отдельные значения XCom.

XComs

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

XComs работают за счёт того, что одна задача может передавать данные в мета-базу данных Airflow, где они хранятся под определённым ключом. Другая задача затем может извлечь эти данные, используя этот ключ, позволяя передавать данные между задачами, даже если они выполняются на разных рабочих узлах или в разное время. Эта функция особенно полезна для задач, зависящих от результатов или вывода предыдущих задач.

Использование XComs способствует отделению задач внутри рабочего процесса, повышая модульность и повторное использование компонентов DAG. Однако рекомендуется использовать XComs умеренно, так как они предназначены для небольших объёмов данных. Передача больших объёмов данных лучше осуществляется через внешние системы или сервисы хранения данных, в то время как Airflow отвечает за оркестрацию задач, а не за перемещение значительных объёмов данных.

Определение задачи загрузки (load task)

На финальном, третьем этапе мы выполним загрузку преобразованных данных. В этом примере мы просто выводим общую сумму заказов через функцию print, чтобы убедиться в её успешности в логах:

@task()
def load(order_data_dict: float):
    print(f"Total order value is: {total_order_value:.2f}")

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

Установка порядка выполнения задач и зависимостей

Наконец, нам нужно задать порядок задач. В этом примере мы объявляем их по порядку с помощью переменных. В других примерах, которые мы рассмотрим, можно увидеть использование символа >>, который указывает, что задача слева предшествует задаче справа. Пример такого использования:

extract >> transform >> load

Однако это не тот способ, который используется в данном примере DAG, и мы рекомендуем следовать следующей структуре:

order_data = extract()
    order_summary = transform(order_data)
    load(order_summary["total_order_value"])

example_dag_basic()

Как видно из приведённого фрагмента кода, мы делаем функцию extract() вызываемой через order_data, который затем передаётся через transform(). Затем результат transform передаётся через load() с помощью переменной order_summary. Задание такого порядка влияет на ожидаемую последовательность выполнения задач.

Последним, но самым важным шагом является вызов функции example_dag_basic() в конце кода. Если этот шаг не будет выполнен, то DAG никогда не будет работать.

Выполнение примера DAG

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

1. Перейдите по адресу: http://localhost:8080
2. Войдите под пользователем admin с соответствующим паролем.
3. Убедитесь, что пример DAG отображается в интерфейсе.
4. В разделе «Actions» справа нажмите зелёную кнопку воспроизведения, чтобы запустить DAG.

Другой способ — нажать на переключатель слева от имени DAG, чтобы включить DAG и начать его выполнение по заданному расписанию.

Выполнение задач DAG может занять до 30 минут. После завершения выполните следующие шаги, чтобы подтвердить выполнение:

1. Нажмите на имя DAG example_dag_basic, чтобы перейти к обзору DAG.
2. Выберите вкладку Graph.
3. Выберите задачу load, нажав на соответствующий блок задачи.
4. В верхнем меню выберите Logs.
5. Убедитесь, что итоговая сумма заказов равна 1236.70.

Группы задач (Task groups)

Для управления сложностью и повышения читаемости DAG в Airflow 2 были введены группы задач (task groups). Группы задач позволяют организовывать задачи в иерархически сгруппированные подмножества внутри DAG. Такая организация полезна не только для визуального упрощения в интерфейсе Airflow, но и для логического разделения, делая крупные рабочие процессы более управляемыми и понятными.

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

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

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

@task_group(group_id='extraction_task_group')
def tg1():
    t1 = extract()
    t2 = EmptyOperator(task_id='task_2')
    t1 >> t2

В этом примере мы определили группу задач как extraction_task_group и создали две отдельные задачи. Задача t1 использует исходную функцию extract(), а задача t2 использует EmptyOperator, который ничего не делает. Мы указываем, что задача t1 должна выполняться до t2.

Мы можем изменить порядок выполнения задач, чтобы отразить новую группу задач как начальную точку. Следующая диаграмма отображает новый визуализированный порядок задач:

Рисунок 2.9: Обновлённый порядок задач

Чтобы развернуть группу задач, просто выберите + 2 tasks на группе задач и разверните секцию для просмотра задач внутри:

Рисунок 2.10: Развёрнутый вид новой задачи

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

Триггеры

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

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

Например, предположим, что в базовом примере DAG мы решаем, что начальная задача преобразования должна выполняться через 30 минут после успешного завершения первой группы задач извлечения. Вы можете использовать TimeDeltaTrigger для этого, установив задержку выполнения задачи агрегации на 30 минут.

Это достигается путём добавления триггера в определение задачи в следующей форме:

trigger=TimeDeltaTrigger(timedelta(minutes=30)),

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

Триггеры на основе времени включают как выражения CRON, так и планирование на основе интервалов. Выражения cron — одни из самых распространённых триггеров, позволяющие запускать задачи через регулярные промежутки времени, заданные синтаксисом cron

(например, 0 0 * * * — для задачи, выполняемой ежедневно в полночь).

Планирование на основе интервалов — это когда задачи могут выполняться через фиксированные промежутки времени (например, каждый час или каждый день) с использованием предопределённого интервала.

Триггеры на основе зависимостей включают завершение предыдущих задач, внешний датчик задач и множество других опций. Завершение предыдущих задач (upstream task completion) — это когда задача может быть запущена после успешного выполнения одной или нескольких указанных предыдущих задач. Это критически важно для рабочих процессов, где задачи напрямую зависят от результата или успешности других задач. Датчик внешних задач (external task sensor) ожидает завершения определённой задачи в другом DAG перед продолжением. Это полезно для координации задач между различными рабочими процессами.

Последними из наиболее распространённых являются триггеры на основе событий, к которым относятся Webhooks и датчики, связанные с электронной почтой или другими сервисами уведомлений. Задачи-триггеры Webhook могут запускаться внешними событиями через Webhook. Это полезно для рабочих процессов, которые должны запускаться на основе действий или сигналов из внешних систем. Датчик электронной почты запускает задачу при получении электронной почты, удовлетворяющей определённым критериям, что полезно для рабочих процессов, начинающихся в ответ на уведомления по электронной почте.

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

Резюме 2 главы

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

Каждая из этих тем имеет критическое значение для понимания и освоения перед тем, как пытаться создавать крупные ETL-пайплайны или другие случаи использования ML/AI с Airflow. Рекомендуется уделить время изучению базового примера DAG и попрактиковаться с различными триггерами или операторами, рассмотренными в этой главе, чтобы вы чувствовали себя уверенно при построении систем более крупного масштаба по мере вашего развития как инженера.

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

Сообщение Apache Airflow Best Practices — Глава 2 «Core Concepts» появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

Глава 1 — Начало работы с Airflow 2.0

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

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

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

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

• Что такое оркестрация данных?
• Обзор Apache Airflow
• Базовые концепции Airflow
• Навыки для эффективного использования Apache Airflow

Что такое оркестрация данных?

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

Оркестрация в контексте разработки программного обеспечения и data engineering — это процесс автоматизации и управления выполнением взаимосвязанных задач или процессов для достижения конкретной цели. Эти задачи могут включать обработку данных, планирование выполнения рабочих процессов, развёртывание сервисов и многое другое. Цель оркестрации — оптимизировать поток операций, повысить эффективность использования ресурсов и гарантировать согласованное выполнение задач.

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

Примеры использования в индустрии

Независимо от отрасли, Apache Airflow может приносить пользу любым командам, занимающимся data engineering или аналитикой. Для лучшего понимания приведём несколько примеров того, как ключевые отрасли, с которыми мы работали, могут использовать этот ведущий оркестратор данных для удовлетворения своих потребностей:

• E-commerce: Бренд в сфере электронной коммерции может нуждаться в автоматизированном ETL/ELT пайплайне для автоматизации извлечения, трансформации и загрузки данных из различных источников, таких как продажи, взаимодействие с клиентами и текущие остатки на складе.
• Банковский сектор / финтех: Ведущие финансовые компании могут использовать Apache Airflow для оркестрации обработки транзакционных данных с целью выявления мошеннических операций или рисков в отчётных и биллинговых системах.
• Ритейл: Крупные розничные сети и бренды могут использовать Apache Airflow для автоматизации ML-нагрузок с целью более точного прогнозирования пользовательских предпочтений и покупательского поведения с учётом сезонности или текущей рыночной конъюнктуры.

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

Обзор Apache Airflow

Apache Airflow известен в сообществе инженеров по данным как наиболее популярная open source платформа для разработки, планирования и мониторинга batch-ориентированных рабочих процессов.
(Документация Apache.org Airflow: https://airflow.apache.org/docs/apache-airflow/stable/index.html)

Apache Airflow зарекомендовал себя как основная open source платформа для оркестрации данных и остаётся лидером благодаря активному сообществу разработчиков. Она предлагает надёжное и гибкое решение задач управления сложными рабочими процессами обработки данных. Airflow позволяет инженерам по данным, data scientist’ам, инженерам в области искусственного интеллекта (AI)/машинного обучения (ML), а также специалистам по MLOps и DevOps легко разрабатывать, планировать и мониторить пайплайны данных. Сила Apache Airflow заключается в его способности представлять рабочие процессы данных в виде ориентированных ациклических графов (DAG’ов). Такой интуитивный подход позволяет пользователям визуализировать и понимать взаимосвязи между задачами, что упрощает создание и сопровождение сложных пайплайнов данных. Более того, расширяемость и модульность Airflow позволяют пользователям настраивать платформу под свои специфические нужды, делая её идеальным выбором для компаний любого размера и из любой отрасли.

Apache Airflow 2.0

Релиз Apache Airflow 2 в декабре 2020 года стал одним из крупнейших достижений сообщества с момента создания Airflow как внутреннего решения в Airbnb в 2014 году. Переход на версию 2.0 стал серьёзным шагом для сообщества и включал сотни обновлений и исправлений ошибок после опроса сообщества Airflow в 2019 году. Этот релиз принёс с собой обновлённый пользовательский интерфейс, новый планировщик, исполнитель на базе Kubernetes и более простой способ группировки задач внутри DAG’ов. Это было прорывное достижение, которое определило дорожную карту для последующих релизов, только усиливших ценность Airflow как инструмента для сообщества.

Ключевые особенности Apache Airflow

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

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

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

Взгляд вперёд

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

• Почему использовать Airflow?: Принципы, навыки и базовые концепции
• Основы Airflow: Понимание основных понятий (DAG’и, задачи, операторы, deferrable-компоненты, подключения и т. д.), компонентов Airflow и основы написания DAG’ов
• Типовые сценарии использования: Раскрытие потенциала Airflow с помощью ETL-пайплайнов, пользовательских плагинов и оркестрации нагрузок между системами
• Масштабирование с командой: Подготовка инстанса Airflow к продакшн-нагрузкам с использованием CI/CD, мониторинга и облака

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

Давайте начнём это практическое руководство по оркестрации пайплайнов данных с использованием Apache Airflow и раскроем истинный потенциал принятия решений на основе данных.

Основные концепции Airflow

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

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

Следование этим рекомендациям поможет вам заложить основу для масштабирования ваших развёртываний Airflow и повысить эффективность рабочих процессов как с точки зрения разработки, так и эксплуатации.

Почему Airflow может вам не подойти

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

Некоторые из этих антипаттернов включают следующее:

• Команды, в которых отсутствует или ограничен опыт программирования на Python. Реализация DAG’ов на Python может быть сложным процессом и требует активного опыта для поддержки кода.
• Стриминговые или не batch-ориентированные рабочие процессы и пайплайны, где сценарий использования требует немедленного обновления. Airflow предназначен для batch-ориентированных и запланированных задач.

Когда выбирать Airflow

Airflow лучше всего использовать для реализации «batch-ориентированных» запланированных пайплайнов данных. Часто сценарии использования включают ETL/ELT, обратный ETL, ML, AI и бизнес-аналитику (BI). На протяжении всей книги мы рассмотрим основные сценарии использования, наблюдаемые в различных лидирующих компаниях отрасли. Некоторые ключевые сценарии включают следующее:

• ETL-пайплайны данных: Почти каждая реализация Airflow помогает автоматизировать задачи такого типа, будь то консолидация данных в хранилище данных или перемещение данных между различными инструментами
• Разработка и распространение пользовательских плагинов для организаций с уникальным стеком и потребностями, которые не были учтены open source сообществом: Airflow позволяет легко адаптировать окружение и экосистему под ваши нужды
• Расширение функциональности UI с помощью плагинов: Модификация и настройка интерфейса для добавления новых представлений, графиков и виджетов, интегрирующихся с внешними системами
• ML-воркфлоу и оркестрация между системами: Команды, создающие и поддерживающие ML-воркфлоу, часто зависят от Airflow для автоматизации обучения, трансформации и оценки моделей

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

Zen of Python

Zen of Python — отличный ориентир для любого Python-разработчика при принятии решений при написании кода; некоторые его части особенно полезны для инженеров по данным, работающих с Airflow. Это набор из 19 «руководящих принципов» написания кода на Python от пионера в области разработки программного обеспечения Тима Питерса. Прежде чем перейти к деталям того, что, на наш взгляд, наиболее ценно при разработке на Apache Airflow, давайте ознакомимся с Zen of Python:

1. Красивое лучше, чем уродливое.
2. Явное лучше, чем неявное.
3. Простое лучше, чем сложное.
4. Сложное лучше, чем запутанное.
5. Плоское лучше, чем вложенное.
6. Разреженное лучше, чем плотное.
7. Читаемость имеет значение.
8. Частные случаи недостаточно особенные, чтобы нарушать правила.
9. Хотя практичность важнее чистоты.
10. Ошибки никогда не должны замалчиваться.
11. Если только они не замалчиваются явно.
12. В условиях неоднозначности откажитесь от соблазна угадывать.
13. Должен быть один — и желательно только один — очевидный способ сделать это.
14. Хотя он может быть не очевиден с первого взгляда, если только вы не голландец.
15. Сейчас лучше, чем никогда.
16. Хотя «никогда» часто лучше, чем прямо сейчас.
17. Если реализацию сложно объяснить — это плохая идея.
18. Если реализацию легко объяснить — возможно, это хорошая идея.
19. Пространства имён — отличная штука, давайте использовать их больше!

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

• Явное лучше, чем неявное. Особенно в задачах, связанных с данными, важно быть явным в своих намерениях — это критично как для защиты от ошибок, так и для поддержки. Отлаживать продакшн-пайплайн проще, когда вы точно знаете, каков был изначальный замысел.
• Простое лучше, чем сложное. Сложное лучше, чем запутанное. Лучшие практики проектирования DAG’ов предполагают наличие множества простых задач, которые затем объединяются в сложный рабочий процесс. Это, как правило, означает, что рабочие процессы лучше справляются с восстановлением после ошибок и повторными запусками, их проще расширять в будущем и легче отлаживать при сбоях.
• Частные случаи недостаточно особенные, чтобы нарушать правила. Хотя практичность важнее чистоты. Согласованность — ключ к сопровождаемому коду, поэтому по возможности нужно стремиться к единообразному подходу. Однако инженерным командам нужно добиваться результата, так что вы должны быть готовы учитывать особые случаи как при проектировании, так и при реализации.
• Ошибки никогда не должны замалчиваться. Если только они не замалчиваются явно. Это частный случай противопоставления явного и неявного. Особенно в работе с данными ошибки должны обрабатываться явно — либо через исключения, либо логироваться для последующего анализа.
• Сейчас лучше, чем никогда. Хотя “никогда” часто лучше, чем прямо сейчас. При построении DAG’ов и всей операционной архитектуры возникает естественное стремление сразу «подготовить систему к будущему» или избыточно абстрагировать — не делайте этого. Следует проявлять особую осторожность при реализации интерфейсов и систем: в конечном итоге вы будете отвечать за их поддержку, и усилия, вложенные сейчас, могут оказаться нужнее в другом месте.
• Если реализацию сложно объяснить — это плохая идея. Если реализацию легко объяснить — возможно, это хорошая идея. Это ещё один случай темы простого/сложного/запутанного, особенно актуальный на этапе проектирования. Если вы не можете объяснить что-то достаточно просто — вероятно, это плохая идея для реализации. Данные постоянно меняются и эволюционируют, и ваши системы должны уметь меняться вместе с ними.

Идемпотентность

Идемпотентность описывает операцию, которую можно применять многократно без изменения результата после первого применения. Наш опыт показывает, что большинство эксплуатационных проблем можно избежать, если учитывать этот принцип с самого начала и на всех этапах проектирования задач в Airflow.

Конфигурация как код

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

Эта парадигма очень мощная и действительно позволяет обращаться с конфигурациями как с полноценным кодом; однако разработчики должны помнить, что код предназначен для описания дискретных конфигурационных единиц, и некоторые «очевидные» паттерны программирования могут привести к нежелательным (или недокументированным) зависимостям, если не обеспечить чётких границ конфигурации в кодовых базах, описывающих ваши рабочие процессы.

Теперь, когда мы на мгновение нашли свой дзен в написании кода на Python и поделились ключевыми соображениями о том, когда стоит выбирать Apache Airflow, давайте перейдём к навыкам, которые наиболее необходимы.

Навыки для эффективного использования Apache Airflow

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

• Python: DAG’и и плагины пишутся на Python. Следовательно, для эффективного внедрения Airflow вы должны уметь писать и понимать код на Python.
• Тестирование приложений: В вашей компании должны быть достаточно зрелые процессы и практики тестирования, чтобы гарантировать, что написанные вами плагины и DAG’и будут работать так, как задумано. Команда, ответственная за работоспособность вашего инстанса(ов) Airflow и плагинов, должна уметь помогать другим командам в подготовке к обновлениям, а команды, пишущие рабочие процессы, — выполнять автоматизированные тесты до вывода в продакшн.
• Экспертиза в предметной области: Знание своей предметной области данных — самый критически важный навык для успешного внедрения Airflow. Независимо от того, насколько вы технически подкованы, если вы не понимаете бизнес-домена, с которым работаете, вам не удастся добиться успеха ни в краткосрочной, ни в долгосрочной перспективе.
• Мониторинг/оповещение приложений: У вас должны быть достаточно зрелые возможности для наблюдения, мониторинга и оповещения, чтобы эффективно использовать Airflow. Некоторые распространённые действия включают мониторинг активности приложения (например, health checks), отправку оповещений дежурным членам команды и автоматические сообщения о статусе.

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

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

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

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

В следующей главе мы представим основы DAG’ов и задач. Мы рассмотрим новые советы по декораторам задач и организации групп задач, а также разберём пример. Вы можете рассчитывать на то, что ваш первый DAG в Airflow будет запущен и готов к эксплуатации.

Сообщение Apache Airflow Best Practices — Глава 1 «Начало работы с Airflow 2.0» появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.