Builder ELT: визуальный open-source конструктор пайплайнов данных
На Хабре опубликовали разбор open-source инструмента Builder ELT — визуальный конструктор для пайплайнов данных.

По словам автора, штука родилась из внутренней питон-обертки, а в итоге доросла до полноценного приложения с GUI, Celery и Keycloak. Для бэкенда и девопса это редкий случай, когда аналитический инструмент не превращается в чёрный ящик: трансформации крутятся на нативном SQL целевой БД, а Python нужен только для нестандартных коннекторов.
Под капотом: не очередной low-code
Стек типичный для внутренней аналитической поделки, пережившей третий рефакторинг: Python, метаданные в своей БД, Celery поверх Redis для очередей, Keycloak как провайдер авторизации. Документация — getbelt.dev, хостится на Cloudflare Pages, так что если упадёт — жалуйтесь автору, а не инфраструктуре.
Главное архитектурное решение — вынос трансформаций в целевую СУБД. Никаких Spark и прочих «движков»: SQL пишется под конкретный диалект и выполняется там же. Тащить данные к себе для трансформации — значит платить по счетам за хранение и сеть. Builder ELT гонит сырые данные и метаданные журнала, бизнес-данные остаются в источнике и приёмнике. Паранойя в правильном смысле. Цель заявлена простая: правило 20/80 — закрыть восемьдесят процентов типовых ELT-сценариев, остальное всегда оставлять на Python-адаптер.
Что умеет уже сейчас
Три строительных блока: подключение, поток, цепочка. Поток — конкретный ELT-процесс, цепочка — граф из потоков с расписанием. Мониторинг drill-down’ом: от прогона цепочки до пакета с ошибкой в логе. Для пакетной загрузки есть нарезка по колонке — данные грузятся последовательно, в журнал пишется история пакета, чтобы потом дёрнуть и перезалить только битый кусок, а не весь слой.
Типовой сценарий из разбора выглядит так: интеграционный поток тянет сырые данные из источника, трансформационный гонит SQL-преобразование на целевой БД, оба склеиваются в цепочку и стартуют руками или по расписанию. Поверх — model lineage, автодокументация, система деплоя и управление доступами через Keycloak. Для опенсорса — закрытый набор болей, на которые обычно закрывают глаза. Локализация и темы интерфейса тоже есть, что приятно для команд с аналитиками в трёх часовых поясах.
Что проверить у себя
Прежде чем тянуть в стек новый ELT-инструмент, задайте себе три вопроса. Первое: есть ли готовый коннектор к вашему хранилищу, или придётся дописывать Python-адаптер. Второе: кто и как будет апдейтить трансформации — если SQL крутится на целевой БД, нужны права и ревью изменений там. Третье: где будет жить метадата-БД. Это кусок прод-инфраструктуры, про локалхост забудьте.
Если под каждый проект у вас свой костыль — штука может стать общим знаменателем. Большего от неё никто и не требует. Ну а когда стандартизируешь пайплайны до мысли «хватит руками гонять данные», самое время задуматься о пассивном доходе и дивидендах.