Запилить еще один Low‑Code ETL? — Конечно, да. Как мы пошли в opensource

Когда много работаешь с ИТ‑проектами, быстро понимаешь, какие инструменты действительно экономят время команды. Я работаю аналитиком и архитектором систем в компании интеграторе, где мы помогаем компаниям автоматизировать передачу данных из 1С в BI‑системы (системы аналитики). Проще говоря — настраиваем обмен между 1С и BI так, чтобы нужные данные автоматически поступали в контур аналитики и обновлялись по расписанию, без регулярной ручной загрузки.

Со временем мы заметили, что нашим заказчикам не хватает быстрого и удобного способа собирать витрины данных для BI — без сложного кода, с понятной логикой и простым обслуживанием. Да, есть конечно Apache AirFlow, есть DBT — но все это для технарей, для искушенных в Python и SQL.

И в какой‑то момент возникла мысль о своем ETL‑решении, но дружелюбном к нормальным бизнес‑пользователям. Так появился DVT — low‑code ETL‑сервис, который мы сначала развивали в собственных проектах, а теперь решили сделать общедоступным, выпустив его в Open Source. 

В этой статье покажу, что конкретно умеет DVT, зачем мы открываем его исходный код и в чем польза этого решения — для компаний и для нас как разработчиков.

Идея визуального конструктора 

У нас не было цели разработать универсальную платформу обработки данных. Мы уже использовали инструмент, который выгружает данные из 1С (Экстрактор 1С). Но выгрузить данные из 1С — только первый шаг. 

Пока источников немного, сборку витрин можно делать вручную или парой‑тройкой скриптов. Но цепочка обработки данных растет — вместе с ней растет количество мест, где описано: что и как делать с данными: часть шагов — в SQL‑запросах, часть — в Python‑коде, что‑то в Excel, еще один шаг — внутри BI. В итоге процесс знают один‑два человека: при изменении дашборда или добавлении полей источника нужен тот, кто знает, где, как и что работает, поскольку процесс сборки витрин для BI оказывается разбросан между множеством систем, и не всегда очевидно, где именно надо вносить правки.

В результате мы вернулись к старой идее — low‑code: когда сборка хранилища, витрин данных представляет собой последовательность понятных операций. Не «написать скрипт, который делает первое, второе и третье», не раскидать процесс ETL между AirFlow, выгрузкой из 1С, представлениями в SQL, портянками dbt, а сделать процесс сборки DWH единым:

получили данные → отфильтровали → преобразовали → объединили → рассчитали поле → записали результат

За основу взяли движок Dask, как легкую альтернативу Apache Spark (понимаю, что тут меня закидают камнями наверное, но с точки зрения походов эти два продукта в чем то схожи).

И над Dask начали рисовать визуальную обертку для простого смертного пользователя.

И, появился DVT (Denvic Visual Transformer) — визуальный конструктор, в котором процесс обработки данных собирается из готовых блоков. Идея сработала не потому, что визуальный интерфейс лучше кода — код никуда не исчезает и для сложной логики остается необходимым. Вопрос в другом: зачем писать код там, где достаточно нескольких типовых шагов?.

В основе DVT — Dask. А значит — «ленивое» (отложенное) исполнение всех шагов пайплайна.

Внутри каждой ноды — удобный визуальный конструктор:

Dask — это библиотека для параллельных и распределённых вычислений на Python. Ее главная задача — помогать обрабатывать большие объемы данных, которые не помещаются в оперативной памяти одного компьютера.

Вместо скриптов — понятная схема 

DVT — это low‑code ETL‑сервис (Extract, Transform, Load — извлечение, преобразование и загрузка) к подготовке данных. Пайплайн обработки данных (схема) собирается из нод — готовых визуальных блоков. Каждая нода отвечает за отдельную операцию, а связи между ними показывают, как данные проходят от источника до готовой витрины.

Например:

1С + CRM → загрузка → сопоставление клиентов по ИНН → объединение таблиц → приведение значений → расчет показателей → проверка результата → витрина для BI

Аналитик не пишет код для каждой задачи — он настраивает блоки: подключает источник, объединяет таблицы, фильтрует записи, считает показатели и передает результат в BI. Если нужно изменить логику обработки, он просто добавляет, удаляет или перенастраивает нужную ноду, не переписывая весь процесс. 

Это принципиальное отличие от проекта, где вся логика спрятана внутри нескольких файлов с SQL или Python — открываешь пайплайн и видишь, откуда пришли данные, что с ними сделали на каждом этапе и что получилось в итоге. 

Что реализовано:

• Чтение и запись в DataFrame и в «Переменные»:

  • из таблицы из БД;

  • из SQL‑запросов;

  • из Excel;

  • из CSV;

  • из Parquet;

  • http‑request;

• Трансформации над DataFrame:

  • Union;

  • Join;

  • Filter;

  • Group By;

  • Cast Columns;

  • Rename Columns;

  • Drop и Select Columns;

  • Pivot и UnPivot;

  • Замена по Regex и просто Replace;

  • Split Columns по разделителю;

  • Execute Python code (входы и выходы: JSON/ Variables/ DataFrame);

  • JSON → DataFrame и DataFrame → JSON;

  • “Переменные” → DataFrame и DataFrame → в «Переменные»;

• Управление:

  • Исполнение подпроектов, включая ожидание и передачу переменных внутрь подпроекта;

  • Цикл на основе DataFrame, при котором на вход «Подпроекта» передается DataFrame и каждая строка DataFrame является итератором цикла и источником для глобальных переменных Подпроекта);

  • Сигналы (для условного ветвления и выстраивания последовательности исполнения нод);

  • Шедулер (встроенная в DVT возможность исполнять проекты по расписанию);

  • Вызов проектов по API, с передачей внутрь параметров (переменных);

