#AirFlow #статьи
Оповещения Apache AirFlow: какие они бывают и зачем их отслеживать
При работе с Apache AirFlow наиболее важно настроить следующие оповещения:
✅о сбоях DAG, если он не выполняется или при попытке выполнения возникают ошибки;
✅о сбое планирования DAG, если он не запускается в течение определенного периода времени из-за отказа экземпляра AirFlow или его неправильной конфигурации;
✅о сбоях задач, когда конкретная задача в DAG не выполняется или при попытке выполнения возникла ошибка;
✅нарушения SLA (Service Level Agreement, соглашение об уровне обслуживания), когда рабочий процесс занимает больше времени, чем ожидалось. Часто это свидетельствует о проблемах с производительностью системы.
✅о качестве данных, когда в рабочих процессах обнаруживаются отсутствующие или неверные данные, что может привести к некорректным результатам.
✅об использовании ресурсов, когда кластер AirFlow потребляет слишком много ЦП или памяти. Эти оповещения позволят вовремя обнаружит проблемы с инфраструктурой и обеспечить бесперебойную работу конвейеров обработки данных.
Далее рассмотрим : Мониторинг оповещений с помощью HealthChecks.io
@BigDataSchool_ru
https://bigdataschool.ru/blog/service-healthchecks-to-monitor-airflow-alerts.html
Оповещения Apache AirFlow: какие они бывают и зачем их отслеживать
При работе с Apache AirFlow наиболее важно настроить следующие оповещения:
✅о сбоях DAG, если он не выполняется или при попытке выполнения возникают ошибки;
✅о сбое планирования DAG, если он не запускается в течение определенного периода времени из-за отказа экземпляра AirFlow или его неправильной конфигурации;
✅о сбоях задач, когда конкретная задача в DAG не выполняется или при попытке выполнения возникла ошибка;
✅нарушения SLA (Service Level Agreement, соглашение об уровне обслуживания), когда рабочий процесс занимает больше времени, чем ожидалось. Часто это свидетельствует о проблемах с производительностью системы.
✅о качестве данных, когда в рабочих процессах обнаруживаются отсутствующие или неверные данные, что может привести к некорректным результатам.
✅об использовании ресурсов, когда кластер AirFlow потребляет слишком много ЦП или памяти. Эти оповещения позволят вовремя обнаружит проблемы с инфраструктурой и обеспечить бесперебойную работу конвейеров обработки данных.
Далее рассмотрим : Мониторинг оповещений с помощью HealthChecks.io
@BigDataSchool_ru
https://bigdataschool.ru/blog/service-healthchecks-to-monitor-airflow-alerts.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
5 типов оповещений Apache AirFlow и их мониторинг в Healthchecks.io
В этой статье для обучения дата-инженеров рассмотрим типы оповещений в Apache AirFlow и их отс
#AirFlow #статьи
💡7 рекомендаций по повышению эффективности фреймворка
Чтобы улучшить работу Apache AirFlow с DAG, дата-инженер может использовать следующие рекомендации и лучшие практики:
✅Управление зависимостями. Зависимости между задачами могут быть сложными, особенно при работе с большими конвейерами.
Рекомендуется использовать объект DAG для определения рабочих процессов и задач с четкими зависимостями.
Следует сразу определять рабочие процессы как Python-код. Это упрощает управление версиями и совместную работу с другими членами команды.
✅Операторы для определения задач. AirFlow предоставляет широкий спектр операторов для типовых задач, например, PythonOperator для выполнения Python-кода, BashOperator для выполнения команд shell-оболочки и SQLOperator для выполнения SQL-запросов.
✅Датчики (сенсоры) для ожидания внешних событий. AirFlow предоставляет специальных тип операторов, называемые датчики или сенсоры, которые бездействуют в ожидании внешних событий, таких как запись файлов в каталог или отправка сообщений в очередь.
✅Подключения (соединения) для хранения учетных данных, таких как пароли базы данных или ключи API. Это позволяет хранить конфиденциальную информацию вне кода и удобнее управлять ею.
✅Переменные для хранения значений конфигурации, таких как количество повторных попыток выполнения задачи. Так можно быстро менять настройки без изменения кода.
✅Обработка ошибок. Когда задачи терпят сбой, не всегда сразу получается найти основную причину.
Для обработки ошибок пригодится функция логирования и повторной попытки для автоматического повторения невыполненных задач.
Журналирование позволяет видеть результаты задач, а также любые сообщения об ошибках, которые они генерируют.
✅Масштабирование конвейеров. По мере роста объемов данных конвейеры могут становиться медленнее и сложнее в управлении.
Чтобы масштабировать конвейеры, целесообразно использовать возможности фреймворков распределенных вычислений, таких как Apache Spark или Flink, а также контейнерную виртуализацию с Kubernetes или Docker.
@BigDataSchool_ru
https://bigdataschool.ru/blog/how-to-fix-dag-errors-in-airflow-gui.html
💡7 рекомендаций по повышению эффективности фреймворка
Чтобы улучшить работу Apache AirFlow с DAG, дата-инженер может использовать следующие рекомендации и лучшие практики:
✅Управление зависимостями. Зависимости между задачами могут быть сложными, особенно при работе с большими конвейерами.
Рекомендуется использовать объект DAG для определения рабочих процессов и задач с четкими зависимостями.
Следует сразу определять рабочие процессы как Python-код. Это упрощает управление версиями и совместную работу с другими членами команды.
✅Операторы для определения задач. AirFlow предоставляет широкий спектр операторов для типовых задач, например, PythonOperator для выполнения Python-кода, BashOperator для выполнения команд shell-оболочки и SQLOperator для выполнения SQL-запросов.
✅Датчики (сенсоры) для ожидания внешних событий. AirFlow предоставляет специальных тип операторов, называемые датчики или сенсоры, которые бездействуют в ожидании внешних событий, таких как запись файлов в каталог или отправка сообщений в очередь.
✅Подключения (соединения) для хранения учетных данных, таких как пароли базы данных или ключи API. Это позволяет хранить конфиденциальную информацию вне кода и удобнее управлять ею.
✅Переменные для хранения значений конфигурации, таких как количество повторных попыток выполнения задачи. Так можно быстро менять настройки без изменения кода.
✅Обработка ошибок. Когда задачи терпят сбой, не всегда сразу получается найти основную причину.
Для обработки ошибок пригодится функция логирования и повторной попытки для автоматического повторения невыполненных задач.
Журналирование позволяет видеть результаты задач, а также любые сообщения об ошибках, которые они генерируют.
✅Масштабирование конвейеров. По мере роста объемов данных конвейеры могут становиться медленнее и сложнее в управлении.
Чтобы масштабировать конвейеры, целесообразно использовать возможности фреймворков распределенных вычислений, таких как Apache Spark или Flink, а также контейнерную виртуализацию с Kubernetes или Docker.
@BigDataSchool_ru
https://bigdataschool.ru/blog/how-to-fix-dag-errors-in-airflow-gui.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
4 ошибки с DAG в интерфейсе Apache AirFlow и способы их исправления
Сегодня рассмотрим, какие ошибки, связанные с DAG, отображаются в пользовательском интер
#AirFlow #Python #статьи
🔥Главные новинки и исправления весенних выпусков Apache AirFlow в 2023 году
30 апреля 2023 года состоялся официальный выпуск Apache AirFlow 2.6.0.
А спустя 2 недели, 16 мая, вышло дополнение 2.6.1.
Эти выпуски содержат более 500 коммитов, включая около 40 новых функций, 50 общих улучшений и примерно 50 исправлений ошибок.
Из наиболее значительных изменений этих релизов можно отметить следующие:
✅повышение стабильности и производительности фреймворка, включая снижение потребления памяти, улучшенную обработку ошибок и улучшенную поддержку Python 3.9;
✅настраиваемые поля DAG, что пригодится дата-инженеру, если нужно добавить дополнительную информацию или собственные поля метаданных.
К примеру, можно создать настраиваемое поле DAG для хранения информации о том, какие данные используются в конвейере или параметры его запуска. Это пригодится для анализа результатов выполнения DAG и отладки.
Настраиваемые поля DAG реализованы с помощью нового класса Python под названием DAGSchema.
✅добавлен новый объект, расширяющий слой добавления уведомлений в DAG. Пользователи могут создавать логику уведомлений из нового базового объекта и вызывать ее непосредственно из своих файлов DAG.
Для этого используется абстрактный класс BaseNotifier, предоставляющий базовую структуру для отправки уведомлений в Airflow с использованием различных функций обратного вызова.
Чтобы расширить класс BaseNotifier, нужно создать новый класс-наследник и переопределить в нем метод notify()своей собственной реализацией, которая отправляет уведомление.
Этот метод принимает единственный параметр — контекст AirFlow, который содержит информацию о текущей задаче и ее выполнении.
✅в версиях 2.6.0 и 2.6.1 добавлена возможность создания нового ресурса для управления заданиями, чтобы более гибко и эффективно ресурсами в системе.
Ресурс для управления заданиями создается с помощью Python-класса BaseExecutor, который позволяет определить новый ресурс для выполнения задач в Apache AirFlow.
После определения ресурса его можно использовать его в системе, чтобы контролировать, какие задачи выполняются и на каких ресурсах.
Так можно более эффективно использовать ресурсы в системе, снижая нагрузку на каждый ресурс и улучшить общую производительность системы.
Например, создать новый ресурс, который будет использовать только определенные типы хранилищ данных.
Про другие новинки читаем далее.
@BigDataSchool_ru
https://bigdataschool.ru/blog/airflow-2-6-release-overview.html
🔥Главные новинки и исправления весенних выпусков Apache AirFlow в 2023 году
30 апреля 2023 года состоялся официальный выпуск Apache AirFlow 2.6.0.
А спустя 2 недели, 16 мая, вышло дополнение 2.6.1.
Эти выпуски содержат более 500 коммитов, включая около 40 новых функций, 50 общих улучшений и примерно 50 исправлений ошибок.
Из наиболее значительных изменений этих релизов можно отметить следующие:
✅повышение стабильности и производительности фреймворка, включая снижение потребления памяти, улучшенную обработку ошибок и улучшенную поддержку Python 3.9;
✅настраиваемые поля DAG, что пригодится дата-инженеру, если нужно добавить дополнительную информацию или собственные поля метаданных.
К примеру, можно создать настраиваемое поле DAG для хранения информации о том, какие данные используются в конвейере или параметры его запуска. Это пригодится для анализа результатов выполнения DAG и отладки.
Настраиваемые поля DAG реализованы с помощью нового класса Python под названием DAGSchema.
✅добавлен новый объект, расширяющий слой добавления уведомлений в DAG. Пользователи могут создавать логику уведомлений из нового базового объекта и вызывать ее непосредственно из своих файлов DAG.
Для этого используется абстрактный класс BaseNotifier, предоставляющий базовую структуру для отправки уведомлений в Airflow с использованием различных функций обратного вызова.
Чтобы расширить класс BaseNotifier, нужно создать новый класс-наследник и переопределить в нем метод notify()своей собственной реализацией, которая отправляет уведомление.
Этот метод принимает единственный параметр — контекст AirFlow, который содержит информацию о текущей задаче и ее выполнении.
✅в версиях 2.6.0 и 2.6.1 добавлена возможность создания нового ресурса для управления заданиями, чтобы более гибко и эффективно ресурсами в системе.
Ресурс для управления заданиями создается с помощью Python-класса BaseExecutor, который позволяет определить новый ресурс для выполнения задач в Apache AirFlow.
После определения ресурса его можно использовать его в системе, чтобы контролировать, какие задачи выполняются и на каких ресурсах.
Так можно более эффективно использовать ресурсы в системе, снижая нагрузку на каждый ресурс и улучшить общую производительность системы.
Например, создать новый ресурс, который будет использовать только определенные типы хранилищ данных.
Про другие новинки читаем далее.
@BigDataSchool_ru
https://bigdataschool.ru/blog/airflow-2-6-release-overview.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Apache AirFlow 2.6: что нового?
Самые главные новинки Apache AirFlow 2.6: настраиваемые поля DAG, уведомления, кластеризация исполнителей Kubernetes,управление ресурсами
#Airflow #статьи
Аналитика системных метрик Apache AirFlow с ADA и Amundsen
ADA — это микросервис, созданный для получения ключевых аналитических показателей задач и DAG из экземпляра базы данных AirFlow.
Благодаря тесной интеграции с фреймворком, ADA может извлекать данные из базы данных и анализировать их.
Подключив ADA к своему экземпляру, дата-инженер получит значения системных метрик, чтобы принимать управленческие решения на основе исторического поведения DAG.
ADA абсолютно не зависит от Python-кода задач и операторов AirFlow, поскольку является средством выполнения SQL-запросов к базе данных метаданных, где хранятся сведения о задачах и DAG.
Это пригодится, например, чтобы оценить длительность выполнения процесса и, если она превышает допустимые лимиты, принять оперативные меры.
Аналогичные задачи аналитики системных метрик Apache AirFlow можно решить с помощью Amundsen, механизма обнаружения данных и метаданных.
Он имеет наглядные веб-GUI, где отображаются сведения по наиболее востребованным шаблонам, например, таблицы с большим количеством запросов. Амундсен включает в себя следующие компоненты:
❇️amundsenfrontendlibrary— служба внешнего интерфейса, представляющая собой приложение Flask с интерфейсом React;
❇️amundsensearchlibrary— служба поиска, использующая возможности Elasticsearch для поиска метаданных внешнего интерфейса;
❇️amundsenmetadatalibrary– служба метаданных, которая использует графовую базу данных Neo4j или Apache Atlas в качестве постоянного уровня для предоставления различных метаданных;
❇️amundsendatabuilder– библиотека приема данных для построения графа метаданных и поискового индекса. Пользователи могли либо загрузить данные с помощью Python-скрипта с библиотекой или с помощью DAG AirFlow, импортирующей библиотеку.
❇️amundsencommon– общая библиотека Amundsen с кодом микросервисов;
❇️amundsengremlin– библиотека для преобразования объектов модели в вершины и ребра в выражения языка обхода графов Gremlin для загрузки данных в серверную часть AWS Neptune;
❇️amundsenrds– модели ORM для поддержки реляционной базы данных в качестве внутреннего хранилища метаданных в Amundsen. Схема в моделях ORM следует логике моделей построения данных и используется в конструкторе данных и библиотеке метаданных для хранения и поиска метаданных в реляционных базах данных.
@BigDataSchool_ru
https://bigdataschool.ru/blog/5-useful-tools-for-data-engineering-with-airflow.html
Аналитика системных метрик Apache AirFlow с ADA и Amundsen
ADA — это микросервис, созданный для получения ключевых аналитических показателей задач и DAG из экземпляра базы данных AirFlow.
Благодаря тесной интеграции с фреймворком, ADA может извлекать данные из базы данных и анализировать их.
Подключив ADA к своему экземпляру, дата-инженер получит значения системных метрик, чтобы принимать управленческие решения на основе исторического поведения DAG.
ADA абсолютно не зависит от Python-кода задач и операторов AirFlow, поскольку является средством выполнения SQL-запросов к базе данных метаданных, где хранятся сведения о задачах и DAG.
Это пригодится, например, чтобы оценить длительность выполнения процесса и, если она превышает допустимые лимиты, принять оперативные меры.
Аналогичные задачи аналитики системных метрик Apache AirFlow можно решить с помощью Amundsen, механизма обнаружения данных и метаданных.
Он имеет наглядные веб-GUI, где отображаются сведения по наиболее востребованным шаблонам, например, таблицы с большим количеством запросов. Амундсен включает в себя следующие компоненты:
❇️amundsenfrontendlibrary— служба внешнего интерфейса, представляющая собой приложение Flask с интерфейсом React;
❇️amundsensearchlibrary— служба поиска, использующая возможности Elasticsearch для поиска метаданных внешнего интерфейса;
❇️amundsenmetadatalibrary– служба метаданных, которая использует графовую базу данных Neo4j или Apache Atlas в качестве постоянного уровня для предоставления различных метаданных;
❇️amundsendatabuilder– библиотека приема данных для построения графа метаданных и поискового индекса. Пользователи могли либо загрузить данные с помощью Python-скрипта с библиотекой или с помощью DAG AirFlow, импортирующей библиотеку.
❇️amundsencommon– общая библиотека Amundsen с кодом микросервисов;
❇️amundsengremlin– библиотека для преобразования объектов модели в вершины и ребра в выражения языка обхода графов Gremlin для загрузки данных в серверную часть AWS Neptune;
❇️amundsenrds– модели ORM для поддержки реляционной базы данных в качестве внутреннего хранилища метаданных в Amundsen. Схема в моделях ORM следует логике моделей построения данных и используется в конструкторе данных и библиотеке метаданных для хранения и поиска метаданных в реляционных базах данных.
@BigDataSchool_ru
https://bigdataschool.ru/blog/5-useful-tools-for-data-engineering-with-airflow.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
5 полезных инструментов для работы с Apache AirFlow
От аналитики системных метрик до преобразования DAG: ADA, Ditto, Amundsen, gusty и Viewflow для работы дата-инженера с Apache AirFlow
#Airflow #статьи
Ditto, gusty и Viewflow для работы с DAG
❇️Ditto — это фреймворк, который позволяет преобразовывать DAG AirFlow, изоморфную для другой платформы оркестрации рабочих процессов, чтобы поддерживать одну кодовую базу и запускать DAG AirFlow в разных средах выполнения.
Ditto предназначен не для однократного преобразования, а для непрерывного и параллельного развертывания DAG.
В основе Ditto лежит графовая библиотека для работы с расширяемыми API. Также этот фреймворк поставляется с готовой поддержкой преобразования EMR в HDInsight.
❇️Python-библиотека gusty позволяет управлять группами DAG, группами задач и задач AirFlow, представленными в виде любого количества файлов YAML, Python, SQL, Jupyter Notebook или R Markdown. Каталог файлов задач мгновенно преобразуется в DAG. Также библиотека gusty управляет зависимостями внутри одной DAG и внешними зависимостями от задач в других DAG для каждого определенного пользователем файла задачи.
Дата-инженеру нужно предоставить список внутренних или внешних зависимостей, и gusty автоматически установит зависимости каждой задачи и создаст внешние сенсоры задач для любых перечисленных внешних зависимостей.
В заключение отметим, что вместе с gusty можно использовать традиционные методы создания DAG AirFlow, выбирая лучший подход для каждого конкретного случая.
❇️Еще одним полезным инструментом для работы с DAG является Viewflow — платформа, построенная на основе Airflow, которая позволяет создавать материализованные представления и автоматически создает группы DAG и задачи Airflow на основе файлов SQL, Python, R или Rmd. Обычно каждый из этих файлов отвечает за материализацию нового представления. Дата-инженеру достаточно лишь написать определение представления, а все остальное сделает Viewflow.
Одной из основных особенностей Viewflow является его способность управлять зависимостями задач, т.е. представлениями, используемыми для создания другого представления. Viewflow может автоматически извлекать из кода, например, SQL-запроса или Python-скрипта, внутренние и внешние зависимости.
@BigDataSchool_ru
https://bigdataschool.ru/blog/5-useful-tools-for-data-engineering-with-airflow.html
Ditto, gusty и Viewflow для работы с DAG
❇️Ditto — это фреймворк, который позволяет преобразовывать DAG AirFlow, изоморфную для другой платформы оркестрации рабочих процессов, чтобы поддерживать одну кодовую базу и запускать DAG AirFlow в разных средах выполнения.
Ditto предназначен не для однократного преобразования, а для непрерывного и параллельного развертывания DAG.
В основе Ditto лежит графовая библиотека для работы с расширяемыми API. Также этот фреймворк поставляется с готовой поддержкой преобразования EMR в HDInsight.
❇️Python-библиотека gusty позволяет управлять группами DAG, группами задач и задач AirFlow, представленными в виде любого количества файлов YAML, Python, SQL, Jupyter Notebook или R Markdown. Каталог файлов задач мгновенно преобразуется в DAG. Также библиотека gusty управляет зависимостями внутри одной DAG и внешними зависимостями от задач в других DAG для каждого определенного пользователем файла задачи.
Дата-инженеру нужно предоставить список внутренних или внешних зависимостей, и gusty автоматически установит зависимости каждой задачи и создаст внешние сенсоры задач для любых перечисленных внешних зависимостей.
В заключение отметим, что вместе с gusty можно использовать традиционные методы создания DAG AirFlow, выбирая лучший подход для каждого конкретного случая.
❇️Еще одним полезным инструментом для работы с DAG является Viewflow — платформа, построенная на основе Airflow, которая позволяет создавать материализованные представления и автоматически создает группы DAG и задачи Airflow на основе файлов SQL, Python, R или Rmd. Обычно каждый из этих файлов отвечает за материализацию нового представления. Дата-инженеру достаточно лишь написать определение представления, а все остальное сделает Viewflow.
Одной из основных особенностей Viewflow является его способность управлять зависимостями задач, т.е. представлениями, используемыми для создания другого представления. Viewflow может автоматически извлекать из кода, например, SQL-запроса или Python-скрипта, внутренние и внешние зависимости.
@BigDataSchool_ru
https://bigdataschool.ru/blog/5-useful-tools-for-data-engineering-with-airflow.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
5 полезных инструментов для работы с Apache AirFlow
От аналитики системных метрик до преобразования DAG: ADA, Ditto, Amundsen, gusty и Viewflow для работы дата-инженера с Apache AirFlow
#Airflow #статьи
Запуск Apache AirFlow в Google Colab
Хотя Google Colab является мощным облачным окружением для запуска и написания Python-кода, выполнение написанных на этом языке программирования цепочек задач (DAG, Directed Acyclic Graph) Apache AirFlow непосредственно в среде Colab не поддерживается.
Это обусловлено тем, что Airflow является системным сервисом (демоном), который запускается на сервере и управляет запуском задач.
Однако, можно настроить AirFlow в облаке, например, на Google Cloud Platform, и запускать DAG-файлы из Colab, используя удаленный исполнитель. Также можно установить AirFlow в Colab, написать и запустить DAG.
Посмотреть состояние запущенного DAG можно в веб-GUI AirFlow, запустив веб-сервер. При запуске в Colab этот веб-сервер запускается на удаленной машине, хотя изначально он привязан к сокету http://localhost:8080, т.е. порту 8080 на локальном хосте.
Поэтому, чтобы достучаться до веб-интерфейса фреймворка, запускаемого в Google Colab, необходимом прокинуть туннель, который делает локальный хост доступным извне. Для этого можно использовать утилиту ngrok, по аналогии как это было сделано с приложением Apache Spark.
Сервис ngrok позволяет открыть доступ к внутренним ресурсам машины, на которой он запущен, из внешней сети путем создания публичного URL-адреса, все запросы на который будут переброшены на локальный адрес и заданный порт удаленной машины.
Для этого в Colab необходимо установить целый набор пакетов и импортировать необходимые модули. Рассмотрим далее
@BigDataSchool_ru
https://bigdataschool.ru/blog/how-to-launch-airflow-on-colab-with-ngrok.html
Запуск Apache AirFlow в Google Colab
Хотя Google Colab является мощным облачным окружением для запуска и написания Python-кода, выполнение написанных на этом языке программирования цепочек задач (DAG, Directed Acyclic Graph) Apache AirFlow непосредственно в среде Colab не поддерживается.
Это обусловлено тем, что Airflow является системным сервисом (демоном), который запускается на сервере и управляет запуском задач.
Однако, можно настроить AirFlow в облаке, например, на Google Cloud Platform, и запускать DAG-файлы из Colab, используя удаленный исполнитель. Также можно установить AirFlow в Colab, написать и запустить DAG.
Посмотреть состояние запущенного DAG можно в веб-GUI AirFlow, запустив веб-сервер. При запуске в Colab этот веб-сервер запускается на удаленной машине, хотя изначально он привязан к сокету http://localhost:8080, т.е. порту 8080 на локальном хосте.
Поэтому, чтобы достучаться до веб-интерфейса фреймворка, запускаемого в Google Colab, необходимом прокинуть туннель, который делает локальный хост доступным извне. Для этого можно использовать утилиту ngrok, по аналогии как это было сделано с приложением Apache Spark.
Сервис ngrok позволяет открыть доступ к внутренним ресурсам машины, на которой он запущен, из внешней сети путем создания публичного URL-адреса, все запросы на который будут переброшены на локальный адрес и заданный порт удаленной машины.
Для этого в Colab необходимо установить целый набор пакетов и импортировать необходимые модули. Рассмотрим далее
@BigDataSchool_ru
https://bigdataschool.ru/blog/how-to-launch-airflow-on-colab-with-ngrok.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Как запустить Apache AirFlow в Google Colab с ngrok
Запуск Apache AirFlow в Google Colab с утилитой ngrok для просмотра исполнения DAG в веб-GUI: пошаговое руководство с примерами Python-кода
#Airflow #статьи
Трудности работы с Apache AirFlow в среде Google Colab
О том, что можно настроить AirFlow в Google Cloud Platform, и запускать DAG-файлы из Colab, используя удаленный исполнитель, рассказывали ранее.
Это довольно интересный опыт, который позволяет познакомиться с самым популярным пакетным ETL-фреймворком без его установки на личный компьютер или доступа к платной serverless-платформе, например, Amazon MWAA (Amazon Managed Workflows for Apache Airflow).
Однако, при эксплуатации Apache AirFlow в Google Colab столкнулись с рядом неудобств.
🔻Прежде всего, очень низкая скорость работы. Например, выполнение даже такой простой задачи, как вывод текущей даты, в веб-GUI занимало около пары секунд. А DAG из 5 операторов без обращения к внешним системам выполнялся примерно 20 секунд, что очень долго.
Возможно, это связано с тем, что при использовании Colab веб-сервер AirFlow запускается на удаленной машине.
И, чтобы получить доступ к веб-интерфейсу фреймворка, прокидывали туннель, который делает локальный хост доступным извне, с помощью утилиты ngrok. Она позволяет открыть доступ к внутренним ресурсам машины, на которой он запущен, из внешней сети путем создания публичного URL-адреса, все запросы на который будут переброшены на локальный адрес и заданный порт удаленной машины.
🔻Второй недостаток, который хочется отметить – это большое число операций, которые следует выполнить вручную. Хотя установка библиотек и импорт модулей выполняются в коде, пришлось разбираться с директориями, например, определяя директорию для хранения DAG и копируя туда файл пакетного конвейера.
Хотя сохранение DAG в виде py-файла в нужную директорию можно сделать прямо из ячейки Colab, также как его удаление/обновление, придется постоянно перезапускать эти ячейки или выполнять данные операции вручную при отладке и изменении конвейера.
🔻Третья неожиданность, с которой столкнется пользователь Apache AirFlow, запуская его в среде Google Colab, это отсутствие возможности создать свой тип соединения в GUI.
🔻Однако, добавление своих соединений напрямую влечет следующую проблему, связанную с нарушением безопасности.
В частности, приходится отправлять учетные данные в сторонний сервис.
Например, чтобы какая-нибудь задача DAG или весь конвейер по его завершении отправляли данные на электронную почту, придется указать логин, пароль, адрес SMTP или POP3-сервера, а также порт.
Аналогичным образом потребуется указать учетные данные дя подключения к другой внешней системе, например, чтобы реализовать полноценный ETL-конвейер, собирающий данные из источника и загружающий преобразованную информацию в какой-либо приемник.
Однако, несмотря на отмеченные недостатки, в заключение подчеркнем еще раз, что запуск Apache AirFlow в среде Google Colab является отличной возможностью для начинающих дата-инженеров вручную познакомиться с этим ETL-инструментом без его развертывания на собственном компьютере или на облачном сервере.
Кроме того, такой вариант использования может пригодиться в случае необходимости быстро проверить какую-то гипотезу или продемонстрировать жизнеспособность концепции.
Поэтому рекомендуем попробовать. Только не забудьте про необходимость тунелирования, поскольку веб-сервер AirFlow в Colab запускается на удаленной машине, к порту 8080 или 8888 которой нужно получить доступ, чтобы работать с веб-интерфейсом ETL-фреймворка.
Например, записать порцию данных в PostgreSQL, не нарушив ограничений уникальности первичного ключа, что разбираем в новой статье.
@BigDataSchool_ru
https://bigdataschool.ru/blog/airflow-on-colab-disadvantages-overview.html
Трудности работы с Apache AirFlow в среде Google Colab
О том, что можно настроить AirFlow в Google Cloud Platform, и запускать DAG-файлы из Colab, используя удаленный исполнитель, рассказывали ранее.
Это довольно интересный опыт, который позволяет познакомиться с самым популярным пакетным ETL-фреймворком без его установки на личный компьютер или доступа к платной serverless-платформе, например, Amazon MWAA (Amazon Managed Workflows for Apache Airflow).
Однако, при эксплуатации Apache AirFlow в Google Colab столкнулись с рядом неудобств.
🔻Прежде всего, очень низкая скорость работы. Например, выполнение даже такой простой задачи, как вывод текущей даты, в веб-GUI занимало около пары секунд. А DAG из 5 операторов без обращения к внешним системам выполнялся примерно 20 секунд, что очень долго.
Возможно, это связано с тем, что при использовании Colab веб-сервер AirFlow запускается на удаленной машине.
И, чтобы получить доступ к веб-интерфейсу фреймворка, прокидывали туннель, который делает локальный хост доступным извне, с помощью утилиты ngrok. Она позволяет открыть доступ к внутренним ресурсам машины, на которой он запущен, из внешней сети путем создания публичного URL-адреса, все запросы на который будут переброшены на локальный адрес и заданный порт удаленной машины.
🔻Второй недостаток, который хочется отметить – это большое число операций, которые следует выполнить вручную. Хотя установка библиотек и импорт модулей выполняются в коде, пришлось разбираться с директориями, например, определяя директорию для хранения DAG и копируя туда файл пакетного конвейера.
Хотя сохранение DAG в виде py-файла в нужную директорию можно сделать прямо из ячейки Colab, также как его удаление/обновление, придется постоянно перезапускать эти ячейки или выполнять данные операции вручную при отладке и изменении конвейера.
🔻Третья неожиданность, с которой столкнется пользователь Apache AirFlow, запуская его в среде Google Colab, это отсутствие возможности создать свой тип соединения в GUI.
🔻Однако, добавление своих соединений напрямую влечет следующую проблему, связанную с нарушением безопасности.
В частности, приходится отправлять учетные данные в сторонний сервис.
Например, чтобы какая-нибудь задача DAG или весь конвейер по его завершении отправляли данные на электронную почту, придется указать логин, пароль, адрес SMTP или POP3-сервера, а также порт.
Аналогичным образом потребуется указать учетные данные дя подключения к другой внешней системе, например, чтобы реализовать полноценный ETL-конвейер, собирающий данные из источника и загружающий преобразованную информацию в какой-либо приемник.
Однако, несмотря на отмеченные недостатки, в заключение подчеркнем еще раз, что запуск Apache AirFlow в среде Google Colab является отличной возможностью для начинающих дата-инженеров вручную познакомиться с этим ETL-инструментом без его развертывания на собственном компьютере или на облачном сервере.
Кроме того, такой вариант использования может пригодиться в случае необходимости быстро проверить какую-то гипотезу или продемонстрировать жизнеспособность концепции.
Поэтому рекомендуем попробовать. Только не забудьте про необходимость тунелирования, поскольку веб-сервер AirFlow в Colab запускается на удаленной машине, к порту 8080 или 8888 которой нужно получить доступ, чтобы работать с веб-интерфейсом ETL-фреймворка.
Например, записать порцию данных в PostgreSQL, не нарушив ограничений уникальности первичного ключа, что разбираем в новой статье.
@BigDataSchool_ru
https://bigdataschool.ru/blog/airflow-on-colab-disadvantages-overview.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
4 главных недостатка запуска Apache AirFlow в Colab
Медленно, муторно, небезопасно: что не так с запуском Apache AirFlow в интерактивной среде Google
#Airflow #статьи
Задачи установки/демонтажа
Apache AirFlow 2.7 содержит более 35 новых функций, около 45 улучшений и примерно 50 исправлений ошибок.
Многие функции и улучшения в этой версии сфокусированы на расширении возможностей поддержки управления ресурсами, тестирования DAG и мониторинга как самих конвейеров обработки данных, так и кластера этого оркестратора пакетных процессов.
Главной особенностью AirFlow 2.7 являются задачи установки/демонтажа. Многие рабочие процессы требуют создания ресурса, его использования для выполнения некоторой задачи, а затем устранение этого ресурса.
В производственных средах AirFlow рекомендуется настраивать ресурсы и конфигурации до запуска определенных задач, а затем отключать ресурсы, даже если задачи не выполняются, чтобы сократить потребление ресурсов и расходы.
Поэтому в AirFlow 2.7 был добавлен специальный тип задачи для создания и удаления ресурсов, чтобы эффективно выполнять действия по настройке и демонтажу инфраструктуры в DAG.
Например, подготовка кластера AWS EMR для запуска DAG: можно создать кластер в DagRun перед первой задачей самого конвейера обработки данных, а затем отключить его после завершения последней задачи, даже в случае сбоев. Эта функция настройки и демонтажа также полезна при обработке данных внутри AirFlow , т.к. данные между задачами передаются через объекты XCom, которые никогда не очищаются и потребляют ресурсы. Именно поэтому не рекомендуется передавать через XCom большие объемы данных.
Задачи установки/демонтажа гарантируют, что необходимые ресурсы для запуска задачи AirFlow будут настроены до выполнения задачи и что эти ресурсы будут удалены после завершения задачи, независимо от каких-либо сбоев задачи. Это полезно не только для выполнения инфраструктурных работ, но и в тестировании качества данных, оркестрации моделей машинного обучения, организации ETL-процессов.
Ранее в AirFlow все эти варианты использования реализовывались с помощью сложных правил триггеров, дополнительных DAG и других обходных путей. Теперь дата-инженеру не требуется писать дополнительный код, чтобы воспользоваться преимуществами этой функции для экономии средств и ресурсов.
Любая существующая задача AirFlow может быть обозначена как задача установки/демонтажа, с особым поведением и дополнительной видимостью отношений установки/демонтажа в пользовательском интерфейсе AirFlow .
Также это можно сделать в коде следующим образом, смотреть на сайте.
@BigDataSchool_ru
https://bigdataschool.ru/blog/airflow-2-7-new-release-overview.html
Задачи установки/демонтажа
Apache AirFlow 2.7 содержит более 35 новых функций, около 45 улучшений и примерно 50 исправлений ошибок.
Многие функции и улучшения в этой версии сфокусированы на расширении возможностей поддержки управления ресурсами, тестирования DAG и мониторинга как самих конвейеров обработки данных, так и кластера этого оркестратора пакетных процессов.
Главной особенностью AirFlow 2.7 являются задачи установки/демонтажа. Многие рабочие процессы требуют создания ресурса, его использования для выполнения некоторой задачи, а затем устранение этого ресурса.
В производственных средах AirFlow рекомендуется настраивать ресурсы и конфигурации до запуска определенных задач, а затем отключать ресурсы, даже если задачи не выполняются, чтобы сократить потребление ресурсов и расходы.
Поэтому в AirFlow 2.7 был добавлен специальный тип задачи для создания и удаления ресурсов, чтобы эффективно выполнять действия по настройке и демонтажу инфраструктуры в DAG.
Например, подготовка кластера AWS EMR для запуска DAG: можно создать кластер в DagRun перед первой задачей самого конвейера обработки данных, а затем отключить его после завершения последней задачи, даже в случае сбоев. Эта функция настройки и демонтажа также полезна при обработке данных внутри AirFlow , т.к. данные между задачами передаются через объекты XCom, которые никогда не очищаются и потребляют ресурсы. Именно поэтому не рекомендуется передавать через XCom большие объемы данных.
Задачи установки/демонтажа гарантируют, что необходимые ресурсы для запуска задачи AirFlow будут настроены до выполнения задачи и что эти ресурсы будут удалены после завершения задачи, независимо от каких-либо сбоев задачи. Это полезно не только для выполнения инфраструктурных работ, но и в тестировании качества данных, оркестрации моделей машинного обучения, организации ETL-процессов.
Ранее в AirFlow все эти варианты использования реализовывались с помощью сложных правил триггеров, дополнительных DAG и других обходных путей. Теперь дата-инженеру не требуется писать дополнительный код, чтобы воспользоваться преимуществами этой функции для экономии средств и ресурсов.
Любая существующая задача AirFlow может быть обозначена как задача установки/демонтажа, с особым поведением и дополнительной видимостью отношений установки/демонтажа в пользовательском интерфейсе AirFlow .
Также это можно сделать в коде следующим образом, смотреть на сайте.
@BigDataSchool_ru
https://bigdataschool.ru/blog/airflow-2-7-new-release-overview.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Apache AirFlow 2.7: обзор августовского релиза
Улучшенный мониторинг DAG и управление кластером, задачи установки/демонтажа, поддержка OpenLineage и другие фичи Apache AirFlow 2.7
#Airflow #статьи
Встроенная поддержка OpenLineage
Поскольку AirFlow используется для проектирования конвейеров обработки данных, вопросы отслеживания их происхождения при выполнении задач извлечения и преобразования становятся особенно актуальными.
С версии 2.7 фреймворк поддерживает спецификацию OpenLineage – открытую платформу для сбора и анализа метаданных о происхождении данных, включая метаданные о наборах данных, заданиях и запусках.
Это позволяет предоставить дата-инженерам информацию, необходимую для выявления основной причины сложных проблем и понимания влияния изменений.
OpenLineage содержит открытый стандарт для сбора данных о происхождении, эталонную реализацию репозитория метаданных (Marquez), библиотеки для распространенных языков и интеграцию с инструментами конвейера данных.
Публикация операционной истории происхождения данных через интеграцию OpenLineage была основной возможностью AirFlow для устранения неполадок и сценариев использования управления.
До версии 2.7 выпуск метаданных OpenLineage был возможен только с помощью реализации плагина, поддерживаемого в проекте OpenLineage, который зависел от AirFlow и внутренних компонентов оператора.
Теперь встроенная поддержка OpenLineage в AirFlow делает публикацию метаданных через экосистему OpenLineage более простой и надежной.
Это реализовано путем перемещения пакета openlineage-AirFlow из проекта OpenLineage к провайдеру AirFlow-openlineage в базовом образе AirFlow Docker, где его можно включить с помощью конфигурации, включая логику извлечения происхождения вместе с модульными тестами, что в большинстве случаев устраняет необходимость в дополнительных экстракторах.
Наличие логики извлечения в каждом провайдере обеспечивает стабильность контракта происхождения в каждом операторе и упрощает добавление покрытия происхождения к пользовательским операторам.
@BigDataSchool_ru
https://bigdataschool.ru/blog/airflow-2-7-new-release-overview.html
Встроенная поддержка OpenLineage
Поскольку AirFlow используется для проектирования конвейеров обработки данных, вопросы отслеживания их происхождения при выполнении задач извлечения и преобразования становятся особенно актуальными.
С версии 2.7 фреймворк поддерживает спецификацию OpenLineage – открытую платформу для сбора и анализа метаданных о происхождении данных, включая метаданные о наборах данных, заданиях и запусках.
Это позволяет предоставить дата-инженерам информацию, необходимую для выявления основной причины сложных проблем и понимания влияния изменений.
OpenLineage содержит открытый стандарт для сбора данных о происхождении, эталонную реализацию репозитория метаданных (Marquez), библиотеки для распространенных языков и интеграцию с инструментами конвейера данных.
Публикация операционной истории происхождения данных через интеграцию OpenLineage была основной возможностью AirFlow для устранения неполадок и сценариев использования управления.
До версии 2.7 выпуск метаданных OpenLineage был возможен только с помощью реализации плагина, поддерживаемого в проекте OpenLineage, который зависел от AirFlow и внутренних компонентов оператора.
Теперь встроенная поддержка OpenLineage в AirFlow делает публикацию метаданных через экосистему OpenLineage более простой и надежной.
Это реализовано путем перемещения пакета openlineage-AirFlow из проекта OpenLineage к провайдеру AirFlow-openlineage в базовом образе AirFlow Docker, где его можно включить с помощью конфигурации, включая логику извлечения происхождения вместе с модульными тестами, что в большинстве случаев устраняет необходимость в дополнительных экстракторах.
Наличие логики извлечения в каждом провайдере обеспечивает стабильность контракта происхождения в каждом операторе и упрощает добавление покрытия происхождения к пользовательским операторам.
@BigDataSchool_ru
https://bigdataschool.ru/blog/airflow-2-7-new-release-overview.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Apache AirFlow 2.7: обзор августовского релиза
Улучшенный мониторинг DAG и управление кластером, задачи установки/демонтажа, поддержка OpenLineage и другие фичи Apache AirFlow 2.7
#AirFlow #статьи
Изменения в GUI и другие обновления Apache AirFlow 2.7
В пользовательский интерфейс AirFlow добавлено представления активности кластера, которое показывает полезные метрики для мониторинга, включая все, что происходит с запусками DAG и экземплярами задач (сколько из них запущено, неудачно, запланировано и т.д.), а также состояния инфраструктуры (планировщик, база данных метаданных), статус и время выполнения DAG.
Также в веб-GUI AirFlow 2.7 добавлены фильтры состояния выполнения и сбоя DAG, что упрощает мониторинг большого количества конвейеров. Теперь можно просто отфильтровать все DAG, чтобы найти все запущенные и выполняющиеся конвейеры, или, наоборот, завершившиеся со сбоем.
Еще одним, связанным с мониторингом улучшением стало добавление провайдера Apprise, который позволяет отправлять уведомления в несколько сервисов, включая Teams, Twitter, Reddit и пр. Чтобы использовать провайдер Apprise, можно импортировать уведомитель и использовать его как функцию обратного вызова.
В AirFlow 2.7 добавлены опции быстрой остановки, которые можно включить с помощью нового параметра fail stop на уровне DAG. Если для этого параметра установлено значение true, при сбое задачи любые другие текущие задачи также завершатся сбоем. Это ускоряет разработку и тестирование DAG, поскольку можно устранять любые сбои, не дожидаясь ненужного завершения выполнения других задач в этом DAG.
Включение и отключение этой функции задается как установка параметра в DAG (на сайте).
В заключение отметим, что еще в AirFlow 2.7 добавлена новая функция chain linear для реализации сложных зависимостей, чтобы отмечать группы задач как успешные или неудачные и параметр конфигурации default deferrable для упрощения реализации отложенных операторов.
Также можно отключить тестирование соединений в пользовательском интерфейсе, API и CLI, что отключено по умолчанию в целях безопасности.
Наконец, отключена поддержка Python 3.7, вместо команд db init, db upgrade и параметра конфигурации load default connections используется команда airflow db migrate для создания или обновления базы данных метаданных. Эта команда не будет создавать соединения по умолчанию: чтобы сделать это, надо явно запустить команду airflow connection create-default-connections после запуска airflow db migrate.
В случае SSL-соединения SMTP-контекст теперь использует контекст по умолчанию (default ssl contest) – контекст Python вместо ранее использовавшегося none. Это обеспечивает баланс между безопасностью и совместимостью. Когда сертификаты старые, самозаверяющие или неправильно настроенные, это может не работать.
Это можно настроить, установив ssl context в конфигурации электронной почты Airflow. Установка значения none не рекомендуется из соображений безопасности, поскольку это отключает проверку сертификатов и разрешает MITM-атаки.
Также из соображений безопасности конечная точка API /dags/*/dagRuns/*/taskInstances/*/xcomEntries/* отключает возможность десериализации произвольных значений XCom на веб-сервере. Для обратной совместимости администратор сервера может установить для этой конфигурации enable xcom deserialize support значение True, чтобы включить флаг и восстановить обратную совместимость. В производственном развертывании рекомендуется не включать эту функцию и вместо этого выполнять десериализацию на стороне клиента.
Наконец, изменено имени приложения Celery по умолчанию с airflow.executors.celery executor на airflow.providers.celery.executors.celery executor.
@BigDataSchool_ru
https://bigdataschool.ru/blog/airflow-2-7-new-release-overview.html
Изменения в GUI и другие обновления Apache AirFlow 2.7
В пользовательский интерфейс AirFlow добавлено представления активности кластера, которое показывает полезные метрики для мониторинга, включая все, что происходит с запусками DAG и экземплярами задач (сколько из них запущено, неудачно, запланировано и т.д.), а также состояния инфраструктуры (планировщик, база данных метаданных), статус и время выполнения DAG.
Также в веб-GUI AirFlow 2.7 добавлены фильтры состояния выполнения и сбоя DAG, что упрощает мониторинг большого количества конвейеров. Теперь можно просто отфильтровать все DAG, чтобы найти все запущенные и выполняющиеся конвейеры, или, наоборот, завершившиеся со сбоем.
Еще одним, связанным с мониторингом улучшением стало добавление провайдера Apprise, который позволяет отправлять уведомления в несколько сервисов, включая Teams, Twitter, Reddit и пр. Чтобы использовать провайдер Apprise, можно импортировать уведомитель и использовать его как функцию обратного вызова.
В AirFlow 2.7 добавлены опции быстрой остановки, которые можно включить с помощью нового параметра fail stop на уровне DAG. Если для этого параметра установлено значение true, при сбое задачи любые другие текущие задачи также завершатся сбоем. Это ускоряет разработку и тестирование DAG, поскольку можно устранять любые сбои, не дожидаясь ненужного завершения выполнения других задач в этом DAG.
Включение и отключение этой функции задается как установка параметра в DAG (на сайте).
В заключение отметим, что еще в AirFlow 2.7 добавлена новая функция chain linear для реализации сложных зависимостей, чтобы отмечать группы задач как успешные или неудачные и параметр конфигурации default deferrable для упрощения реализации отложенных операторов.
Также можно отключить тестирование соединений в пользовательском интерфейсе, API и CLI, что отключено по умолчанию в целях безопасности.
Наконец, отключена поддержка Python 3.7, вместо команд db init, db upgrade и параметра конфигурации load default connections используется команда airflow db migrate для создания или обновления базы данных метаданных. Эта команда не будет создавать соединения по умолчанию: чтобы сделать это, надо явно запустить команду airflow connection create-default-connections после запуска airflow db migrate.
В случае SSL-соединения SMTP-контекст теперь использует контекст по умолчанию (default ssl contest) – контекст Python вместо ранее использовавшегося none. Это обеспечивает баланс между безопасностью и совместимостью. Когда сертификаты старые, самозаверяющие или неправильно настроенные, это может не работать.
Это можно настроить, установив ssl context в конфигурации электронной почты Airflow. Установка значения none не рекомендуется из соображений безопасности, поскольку это отключает проверку сертификатов и разрешает MITM-атаки.
Также из соображений безопасности конечная точка API /dags/*/dagRuns/*/taskInstances/*/xcomEntries/* отключает возможность десериализации произвольных значений XCom на веб-сервере. Для обратной совместимости администратор сервера может установить для этой конфигурации enable xcom deserialize support значение True, чтобы включить флаг и восстановить обратную совместимость. В производственном развертывании рекомендуется не включать эту функцию и вместо этого выполнять десериализацию на стороне клиента.
Наконец, изменено имени приложения Celery по умолчанию с airflow.executors.celery executor на airflow.providers.celery.executors.celery executor.
@BigDataSchool_ru
https://bigdataschool.ru/blog/airflow-2-7-new-release-overview.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Apache AirFlow 2.7: обзор августовского релиза
Улучшенный мониторинг DAG и управление кластером, задачи установки/демонтажа, поддержка OpenLineage и другие фичи Apache AirFlow 2.7
#Airflow #spark #статьи
Spark Databrics vs Apache AirFlow: versus или вместе?
Впрочем, вопрос Spark Databrics vs Apache AirFlow можно рассматривать не как противопоставление этих технологий, а с точки зрения совместного использования.
Благодаря модульной структуре управления пакетами провайдеров, AirFlow отлично справляется с управлением рабочими процессами Databricks в контексте более крупного конвейера данных с использованием пакета провайдера Airflow Databricks. Этот пакет представляет собой набор классов Python, которые позволяют использовать AirFlow для управления заданиями Databricks.
Он предоставляет два оператора:
✔️DatabricksRunNowOperator для запуска существующего задания Databricks;
✔️DatabricksSubmitRunOperator для отправки нового задания в кластер Databricks.
Чтобы использовать пакет провайдера Databricks для AirFlow, необходимо создать соответствующее соединение Databricks в Airflow, указав учетные данные.
После создания подключения можно использовать операторы Databricks для запуска или отправки заданий в кластер.
Такой комбинированный подход позволяет извлечь выгоду из сильных сторон обеих платформ, создавая более мощное решение для оркестрации и обработки данных, чем каждая технология по отдельности.
Вместе они заполняют пробелы друг друга: AirFlow может запускать, планировать и отслеживать задания Databricks, гарантируя, что они выполняются в правильной последовательности и с обработкой любых сбоев. А Databricks может эффективно обрабатывать огромные объемы данных и выполнять их расширенную аналитику.
Таким образом, сочетание технологий обеспечивает бесперебойный сквозной конвейер данных, от приема и преобразования до аналитики и отчетности, с надежностью оркестрации AirFlow и мощью аналитического механизма Databricks.
@BigDataSchool_ru
https://bigdataschool.ru/blog/apache-airflow-vs-spark-databricks.html
Spark Databrics vs Apache AirFlow: versus или вместе?
Впрочем, вопрос Spark Databrics vs Apache AirFlow можно рассматривать не как противопоставление этих технологий, а с точки зрения совместного использования.
Благодаря модульной структуре управления пакетами провайдеров, AirFlow отлично справляется с управлением рабочими процессами Databricks в контексте более крупного конвейера данных с использованием пакета провайдера Airflow Databricks. Этот пакет представляет собой набор классов Python, которые позволяют использовать AirFlow для управления заданиями Databricks.
Он предоставляет два оператора:
✔️DatabricksRunNowOperator для запуска существующего задания Databricks;
✔️DatabricksSubmitRunOperator для отправки нового задания в кластер Databricks.
Чтобы использовать пакет провайдера Databricks для AirFlow, необходимо создать соответствующее соединение Databricks в Airflow, указав учетные данные.
После создания подключения можно использовать операторы Databricks для запуска или отправки заданий в кластер.
Такой комбинированный подход позволяет извлечь выгоду из сильных сторон обеих платформ, создавая более мощное решение для оркестрации и обработки данных, чем каждая технология по отдельности.
Вместе они заполняют пробелы друг друга: AirFlow может запускать, планировать и отслеживать задания Databricks, гарантируя, что они выполняются в правильной последовательности и с обработкой любых сбоев. А Databricks может эффективно обрабатывать огромные объемы данных и выполнять их расширенную аналитику.
Таким образом, сочетание технологий обеспечивает бесперебойный сквозной конвейер данных, от приема и преобразования до аналитики и отчетности, с надежностью оркестрации AirFlow и мощью аналитического механизма Databricks.
@BigDataSchool_ru
https://bigdataschool.ru/blog/apache-airflow-vs-spark-databricks.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Apache AirFlow vs Spark в Databricks для оркестрации рабочих процессов
Чем отличается оркестрация ETL-процессов в Databricks и Apache AirFlow: принципы работы, достоинства
#Airflow #статья
5 советов новичку по работе с AirFlow
Apache AirFlow – замечательный инструмент оркестрации конвейеров пакетной обработки данных с довольно низким порогом входа. Простота работы с AirFlow достигается НЕ за счет наглядного GUI, хотя графический веб-интерфейс у этого фреймворка тоже имеется, а благодаря тому, что все его компоненты – это Python-приложения.
Их можно разворачивать по-разному и расширять. Поэтому каждый дата-инженер, знакомый с Python, может написать код конвейера обработки данных в виде набора задач (DAG, Directed Acyclic Graph) и запускать его по расписанию с помощью планировщика Apache AirFlow.
В официальной документации и учебниках, а также различных статьях в т.ч. на нашем сайте, описано множество лучших практик использования этой платформы, которые охватывают разные сценарии и ориентированы на все категории пользователей: от начинающих до профессионалов с глубоким знанием фреймворка.
Однако, при изучении AirFlow новичок сталкивается с довольно ограниченным кругом задач, которые можно решить разными способами. Но на практике начинающие специалисты выбирают самые простые методы. Но даже при их использовании можно столкнуться с рядом проблем. Сначала кратко перечислим их, а затем рассмотрим каждый более подробно и с примерами.
Итак, наши личные топ-5 советов новичку по работе с AirFlow:
1. спроектируйте DAG как последовательность шагов аналогично цепочке действий бизнес-процесса;
2. выберите подходящий способ обмена данными между задачами;
3. определите периодичность и расписание запуска DAG;
4. описывайте каждую задачу и запросы к БД в отдельном файле, а также отдельно описывайте подключения к внешним системам, отделяя это от кода самого DAG;
5. при установке фреймворка обязательно указывайте версию и зависимости.
Подробно каждый пункт разберем по ссылке.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/airflow/5-tips-for-newbs-about-airflow.html
5 советов новичку по работе с AirFlow
Apache AirFlow – замечательный инструмент оркестрации конвейеров пакетной обработки данных с довольно низким порогом входа. Простота работы с AirFlow достигается НЕ за счет наглядного GUI, хотя графический веб-интерфейс у этого фреймворка тоже имеется, а благодаря тому, что все его компоненты – это Python-приложения.
Их можно разворачивать по-разному и расширять. Поэтому каждый дата-инженер, знакомый с Python, может написать код конвейера обработки данных в виде набора задач (DAG, Directed Acyclic Graph) и запускать его по расписанию с помощью планировщика Apache AirFlow.
В официальной документации и учебниках, а также различных статьях в т.ч. на нашем сайте, описано множество лучших практик использования этой платформы, которые охватывают разные сценарии и ориентированы на все категории пользователей: от начинающих до профессионалов с глубоким знанием фреймворка.
Однако, при изучении AirFlow новичок сталкивается с довольно ограниченным кругом задач, которые можно решить разными способами. Но на практике начинающие специалисты выбирают самые простые методы. Но даже при их использовании можно столкнуться с рядом проблем. Сначала кратко перечислим их, а затем рассмотрим каждый более подробно и с примерами.
Итак, наши личные топ-5 советов новичку по работе с AirFlow:
1. спроектируйте DAG как последовательность шагов аналогично цепочке действий бизнес-процесса;
2. выберите подходящий способ обмена данными между задачами;
3. определите периодичность и расписание запуска DAG;
4. описывайте каждую задачу и запросы к БД в отдельном файле, а также отдельно описывайте подключения к внешним системам, отделяя это от кода самого DAG;
5. при установке фреймворка обязательно указывайте версию и зависимости.
Подробно каждый пункт разберем по ссылке.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/airflow/5-tips-for-newbs-about-airflow.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
5 советов начинающему дата-инженеру по AirFlow: личный опыт
Как спроектировать DAG и выбрать способ обмена данными между задачами, где определить по
#Airflow #статьи
Категории и роли пользователей Apache AirFlow
Поскольку основным источником угрозы почти для любой информационной системы являются люди, при разработке методов обеспечения безопасности надо, прежде всего, классифицировать пользователей.
В случае Apache AirFlow можно выделить следующие категории пользователей:
✔️менеджер развертывания – администратор, который отвечает за установку, безопасность и настройку фреймворка;
✔️аутентифицированный пользователь — пользователь интерфейсов, который имеет доступ к веб-GUI и API, а также может взаимодействовать с ними, отправляя соответствующие запросы;
✔️автор DAG — дата-инженер, который разрабатывает DAG и отправляет его в AirFlow, помещая Python-файлы. Код этих py-файлов не проверяется и выполняется в AirFlow без помещения в песочницу. Поэтому авторы DAG могут выполнять произвольный код на рабочих процессах, которые запускаются планировщиком (Celery Workers для Celery Executor, локальные процессы в случае Local Executor, Task Kubernetes POD при Kubernetes Executor), в файловом процессоре DAG, который может выполняться как автономный процесс или быть частью планировщика, и в Triggerer.
Менеджер развертывания может решить ввести дополнительные механизмы контроля, чтобы не допустить выполнения произвольного кода авторами DAG.
Это важно, поскольку выполнение кода DAG происходит в среде, в зависимости от выбранного исполнителя:
✔️если локальный исполнитель и файловый процессор DAG работают как часть планировщика, автор DAG может выполнять произвольный код на компьютере, на котором работает планировщик. Так можно повлиять на сам процесс планировщика и потенциально повлиять на всю установку AirFlow, включая изменение политик всего кластера и изменение конфигурации фреймворка.
✔️в случае Celery Executor автор DAG может выполнять произвольный код на рабочем процессе Celery, что может потенциально повлиять на все задачи, выполняемые там же;
✔️при Kubernetes Executor автор DAG может выполнять произвольный код на запускаемом поде Kubernetes. Каждая задача выполняется в отдельном поде, обеспечивая изоляцию задач.
✔️В случае выполнения отложенных задач, т.е. Triggerer автор DAG может выполнять произвольный код без изоляции задач, использующих отложенные функции друг друга. При этом произвольный код различных задач может выполняться в одном и том же процессе/узле кластера AirFlow.
Файлы DAG не нужны для планировщика и веб-сервера, поэтому менеджер развертывания может изолировать выполнение кода, предоставляемого авторами DAG, особенно в планировщике и веб-сервере.
Так можно гарантировать, что планировщик и веб-сервер даже не имеют доступа к файлам DAG, т.к. это требует развертывания автономного файлового процессора DAG. Рекомендуется, чтобы код автора DAG никогда не мог выполняться в процессе планировщика или веб-сервера. Для этого надо запретить авторам DAG выполнение функций, которые позволяют использовать предварительно зарегистрированный пользовательский код для выполнения в процессе планировщика или веб-сервера.
Также автор DAG не должен иметь доступ к установке или изменению пакетов, установленных на веб-сервере и планировщике.
Поэтому менеджер развертывания должен использовать дополнительные механизмы для предотвращения выполнения авторами DAG произвольного кода. В частности, можно ввести средства для проверки DAG перед его отправкой в AirFlow, чтобы просматривать код перед его развертыванием, статически проверять и добавлять другие способы предотвращения вредоносного кода.
Способ отправки и защиты кода в папку DAG полностью зависит от менеджера развертывания. Сам фреймворк не предоставляет подобных инструментов и механизмов для защиты доступа к папке DAG.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/airflow/airflow-authentication-and-authorization.html
Категории и роли пользователей Apache AirFlow
Поскольку основным источником угрозы почти для любой информационной системы являются люди, при разработке методов обеспечения безопасности надо, прежде всего, классифицировать пользователей.
В случае Apache AirFlow можно выделить следующие категории пользователей:
✔️менеджер развертывания – администратор, который отвечает за установку, безопасность и настройку фреймворка;
✔️аутентифицированный пользователь — пользователь интерфейсов, который имеет доступ к веб-GUI и API, а также может взаимодействовать с ними, отправляя соответствующие запросы;
✔️автор DAG — дата-инженер, который разрабатывает DAG и отправляет его в AirFlow, помещая Python-файлы. Код этих py-файлов не проверяется и выполняется в AirFlow без помещения в песочницу. Поэтому авторы DAG могут выполнять произвольный код на рабочих процессах, которые запускаются планировщиком (Celery Workers для Celery Executor, локальные процессы в случае Local Executor, Task Kubernetes POD при Kubernetes Executor), в файловом процессоре DAG, который может выполняться как автономный процесс или быть частью планировщика, и в Triggerer.
Менеджер развертывания может решить ввести дополнительные механизмы контроля, чтобы не допустить выполнения произвольного кода авторами DAG.
Это важно, поскольку выполнение кода DAG происходит в среде, в зависимости от выбранного исполнителя:
✔️если локальный исполнитель и файловый процессор DAG работают как часть планировщика, автор DAG может выполнять произвольный код на компьютере, на котором работает планировщик. Так можно повлиять на сам процесс планировщика и потенциально повлиять на всю установку AirFlow, включая изменение политик всего кластера и изменение конфигурации фреймворка.
✔️в случае Celery Executor автор DAG может выполнять произвольный код на рабочем процессе Celery, что может потенциально повлиять на все задачи, выполняемые там же;
✔️при Kubernetes Executor автор DAG может выполнять произвольный код на запускаемом поде Kubernetes. Каждая задача выполняется в отдельном поде, обеспечивая изоляцию задач.
✔️В случае выполнения отложенных задач, т.е. Triggerer автор DAG может выполнять произвольный код без изоляции задач, использующих отложенные функции друг друга. При этом произвольный код различных задач может выполняться в одном и том же процессе/узле кластера AirFlow.
Файлы DAG не нужны для планировщика и веб-сервера, поэтому менеджер развертывания может изолировать выполнение кода, предоставляемого авторами DAG, особенно в планировщике и веб-сервере.
Так можно гарантировать, что планировщик и веб-сервер даже не имеют доступа к файлам DAG, т.к. это требует развертывания автономного файлового процессора DAG. Рекомендуется, чтобы код автора DAG никогда не мог выполняться в процессе планировщика или веб-сервера. Для этого надо запретить авторам DAG выполнение функций, которые позволяют использовать предварительно зарегистрированный пользовательский код для выполнения в процессе планировщика или веб-сервера.
Также автор DAG не должен иметь доступ к установке или изменению пакетов, установленных на веб-сервере и планировщике.
Поэтому менеджер развертывания должен использовать дополнительные механизмы для предотвращения выполнения авторами DAG произвольного кода. В частности, можно ввести средства для проверки DAG перед его отправкой в AirFlow, чтобы просматривать код перед его развертыванием, статически проверять и добавлять другие способы предотвращения вредоносного кода.
Способ отправки и защиты кода в папку DAG полностью зависит от менеджера развертывания. Сам фреймворк не предоставляет подобных инструментов и механизмов для защиты доступа к папке DAG.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/airflow/airflow-authentication-and-authorization.html
Курсы Big Data, Hadoop, Arenadata, Kafka и Spark
Аутентификация и авторизация пользователей в Apache AirFlow
Зачем ограничивать доступ к папке с DAG и как это сделать: категории и роли пользователей
#Airflow #статьи
Краткий ликбез по WSL и Docker для любителей Windows
Обычно я всегда запускала веб-сервер Apache AirFlow в интерактивной среде Google Colab, которая по своей сути представляет собой виртуальную машину с Unix-подобной ОС. А, чтобы получить доступ к localhost, использовала утилиту тунелирования ngrok.
С одной стороны, это было удобно, поскольку каждая Colab-среда работает изолировано: можно было не связываться с виртуальными Python-средами, чтобы избежать «ада зависимостей», когда одна библиотека конфликтует с другой, достаточно просто закрыть ненужную Colab-среду.
Однако, запускать приложения AirFlow в режиме standalone удобнее всего на собственной локальной машине, чтобы избежать задержек и других недостатков Colab. Поэтому решила запускать веб-серверы в своей собственной среде, независимо от внешних сервисов.
Избежать конфликта зависимостей, свойственных AirFlow, при запуске его на локальной машине с операционной системой Windows, можно 2-мя способами:
1️⃣использовать виртуальные среды Python;
2️⃣сделать контейнер, упаковав в него приложение со всеми зависимостями.
Далее рассмотрим именно 2-ой способ.
Чтобы запустить контейнер на операционной системе Windows, надо установить WSL - подсистему Windows для Linux, которая позволяет запускать среду Linux на Windows без отдельной виртуальной машины. С WSL можно запускать Linux в оболочке Bash с выбранным дистрибутивом, чтобы работать с CLI-интерфейсом и приложениями Linux.
В отличие от полноценной виртуальной машины, WSL требует меньше ресурсов (ЦП, памяти и хранилища), а также может обращаться к файлам Windows в Linux. Обеспечить изоляцию приложений, чтобы избежать конфликтов с зависимостями, свойственных Python-разработке, можно с помощью контейнеризации, что также хорошо поддерживается в WSL.
Сегодня наиболее популярным инструментом контейнеризации является Docker – он позволяет упаковать приложение со всем его окружением и зависимостями в контейнер, который можно запустить на любой Linux-подобной системе.
Эта платформа дает возможность отделить приложения от инфраструктуры, перезапуская их по мере необходимости. Изоляцию обеспечивает запуск каждого контейнера в отдельном процессе. Docker-образ можно развернуть несколько раз, получив независимые контейнеры с работающими приложениями.
Docker-контейнер — это запущенный и изолированный образ с возможностью временного сохранения данных, которые записываются в его верхний слой и при удалении контейнера удаляются.
Далее читайте: Создание и запуск docker-контейнера Apache AirFlow.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/airflow/airflow-docker-container-in-wsl-on-windows.html
Краткий ликбез по WSL и Docker для любителей Windows
Обычно я всегда запускала веб-сервер Apache AirFlow в интерактивной среде Google Colab, которая по своей сути представляет собой виртуальную машину с Unix-подобной ОС. А, чтобы получить доступ к localhost, использовала утилиту тунелирования ngrok.
С одной стороны, это было удобно, поскольку каждая Colab-среда работает изолировано: можно было не связываться с виртуальными Python-средами, чтобы избежать «ада зависимостей», когда одна библиотека конфликтует с другой, достаточно просто закрыть ненужную Colab-среду.
Однако, запускать приложения AirFlow в режиме standalone удобнее всего на собственной локальной машине, чтобы избежать задержек и других недостатков Colab. Поэтому решила запускать веб-серверы в своей собственной среде, независимо от внешних сервисов.
Избежать конфликта зависимостей, свойственных AirFlow, при запуске его на локальной машине с операционной системой Windows, можно 2-мя способами:
1️⃣использовать виртуальные среды Python;
2️⃣сделать контейнер, упаковав в него приложение со всеми зависимостями.
Далее рассмотрим именно 2-ой способ.
Чтобы запустить контейнер на операционной системе Windows, надо установить WSL - подсистему Windows для Linux, которая позволяет запускать среду Linux на Windows без отдельной виртуальной машины. С WSL можно запускать Linux в оболочке Bash с выбранным дистрибутивом, чтобы работать с CLI-интерфейсом и приложениями Linux.
В отличие от полноценной виртуальной машины, WSL требует меньше ресурсов (ЦП, памяти и хранилища), а также может обращаться к файлам Windows в Linux. Обеспечить изоляцию приложений, чтобы избежать конфликтов с зависимостями, свойственных Python-разработке, можно с помощью контейнеризации, что также хорошо поддерживается в WSL.
Сегодня наиболее популярным инструментом контейнеризации является Docker – он позволяет упаковать приложение со всем его окружением и зависимостями в контейнер, который можно запустить на любой Linux-подобной системе.
Эта платформа дает возможность отделить приложения от инфраструктуры, перезапуская их по мере необходимости. Изоляцию обеспечивает запуск каждого контейнера в отдельном процессе. Docker-образ можно развернуть несколько раз, получив независимые контейнеры с работающими приложениями.
Docker-контейнер — это запущенный и изолированный образ с возможностью временного сохранения данных, которые записываются в его верхний слой и при удалении контейнера удаляются.
Далее читайте: Создание и запуск docker-контейнера Apache AirFlow.
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/airflow/airflow-docker-container-in-wsl-on-windows.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Как создать и запустить docker-контейнер Apache AirFlow на Windows
Что такое WSL, Docker и как запустить веб-сервер Apache AirFlow в контейнере на локальной машине в Ub
#AirFlow #статьи
Еще раз про хуки и соединения Apache AirFlow
Доступность системы является ключевым свойством информационной безопасности. Проверить, что веб-сервис доступен, можно по статусу HTTP-ответа на GET-запрос. Чтобы делать такую проверку периодически, т.е. по расписанию, можно использовать Apache AirFlow. Этот пакетный ETL-оркестратор отлично подходит для подобных сценариев. Для синхронного взаимодействия с HTTP-серверами в AirFlow есть класс HttpHook, а для асинхронного – HttpAsyncHook.
Вообще хук (hook) в AirFlow — это высокоуровневый интерфейс к внешней платформе, который позволяет быстро общаться со сторонними системами без необходимости писать низкоуровневый код, который обращается к их API или использует специальные библиотеки. Хуки также являются строительными блоками, из которых строятся Операторы.
Хуки в AirFlow интегрируются с подключениями (Connection) для сбора учетных данных – набор параметров: имя пользователя, пароль и хост, а также тип внешней системы.
Все эти параметры можно настроить программно или в пользовательском интерфейсе фреймворка.
Например, я хочу проверять доступность нашего сайта, т.е. именно он будет выступать в роли внешней системы. Для этого надо задать его адрес в настройках подключения, чтобы использовать методы http-хуков.
Поскольку теперь я запускаю docker-контейнер с Apache AirFlow в режиме standalone на своей локальной машине, чтобы выйти в веб-интерфейс, мне достаточно обратиться к localhost и порту, на котором развернуто это приложение.
Добавить новое подключение к внешней системе надо в разделе Admin/Connections.
Внешней системой является открытый веб-сайт, а не база данных и не частное приложение, поэтому указывать порт, логин и пароль нет необходимости. Достаточно только задать имя подключения, которое будет использоваться в коде Python-оператора, тип соединения и хост.
Далее рассмотрим пример реализации: код задачи и DAG
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/airflow/airflow-hook-http-service-example.html
Еще раз про хуки и соединения Apache AirFlow
Доступность системы является ключевым свойством информационной безопасности. Проверить, что веб-сервис доступен, можно по статусу HTTP-ответа на GET-запрос. Чтобы делать такую проверку периодически, т.е. по расписанию, можно использовать Apache AirFlow. Этот пакетный ETL-оркестратор отлично подходит для подобных сценариев. Для синхронного взаимодействия с HTTP-серверами в AirFlow есть класс HttpHook, а для асинхронного – HttpAsyncHook.
Вообще хук (hook) в AirFlow — это высокоуровневый интерфейс к внешней платформе, который позволяет быстро общаться со сторонними системами без необходимости писать низкоуровневый код, который обращается к их API или использует специальные библиотеки. Хуки также являются строительными блоками, из которых строятся Операторы.
Хуки в AirFlow интегрируются с подключениями (Connection) для сбора учетных данных – набор параметров: имя пользователя, пароль и хост, а также тип внешней системы.
Все эти параметры можно настроить программно или в пользовательском интерфейсе фреймворка.
Например, я хочу проверять доступность нашего сайта, т.е. именно он будет выступать в роли внешней системы. Для этого надо задать его адрес в настройках подключения, чтобы использовать методы http-хуков.
Поскольку теперь я запускаю docker-контейнер с Apache AirFlow в режиме standalone на своей локальной машине, чтобы выйти в веб-интерфейс, мне достаточно обратиться к localhost и порту, на котором развернуто это приложение.
Добавить новое подключение к внешней системе надо в разделе Admin/Connections.
Внешней системой является открытый веб-сайт, а не база данных и не частное приложение, поэтому указывать порт, логин и пароль нет необходимости. Достаточно только задать имя подключения, которое будет использоваться в коде Python-оператора, тип соединения и хост.
Далее рассмотрим пример реализации: код задачи и DAG
@BigDataSchool_ru
https://bigdataschool.ru/blog/news/airflow/airflow-hook-http-service-example.html
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Тестирование доступности веб-сайта с помощью http-хуков Apache AirFlow
Сегодня я покажу, как проверить доступность веб-сайта с помощью http-хука в Apache AirFlow и отпр
#Airflow
🔥Пользовательские бэкенды для XCom и другие новинки Apache AirFlow 2.9
8 апреля 2024 года вышел очередной релиз Apache AirFlow. Он содержит более 35 интересных новых функций, более 70 улучшений и более 30 исправлений ошибок. Одним из наиболее значимых изменений стала возможность подключать пользовательские бэкенды для объектов XCom, которые используются для передачи данных между задачами DAG. Хотя пользовательское хранилище объектов XCom было реализовано как экспериментальная еще в прошлом выпуске Airflow 2.8. Это позволяет взаимодействовать с файлами в локальной файловой системе или облачными объектными хранилищами (AWS S3, Google Cloud Storage и Azure Blob Storage) с помощью одного и того же кода вместо использования множества операторов. А в релизе 2.9 можно использовать объектное хранилище в качестве бэкэнда для объектов XCom, обеспечивая масштабируемую и эффективную связь между задачами. Это существенно расширяет границы применения простого, но достаточно эффективного, механизма обмена данными между разными задачами. Теперь можно обращаться к внешним сервисам вместо традиционного хранилище XCom на основе базы данных метаданных.
Таким образом, теперь XCom потенциально можно использовать и для большого объема передаваемой информации, поскольку ее хранение не будет потреблять внутренний ресурс фреймворка. Однако, стоит помнить, что любое обращение к внешним сервисам имеет определенные накладные расходы, связанные с установкой соединения и передачей данных по сети.
За настройку бэкенда отвечает соответствующая конфигурация:
AIRFLOW__CORE__XCOM_BACKEND="airflow.providers.common.io.xcom.backend.XComObjectStoreBackend"
Указать для хранения XCom-объектов внешнюю систему надо явно, используя следующие настройки, например, для работы с AWS S3 надо задать не только путь, но и пороговое значение в байтах, при превышении которого будет использоваться внешнее хранилище:
AIRFLOW__COMMON_IO__XCOM_OBJECTSTORAGE_PATH="s3://my_aws_conn@my-bucket/xcom"
AIRFLOW__COMMON_IO__XCOM_OBJECTSTORAGE_THRESHOLD="1000"
Также можно установить поддерживаемые методы сжатия, чтобы сжимать данные перед их сохранением в объектном хранилище и более эффективно утилизировать этот ресурс:
AIRFLOW__COMMON_IO__XCOM_OBJECTSTORAGE_COMPRESSION="zip"
Всего релиз 2.9 содержит более 35 интересных новых функций, более 70 улучшений и более 30 исправлений ошибок, о самых интересных из них читайте в нашем блоге.🌞
🔥Пользовательские бэкенды для XCom и другие новинки Apache AirFlow 2.9
8 апреля 2024 года вышел очередной релиз Apache AirFlow. Он содержит более 35 интересных новых функций, более 70 улучшений и более 30 исправлений ошибок. Одним из наиболее значимых изменений стала возможность подключать пользовательские бэкенды для объектов XCom, которые используются для передачи данных между задачами DAG. Хотя пользовательское хранилище объектов XCom было реализовано как экспериментальная еще в прошлом выпуске Airflow 2.8. Это позволяет взаимодействовать с файлами в локальной файловой системе или облачными объектными хранилищами (AWS S3, Google Cloud Storage и Azure Blob Storage) с помощью одного и того же кода вместо использования множества операторов. А в релизе 2.9 можно использовать объектное хранилище в качестве бэкэнда для объектов XCom, обеспечивая масштабируемую и эффективную связь между задачами. Это существенно расширяет границы применения простого, но достаточно эффективного, механизма обмена данными между разными задачами. Теперь можно обращаться к внешним сервисам вместо традиционного хранилище XCom на основе базы данных метаданных.
Таким образом, теперь XCom потенциально можно использовать и для большого объема передаваемой информации, поскольку ее хранение не будет потреблять внутренний ресурс фреймворка. Однако, стоит помнить, что любое обращение к внешним сервисам имеет определенные накладные расходы, связанные с установкой соединения и передачей данных по сети.
За настройку бэкенда отвечает соответствующая конфигурация:
AIRFLOW__CORE__XCOM_BACKEND="airflow.providers.common.io.xcom.backend.XComObjectStoreBackend"
Указать для хранения XCom-объектов внешнюю систему надо явно, используя следующие настройки, например, для работы с AWS S3 надо задать не только путь, но и пороговое значение в байтах, при превышении которого будет использоваться внешнее хранилище:
AIRFLOW__COMMON_IO__XCOM_OBJECTSTORAGE_PATH="s3://my_aws_conn@my-bucket/xcom"
AIRFLOW__COMMON_IO__XCOM_OBJECTSTORAGE_THRESHOLD="1000"
Также можно установить поддерживаемые методы сжатия, чтобы сжимать данные перед их сохранением в объектном хранилище и более эффективно утилизировать этот ресурс:
AIRFLOW__COMMON_IO__XCOM_OBJECTSTORAGE_COMPRESSION="zip"
Всего релиз 2.9 содержит более 35 интересных новых функций, более 70 улучшений и более 30 исправлений ошибок, о самых интересных из них читайте в нашем блоге.🌞
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
Apache AirFlow 2.9: обзор свежего релиза
8 апреля 2024 года вышел очередной релиз Apache AirFlow. Знакомимся с ключевыми новинками выпуск
#ClickHouse #AirFlow #интеграция
Интеграция ClickHouse с Apache AirFlow
Чем полезна интеграция ClickHouse с Apache Airflow и как ее реализовать: операторы в пакете провайдера и плагине на основе Python-драйвера. Принципы работы и примеры использования.
2 способа интеграции ClickHouse с AirFlow
Продолжая разговор про интеграцию ClickHouse с другими системами, сегодня рассмотрим, как связать эту колоночную СУБД с мощным ETL-движком Apache AirFlow. Полная статья: https://bigdataschool.ru/blog/news/airflow/clickhouse-airflow-integration.html
Курсы: https://bigdataschool.ru/courses/clickhouse
https://bigdataschool.ru/courses/data-flow-with-apache-airflow
https://bigdataschool.ru/courses/airflow-on-yandex-managed-service
Наш сайт: https://bigdataschool.ru/
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Интеграция ClickHouse с Apache AirFlow
Чем полезна интеграция ClickHouse с Apache Airflow и как ее реализовать: операторы в пакете провайдера и плагине на основе Python-драйвера. Принципы работы и примеры использования.
2 способа интеграции ClickHouse с AirFlow
Продолжая разговор про интеграцию ClickHouse с другими системами, сегодня рассмотрим, как связать эту колоночную СУБД с мощным ETL-движком Apache AirFlow. Полная статья: https://bigdataschool.ru/blog/news/airflow/clickhouse-airflow-integration.html
Курсы: https://bigdataschool.ru/courses/clickhouse
https://bigdataschool.ru/courses/data-flow-with-apache-airflow
https://bigdataschool.ru/courses/airflow-on-yandex-managed-service
Наш сайт: https://bigdataschool.ru/
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
#AirFlow #DAG #логфайл
5 типовых ошибок в Apache AirFlow и как их исправить: советы дата-инженеру
Почему планировщик Apache AirFlow чувствителен к всплескам рабочих нагрузок, из-за чего тормозит база данных метаданных, как исправить проблемы с файлом DAG, лог-файлами и внешними ресурсами: разбираемся с ошибками пакетного оркестратора и способами их решения.
Проблемы с планировщиком
Хотя Apache AirFlow позиционируется как довольно простой фреймворк для оркестрации пакетных процессов с низком порогом входа.
Статья: https://bigdataschool.ru/blog/news/airflow/how-to-solve-typical-problems-with-airflow.html
Курсы: https://bigdataschool.ru/courses/data-flow-with-apache-airflow https://bigdataschool.ru/courses/airflow-on-yandex-managed-service
Наш сайт: https://bigdataschool.ru
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
5 типовых ошибок в Apache AirFlow и как их исправить: советы дата-инженеру
Почему планировщик Apache AirFlow чувствителен к всплескам рабочих нагрузок, из-за чего тормозит база данных метаданных, как исправить проблемы с файлом DAG, лог-файлами и внешними ресурсами: разбираемся с ошибками пакетного оркестратора и способами их решения.
Проблемы с планировщиком
Хотя Apache AirFlow позиционируется как довольно простой фреймворк для оркестрации пакетных процессов с низком порогом входа.
Статья: https://bigdataschool.ru/blog/news/airflow/how-to-solve-typical-problems-with-airflow.html
Курсы: https://bigdataschool.ru/courses/data-flow-with-apache-airflow https://bigdataschool.ru/courses/airflow-on-yandex-managed-service
Наш сайт: https://bigdataschool.ru
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Курсы Big Data,Arenadata,Greenplum, Kafka и Spark
5 типовых ошибок в Apache AirFlow и как их исправить: советы дата-инженеру
Почему планировщик Apache AirFlow чувствителен к всплескам рабочих нагрузок, из-за чего тормо
#AirFlow #фреймворки
Контекст в Apache AirFlow
Для чего нужен контекст задачи Apache AirFlow, что он собой представляет, какие включает объекты, как получить к ним доступ и чем они полезны дата-инженеру.
Что такое контекст задачи Apache AirFlow
В разработке ПО контекстом называется среда, в которой существует объект. Это понятие очень важно при использовании специализированных фреймворков.
Полная статья: https://bigdataschool.ru/blog/news/airflow/airflow-context.html
Курсы: https://bigdataschool.ru/courses/data-flow-with-apache-airflow https://bigdataschool.ru/courses/airflow-on-yandex-managed-service
Наш сайт: https://bigdataschool.ru
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Контекст в Apache AirFlow
Для чего нужен контекст задачи Apache AirFlow, что он собой представляет, какие включает объекты, как получить к ним доступ и чем они полезны дата-инженеру.
Что такое контекст задачи Apache AirFlow
В разработке ПО контекстом называется среда, в которой существует объект. Это понятие очень важно при использовании специализированных фреймворков.
Полная статья: https://bigdataschool.ru/blog/news/airflow/airflow-context.html
Курсы: https://bigdataschool.ru/courses/data-flow-with-apache-airflow https://bigdataschool.ru/courses/airflow-on-yandex-managed-service
Наш сайт: https://bigdataschool.ru
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
#AirFlow #DAG #2.10 #обновление
Apache AirFlow 2.10: что нового?
24 августа вышел новый релиз Apache AirFlow. Знакомимся с новинками версии 2.10: гибкая настройка исполнителей для всей среды, конкретного DAG и отдельных задач, а также динамическое планирование набора данных и улучшения GUI.
Гибкая настройка исполнителей
Одной из самых главных новинок Apache AirFlow 2.10 стала конфигурация гибридного исполнения, позволяющая использовать несколько исполнителей одновременно в рамках одной среды. Раньше среда Airflow ограничивалась одним исполнителем, который является свойством конфигурации планировщика, управляющим запуском запланированных рабочих процессов.
Статья
Курсы: AIRF YARF
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"
Apache AirFlow 2.10: что нового?
24 августа вышел новый релиз Apache AirFlow. Знакомимся с новинками версии 2.10: гибкая настройка исполнителей для всей среды, конкретного DAG и отдельных задач, а также динамическое планирование набора данных и улучшения GUI.
Гибкая настройка исполнителей
Одной из самых главных новинок Apache AirFlow 2.10 стала конфигурация гибридного исполнения, позволяющая использовать несколько исполнителей одновременно в рамках одной среды. Раньше среда Airflow ограничивалась одним исполнителем, который является свойством конфигурации планировщика, управляющим запуском запланированных рабочих процессов.
Статья
Курсы: AIRF YARF
Наш сайт
Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"