ТОП-3 практики оркестрации данных с Apache AirFlow: советы Astronomer

Автор Категория ,
ТОП-3 практики оркестрации данных с Apache AirFlow: советы Astronomer

Сегодня рассмотрим несколько рекомендаций по построению масштабной и устойчивой экосистемы интеграции корпоративных данных на базе Apache AirFlow от компании Astronomer, которая активно способствует продвижению и коммерциализации этого популярного инструмента дата-инженерии. Как организовать эффективную маршрутизацию рабочих процессов с пакетным ETL-оркестратором: 3 лучших практики.

Стандартизация сред разработки и промышленной эксплуатации с Kubernetes

Проще всего масштабировать production-среду AirFlow — это воспользоваться преимуществами контейнерной виртуализации и запустить ETL-оркестратор на Kubernetes, что мы рассматривали здесь. Такой шаблон развертывания на основе контейнеров обеспечивает встроенную возможность повторного использования: пользовательские задачи AirFlow будут выполняться в подах Kubernetes, а код DAG управляется централизованно через реестр Docker-образов, облегчая управление версиями и обслуживание. Это гарантирует, что пользовательские DAG работают на отказоустойчивой архитектуре, а также ведут себя одинаково при каждом запуске.

Разумеется, на практике это не самый легкий шаблон развертывания с точки зрения инфраструктуры. В дополнение к стандартным компонентам AirFlow, таким как планировщик, веб-сервер и база данных, потребуется установить, настроить и поддерживать кластер Kubernetes и, возможно, другую вспомогательную инфраструктуру для масштабирования экземпляра AirFlow. Также придется следить за любыми изменениями в этом стеке, от обновления версий до крупных исправлений для обеспечения безопасности. Альтернативой является сервис облачной инфраструктуры AirFlow, где за развертывание и обслуживание отвечает провайдер.

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

К примеру, многие Python-пакеты полагаются на различные расширения для повышения производительности. Некоторые из них могут быть написаны на C и должны быть скомпилированы для определенной архитектуры набора инструкций (x86) и двоичного интерфейса приложения (Linux). Если пользовательские DAG предполагают использовать расширения C с такими Python-библиотеками Numpy, Scikit-learn или Pandas, эти расширения должны быть доступны в их локальной среде. Но при развертывании DAG AirFlow в контейнерах, можно встроить все необходимое ПО в Docker-образы среды выполнения.

Astronomer предлагает сделать еще проще, предоставляя Astro CLI с открытым исходным кодом. Этот интерфейс командной строки стандартизирует процесс развертывания, интегрируясь с цепочкой инструментов CI/CD и предоставляя пользователям локальную среду разработки, в комплекте с веб-сервером, планировщиком AirFlow, базой данных PostgreSQL и локальным исполнителем, где можно создавать, тестировать и развертывать их Docker-образы DAG. Пользователь создает Astro Project, который генерирует папки только для своих файлов DAG, плагинов и зависимостей. Astro Project интегрируется с Git, позволяя пользователям клонировать репозитории проектов, извлекать определенные ветки кода, такие как DAG, задачи или операторы,  изменять или настраивать их. Это упрощает поиск и повторное использование надежного кода в Docker-образах, которые создаются и тестируются локально. Как только Docker-образы будут соответствовать нужным требованиям по функциональности и воспроизводимости, можно использовать подходящий инструмент CI/CD для развертывания этого кода в производственной среде AirFlow. В рамках платформы Astro, пользователи могут использовать CLI-интерфейс для развертывания AirFlow в своих средах. Astro CLI доступен по лицензии Apache 2.0. Подробнее о том, как реализовать собственный CLI-интерфейс для Apache AirFlow с помощью Python-библиотеки Fire, мы писали здесь.

Параллельная обработка DAG встроенными средствами AirFlow

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

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

А в версии 2.2 появилась поддержка отложенных операторов, что упрощает планирование и управление длительными задачами. В следующем релизе ожидается ​​поддержка динамического сопоставления задач, что даст планировщику улучшенные возможности инициирования и динамического планирования, а также для максимального использования встроенного параллелизма AirFlow. С каждым новым выпуском AirFlow упрощает разработку DAG для планирования одновременного выполнения независимых задач, упрощая создание надежных конвейеров обработки данных, поддерживающих реальные бизнес-процессы.

Сближение данных и вычислений

Apache AirFlow не случайно считается самым популярным оркестратором для ETL-процессов. Но это функциональное назначение должно быть сбалансировано с другими факторами организации пакетных конвейеров, одним из которых является стоимость. В локальном ЦОД или облачной среде перемещение больших объемов данных становится слишком дорогим. Поэтому целесообразно приблизить фактическую обработку рабочей нагрузки к месту фактического нахождения самих данных. Для этого у AirFlow есть специализированные пакеты провайдеров для Databricks, dbt, Google BigQuery, Fivetran, MySQL, PostgreSQL, Oracle, Redshift, Snowflake, SQL Server, а также хуки для AWS S3, Docker, HDFS, Hive, MySQL, PostgreSQL, Presto, Samba, Slack, SQLite и пр. Подробно об этом мы писали здесь.

Эти и подобные поставщики упрощают планирование и выполнение задач в вышестоящих вычислительных механизмах. Вообще AirFlow предоставляет десятки операторов, упрощающих перемещение или копирование данных между облачными сервисами хранения объектов типа AWS S3 и Google Cloud Storage, а также локальными механизмами. В частности, можно использовать оператор S3CopyObjectOperator для создания копии объекта, например, файла Parquet, уже сохраненного в S3, или S3toSnowflakeOperator для автоматической загрузки данных из S3 в виртуальную базу данных Snowflake. Точно так же оператор S3toRedshiftTransferOperator упрощает копирование данных из S3 в AWS Redshift. Доступность этих и других подобных инструментов упрощает дата-инженерам использование AirFlow для планирования и организации даже сложных ETL-конвейеров. Читайте в нашей следующей статье 2-ю часть советов дата-инженеров Astronomer.

Все подробности администрирования и эксплуатации Apache AirFlow для организации ETL/ELT-процессов в аналитике больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Источники

  1. https://www.astronomer.io/blog/10-best-practices-for-modern-data-orchestration-with-AirFlow
  2. https://github.com/astronomer/astro-cli