Версия сайта для слабовидящих
Сегодня рассмотрим несколько рекомендаций по построению масштабной и устойчивой экосистемы интеграции корпоративных данных на базе 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 в Москве:
Источники
