Построение ETL процессов на базе Cron и оркестратора задач Luigi

Сегодня при развертывание хранилищ данных и формирование отчетности на базе витрин мы выгружаем информацию не только из внутренних систем-источников заказчика, например, локально или на удаленном сервере СУБД PostgreSQL и другие, но и получаем её часть по API, с почтовой рассылки интегрированной по imap, из мессенджеров заказчика или его клиентов и так далее. При проектировании хранилища и витрин немаловажную роль играют ETL/ELT или EL (Extract and Load) процессы загрузки данных в хранилище. От выбора способа организации зависит качество данных, способ планирования ETL-пайплайнов, регулярность получение информации и в следствии чего обновление отчетности в инструментах Business Intelligence, Excel и других, визуализации отработанных функций и выбор инструмента оркестрации задач: выгрузки, изменении и загрузки данных в денормализованный Staging слой хранилища, а также миграция данных между Staging слоем и нормализованным Core слоем, чтобы аналитики могли выгружать полностью обработанные и полученные своевременно данные для моделирования отчетности в виде схемы «Звезда» или «Снежинка».

Помимо задач построения хранилища данных часто ETL пайплайны используют в анализе данных при разработке моделей машинного обучения: задачи ранжирования, рекомендации, классификации или регрессии. Когда мы должны не только прочитать текущие данные, очистить их, создать более эффективные фичи под конкретную задачу для увеличению ее метрики, написать разбивку данных на тестовую и контрольную группу или написать кросс валидацию для более эффективного прогноза модели, но и еще настроить оркестрацию и последовательное выполнение задач с целью сохранение каждого выполненного шага, чтобы оптимизировать время выполнения следующего в случае, если произошла ошибка в ходе выполнения предыдущего шага ETL/ELT пайплайна (см. рис. 1).

Рис. 1. Стандартный ETL/ELT пайплайн

Сегодня для решения подобных задач часто используют Apache Airflow ввиду его популярности и многозадачности. В больших компаниях он является незаменимым инструментом дата инженеров, однако рынке есть не только он, но и:

1. Cron
2. Luigi
3. Ray
4. Kedro
5. Prefect
6. Dagster

В компаниях с количеством источников равным десяти и меньше часто используют Apache Airflow, что может быть чрезмерным и недостаточно аргументированным выбором для решаемых ими задач. Такие компании могут использовать и только Cron. Каждый подход имеет достоинства и недостатки, однако для такого рода компаний мы можем использовать два инструмента совместно: Cron и Luigi, это позволит выполнять те же задачи так же оперативно, как это делает Apache Airflow, однако здесь мы получаем легковесность всей работающей системы и понимание её работы не только от специалиста, но и от всех сотрудников компании.

Таким образом, обозначим цель и методы исследования статьи.

Так целью статьи является проанализировать инструменты оркестрации и планирования выполнения задач для компаний с количеством источников данных менее десяти.

Методы исследования:

1. Анализ
2. Сравнение

Рассмотрим инструмент Apache Airflow и сравним с системой вида Cron + Luigi. Apache Airflow – это open-source инструмент оркестрации, планирования и исполнения задач, ключевой компонент Apache Airflow – это DAG, который содержит в себе операторы, они выполняют задачи в той последовательности и по тому расписанию, который укажет пользователь. DAG – это ориентированный ациклический граф [1, с. 2]. Ациклический значит, что любая задача не может содержать саму себя, то есть он не должен иметь циклов. Apache Airflow можно развернуть локально или через Docker контейнер, все задачи, которые мы исполняем можно увидеть в графическом веб-интерфейсе, который открывается на порту 8080, по умолчанию.

Примеры DAG [1, с. 2] (см. рис. 2).

Рис. 2. Направленный ациклический граф

Apache Airflow содержит в себе следующие компоненты (см. рис. 3).

Рис. 3. Основные компоненты Apache Airflow

Также по умолчанию Airflow разворачивает SQLite СУБД для работы с данными пользователя. Airflow содержит REST API для постановки и отслеживания задач планировщика.

Airflow может исполнять следующие операторы:

1. PythonOperator – выполняет функцию Python
2. BashOperator – выполняет команды bash
3. PostgresOperator – выполняет SQL команды в Postgres. Может быть полезен при настройке миграции данных между двумя базами данных PostgreSQL.
4. EmailOperator – отправка почты
5. TransfersOperators – операторы передачи данных

Luigi – open-source система, которая представляет собой Python-пакет. Apache Luigi и Apache Airflow реализуют одну из ключевых функций оркестратора – это сохранение результатов работы каждого шага ETL/ELT процесса. Luigi – это легковесный инструмент, который позволяет управлять рабочими процессами и имеет веб-интерфейс.

Luigi состоит всего из трех основных компонентов (см. рис. 4).

Рис. 4. Основные компоненты Luigi

Ввиду чего Luigi проще поддерживать, чем Airflow. У Luigi простой и понятный Python код, в отличие от Airflow [2, с. 51]. В отличие от Airflow, Luigi можно запустить в два шага:

1. Установить библиотеку
2. Запустить веб-сервер (см. рис. 5)

Рис. 5. Веб-интерфейс Luigi

Недостаток Luigi в виде отсутствия планировщика задач перекрывает Cron, который установлен на всех операционных системах (см. рис. 6).

Рис. 6. Планировщик задач Cron. Пример из реальной практики

В заключении можно сказать, что из-за чрезвычайной гибкости инструменты Luigi и Cron больше подходят компаниям, которые имеют небольшое количество источников и хотят создать платформу для анализа данных в виде хранилища, чтобы строить на его базе отчеты, обновлять их с заданным расписанием и дешево поддерживать архитектуры с точки зрения затрат на специалистов.