Всем привет! С вами снова Виталий Виноградов, я занимаюсь в свободное время созданием asapBI - платформы для моделирования баз данных и ETL.
Продолжу цикл по системе.
Чего хочется от ETL процесса?
Если процесс простой – например, проброс данных из одной таблицы в другую с промежуточным расчетом – то графический мэппинг полей. Таких простых пробросов – 90%, не хочется лазить по SQL-коду.
Если же процесс сложный – только тогда уже в бой идет ручной SQL, Python, Java, Scala, R.
Если процесс длительный – тогда его лучше выполнять на внешних кластерах Trino, Spark, Impala – как говорится, хранилища отдельно, считалища – отдельно.
Еще нужна только одна точка контроля загрузок – не дело, когда мониторинг загрузок раскидан по разным системам.
В связи с последними (?) событиями было бы здорово иметь возможность заниматься разработкой в оффлайне – сидишь в палатке без 5G, разрабатываешь модели и тестируешь трансформации и цепочки локально, а вечером результат сбрасываешь в общую систему разработки через wi-fi придорожного кафе.
Причем компоненты лучше использовать Open Source:
больше программистов на рынке труда
убираем вендор лок
используем поддерживаемые современные решения
Должна быть возможность убрать asapBI и продолжать работать с созданными объектами вручную (= медленно и печально) – этим мы предотвращаем вендор лок уже со стороны asapBI.
Как бы нам это все замиксовать?
Принцип работы asapBI: единый интерфейс
На текущий момент существует много систем со своими интерфейсами. Создаваемых объектов много, надо не забывать, где что лежит и как завязано.
По идее, хорошо бы иметь единый интерфейс, где объекты, рассыпанные по разным системам, связаны между собой.
Если убрать этот интерфейс, то модели данных и ETL процессы не рассыплются, все продолжит работу, но настраивать будет уже не так удобно. Этот интерфейс просто объединяет в себе удобную работу с разными инструментами. Именно этот принцип я и реализую в asapBI.
Архитектура asapBI:
Практический пример: создаём DTP
Пройдемся по ETL-процессам в asapBI.
Единицей процесса является DTP – Data Transfer Process (хе-хе, привет саперам! 😉) – это алгоритм заполнения одной таблицы из других, возможно находящихся в других базах.
Пример DTP:
На вкладке Transformation создается мэпинг полей. В общем случае, если выбирается среда выполнения Trino или Spark, возможна передача данных между разными базами – например, из Greenplum в Clickhouse.
У системы есть коннект к Airflow – мы можем разместить этот DTP там. У Airflow, в свою очередь, есть коннект к Spark – выберем его, чтобы Airflow передавал наш DTP на кластер Spark для выполнения:
Можно выбрать язык реализации – это третий выпадающий список «Execution language». Для Spark это либо SQL, либо Python.
Готовый код можно увидеть и отредактировать на вкладке Code:
В Python варианте автогенерация для Spark выглядит следующим образом:
При сохранении DTP в Airflow создается готовый к выполнению даг:
Эти даги можно запускать и отлаживать как в интерфейсе Airflow, так и в интерфейсе asapBI:
Даги можно собирать в цепочки (в терминах Airflow это тоже будут даги) – пример цепочки:
Простую цепочку можно создать, добавив разные DTP в дерево задач (блок Tasks). Если же нужны условные операторы, циклы и прочие излишества – тогда правим автоматически сгенерированный код дага:
Тот же самый список цепочек можно увидеть и запустить в стандартном интерфейсе Airflow - правда здесь цепочки не разложены по папкам, как в дереве asapBI:
В SAP не приветствовался параллельный запуск множества DTP и приходилось ставить их друг за другом. Это влекло проблемы в виде либо нерассчитанных к утру витрин, либо пошаговой ручной перезагрузки упавшей части цепочки.
В Airflow же, напротив, можем строить цепочки с параллельным запуском множества дагов - оркестратор будет запускать одновременно столько задач, сколько сможет прожевать.
Это дает возможность параллелить независимые шаги загрузки и при падении какого либо дага в цепочке просто его вручную или автоматически перезапускать. При этом достигается реальная независимость процессов загрузки друг от друга.
Если на проекте нет оркестраторов – ни Airflow, ни Dagster – можно выбрать для деплоя базу и автоматически сгенерировать там функцию:
Сам сгенерированный код функции тоже можно поправить:
Т.е. по сути asapBI – просто удобный интерфейс, объединяющий множество разных систем. Для простых случаев используется графический интерфейс, для сложных - ручной код.
Система - не черный ящик, всегда можно посмотреть, какой код получается, дописать и подправить его.
Все это можно создать и поддерживать и без asapBI, но вот времени на это уйдет…
Будущее профессии: заменит ли ИИ дата‑инженеров?
Предполагается широкое использование ИИ типа «Пробрось новое поле из такого-то источника до такой-то витрины».
Только вот неясно – может быть с развитием ИИ все эти модели будут не нужны? Данные ведь можно сваливать в Data Lakehouse и давать задачу ИИ проанализировать и сразу выдать инсайт без этих ваших (наших) дашбордов и моделей.
