Содержание обзора:
Apache Airflow: что это?
Apache Airflow- это система с открытым исходным кодом (open sorce), назначение которой является:
- создание,
- выполнение,
- мониторинг,
- оркестровка потоков операций по обработке данных (пайплайнов).
Airflow часто определяют как ETL инструмент и это не совсем верно. По своей сути он является оркестратором.
Для простоты понимания мы также будем придерживаться мнения о его принадлежности к ETL (Extract, Transform, Load).
Основные концепции Apache Airflow
Основными концепциями, которыми оперирует Apache Airflow, являются:
- DAG (Directed Acyclic Graph) —,
Стоит подробно разобраться в определении дага (направленного ацикличного графа), поскольку каждый элемент в его определении очень важен:
— Направленный — задачи имеют последовательность исполнения;
— Ацикличный — при исполнении задач в графе недопустимы циклы, каждая задача выполняется один раз;
— Граф — как вы уже могли догадаться, задачи пайплайна представлены в виде графа, т.е. элементов (вершин), попарно соединённых связями (ребрами).
- Pipeline — конвейер данных,
- Operator — элемент, в котором содержатся операции, которые нужно выполнить. Их разделяют на 3 разных типа в зависимости от вида операции.
Типы операторов представлены в таблице ниже:
- Task Instance (экземпляр задачи) — конкретное выполнение задачи.
Экземпляр задачи содержит информацию:
— задача,
— момент времени её выполнения,
— даг, в который она входит.
Если описывать отношения перечисленных понятий, можно сказать: даг содержит описание операторов, в которых содержатся операции (задачи), которые при выполнении дага становятся экземплярами задач.
Преимущества Apache Airflow
Любой конвейер данных (или пайплайн) представляет собой последовательность шагов, каждый из которых выполняет определённый набор действий, так что пайплайн можно представить в виде графа. В принципе, если не использовать графовую структуру, пайплайн тоже будет работать и выполнять свои функции, но эта структура даёт несколько больших преимуществ:
- Графовая структура позволяет распараллелить независимые друг от друга задачи. В то же время в простом пайплайне, представленном в виде кода, все задачи будут выполняться последовательно. Так что на исполнение задач в итоге затрачивается гораздо больше времени.
- Другое преимущество графового представления в том, что оно предполагает разбиение пайплайна на более малые задачи. Это позволяет тестировать код частями и быстрее находить ошибки, чем при запуске всего скрипта пайплайна.
Использование графовой структуры для запуска зависимых задач едва ли можно назвать чем-то новым в сфере ИТ и дата-инжениринга. Поэтому было разработано множество решений для управления рабочими процессами, позволяющих определять и выполнять графики задач в виде рабочих процессов или конвейеров. Airflow — одно из таких решений.
Чем Apache Airflow не является?
Важно помнить, что Airflow не является инструментом потоковой передачи данных.
Это именно оркестратор задач, то есть, он не предоставляет средств для извлечения и загрузки данных, но помогает выполнять задачи, связанные с извлечением и загрузкой данных в нужном пользователю режиме.
Архитектура Airflow
Основные компоненты airflow, работающие при первом его запуске:
- Веб-сервер (Web server ) — реализованный на Flask (фреймворк Python) компонент, который предоставляет доступ к пользовательскому интерфейсу (UI).
- Планировщик (Scheduler ) — позволяет запускать даги в по определённому расписанию.
- База метаданных (Metastore/metabase ) — поддерживающая SQLAlchemy база с метаданными пайплайнов, задач, дагов, пользователей и всем другим, что сохраняется при работе с airflow.
- Triggerer— позволяет запускать задачи специфического типа.
Простой тип архитектуры, представленный на схеме 1, соответствует архитектуре при первом запуске и предполагает использование исполнителей Local Executor или Sequential Executor.
В представленной схеме процессы выполняют задачи вместо воркера.
А также:
- Исполнитель (Executor ) — определяет, как и с помощью чего задачи выполняются (напр., если хотите, чтобы они выполнялись с помощью Kubernetes cluster — выбирать Kubernetes executor; если с помощью Celery cluster — то Celery executor). Исполнитель, несмотря на говорящее название, не исполняет задачи, а именно указывает способ их исполнения.
- Очередь исполнения (Queue)— принимает задачи на исполнение в определённом порядке. Очередь есть всегда, независимо от выбранного вида исполнителя.
- Воркер (Worker) — выполняет задачи из очереди. Вместо воркера могут быть какие-то другие процессы или PODs, если используется Kubernetes.
Архитектура, представленная на схеме 2 – более масштабируемая.
В данной схеме очередь отдельна от планировщика. Если нужно повысить производительность Airflow (исполнять больше задач), можно добавить воркер.
Алгоритм выполнения задач планировщиком (scheduler-ом).
Алгоритм выполнения задач планировщиком представлен на схеме:
В БД метаданных (Metastore) происходит запуск дага (создаётся DagRun) со статусом “запущен” (running), в котором первая задача берётся на исполнение и становится экземпляром задачи (TaskInstance) со статусом “пусто” (none).
Статусы экземпляра задачи далее:
- “запланирована” (scheduled);
- планировщик посылает экземпляр задачи в очередь исполнителя – статус задачи “в очереди” (queued);
- исполнитель создаёт подпроцесс чтобы запустить задачу — статус “запущена” (running);
- задача исполнена — статус “успешно”/”провалено” (success/failed).
После этого планировщик проверяет, есть ли новые задачи на исполнение.
Статусы Dag в процессе исполнения: queued, running, success/failed.
Таблица с примерным описанием статусов Дага и его задач при исполнении представлена ниже.
Раздел 3. Важные представления в Airflow
Даг в Airflow может быть отображен по-разному с помощью различных представлений.
Основные представления Дага в пользовательском интерфейсе Airflow представлены в таблице:
