Версия сайта для слабовидящих
Чем отличается оркестрация ETL-процессов в Databricks и Apache AirFlow: принципы работы, достоинства и недостатки, а также что выбирать дата-инженеру для решения практических задач.
Apache AirFlow vs Spark в Databricks: сходства и отличия
Облачная платформа Databricks, основанная на Apache Spark, предлагает пользователям единую среду для создания, запуска и управления различными рабочими процессами, от анализа больших данных до ETL и машинного обучения. Apache AirFlow представляет собой Python-фреймворк с открытым исходным кодом для программного создания, планирования и мониторинга пакетных заданий. Чтобы понять, чем отличаются эти инструменты с точки зрения дата-инженерии, сперва кратко сравним их по следующим критериям в таблице, а затем рассмотрим особенно интересные отличия более подробно.
|
Критерий |
Spark в Databricks |
Apache AirFlow |
|
Назначение |
Анализ и обработка больших данных с использованием оптимизированного Apache Spark |
Оркестрация и планирование рабочего процесса |
|
Языковая поддержка |
Python, SQL, PySpark, Spark SQL |
|
|
Управление зависимостями |
Необходимо управлять зависимостями для каждой задачи индивидуально, нет системы управления зависимостями среды. |
Управляйте зависимостями на уровне среды, импортируйте необходимые библиотеки один раз на уровне DAG. |
|
Управление рабочим процессом |
Базовое выполнение рабочего процесса с использованием сторонних инструментов для планирования и сложных зависимостей задач |
Динамическое создание рабочих процессов, зависимости задач и расширенное планирование с ветвлением и повторными попытками |
|
Вычислительная мощность |
Специально разработан и оптимизирован для крупномасштабных операций высокопроизводительной обработки данных |
Больше подходит для организации задач, а не для выполнения сложных вычислительных операций в распределенном режиме над большими объемами данных |
|
Поддержка Spark |
Встроенная поддержка Spark и выполнение заданий с высокой эффективностью |
Необходимо подключение к внешнему кластеру Spark для выполнения заданий |
|
Подключение к внешним сервисам |
Нет системы управления соединениями, необходимо устанавливать их вручную и настраивать профиль Spark для взаимодействия с ними в каждом блокноте для задачи, которая их использует |
Можно создавать любые подключения в пользовательском интерфейсе или программно, чтобы использовать их, ссылаясь на объекты соединений |
|
Интеграции с хранилищами данных и внешними сервисами |
Интегрируется с облачными хранилищами объектов и ODBC/JDBC-базами данных |
Интегрируется с сотнями провайдеров различных сервисов и хранилищ данных |
Управление задачами и зависимостями
Ключевой концепцией AirFlow является DAG – Направленный ациклический граф, состояний из задач – операторов, описанных на Python. Будучи open-source продуктом, AirFlow постоянно развивается. Например, если добавить метод expand() к каждой функции DAG, можно создавать динамические задачи AirFlow для параллельной обработки данных. Такое динамическое сопоставление задач, о котором мы писали здесь, создает один экземпляр задачи для каждого входа. Таким образом, вместо того последовательного выполнения задач, они будут выполняться параллельно, что сократит время выполнения ETL-конвейера и улучшит видимость процесса для каждого набора данных. В Databricks вместо динамического сопоставления задач для создания нескольких экземпляров задач для каждого набора данных, приходиться использовать циклы for. Хотя это позволяет добиться цели, данные каждого набора обрабатываются последовательно, а не параллельно, что увеличивает время выполнения конвейера.
Поскольку Databricks является готовым продуктом конкретного поставщика, он имеет определенные ограничения. В частности, чтобы создать рабочий процесс Databricks, дата-инженеру придется создать отдельные блокноты для каждой задачи в рабочем процессе, а не использовать один скрипт. В отличие от AirFlow, рабочие процессы Databricks не поддерживают зависимости задач в одном блокноте. Чтобы исключить ситуацию нарушения хода выполнения ETL-конвейера Databricks, когда нижестоящая задача запустится до завершения выполнения вышестоящей задачи, дата-инженеру следует описать каждую задачу в отдельном блокноте. Затем можно установить зависимости между задачами, чтобы определить порядок их запуска.
После того, как все задачи были собраны в отдельные блокноты, их можно добавить в рабочий процесс Databricks, чтобы организовать полноценный конвейер данных. Дата-инженер делает это в GUI платформы Databricks, сперва создавая рабочий процесс, а потом добавляя в него каждую задачу вручную. При этом надо задать имя задачи и путь к блокноту, где она описана. Каждая задача автоматически связывается с предыдущей созданной задачей, поэтому нет необходимости явно задавать какие-либо зависимости. После создания всех задач можно запустить рабочий процесс, чтобы убедиться и отслеживать его в пользовательском интерфейсе Databricks Runs.
Благодаря упрощенному взаимодействию между задачами, еще одним преимуществом Apache AirFlow в сравнении с Databricks является отсутствие необходимости в сохранении промежуточных данных. Databricks не позволяет напрямую передавать наборы данных между задачами, т.е. в начале каждой задачи надо считывать данные из хранилища файлов Databricks и в конце сохранять их обратно.
Наконец, в Databricks нет системы управления зависимостями среды и необходимо управлять зависимостями для каждой задачи индивидуально. А в Apache AirFlow есть возможность управлять зависимостями на уровне среды, импортируя необходимые библиотеки один раз на уровне всего DAG.
Сравнение вычислительной мощности
С точки зрения вычислительной мощности Apache Airflow уступает Spark в Databricks, поскольку изначально Spark был разработан как распределенный движок для крупномасштабных операций высокопроизводительной обработки данных. Spark выполняет операции MapReduce в оперативной памяти и имеет множество специальных оптимизаций для их ускоренного проведения в кластерной среде. А Apache AirFlow является классическим оркестратором и больше подходит для организации задач, а не для выполнения сложных вычислительных операций в распределенном режиме над большими объемами данных.
Будучи основанным на Apache Spark, фреймворк Databricks оптимизирует процесс создания, запуска и управления рабочими процессами, ориентированными на этот вычислительный движок. Такая унификация полезна для пользователей, которым нужна согласованная интегрированная среда для управления Spark-приложениями. Однако, взаимодействие с другими службами немного неуклюже, поскольку все данные должны проходить через кластер Spark. Необходимо настроить кластер Databricks для каждой отдельной задачи в рабочем процессе. Открытый исходный код Apache AirFlow дает более широкие возможности настройки, позволяя создавать, планировать и контролировать рабочие процессы программно на Python. Это обеспечивает универсальность и гибкость, а также легко интегрируется с широким спектром инструментов в экосистеме. Однако вместе с гибкостью возникает необходимость в более практическом управлении, требующем от пользователей импорта необходимых пакетов и обработки зависимостей, а также владения Python.
Таким образом, выбор между Databricks и AirFlow для организации ETL-конвейеров зависит от типа выполняемых рабочих нагрузок. Для рабочих высоконагруженных процессов на основе Spark со сложной вычислительной логикой и большими объемами данных, Databricks будет отличным выбором. Но если конвейеры данных включают в себя несколько разных систем, работающих вместе, стоит присмотреться к AirFlow, что мы и рассмотрим далее.
Интеграция с внешними сервисами и хранилищами данных
Теперь рассмотрим, как AirFlow и Databricks подключаются к внешним сервисам. Хотя Databricks имеет набор коннекторов для внешних служб и пользовательский интерфейс для приема данных, у него нет интерфейса для экспорта данных или управления перемещением данных между внешними системами. Кроме того, поскольку Databricks работает в кластере Spark, дата-инженеру придется настроить кластер Spark так, чтобы удаленно взаимодействовать с внешними хранилищами и сервисами, например, AWS S3, Snowflake и пр. Однако, даже после настройки Databricks предполагает выполнение промежуточных операций. Например, вместо того, чтобы просто запустить операцию копирования непосредственно из S3 в Snowflake, Databricks требует фактической загрузки данных обратно из S3 и создания датафрейма Spark. И лишь после этого можно приступить к загрузке данных из Spark в Snowflake. Это существенно увеличивает время выполнения ETL-конвейера, особенно в случае последовательного выполнения подобной задачи для нескольких наборов данных.
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.
Узнайте больше про использование Apache AirFlow для дата-инженерии и аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
