DVT — новый open source ETL (Low-Code и не только)

Привет! На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Я достаточно много занимаюсь интеграциями, хранилищами данных и BI, поэтому, когда ребята из «Денвик Аналитика» предложили познакомиться с новым инструментом DVT, не стал отказываться.

Что такое DVT

«Денвик» начинался с «Экстрактора 1С», основная задача которого — вытащить данные из 1С в хранилище без участия программиста. Дальше логика очевидная: данные выгрузили, теперь их надо трансформировать. Так появился Denvic Visual Transformer, сокращённо DVT.

Изначально это был коммерческий продукт. Потом в «Денвик» решили, что он не в фокусе компании, и выложили его в open source под AGPL 3.0: https://github.com/Denvic-Tech/dvt.

Логика работы привычная для такого класса систем: есть рабочее поле, на него добавляются ноды, ноды соединяются в граф, а получившийся граф представляет собой pipeline обработки данных. При этом DVT — уже не просто редактор схем. В текущей архитектуре есть отдельные сервисы исполнения, планировщик, API, мониторинг выполнения, worker'ы и механизм расширений. Проекты можно запускать по расписанию, а статус выполнения видеть непосредственно в интерфейсе.

Сам продукт разворачивается on-premise в Docker/Docker Compose, что для корпоративной среды я скорее отношу к плюсам.

Что мне здесь кажется правильным

Основная идея DVT мне нравится своей прагматичностью: если операция типовая, она должна быть типовой и с точки зрения реализации. Мне, например, совершенно не кажется обязательным писать очередные двадцать строк Python для того, чтобы прочитать CSV, переименовать несколько колонок, сделать JOIN и положить результат в PostgreSQL. Особенно если через полгода другой человек должен будет открыть этот процесс и понять, что там происходит.

Визуальный pipeline в этом смысле имеет большое преимущество: архитектура конкретной загрузки видна сразу. Открыл проект и видишь источник, последовательность преобразований и приёмник. А если стандартных возможностей не хватает, DVT не пытается полностью заменить код. В платформе есть собственный Python Node DSL и механизм расширений, через который можно добавлять новые источники, преобразования и другие ноды.

Отдельно хочу отметить направление с MCP. Пока это именно эксперимент, а не готовая функция продукта, но разработчики уже показывают взаимодействие Codex с DVT через MCP. Причём речь не просто о генерации куска SQL или Python: агент получает доступ к инструментам DVT, может собрать pipeline из нод, запустить его, получить ошибку, проанализировать её и внести изменения в проект.

На мой взгляд, для low-code-платформ это очень логичное направление развития. Визуальный pipeline остаётся понятным человеку и пригодным для дальнейшего сопровождения, а AI можно использовать для его построения и изменения. В результате мы получаем не сгенерированный где-то в чате кусок кода, который потом надо переносить и разбирать, а обычный проект DVT из тех же самых нод.

Источники данных

Из коробки DVT уже умеет работать с основным набором источников, который встречается в обычных проектах DWH и BI: PostgreSQL, ClickHouse, Oracle, MySQL, Microsoft SQL Server, Excel, CSV, Parquet, S3, FTP/SFTP и сетевыми каталогами. В документации также заявлена работа с REST API.

То есть вполне можно представить обычный сценарий: данные о продажах забираем из PostgreSQL, план приходит в Excel, какие-нибудь внешние данные — через REST API, всё это объединяем, чистим и складываем в ClickHouse для дальнейшей работы BI.

Никакой технологической революции здесь нет, и это скорее хорошо. ETL вообще не та область, где мне хотелось бы каждый раз видеть технологическую революцию. Мне нужен предсказуемый инструмент, который умеет нормально читать данные, преобразовывать их, записывать и показывать, что произошло при выполнении.

А где здесь Dask?

В первоначальном описании DVT много внимания уделялось Dask, и продукт фактически представлялся как визуальная оболочка над ним. Сейчас я бы не стал делать на этом акцент.

В актуальном публичном репозитории DVT описывается уже как самостоятельная visual ETL-платформа. Исполнение вынесено в worker'ы, для очередей используются Celery и Valkey, есть PostgreSQL, отдельный оркестратор, Gateway API и планировщик.

