apache airflow что это
Airflow — инструмент, чтобы удобно и быстро разрабатывать и поддерживать batch-процессы обработки данных
Привет, Хабр! В этой статье я хочу рассказать об одном замечательном инструменте для разработки batch-процессов обработки данных, например, в инфраструктуре корпоративного DWH или вашего DataLake. Речь пойдет об Apache Airflow (далее Airflow). Он несправедливо обделен вниманием на Хабре, и в основной части я попытаюсь убедить вас в том, что как минимум на Airflow стоит смотреть при выборе планировщика для ваших ETL/ELT-процессов.
Ранее я писал серию статей на тему DWH, когда работал в Тинькофф Банке. Теперь я стал частью команды Mail.Ru Group и занимаюсь развитием платформы для анализа данных на игровом направлении. Собственно, по мере появления новостей и интересных решений мы с командой будем рассказывать тут о нашей платформе для аналитики данных.
Пролог
Итак, начнем. Что такое Airflow? Это библиотека (ну или набор библиотек) для разработки, планирования и мониторинга рабочих процессов. Основная особенность Airflow: для описания (разработки) процессов используется код на языке Python. Отсюда вытекает масса преимуществ для организации вашего проекта и разработки: по сути, ваш (например) ETL-проект — это просто Python-проект, и вы можете его организовывать как вам удобно, учитывая особенности инфраструктуры, размер команды и другие требования. Инструментально всё просто. Используйте, например, PyCharm + Git. Это прекрасно и очень удобно!
Теперь рассмотрим основные сущности Airflow. Поняв их суть и назначение, вы оптимально организуете архитектуру процессов. Пожалуй, основная сущность — это Directed Acyclic Graph (далее DAG).
DAG — это некоторое смысловое объединение ваших задач, которые вы хотите выполнить в строго определенной последовательности по определенному расписанию. Airflow представляет удобный web-интерфейс для работы с DAG’ами и другими сущностями:
DAG может выглядеть таким образом:
Разработчик, проектируя DAG, закладывает набор операторов, на которых будут построены задачи внутри DAG’а. Тут мы приходим еще к одной важной сущности: Airflow Operator.
Операторы
Оператор — это сущность, на основании которой создаются экземпляры заданий, где описывается, что будет происходить во время исполнения экземпляра задания. Релизы Airflow с GitHub уже содержат набор операторов, готовых к использованию. Примеры:
Есть более специфические операторы: DockerOperator, HiveOperator, S3FileTransferOperator, PrestoToMysqlOperator, SlackOperator.
Вы также можете разрабатывать операторы, ориентируясь на свои особенности, и использовать их в проекте. Например, мы создали MongoDBToHiveViaHdfsTransfer, оператор экспорта документов из MongoDB в Hive, и несколько операторов для работы с ClickHouse: CHLoadFromHiveOperator и CHTableLoaderOperator. По сути, как только в проекте возникает часто используемый код, построенный на базовых операторах, можно задуматься о том, чтобы собрать его в новый оператор. Это упростит дальнейшую разработку, и вы пополните свою библиотеку операторов в проекте.
Далее все эти экземпляры задачек нужно выполнять, и теперь речь пойдет о планировщике.
Планировщик
Планировщик задач в Airflow построен на Celery. Celery — это Python-библиотека, позволяющая организовать очередь плюс асинхронное и распределенное исполнение задач. Со стороны Airflow все задачи делятся на пулы. Пулы создаются вручную. Как правило, их цель — ограничить нагрузку на работу с источником или типизировать задачи внутри DWH. Пулами можно управлять через web-интерфейс:
Каждый пул имеет ограничение по количеству слотов. При создании DAG’а ему задается пул:
Пул, заданный на уровне DAG’а, можно переопределить на уровне задачи.
За планировку всех задач в Airflow отвечает отдельный процесс — Scheduler. Собственно, Scheduler занимается всей механикой постановки задачек на исполнение. Задача, прежде чем попасть на исполнение, проходит несколько этапов:
Scheduler работает на множестве всех DAG’ов и всех задач внутри DAG’ов.
Чтобы Scheduler начал работу с DAG’ом, DAG’у нужно задать расписание:
Также можно использовать cron-выражения:
Execution Date
Чтобы разобраться в том, как работает Airflow, важно понимать, что такое Execution Date для DAG’а. В Airflow DAG имеет измерение Execution Date, т. е. в зависимости от расписания работы DAG’а создаются экземпляры задачек на каждую Execution Date. И за каждую Execution Date задачи можно выполнить повторно — или, например, DAG может работать одновременно в нескольких Execution Date. Это наглядно отображено здесь:
К сожалению (а может быть, и к счастью: зависит от ситуации), если правится реализация задачки в DAG’е, то выполнение в предыдущих Execution Date пойдет уже с учетом корректировок. Это хорошо, если нужно пересчитать данные в прошлых периодах новым алгоритмом, но плохо, потому что теряется воспроизводимость результата (конечно, никто не мешает вернуть из Git’а нужную версию исходника и разово посчитать то, что нужно, так, как нужно).
Генерация задач
Реализация DAG’а — код на Python, поэтому у нас есть очень удобный способ сократить объем кода при работе, например, с шардированными источниками. Пускай у вас в качестве источника три шарда MySQL, вам нужно слазить в каждый и забрать какие-то данные. Причем независимо и параллельно. Код на Python в DAG’е может выглядеть так:
DAG получается таким:
При этом можно добавить или убрать шард, просто скорректировав настройку и обновив DAG. Удобно!
Можно использовать и более сложную генерацию кода, например работать с источниками в виде БД или описывать табличную структуру, алгоритм работы с таблицей и с учетом особенностей инфраструктуры DWH генерировать процесс загрузки N таблиц к вам в хранилище. Или же, например, работу с API, которое не поддерживает работу с параметром в виде списка, вы можете сгенерировать по этому списку N задач в DAG’е, ограничить параллельность запросов в API пулом и выгрести из API необходимые данные. Гибко!
Репозиторий
В Airflow есть свой бекенд-репозиторий, БД (может быть MySQL или Postgres, у нас Postgres), в которой хранятся состояния задач, DAG’ов, настройки соединений, глобальные переменные и т. д., и т. п. Здесь хотелось бы сказать, что репозиторий в Airflow очень простой (около 20 таблиц) и удобный, если вы хотите построить какой-либо свой процесс над ним. Вспоминается 100500 таблиц в репозитории Informatica, которые нужно было долго вкуривать, прежде чем понять, как построить запрос.
Мониторинг
Учитывая простоту репозитория, вы можете сами построить удобный для вас процесс мониторинга задачек. Мы используем блокнот в Zeppelin, где смотрим состояние задач:
Это может быть и web-интерфейс самого Airflow:
Код Airflow открыт, поэтому мы у себя добавили алертинг в Telegram. Каждый работающий инстанс задачи, если происходит ошибка, спамит в группу в Telegram, где состоит вся команда разработки и поддержки.
Получаем через Telegram оперативное реагирование (если такое требуется), через Zeppelin — общую картину по задачам в Airflow.
Итого
Airflow в первую очередь open source, и не нужно ждать от него чудес. Будьте готовы потратить время и силы на то, чтобы выстроить работающее решение. Цель из разряда достижимых, поверьте, оно того стоит. Скорость разработки, гибкость, простота добавления новых процессов — вам понравится. Конечно, нужно уделять много внимания организации проекта, стабильности работы самого Airflow: чудес не бывает.
Сейчас у нас Airflow ежедневно отрабатывает около 6,5 тысячи задач. По характеру они достаточно разные. Есть задачи загрузки данных в основное DWH из множества разных и очень специфических источников, есть задачи расчета витрин внутри основного DWH, есть задачи публикации данных в быстрое DWH, есть много-много разных задач — и Airflow все их пережевывает день за днем. Если же говорить цифрами, то это 2,3 тысячи ELT задач различной сложности внутри DWH (Hadoop), около 2,5 сотен баз данных источников, это команда из 4-ёх ETL разработчиков, которые делятся на ETL процессинг данных в DWH и на ELT процессинг данных внутри DWH и конечно ещё одного админа, который занимается инфраструктурой сервиса.
Планы на будущее
Количество процессов неизбежно растет, и основное, чем мы будем заниматься в части инфраструктуры Airflow, — это масштабирование. Мы хотим построить кластер Airflow, выделить пару ног для worker’ов Celery и сделать дублирующую себя голову с процессами планировки заданий и репозиторием.
Эпилог
Это, конечно, далеко не всё, что хотелось бы рассказать об Airflow, но основные моменты я постарался осветить. Аппетит приходит во время еды, попробуйте — и вам понравится 🙂
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
Apache Airflow
Содержание
Описание
Основные сущности [Источник 1]
К основным сущностям, используемым в Apache Airflow относятся:
Еще к модулям Apache Airflow, которые стоит рассмотреть подробно относятся: Планировщик и так называемая Execution Data.
Airflow operator [Источник 2]
Есть так же и другие, более специфические операторы: DockerOperator, JdbcOperator, OracleOperator и т. п..Так же можно создавать свои операторы на базе класса BaseOperator.
Для каждого DAG операторы инициализируются как задачи. Следующий код демонстрирует создание задач с использованием операторов:
Для того чтобы определить зависимости между задачами необходимо иx связать:
Код говорит о том что задача t2 будет зависеть от задачи t1. По сути это эквивалентно:
Планировщик
Для того чтобы планировщик начал работать с DAG’ом необходимо установить аргумент shedule_interval, как и в одном из примеров выше. Есть уже готовые свойства для задания времени. Например:
Так же это возможно сделать cron-выражением:
Execution date
Ключевая особенность Apache Airflow состоит в том что все запуски задач в DAG’ах получают свою Execution date. То есть хранятся все запуски задач DAG’ах за определенные промежутки времени. Это позволяет еще раз в точности воспроизводить результаты, полученные в той или иной Execution date. Так же получается что различные задачи в DAG’ах могут работать одновременно в разных Execution date. При корректировке кода задачи, запуски задач в предыдущих Execution date будут уже с учетом этих корректировок. При этом, очевидно, теряется воспроизводимость результатов, но появляется возможность протестировать новый алгоритм на старых данных.
Хранилище
В Airflow есть свой бекенд-репозиторий. Поскольку Airflow был построен для взаимодействия с его метаданными с помощью большой библиотеки SqlAlchemy, должна быть возможность использовать любую базу данных, поддерживаемую в качестве серверной части SqlAlchemy. Рекомендуется использовать MySQL или Postgres. В базе хранятся состояния задач, DAG’ов, глобальные переменные и т. д..
Установка
Установка проводится на чистую ОС Ubuntu 18.04
Предварительная настройка
Для установки на чистую ОС потребуется: Python,
не помешает так же установить
Установка Apache Airflow
Указываем домашнюю директорию для airflow
При помощи pip скачиваем и устанавливаем airflow
Для большей наглядности процедуры установки и решения возникающих проблем с недостающими пакетами можно посмотреть видео с установкой Apache Airflow:
Решение возможных проблем установки и запуска Apache Airflow
Для устранения ошибки command ‘x86_64-linux-gnu-gcc’ failed with exit status 1 может помочь установка следующих пакетов [Источник 3]
или другой вариант [Источник 4]
Если проблема связана с fernet то может помочь установка пакета cryptography
Конфигурирование
Подготовка среды к работе с mysql
Для работы с базами данных в Apache Airflow необходимо устанавливать дополнительно пакеты для каждой базы отдельно (ставим mysql для работы с mediawiki)
или для всех сразу.
Для того чтобы эта установка прошла корректно необходимо установить еще два пакета.
Так же для работы с шифрованием потребуется сгенерировать и вставить в конфигурационный файл специальный ключ fernet_key: для этого открываем python в консоли
и в открывшемся терминале построчно вводим
в результате в консоль выведет сгенерированный ключ, его необходимо скопировать. Далее выходим из python’а
и открываем конфигурационный файл airflow
находим переменную fernet_key и заменяем ее значение из буфера нашим ключом.
Инициализация airflow
Для инициализации самой airflow достаточно нескольких команд. Для начала инициализируем базу данных для бек-енда самой airflow, где она хранит все записи.
Теперь запустим airflow webserver
Так же не помешает сразу запустить scheduler
Для большей наглядности представлено видео-руководство.
Демонстрационный пример работы с бд mysql
Тест соединения с БД mysql
Для тестирования соединения в Apache Airflow есть специальный сервис Ad Hoc Query. Ему можно скармливать запросы к базе данных и получать результаты.
Демонстрация работы DAG
В видео с демонстрацией представлен запуск DAG, просмотр результатов и логов после того как он отработает.
Вывод
Из минусов стоит отметить:
Apache Airflow и будущее инжиниринга данных: вопрос и ответы
Введение
Иногда мне попадаются статьи о будущем технологий, в которых это будущее выглядит ясно и непротиворечиво.
После прочтения статьи я связался с Максом и попросил его об интервью, и к моей огромной радости, он согласился и дал полные ответы на вопросы про Apache Airflow и будущее дата инжиниринга. Его ответы ниже, но сначала я хотел бы добавить немного контекста.
Вы может быть удивлены: “почему дата инжиниринг и почему это важно?”
“Дата инжиниринг можно рассматривать как объединение BI и систем хранения данных, которое взяло многое из разработки ПО”
Без предисловий, давайте перейдем к ответам Макса на вопросы.
Отличные ребята из Astronomer.io связались со мной чтобы сделать короткое интервью об Apache Airflow и дата инжиниринге. Ниже несколько вопросов и мои ответы.
Вопрос 1: Когда выйдет следующий релиз Apache Airflow и какую из основных фичей ты считаешь главной?
8orc4 (релиз кандидат №4) только что был одобрен комьюнити Apache, но был задержан, после того как разработчики из Airbnb нашли несколько блокеров. Прямо сейчас почти все исправлено и релиз уже близко. Мы ожидаем, что релиз 1.8.0 выйдет на этой или на следующей неделе. Это первый релиз, который “драйвил” только Airbnb. Bolke de Bruin из ING (Нидерланды) проделал впечатляющую работу, чтобы релиз вышел. Это гигантский объем работы, который все время увеличивался, так как время с последнего релиза выросло. Это первый релиз с версии 1.7.1.3, которая вышла 13 июня 2016.
Изменения по сравнению с 1.7.1.3 огромны. Ниже мой список хайлайтов:
многопоточный планировщик, что позволяет гораздо быстрее планировать задачи и повышает отказоустойчивость при импорте DAG файлов. До этого sys.exit() в DAG файле выключал планировщик
заменена библиотека для построения графиков с Highcharts на NVD3. У Highcharts была лицензия не совместимая с правилами Apache и замена библиотеки вывела нас из “серой” юридической зоны
улучшение интеграции с Google Cloud Services: с улучшением операторов и хуков
улучшенную модульную зависимость, обеспечивающую более легкий в обслуживании и расширяемый код, позволяющая использовать новую фичу в интерфейсе “почему моя задача не выполняется”
исправили все задачи, связанные с “зомби” и “неубиваемыми” процессами
улучшенная обработка пула задач там, где в предыдущих версиях была “избыточная” подписка на задачи из пула
новый набор операторов и хуков
исправлена куча багов и улучшений UI по всем направлениям
Надеемся получить более стабильный релиз согласно этому списку, хотя пока нет официального обязательства сделать это.
Вопрос 2: Как прошел переход с внутреннего инструмента Airbnb на проект Apache?
Все прошло гладко. Apache расширил вклад сообщества позволив внешним контрибьютерам смерджить пуллреквесты, что ускорило скорость изменения проекта. С другой стороны, это замедлило выпуск релиза, заставляя нас справляться с нашей собственной релизной веткой, состоящей из предыдущего официального релиза плюс список “вишенок” (список коммитов, которые мы делаем поверх релиза). Мы также склоняемся к тому, чтобы развивать свою внутреннюю ветку и пушить пуллреквест в коммьюнити, после того как стабилизируем его у себя на продакшене.
Мы очень оценили помощь, которую получили в разработке последнего релиза, и наблюдали как проект развивается самостоятельно при минимальном участии с нашей стороны. Раньше я сам ревьюил и мерджил каждый пуллреквест и за последние несколько лет это вышло из-под контроля. Приятно видеть выход из этого “порочного круга” с течением времени.
Вопрос 3: Каким ты видишь продолжение развития Airflow? Какие новые применения Airflow появятся в течение следующих 5 лет?
Экосистеме инфраструктуры данных еще предстоит продемонстрировать какие-либо признаки превращения в нечто более управляемое. Кажется, мы все еще находимся в стадии расширения, когда каждый день приносит новую распределенную базу данных, новые фреймворки, новые библиотеки и новых коллег. По мере того, как эти системы становятся все более сложными и быстро развиваются становится еще более важным иметь что-то вроде Airflow, который объединяет все вместе в определенном месте, где каждый маленький кусочек пазла может быть правильно оркестрован с помощью “разумного” API.
Можно предположить, что интеграция с другими системами будет зоной роста Airflow, по мере того как в нем появятся все фичи из мира оркестровки.
Там, где изначально предполагалось, что Airflow будет использоваться главным образом как оркестратор, а не брать на себя реальную нагрузку, оказалось что многие используют Airflow для более сложных задач таких как: запуск скриптов на R, задачи обработки данных на Python, обучение ML моделей, ранжирование… В то время как мы внутренне поощряем людей писать сервисы и использовать инфраструктуру, такую как Kubernetes или Yarn для такого рода задач, похоже, что Airflow нужно расти и в этом направлении тоже, с поддержкой контейнеризации (пожалуйста, запустите эту задачу в этом контейнере Docker!), и управлениями ресурсами (выделите 4 CPU и 64 ГБ оперативной памяти для этой задачи, пожалуйста). Мы знаем об ограничениях, которые могут возникнуть у людей в их средах, и хотим позволить им получить максимальную отдачу от Airflow. Так что если у вас завалялся кластер Kubernetes, мы должны максимально использовать его, но если вы этого не хотите, хотелось бы, чтобы вы смогли запустить эти в Airflow.
Я верю, что Airflow подходит для того, чтобы стать батч процессинг оркестратором, который будет доминировать в ближайшие 5 лет. У нас есть прочная технологическая основа и большое, динамично развивающееся сообщество!
Вопрос 4: Как ты оцениваешь подобные технологии, такие как Luigi, Azkaban и тд?
Сам я не использовал Luigi, Azkaban или Oozie, так что я просто повторю слова тех, кто перешел из этих сообществ и присоединились к Airflow.
Oozie — это то ПО, о котором я слышал больше всего негативных отзывов. Попробуйте найти хоть одного пользователя Oozie (но только не из разработчиков самого Oozie), который бы положительно отзывался о нем. Просто попробуйте! Возможно, это именно тот случай, когда проект закрыл основные проблемы, но люди продолжают жаловаться, я думаю что проект уже скомпрометирован и это не исправить.
Я твердо верю в конфигурацию как код, как способ создания рабочих процессов, и я вижу, что актуальность Airflow в современной экосистеме данных неуклонно растет. Определенно кажется, что каждый стартап, серьезно относящийся к данным и аналитике в районе Bay Area, на данный момент использует Airflow.
Современные стартапы больше не относятся к аналитике и данным как к чему-то второстепенному. Как правило они нанимают первого data scientist`а на ранней стадии и первая волна разработчиков будет использовать необходимые аналитические инструменты в ранних версиях продукта. Венчурные инвесторы требуют отчетности и могут предоставить услуги “grow hacker” на ранней стадии, чтобы дать рекомендации стартапу и измерить их потенциальную отдачу от инвестиций и посмотреть, где можно удвоить.
Я думаю, что будущие стартапы будут катапультированы вверх по кривой зрелости данных с доступом к лучшему, более дешевому и доступному аналитическому ПО и услугам. Большая часть работы уже реализуется с помощью опенсорса, но также растет число интегрированных решений поставщиков, таких как MixPanel, Interana, Optimizely, и растет предложение облачных провайдеров, таких как AWS, GCS и Microsoft.
Вещи, которые раньше были передовыми, такие как OLAP в реальном времени, обнаружение аномалий, A/B-тестирование и сегментация пользователей, когортный анализ, теперь доступны любому стартапу с любым количеством сотрудников и должным финансированием.
В то время как эти предложения становятся все более доступными, они становятся необходимостью для поддержания конкурентоспособности и предоставляют возможности гибким стартапам перепрыгивать через медленных игроков в этой области.
Заключение
В 2011 году Marc Andreessen написал популярную статью «Почему программное обеспечение пожирает мир». В 2017 году компьютеры, на которых работает все это программное обеспечение, производят горы данных, большая часть которых ценна, но только с помощью правильных инструментов, чтобы разобраться во всем этом.
Airflow предоставляет абстракцию на уровне рабочего процесса для конвейеров данных. Astronomer’s DataRouter использует его в качестве сервиса для передачи данных из любого источника в любое место назначения. Вы можете узнать больше о том, как Astronomer использует Airflow и наши принципы опенсорса в блоге.
Стартапы больше не просто создают ПО — мы создаем продукты и компании, в которых анализ данных является топливом, питающим космический корабль. По мере того, как экосистема разработки данных продолжает развиваться, ожидания относительно количества и качества информации, которую стартапы черпают из своих различных источников данных, также будут продолжать расти.
** Особая благодарность Максу за то, что он нашел время поговорить с нами и поделиться своими мыслями. **
Введение в Apache Airflow
Если вы работаете с большими данными, вы, скорее всего, слышали об Apache Airflow. Он начался как проект с открытым исходным кодом в Airbnb в 2014 году, чтобы помочь компании справиться с конвейерами пакетных данных. С тех пор она стала одной из самых популярных платформ для управления рабочими процессами с открытым исходным кодом в инженерии данных.
Apache Airflow написан на Python, что обеспечивает гибкость и надежность. Его мощный и хорошо оборудованный пользовательский интерфейс упрощает задачи управления рабочим процессом, например отслеживание заданий и настройку платформы. Поскольку он полагается на код для определения своих рабочих процессов, пользователи могут писать, какой код они хотят выполнять на каждом этапе процесса.
Сегодня мы собираемся изучить основы этого популярного инструмента, а также основы.
Что такое Apache Airflow?
Apache Airflow — это надежный планировщик для программного создания, планирования и мониторинга рабочих процессов. Он предназначен для обработки и организации сложных конвейеров данных. Первоначально он был разработан для решения проблем, связанных с долгосрочными задачами cron и существенными скриптами, но он превратился в одну из самых мощных платформ конвейера данных на рынке.
Мы можем описать Airflow как платформу для определения, выполнения и мониторинга рабочих процессов. Мы можем определить рабочий процесс как любую последовательность шагов, которые вы предпринимаете для достижения определенной цели. Распространенной проблемой, возникающей в растущих командах по работе с большими данными, является ограниченная возможность объединить связанные задания в непрерывный рабочий процесс. До Airflow был Oozie, но у него было много ограничений, но Airflow превзошел его для сложных рабочих процессов.
Airflow также является платформой, ориентированной на код, и основана на идее, что конвейеры данных лучше всего выражаются в виде кода. Он был построен с возможностью расширения, с доступными плагинами, которые позволяют взаимодействовать со многими распространенными внешними системами, а также с платформой для создания ваших собственных платформ, если вы хотите. Он может выполнять тысячи различных задач в день, оптимизируя управление рабочим процессом.
Воздушный поток используется во многих отраслях:
Чем отличается Apache Airflow?
Ниже перечислены некоторые различия между Airflow и другими платформами управления рабочими процессами.
Зачем использовать Apache Airflow?
В этом разделе мы рассмотрим некоторые плюсы и минусы Airflow, а также некоторые известные варианты использования.
Плюсы:
Минусы:
Сценарии использования
Airflow можно использовать практически для всех конвейеров пакетных данных, и существует множество различных задокументированных случаев использования, наиболее распространенными из которых являются проекты, связанные с большими данными. Вот несколько примеров использования, перечисленных в репозитории Airflow на Github:
Основы Apache Airflow
Теперь, когда мы обсудили основы Airflow, а также преимущества и варианты использования, давайте погрузимся в основы этой надежной платформы.
Направленный ациклический граф (DAG)
Рабочие процессы определяются с помощью направленных ациклических графов (DAG), которые состоят из задач, которые должны быть выполнены, вместе с их связанными зависимостями. Каждая группа DAG представляет группу задач, которые вы хотите запустить, и они показывают отношения между задачами в пользовательском интерфейсе Apache Airflow. Давайте разберемся с аббревиатурой:
Примечание. Группа DAG определяет, как выполнять задачи, но не определяет, что именно делают.
DAG можно указать, создав экземпляр объекта airflow.models.dag.DAG, как показано в приведенном ниже примере. DAG будет отображаться в пользовательском интерфейсе веб-сервера как «Example1» и будет запущен один раз.
DAG run
Когда DAG выполняется, это называется запуском DAG. Допустим, у вас есть DAG, который будет запускаться каждый час. Каждый экземпляр этого DAG запускает DAG. Одновременно может быть несколько запусков DAG, подключенных к DAG.
Задачи
Задачи представляют собой экземпляры операторов, и они различаются по сложности. Вы можете представить их как единицы работы, представленные узлами в группе доступности базы данных. Они отображают работу, которая выполняется на каждом этапе вашего рабочего процесса, а реальная работа, которую они изображают, определяется операторами.
Операторы
В то время как группы DAG определяют рабочий процесс, операторы определяют работу. Оператор подобен шаблону или классу для выполнения определенной задачи. Все операторы происходят из BaseOperator. Есть операторы для многих общих задач, таких как:
Эти операторы используются для указания действий, выполняемых в Python, MySQL, электронной почте или bash.
Есть три основных типа операторов:
Крючки
Хуки позволяют Airflow взаимодействовать со сторонними системами. С помощью хуков вы можете подключаться к внешним базам данных и API, таким как MySQL, Hive, GCS и другим. Они похожи на строительные блоки для операторов. В хуках не содержится никакой защищенной информации. Он хранится в базе данных зашифрованных метаданных Airflow.
Примечание. У Apache Airflow есть поддерживаемые сообществом пакеты, которые включают ядро operatorsи hooksтакие сервисы, как Google и Amazon. Их можно установить непосредственно в среде Airflow.
Отношения
Воздушный поток превосходит определение сложных отношений между задачами. Допустим, мы хотим указать, что задача t1выполняется перед задачей t2. Есть четыре различных утверждения, которые мы могли бы использовать для определения этого точного отношения:
Общая картина Архитектура Apache Airflow
Эту надежную и масштабируемую платформу планирования рабочих процессов составляют четыре основных компонента:
Примеры исполнителей:
Итак, как работает Airflow?
Airflow проверяет все группы DAG в фоновом режиме за определенный период. Этот период устанавливается с помощью processor_poll_intervalконфига и равен одной секунде. После проверки файла DAG запускается DAG в соответствии с параметрами планирования. Экземпляры задач создаются для задач, которые необходимо выполнить, и их статус устанавливается SCHEDULEDв базу данных метаданных.
Расписание запрашивает базу данных, извлекает задачи в SCHEDULEDсостоянии и распределяет их по исполнителям. Затем состояние задачи изменится на QUEUED. Эти поставленные в очередь задачи извлекаются из очереди рабочими, которые их выполняют. В этом случае статус задачи меняется на RUNNING.
Когда задача завершается, работник помечает ее как неудавшуюся или завершенную, а затем планировщик обновляет окончательный статус в базе данных метаданных.
Первые шаги по работе с Apache Airflow
Теперь, когда вы знаете основы Apache Airflow, вы готовы приступить к работе! Отличный способ изучить этот инструмент — построить что-нибудь с его помощью. После загрузки Airflow вы можете создать свой собственный проект или внести свой вклад в проект с открытым исходным кодом в Интернете.
Несколько интересных проектов с открытым исходным кодом:
Еще многое предстоит узнать об Airflow. Вот некоторые рекомендуемые темы для обсуждения: