Что не так с работой Apache AirFlow в многопользовательской среде, зачем предоставлять каждой команде свое развертывание ETL-фреймворка, каковы недостатки этого решения и как организовать мультитенантный кластер.
Почему Apache Airflow не предназначен для многопользовательского использования
В современной дата-инженерии Apache AirFlow стал наиболее популярным инструментом для пакетных ETL-процессов. Чтобы использовать его наиболее эффективно в большой организации, надо решить вопрос с разделением среды Airflow между разными командами или предоставить возможность собственного развертывания для каждой команды. Второй вариант считается более оптимальным, поскольку Airflow изначально не был предназначен для совместного использования.
Несмотря на то, что Airflow поддерживает ролевую политику управления доступом (RBAC) на уровне DAG, о чем мы писали здесь, этого недостаточно для настоящей многопользовательской среды. Во-первых, пользовательские DAG напрямую обращаются к базе данных метаданных. Таким образом, авторы DAG имеют возможность написать конвейеры обработки данных, которые могут изменять привилегии пользователей Apache Airflow и взаимодействовать с базовым хранилищем. Получается, хотя RBAC на уровне DAG полезен для контроля доступа, он создает ложное чувство безопасности: любой разработчик DAG потенциально может изменить привилегии любого пользователя. Более того, RBAC контролирует только то, что может видеть пользователь, а не базовые ресурсы, такие как подключения к внешним системам (Connections) и переменные (Variables).
Смягчить эти риски может внедрение строгого CI/CD-процесса и жестких правил проектирования, о чем мы рассказываем в новой статье. Но в целом такой подход приводит к техническому долгу и более медленным циклам обновления. Это также накладывает значительную нагрузку на специалистов по обслуживанию и сопровождению AirFlow во время простоев или неожиданных сбоев платформы, поскольку у конечных дата-инженеров обычно нет доступа к средствам его отладки.
Кроме того, при совместном использовании AirFlow действия одной команды могут непреднамеренно повлиять на другую. Например, ключевые наборы данных не будут соответствовать связанным с ними SLA из-за того, что одна команда занимает слишком много рабочих ресурсов во время пиковых нагрузок. Это становится особенно ощутимо, когда разные команды планируют критически важные рабочие нагрузки ночью. В частности, процессы загрузки данных в корпоративное DWH обычно выполняются в этот период, когда большинство пользователей не работают с прикладными системами. При использовании AirFlow для выполнения ETL-процессов с разными системами от разных команд в одно и то же время, производительность фреймворка может сильно снизиться из-за недостатка рабочих ресурсов и доступности планировщика. Airflow не имеет механизма приоритета расписания конвейеров обработки данных. Поэтому даже критически важные DAG не могут быть приоритетными с точки зрения планирования.
Еще одним ограничением для эффективной многопользовательской работы с Apache Airflow, является то, что многие конфигурации тонкой настройки существуют на уровне среды, а не на уровне DAG. Поэтому разные команды могут иметь конфликтующие конфигурации настроек параллелизма, исполнителей и пр. или разные значения по умолчанию, такие как повторные попытки и т. д.
Конфликты пакетов Python также создают проблемы: специалисты по Data Science могут использовать специфические библиотеки машинного обучения, которые конфликтуют с базовыми пакетами других пользователей. Сюда же относится несоответствие между разными версиями пакетов провайдеров. Ручное разрешение таких конфликтов может занять много времени, требуя компромисса, рефакторинга, использования специальных решений типа KubernetesPodOperators или разработки и внедрения жестких правил конфигурирования среды.
Наконец, координация обновлений становится намного сложнее, когда нужно синхронизировать несколько команд. Планирование любого простоя или окна обслуживания может вызвать сбои в работе разных пользователей. Это усложняет внедрение новых функций, выпускаемых в каждом релизе Airflow. Такая же проблема может возникнуть и при координации различных репозиториев. Командам придется поддерживать несколько разных скриптов CI/CD или размещать все свои DAG в одном репозитории. Оба этих варианта увеличивают расходы на эксплуатацию и обслуживание.
Таким образом, кажется рациональным предоставить каждой команде свою собственную среду развертывания AirFlow, чтобы дата-инженеры могли эффективно настраивать ее под свои сценарии использования. Однако, у этого решения тоже есть недостатки, которые мы рассмотрим далее.
И все же как развернуть AirFlow в многопользовательской среде
Как показывает практика, поддержание даже одной среды требует значительных усилий. А если таких сред несколько, затраты ресурсов на сопровождения существенно увеличиваются. Расходы на инфраструктуру тоже растут из-за долго работающих служб Airflow, таких как планировщик и веб-сервер. Кроме того, разрешение разным командам разворачивать собственные среды Airflow может создать проблемы с наблюдаемостью: ключевые наборы данных будут управляться устаревшими или небезопасными настройками. Однако, централизованное логирование, мониторинг и управление становятся необходимыми, особенно когда DAG одной команды поставляют входные данные для другой.
Решить эти проблемы помогают изолированные среды с полной наблюдаемостью, например, Astro от Astronomer или Yandex Managed Service for Apache Airflow™ от Яндекса. Эти платформы обеспечивают единую точку контроля и управления для развертывания Airflow. Все эти среды могут работать в отдельных кластерах и облачных провайдерах, интегрируясь с сервисами контроля и управления доступом для бесшовных разрешений. Пользователи видят только те DAG, к которым у них есть доступ, независимо от того, где они запущены, а администраторы наблюдают базовые показатели каждой среды, выполнение SLA для DAG и затраты на каждое развертывание. Такой подход обеспечивает эффективную многопользовательскую эксплуатацию для контроля выполнения и разрешений, не жертвуя унифицированной наблюдаемостью.
Кроме того, эфемерные среды развертывания ускоряют эксперименты и поставку результатов, что особенно важно для современного бизнеса. Каждая среда может иметь собственный график работы, максимально используя инфраструктуру, когда это необходимо. Так можно оптимизировать затраты на обработку данных. Автоматизировать этот процесс управления инфраструктурой можно с помощью Terraform — инструмент IaaS (инфраструктура как код), который позволяет безопасно и эффективно создавать, изменять и версионировать облачные и локальные ресурсы как код.
Автоматизацию, необходимую для стандартизации этого процесса в рамках предприятия, можно реализовать напрямую через astro-cli, через полнофункциональный REST API или через официального провайдера пакетов Terraform от HashiCorp, который позволяет управлять ресурсами Airflow, в т.ч. для управления и предоставления сред. Это упрощает развертывание и масштабирование кластеров Airflow, обеспечивая согласованные и повторяемые настройки.
Наконец, облачные многопользовательские среды Airflow стремятся обеспечить сопутствующие потребности своих пользователей в задачах инженерии данных. Например, путем поддержки dbt – популярного инструмента преобразования данных без их фактического копирования, который часто используется вместе с Airflow.Ранее такое совместное использование Airflow с dbt требовало двух отдельных процессов: изменения в моделях dbt отправлялись в один репозиторий, а затем приходилось развертывать DAG Airflow, которые их запускали. Современные платформы дата-инженерии на базе Airflow снижают накладные расходы на поддержку двух отдельных процессов CI/CD, позволяя развертывать изменения dbt непосредственно в Airflow без повторного развертывания DAG. О возможностях и преимуществ совместного использования Airflow с dbt мы рассказывали здесь.
Узнайте больше про администрирование и эксплуатацию Apache AirFlow для оркестрации пакетных процессов в задачах реальной дата-инженерии на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Data Pipeline на Apache AirFlow и Apache Hadoop
- AIRFLOW с использованием Yandex Managed Service for Apache Airflow™
Источники