Примеры: два сценария работы с DVT

Допустим, вы хотите посчитать прибыльность продаж на маркетплейсе:

• Себестоимость у вас хранится в 1С, данные о продажах и комиссиях — в выгрузке из маркетплейса, а возвраты — в отдельном файле. Чтобы получить маржу, эти данные нужно связать, применив к ним единые правила расчета. 

• В DVT вы собираете процесс расчета в одну цепочку:

  • 1С (себестоимость) + маркетплейс (продажи и комиссии) + возвраты → сопоставление → объединение → расчет маржи → проверка → витрина → BI 

• После каждого шага видно результат обработки. Если вдруг маржа отличается от ожидаемой, не нужно разбирать весь пайплайн: можно открыть нужную ноду и проверить, какие записи она получила и что с ними произошло.

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

В этом и есть практический смысл low‑code: правила обработки видны прямо в пайплайне. Другому специалисту проще разобраться в логике, так как он видит каждый шаг, может проверить его настройки и внести изменение, не разбираясь во всем коде с нуля. А это значит:

• меньше ручной работы;

• меньше времени на разбор, поддержку и изменение процессов. 

Другой пример — управленческая отчетность по нескольким юридическим лицам:

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

• В DVT вы также собираете процесс в одну схему:

  • 1С: юрлицо 1 + юрлицо 2 + юрлицо 3 → очистка и сопоставление справочников → объединение → расчет показателей → проверка → витрина → BI 

• Если позже вы захотите добавить CRM, файл со справочником или внешний API, источник можно подключить к этому же пайплайну. DVT работает с 1С, СУБД, файлами, JSON и REST/HTTP‑запросами. В документации сервиса есть и более конкретные сценарии: подключение Bitrix24, работа с Google Таблицами и инкрементальная загрузка.

То есть: типовые шаги обработки данных (загрузку, фильтрацию, объединение и расчеты) вы собираете визуально. Если нужна своя логика, добавляете SQL или Python. Плюс можно работать с JSON, HTTP‑запросами, переменными и параметрами. Нестандартные интеграции и сценарии с большими объемами данных остаются за data‑инженером: он пишет нужную логику, ускоряет обработку и при необходимости меняет архитектуру. 

Почему мы выпускаем DVT в Open Source 

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

Мы создали DVT потому, что он изначально был нужен нам самим. Но основной фокус деятельности нашей компании — разработка решений, связывающих между собой 1С и BI. Собственный low‑code ETL — не наш фокус в разработке.

Плюс ко всему на рынке уже есть инструменты для работы с данными: Airflow, dbt, Loginom и другие решения. Держать DVT в закрытом виде и отдельно развивать его силами нашей небольшой команды не имеет смысла.

Есть еще одна причина, почему история DVT вообще дошла до Open Source.

Накануне принятия такого решения мы собрали прототип MCP‑сервера для нашего DVT на dev‑контуре, и подключили к нему Codex.

Codex вычитал инструкции MCP. И (о чудо) мы получили систему сборки ETL‑проектов в чате. Все получилось легко и просто. Открывая исходный код, мы упростили себе поддержку и развитие этого продукта, давая ему хороший шанс на жизнь.

Этот опыт с ИИ заставил нас иначе посмотреть на то, что делать с DVT дальше. Если раскрытие кода DVT позволяет быстро обучить ИИ работе с пайплайнами ETL, то точно надо идти в opensource.

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

Во‑первых, мы получили поддержку обычных аналитиков, так как сервис сделан для бизнес‑пользователей, ане технических гуру.

Во‑вторых, мы продолжили использовать свой сервис при подготовке данных для BI, не опасаясь конкуренции с коммерческими ETL‑решениями.

В‑третьих, мне интересно увидеть мир за пределами коммерческой разработки.

Что меняется для пользователя

Для пользователя главное изменение в другом: он меньше зависит от нашей команды. Если готовой функциональности DVT для конкретного процесса не хватает, можно:

• предложить изменение через репозиторий;

• добавить собственное расширение;

• изменить существующую ноду под свои правила обработки данных;

• дополнить документацию примерами своих сценариев.

При этом DVT не нужен каждой компании. Если у вас:

• Один источник и простой запрос — SQL, скорее всего, решит задачу быстрее;

• У вас есть компетенции в SQL, dbt, AirFlow — тогда использовать DVT нет смысла.

С чего начать

DVT уже доступен в Open Source: https://github.com/Denvic‑Tech/dvt

Установка достаточно простая, главное развернуть Docker

А дальше — просто начинаете пользоваться. Например:

1. Пересоберите небольшой SQL‑запрос в визуальном пайплайне. Если данные для отчета или витрины сейчас формирует SQL‑запрос, повторите его логику в DVT: объедините таблицы, отфильтруйте данные и выполните расчеты. Сравните результат и проверьте, сможет ли другой специалист понять, что происходит с данными на каждом этапе, без чтения SQL‑кода.

2. Соберите данные из БД, Excel и CSV‑файлов в единую витрину данных.

3. Поэкспериментируйте со сборкой плоских таблиц, так любимых многими BI‑системами

4. Выгрузите данные из БД (даже из запроса SQL) в CSV или Excel в S3 или на сетевой диск.

5. Подцепите HTTP‑Request ноду и соедините данные БД и данные из Rest API какого‑нибудь сервиса.

Если говорить об Open Source как о способе превратить инструмент из узкоспециализированного решения в основу для разных процессов подготовки данных, то открытый код меняет саму роль продукта. Он становится частью общей системы работы с данными, а не просто инструментом под один сценарий. Плюс — Open Source покажет главное: насколько инструмент востребован компаниями и как широко его можно использовать в сценариях, которые разработчик изначально не предусматривал.