Предложение фреймворка для Apache Airflow
Это вторая статья о том, почему инженеры по обработке данных не должны создавать группы DAG для Airflow. В этой новой статье мы собираемся представить предложение фреймворка для Apache Airflow.
Эта статья призвана пролить свет на то, как создание фреймворка может помочь вам решить некоторые проблемы, связанные с написанием DAG.
В этой новой статье я сделаю краткий обзор первой части. Так что читать его не обязательно. Тем не менее, вам следует подумать о том, чтобы прочитать его, если вы хотите более подробное объяснение того, что я собираюсь затронуть в этом.
Почему Data Engineer не должен писать группы DAG
Как я уже упоминал в первой статье, работа инженера по данным - не писать ETL. Работа инженера по обработке данных - писать надежный, масштабируемый и поддерживаемый код.
Инженеры по обработке данных не должны писать группы доступности базы данных ради создания групп доступности базы данных. Навыки инженеров данных можно будет лучше использовать, если они сосредоточатся на обобщении и абстрагировании, а не на написании простых групп DAG.
При написании DAG есть две основные проблемы:
- Это повторяющийся процесс. Это нарушает принцип DRY (Не повторяйся). Если не сделать это должным образом, вы получите много дублированного и неподдерживаемого кода.
- Это может быть сложно сделать тем, у кого нет ноу-хау. Когда это происходит, инженеры по обработке данных становятся теми, кто пишет DAG для других людей. Это не обязательно плохо, но мы можем добиться большего.
Я считаю, что есть несколько принципов, которым вы можете следовать, чтобы смягчить эти две основные проблемы:
- По возможности используйте динамические группы DAG для создания ваших групп DAG. Это хороший способ придерживаться принципа СУХОЙ.
- Улучшите способ создания динамических групп DAG с помощью объектно-ориентированного программирования (ООП) и шаблонов проектирования. Если все сделано правильно, это может улучшить ремонтопригодность вашего кода.
- Создавайте интерфейсы, позволяющие людям взаимодействовать со своими группами DAG. Ваша задача как инженера по обработке данных - не писать DAG для других людей. Ваша задача - дать людям возможность писать собственные группы DAG и взаимодействовать с ними.
Эти принципы помогли нам решить указанные выше проблемы. Мы использовали их для создания инфраструктуры, которая находится на ранней стадии. Но это оказалось полезным.
В следующем разделе мы собираемся представить наше предложение по структуре, известное как Castor -, что на испанском означает beaver. Мы надеемся, что этот фреймворк может пролить свет на то, как мы можем двигаться дальше, чтобы лучше использовать Apache Airflow.
Эта структура позволяет определять конвейеры данных с использованием более декларативного подхода. Вместо императивного подхода, обеспечивающего соблюдение путем написания DAG. Мы уверены, что конвейеры декларативных данных - это будущее конвейеров данных.
Castor: фреймворк для Apache Airflow
Представьте, что написать DAG будет так же просто, как написать простой файл конфигурации. Этот файл конфигурации сделает все за вас. Вам нужно только указать, что вы хотите сделать, а все остальное сделает что-то еще.
Это то, чего мы пытались достичь, когда писали наш фреймворк, Castor. Мы хотели упростить написание DAG, чтобы это было так же просто, как написать файл конфигурации. Но мы также хотели решить проблемы, уже изложенные в этих двух статьях.
Для этого мы объединили динамические группы DAG, ООП и шаблоны проектирования программного обеспечения и создали Castor. Вот некоторые из преимуществ, которые мы получили, создав и используя этот фреймворк:
- Это помогло нам стандартизировать способ работы с нашими группами DAG. Итак, все в команде находятся на одной волне. Передача осуществляется легко, так как все знают структуру. Когда вам нужно передать процесс кому-то другому, вы передаете файлы конфигурации и все. Файлы конфигурации легче читать и понимать, чем код DAG.
- Почти все группы DAG создаются из одних и тех же строк кода. Итак, если мы хотим внести изменения, мы делаем это в одном файле, и это применимо к остальной части проекта. Нам не нужно делать одно и то же изменение в 10 или 20 файлах.
- Мы использовали шаблоны проектирования, чтобы добиться такого уровня разделения кода, который позволяет нам чувствовать себя в безопасности. Теперь вводить новые функции стало проще. Так же, как и осуждая их.
- Поскольку написать DAG так же просто, как написать файл конфигурации, это может сделать практически любой. Таким образом, мы даем возможность аналитикам данных и специалистам по обработке данных писать свои собственные группы доступности базы данных, не прибегая к стилю программирования Airflow.
Наша структура состоит из 5 компонентов: файлы конфигурации, фабрика DAG, создатель задач, стратегии задач и фабрика операторов.
Файлы конфигурации
Файлы конфигурации - это то, как создаются группы DAG. Вы в основном указываете, что хотите в своей группе DAG, и все.
Возьмем, к примеру, простой DAG с 5 задачами. Две из этих двух задач - DummyOperators, благодаря которым группа DAG выглядит красиво с задачей start и задачей end. Остальные 3 задачи - это просто PythonOperators, делающие все, что вы хотите - извлечение данных, преобразование данных и т. Д. Вот как это выглядит в пользовательском интерфейсе Airflow.
Если вы хотите использовать традиционный подход, вы пишете код для группы DAG, и все. Но если вы используете более декларативный подход, то вот как это выглядит при использовании файла конфигурации YAML:
Интерфейс принимает файл конфигурации и передает его другим компонентам платформы. Такие компоненты создают из файла DAG по вашему запросу.
Завод DAG
DAG Factory - это просто реализация паттерна Factory Method.
Фабрика DAG отвечает не только за создание групп DAG. Но чтобы убедиться, что задачи групп DAG правильно созданы в соответствии с зависимостями, объявленными в файле конфигурации. Для этого он использует Task Creator.
Вот так выглядит код
Создатель задач и стратегии задач
Здесь начинается волшебство. Создатель задач и стратегии задач являются реализацией паттерна стратегии.
Если вы ничего не знаете о шаблоне стратегии, вот диаграмма UML для него.
По сути, у вас есть интерфейс (стратегия), который объявляет, что должно быть реализовано дочерними классами. Затем класс context взаимодействует с этими дочерними классами через интерфейс.
Это интересный паттерн, поскольку вы заменяете наследование композицией. Кроме того, он следует принципу открытого-закрытого. Таким образом, вы можете добавлять новые стратегии без изменения контекста . Если вы хотите узнать больше об этом шаблоне, отметьте this для получения дополнительной информации.
В контексте Castor мы используем шаблон стратегии для создания задач. Один из способов создания задач воздушного потока - использование операторов воздушного потока. Итак, следуя этому шаблону, вы получаете столько стратегий, сколько операторов вы хотели бы использовать.
Для начала мы реализовали только две стратегии: PythonOperatorStrategy и DummyOperatorStrategy. Так выглядит диаграмма UML.
Вывод из этого состоит в том, что вам следует однажды написать код стратегии, которую вы хотите использовать, а затем забыть о ней. Вам не нужно вручную создавать еще одну задачу Airflow в своей жизни.
Операторская фабрика
Наконец, у нас есть фабрика операторов. Это еще одна реализация паттерна Factory Method. Мне лично нравится Operator Factory, так как я пострадал из-за того, что у меня ее не было во время перехода с Airflow 1.10 на 2.0.
Это просто. Если вы используете Airflow Operators повсюду в своем проекте, вы обречены внести много изменений в проект, если операторы меняются.
Позвольте мне рассказать вам, как это выглядит, потому что мы это сделали. У нас было много файлов с использованием KubertenesPodOperators по всему нашему проекту. Скажем, от 10 до 20 файлов.
После перехода на 2.0 мы понимаем, что KubernetesPodOperator изменился. Вот краткий список того, что изменилось:
- Порт перенесен из списка [Port] в список [V1ContainerPort]
- env_vars перенесен из Dict в список [V1EnvVar]
- Ресурсы перешли с Dict на V1ResourceRequirements
- Ресурсы перешли с Dict на V1ResourceRequirements
- … Смотрите полный список изменений здесь
После миграции все давало сбой. Через пару часов мы поняли, что проблема связана с изменениями, внесенными в KubernetesPodOperator. Итак, мы это исправили. Но нам пришлось внести те же изменения в 20 файлов, где мы использовали KubernetesPodOperator.
Именно тогда мы понимаем, что должны реализовать фабрику операторов. Здесь мы централизуем все взаимодействия с операторами воздушного потока. Итак, если вы хотите взаимодействовать с оператором воздушного потока, мы делаем это через фабрику операторов. Более того, если нам нужно внести изменения, мы делаем это только на Factory, и все.
Реализация довольно проста. Вот код.
Последние мысли
В этой статье мы представили предложение структуры, известное как Castor. Причина, по которой это предложение, заключается в том, что структура еще не готова к производству. В нем нет тестов, это своего рода экспериментальный код.
Вот репозиторий Github, если вы хотите взглянуть на него.
Цель этой статьи - не рекламировать нашу платформу. Скорее цель состоит в том, чтобы пролить свет на то, как мы можем лучше использовать Apache Airflow. В этом случае мы выступаем за использование более декларативных конвейеров данных, поскольку считаем, что они являются будущим конвейеров данных.
Еще раз хочу узнать больше о том, что вы думаете по этому поводу.
Спасибо за прочтение!
Особая благодарность Хуану Фелипе Гомесу за то, что он сделал это возможным.
Если вы хотите быть в курсе моих работ, присоединяйтесь к моей рассылке новостей! Время от времени я делюсь кое-чем со своими читателями. Буду признателен, если вы присоединитесь :)