С точки зрения пользователя гораздо важнее не то, какая Python-библиотека находится где-то внутри конкретной ноды, а общая модель работы платформы: есть граф обработки данных, механизм его исполнения, расписание, мониторинг и возможность расширять систему. Это уже больше похоже именно на ETL-платформу, а не на визуальный редактор для Python-библиотеки.

Отдельно про 1С

Если у компании большая часть операционных данных находится в 1С, вопрос доставки этих данных в DWH обычно возникает одним из первых.

В roadmap DVT есть дальнейшая интеграция с «Экстрактором 1С», включая исполнение его проектов и использование DVT в качестве фронтенда. На момент написания статьи это именно направление развития продукта, пока ещё не готовая функциональность.

Но если разработчикам удастся нормально связать визуальную подготовку данных с извлечением из 1С, это может оказаться одной из наиболее интересных особенностей продукта. Связка «1С → DWH → BI» встречается постоянно.

Кому такой инструмент может быть полезен

Я бы в первую очередь смотрел на DVT там, где уже назрела необходимость систематизировать подготовку данных, но строить для каждого преобразования отдельный программный стек не хочется:

• небольшие и средние DWH;

• подготовка витрин для BI;

• регулярный обмен данными между базами и файловыми источниками;

• прототипирование новых витрин;

• команды, где с данными одновременно работают аналитики и разработчики;

• проекты, которым важно развёртывание внутри собственного контура.

При этом важно понимать границы. DVT — это ETL-инструмент, и я бы не пытался использовать его как замену полноценной интеграционной платформе для сложных транзакционных интеграций между корпоративными системами.

У ETL и ESB всё-таки разные задачи. Перенести раз в час несколько миллионов строк из PostgreSQL в ClickHouse, предварительно что-то с ними сделав, — одна задача. Организовать гарантированный асинхронный обмен заказами между ERP, WMS, CRM и внешними сервисами с очередями, повторными отправками, SLA и контролем доставки — уже другая.

Open source

Есть ещё один важный момент: летом 2026 года DVT перевели в open source. Сейчас исходный код опубликован на GitHub, ядро распространяется под AGPLv3. При этом для расширений предусмотрено отдельное исключение, позволяющее при соблюдении определённых условий использовать собственные лицензии.

Для меня это серьёзный плюс. Не потому, что open source автоматически делает продукт хорошим, а потому, что для инфраструктурного ПО возможность посмотреть код, разобраться в архитектуре, самостоятельно написать расширение и при необходимости исправить проблему существенно снижает зависимость от производителя. Особенно если речь идёт о компоненте, через который в дальнейшем начинают проходить заметные объёмы корпоративных данных.

Что пока вызывает вопросы

Продукт молодой, и это видно и по roadmap, и по тому, насколько активно меняется функциональность. Только недавно (весной 2026 года) появлялись и переделывались ноды работы с БД, очередь задач, мониторинг, файловый менеджер, редакторы SQL/Python, условное ветвление и другие базовые возможности.

Поэтому я бы пока не рассматривал DVT как безусловную замену зрелым ETL-платформам, которые развиваются десятилетиями. Здесь ещё предстоит проверить на практике масштабирование, стабильность длительных процессов, обновления, обратную совместимость проектов, диагностику ошибок и вообще удобство промышленной эксплуатации.

Open source здесь тоже только начинается. Репозиторий публичный, но вокруг него ещё должна сформироваться экосистема пользователей, разработчиков расширений и контрибьюторов. На ранней стадии особенно нужны первые последователи — команды, готовые пользоваться продуктом, находить баги, давать обратную связь и вместе с разработчиками проходить неизбежные шероховатости молодой системы.

Вместо вывода

DVT мне кажется интересной попыткой сделать практичный open-source ETL: визуальный там, где задача типовая, и расширяемый кодом там, где стандартных возможностей не хватает. Отдельно интересно посмотреть, во что вырастет связка с MCP и «Экстрактором 1С».

Продукт пока молодой, поэтому многое будет зависеть от первых пользователей. Хочется пожелать ребятам из «Денвик» найти команды, готовые вместе с ними пройти этот этап и помочь DVT повзрослеть.