asapBI: архитектура ETL процессов – Airflow, Trino, Spark и прочий зоопарк

19 мар 2026

Чего хочется от ETL процесса?

Простые процессы – например, проброс данных из одной таблицы в другую с промежуточным расчетом – графический мэппинг полей. Таких простых пробросов – 90%, не хочется лазить по SQL-коду.
Сложные процессы – только тогда уже в бой идет ручной SQL, Python, Java, Scala, R.
Длительные процессы – тогда их лучше выполнять на внешних кластерах Trino, Spark, Impala – как говорится, хранилища отдельно, считалища – отдельно.
Единая точка контроля – нужна только одна точка контроля загрузок, не дело, когда мониторинг раскидан по разным системам.
Оффлайн-разработка – в связи с последними (?) событиями было бы здорово иметь возможность заниматься разработкой в оффлайне: сидишь в палатке без 5G, разрабатываешь модели и тестируешь трансформации и цепочки локально, а вечером результат сбрасываешь в общую систему через Wi-Fi придорожного кафе.

Почему Open Source?

Больше программистов на рынке труда, много документации
Убираем вендор-лок
Используем поддерживаемые современные решения

Важный принцип: должна быть возможность убрать asapBI и продолжать работать с созданными объектами вручную (= медленно и печально) – этим мы предотвращаем вендор-лок уже со стороны asapBI.

Как бы нам это все замиксовать?

Принцип работы asapBI: единый интерфейс

Обычно на проекте существует множество систем со своими интерфейсами. Создаваемых объектов много, надо не забывать, где что лежит и как завязано.

По идее, хорошо бы иметь единый интерфейс, где объекты, рассыпанные по разным системам, связаны между собой.

💡 Если убрать этот интерфейс, то модели данных и ETL процессы не рассыплются, все продолжит работу, но настраивать будет уже не так удобно.

Единый интерфейс просто объединяет в себе удобную работу с разными инструментами. Именно этот принцип я и реализую в asapBI.

Архитектура asapBI: оркестратор процессов

Рис. 1. Архитектура asapBI как оркестратор процессов

Рис. 1. Архитектура asapBI: единый интерфейс для управления базами данных, оркестраторами и вычислительными кластерами

Практический пример: создаём DTP и цепочку загрузки

Пройдемся по ETL-процессам в asapBI.

Единицей процесса является DTP – Data Transfer Process (хе-хе, привет саперам! 😉) – это алгоритм заполнения одной таблицы из других, возможно находящихся в других базах.

Пример DTP

Рис. 2. Создание DTP и настройка мэпинга полей

Рис. 2. Создание DTP и настройка графического мэппинга полей

На вкладке Transformation создается мэпинг полей. В общем случае, если выбирается среда выполнения Trino или Spark, возможна передача данных между разными базами – например, из Greenplum в Clickhouse.

Деплой в Airflow, выполнение на Spark

Рис. 3. Настройка деплоя DTP: выбор оркестратора и среды выполнения

У системы есть коннект к Airflow – мы можем разместить этот DTP там. У Airflow, в свою очередь, есть коннект к Spark – выберем его, чтобы Airflow передавал наш DTP на кластер Spark для выполнения.

Можно выбрать язык реализации – это третий выпадающий список Execution language. Для Spark это либо SQL, либо Python.

Просмотр и редактирование сгенерированного кода

Готовый код можно увидеть и отредактировать на вкладке Code:

Рис. 4. Сгенерированный SQL-код для DTP

В Python-варианте автогенерация для Spark выглядит следующим образом:

Рис. 5. DTP сгенерировал Python код для Spark

Рис. 5. Сгенерированный Python-код для Spark

Работа с Airflow

При сохранении DTP в Airflow создается готовый к выполнению даг:

Рис. 6. Два DTP в интерфейсе Airflow как даги

Рис. 6. DTP в интерфейсе Apache Airflow

Эти даги можно запускать и отлаживать как в интерфейсе Airflow, так и в интерфейсе asapBI:

Рис. 7. Лог выполнения и отладки DTP

Цепочки задач (DAG)

Даги можно собирать в цепочки (в терминах Airflow это тоже будут даги) – пример цепочки:

Рис. 8. Цепочка DTP с логом упавшего запуска

Рис. 8. Цепочка DTP: лог упавшего запуска и кнопка рестарта. Всего цепочка запускалась три раза — один раз вручную и два по расписанию

Простую цепочку можно создать, добавив разные DTP в дерево задач (блок Tasks). Если же нужны условные операторы, циклы и прочие излишества – тогда правим автоматически сгенерированный код дага:

Рис. 9. Автоматически сгенерированный код цепочки

Рис. 9. Python-код цепочки DAG для Airflow

Тот же самый список цепочек можно увидеть и запустить в стандартном интерфейсе Airflow — правда здесь цепочки не разложены по папкам, как в дереве asapBI:

Рис. 10. Список цепочек (дагов) в Airflow

Рис. 10. Список DAG в интерфейсе Apache Airflow

Преимущества параллельного выполнения

🔴 SAP подход

Не приветствовался параллельный запуск множества DTP. Приходилось ставить их друг за другом.

Проблемы: нерассчитанные к утру витрины, пошаговая ручная перезагрузка упавшей части цепочки.

🟢 Airflow подход

Можно строить цепочки с параллельным запуском множества дагов — оркестратор запускает одновременно столько задач, сколько сможет «прожевать».

Преимущества: параллелизация независимых шагов, автоматический рестарт упавших задач, реальная независимость процессов.

Деплой без оркестратора

Если на проекте нет оркестраторов – ни Airflow, ни Dagster – можно выбрать для деплоя базу и автоматически сгенерировать там функцию:

Рис. 11. Выбор базы данных для деплоя — только той, в которой исходная и целевая таблица

Сам сгенерированный код функции тоже можно поправить:

Рис. 12. DTP сгенерировал функцию в базе данных

Рис. 12. Сгенерированная хранимая функция в базе данных

🎯 Итог: по сути asapBI – просто удобный интерфейс, объединяющий множество разных систем, с автогенерацией рутинного кода. Для простых случаев используется графический интерфейс, для сложных — ручной код. Система — не черный ящик, всегда можно посмотреть, какой код получается, дописать и подправить его. Все это можно создать и поддерживать и без asapBI, но вот времени на это уйдет…

🔮 Будущее профессии: заменит ли ИИ дата‑инженеров?

Предполагается широкое использование ИИ типа «Пробрось новое поле из такого-то источника до такой-то витрины».

Только вот неясно – может быть с развитием ИИ все эти модели будут не нужны? Данные ведь можно сваливать в Data Lakehouse и давать задачу ИИ проанализировать и сразу выдать инсайт без этих ваших (наших) дашбордов и моделей.

Что думаете вы? Станет ли SQL новым Ассемблером, а визуальные построители и ИИ — основным инструментом дата-инженера?