FAQ: Работа Экстрактора 1С и DVT
На вебинаре, видео которого мы опубликовали ниже, мы разобрали весь путь данных — от рабочей базы 1С до готовой аналитической витрины: 1С → автоматическая выгрузка → ETL и преобразование → хранилище данных → BI-система. Для осуществления выгрузки мы использовали Экстрактор 1С, а для преобразования данных — DVT.
Ниже мы собрали подробные ответы экспертов на вопросы о том, как выгружать данные из 1С, строить ETL-конвейеры, готовить витрины и создавать единый источник данных для BI.
Я правильно понимаю, что в хранилище данных у вас два слоя — слой для выгрузки данных из Экстрактора и слой для витрины?
Да, такая архитектура вполне рабочая: первый слой — сырые или минимально обработанные данные из источников, второй — аналитические витрины, уже подготовленные под BI. Но два слоя — не ограничение платформы. В более сложном DWH мы можем разделить архитектуру на Raw/Staging → интеграционный слой → Data Marts. Экстрактор 1С отвечает прежде всего за стабильное получение данных из 1С, а DVT — за очистку, объединение, преобразование и формирование витрин. В документации Экстрактора даже отдельно отмечено, что сложные преобразования лучше переносить из слоя извлечения в последующий ETL.
Если у меня 30 баз на разных СУБД, будет 30 проектов в Экстракторе или по количеству СУБД?
Для каждой 1С может быть неограниченное число проектов выгрузки. Как для сырых данных объектной модели так и для денормализованных наборов, в том числе и отчетов.
DVT сейчас в демо-доступе. Когда-то он станет платным? И что будет с настроенными трансформациями?
Ранее DVT был закрытым коммерческим продуктом, а бесплатный доступ предоставлялся для тестирования. На текущий момент DVT — открытый продукт, выпущенный в Open Source по лицензии AGPL-3.0. Однако, отметим, что аддоны к 1С и к Битрикс24 являются платными.
Есть ли возможность постепенно расширять количество пользователей и подразделений?
Да. Мы не требуем сразу строить корпоративное DWH на всю компанию. Можно начать, например, с финансов или продаж, затем подключать склад, маркетинг, HR и остальные направления. DVT поддерживает авторизацию, добавление пользователей, проекты и папки. Архитектуру можно постепенно расширять дополнительными источниками, пайплайнами и вычислительными ресурсами. При этом точную схему лицензирования под количество пользователей и подключений лучше определять исходя из выбранного варианта поставки.
Как быстро можно добавить новый источник данных после запуска проекта?
Если источник уже поддерживается готовым коннектором, значительная часть работы сводится к созданию подключения, выбору данных и включению новой ветки в пайплайн. DVT работает с 1С, PostgreSQL, MS SQL Server, ClickHouse, Oracle, Excel, CSV, JSON, XML, REST/HTTP API, Bitrix24, S3, Parquet и другими источниками. Поэтому добавление новой системы не требует переписывать весь существующий конвейер. Для нестандартных источников можно использовать SQL, HTTP, Python или расширения.
Как построить единый источник данных для бизнеса, если сейчас каждый отдел считает показатели по-своему?
Это задача не только ETL. Сначала нужно договориться, что именно означает показатель. Например, «выручка» может считаться по отгрузке, оплате, управленческому учёту или бухгалтерским проводкам. Если просто собрать все цифры в одном DWH, четыре определения выручки никуда не исчезнут. Поэтому мы сначала фиксируем единую методику: источник показателя, формулу, период, разрезы, владельца метрики. Затем эта логика переносится в DVT и аналитическую модель. В результате формула живёт не внутри десяти разных Excel и BI-отчётов, а централизованно в конвейере данных.
Как реализуется разделение процессов загрузки, очистки и бизнес-трансформации данных?
Мы разделяем эти задачи технологически. Экстрактор 1С → Raw/Staging → DVT → аналитические витрины → BI. Экстрактор отвечает за получение актуальных данных. DVT - за очистку, типизацию, Join/Union, фильтрацию, агрегации, расчётные поля и бизнес-правила. Результатом становятся подготовленные таблицы для DWH или BI. Такой подход не смешивает механику получения данных и бизнес-логику аналитики.
Если данные находятся в 1С, Excel, CRM и других системах — как DVT помогает привести их к единому аналитическому виду?
Это один из основных сценариев DVT. Например, из 1С приходит номенклатура и продажи, из CRM — лиды и сделки, из Excel — планы подразделений. В DVT можно привести типы полей к единому виду, нормализовать названия, удалить пустые значения, сопоставить справочники, выполнить Join/Union, рассчитать новые показатели и записать результат в одну витрину. То есть BI получает уже не четыре разрозненных источника, а подготовленную аналитическую модель.
Что происходит, если после внедрения меняется структура базы 1С?
Здесь нужно разделять техническое изменение и изменение бизнес-смысла. Добавление поля, изменение структуры объекта или обновление конфигурации требует проверки схемы и маппинга проекта. Экстрактор работает с метаданными 1С и поддерживает управление структурой таблицы-приёмника и маппингом полей. Но если разработчик 1С не просто переименовал реквизит, а изменил саму логику учёта, ни один ETL-инструмент не должен «молча исправлять» такую ситуацию. Это изменение нужно провести через модель данных и проверить связанные витрины. Но в любом случае, Экстрактор умеет выгружать метаданные конфигурации. Это позволяет предсказать и отредактировать проекты выгрузок, в которые входят измененные объекты.
Как проходит внедрение: от первого обследования до появления первых отчётов?
Мы стараемся не начинать проект с задачи «выгрузить всю 1С». Сначала выбираем конкретный бизнес-сценарий: например, продажи, P&L, остатки или дебиторскую задолженность. Затем определяем показатели и источники → настраиваем получение данных → создаём Raw/Staging → собираем преобразования в DVT → формируем первую витрину → подключаем BI → сверяем цифры с учётной системой. После пилотной витрины архитектура расширяется на другие показатели и подразделения. Такой подход быстрее показывает бизнесу результат и одновременно проверяет всю цепочку от 1С до дашборда.
Может ли продукт закрыть потребности бизнеса без создания отдельной большой команды дата-инженеров?
Во многих сценариях — да, и именно здесь low-code даёт большой эффект. В DVT типовые процессы собираются визуально: чтение → фильтрация → Join → преобразование → запись. Аналитик может собрать значительную часть конвейера самостоятельно. Для нестандартной логики остаются SQL, Python, HTTP и расширения. Но мы бы не обещали «Data Engineer больше вообще не нужен». На сложном корпоративном DWH всё равно требуются компетенции в архитектуре, моделировании данных, инфраструктуре и Data Quality. Задача продукта — не убрать инженера, а убрать из его работы сотни однотипных ETL-операций.
Где лучше выполнять преобразование данных: внутри BI или до загрузки в хранилище? Может ли продукт заменить несколько отдельных инструментов?
Бизнес-логику, которой пользуются несколько отчётов, лучше выносить из BI в централизованный слой подготовки данных. Если один и тот же показатель рассчитывается отдельно в DataLens, Power BI и ещё двух отчётах, со временем появляются четыре версии формулы. Мы предпочитаем схему: 1С → Экстрактор → DWH → DVT → витрина → BI. Экстрактор закрывает промышленное извлечение из 1С, DVT - ETL/ELT и витрины, BI остаётся слоем анализа и визуализации. Инжектор 1С добавляется, когда преобразованные данные нужно вернуть обратно в 1С. Продукты можно использовать независимо друг от друга.
Реализуете ли вы BI-проекты под ключ?
Да. Можно взять только Экстрактор или DVT, а можно реализовать всю цепочку:обследование источников → архитектура DWH → получение данных → ETL → модель → витрины → BI-дашборды → ввод в промышленную эксплуатацию. На нашем сайте отдельно представлены внедрения DataLens, Visiology и PIX BI, а сама линейка решений рассчитана на проекты от выгрузки 1С до готового BI-контура.Но возможен любой ваш сценарий.
Можно ли одним процессом готовить данные одновременно для ClickHouse и PostgreSQL?
Да. Один процесс подготовки данных может формировать результат для нескольких целевых систем. Это позволяет использовать единую бизнес-логику подготовки и не создавать отдельные цепочки обработки под каждую СУБД.
Можно ли построить нормальную аналитику, если данные сейчас собираются из нескольких Excel-файлов разных подразделений?
Excel может использоваться как один из источников данных в общем аналитическом контуре. DVT позволяет:
загружать данные из файлов;
объединять их с информацией из 1С и других систем;
выполнять очистку;
формировать единые наборы данных для аналитики.
Если у нас уже есть BI-система, может ли DVT заменить только слой подготовки данных, не меняя текущую BI-платформу?
Да. И это один из наиболее логичных сценариев внедрения. Например: 1С + CRM + Excel → DVT → ClickHouse → существующий Power BI или: источники → DVT → PostgreSQL → существующий DataLens. DVT не требует менять BI. Он формирует подготовленные таблицы и витрины, к которым ваша текущая BI-система продолжает подключаться привычным способом.
Как реализуется управление доступами в DVT? Можно ли ограничить разные команды отдельными процессами?
В DVT есть авторизация и управление пользователями; документация описывает добавление пользователей, а интерфейс — проекты и папки.
Может ли Экстрактор 1С использовать разные стратегии извлечения в зависимости от типа объекта?
Да. Экстрактор поддерживает несколько типов источника: Объект, Запрос, Обработчик, множественную выгрузку объектов, а также файловые источники. Поэтому справочник, документ, регистр или сложный расчёт не обязаны выгружаться одинаково. Более того, в массовой выгрузке автоматическое сегментирование различается: для справочников может использоваться разбиение по наименованию, для документов и регистров — по периодам. Есть отдельные сценарии регистрации изменений по ссылке для документов.
Может ли Экстрактор работать с несколькими информационными базами одновременно и объединять данные в единую аналитическую модель?
Да. Несколько баз 1С могут выгружаться в одну аналитическую БД, а далее DVT может унифицировать структуру и собрать общую модель. В официальной документации есть отдельный пример консолидации данных из 1С:ERP и 1С:УНФ в одну базу-приёмник, включая добавление идентификатора исходной базы. Для группы компаний это может выглядеть так: ERP Москва + ERP Казань + УТ + УНФ → единый DWH → DVT → корпоративная витрина продаж.
Как решается проблема изменений структуры объектов 1С после обновлений? Можно ли выгружать только изменённые данные?
Да, и здесь это две разные задачи. Для изменения структуры контролируется схема и маппинг проекта. Если в конфигурации появились новые поля или изменились существующие, проект можно синхронизировать с новой моделью. Для объёма данных применяется инкрементальная выгрузка. Экстрактор регистрирует изменения, помещает их в очередь и выгружает только изменившиеся сегменты вместо полного ежедневного перечитывания всей базы. Расписание можно задавать на уровне проекта. Именно инкремент становится критичным, когда база уже измеряется сотнями гигабайт или терабайтами.
Поддерживаются ли типовые конфигурации 1С:ERP, УТ, БП, ЗУП?
Да. ERP, Управление торговлей, Бухгалтерия, ЗУП, УНФ и другие конфигурации 1С 8 поддерживаются (в том числе и кастомные).
Текущая линейка Экстрактора заявляет совместимость с конфигурациями 1С 8 на платформах 8.2, 8.3 и 8.5; на странице лицензий отдельно отмечено исключение для базовых версий. Кроме типовых конфигураций, можно работать и с доработанными решениями, поскольку Экстрактор ориентируется на метаданные конкретной информационной базы.
Можно ли построить нормальную аналитику, если данные сейчас собираются из нескольких Excel-файлов разных подразделений?
Да, конечно. Более того, это хороший первый шаг к отказу от ручной управленческой отчётности. Excel можно использовать как источник DVT, затем привести названия колонок и типы данных к единому формату, сопоставить подразделения и справочники, удалить некорректные строки, объединить файлы через Union и записать результат в централизованную таблицу. DVT напрямую поддерживает Excel и другие файловые форматы. Главная задача здесь — не визуализировать пять Excel, а превратить их в одну управляемую модель данных.
Как правильно получать данные из 1С, чтобы не нагружать рабочую систему?
Первое правило: отказаться от постоянных полных выгрузок больших таблиц. Для этого в Экстракторе используются инкрементальное обновление, сегментирование, расписания и управляемая многопоточность. Для больших объёмов PostgreSQL и MS SQL поддерживаются массовые способы вставки, а для небольших инкрементов используются другие режимы записи. При этом физику нельзя отменить: любая выборка данных потребляет ресурсы. Поэтому задача не в обещании «нулевой нагрузки», а в том, чтобы получать только нужные изменения, небольшими управляемыми порциями и в подходящее время, не заставляя BI обращаться непосредственно к продуктивной 1С.
Для небольших компаний на 1С:УНФ не рассматриваете?
Рассматриваем. УНФ поддерживается. Размер компании здесь вторичен. Если есть задача регулярно получать продажи, остатки, финансы или другие данные из УНФ для BI, Экстрактор можно использовать и в таком сценарии. В документации даже есть пример, где данные из 1С:ERP и 1С:УНФ объединяются в одной аналитической БД. Для небольшой компании вопрос скорее в экономике проекта: нужен ли полноценный DWH либо достаточно небольшой схемы УНФ → Экстрактор → БД → BI.
Какие данные нужно подготовить перед созданием первого дашборда?
Вопрос достаточно абстрактный, поскольку выбор данных и архитектуры напрямую зависит от конкретной бизнес-задачи. Прежде всего нужно определить бизнес-цель. Например — сократить объём просроченной продукции и связанные с ней потери. Далее формируется методика решения задачи. В данном случае это может быть логика автоматического перерасчёта стоимости товаров в зависимости от того, сколько времени остаётся до окончания срока годности. После этого определяется технологический стек — например, система, построенная на базе продуктов «Денвик Аналитика». Следующий этап — определить источники и приёмники данных внутри информационных систем. И только на этом шаге становится понятно, какие именно данные потребуются, где они находятся, в каком формате их нужно получать и куда передавать. Далее проект развивается уже по стандартной проектной методологии: проектирование потоков данных, настройка интеграций и преобразований, тестирование бизнес-логики, запуск и контроль результатов.
Выполнение проектов DVT
Почему проект долго стоит в очереди?
Воркеры могут быть заняты или недоступны. Проверьте состояние сервисов и текущие задачи. При регулярном ожидании разнесите расписания или обсудите с администратором число воркеров. См. запуск и очередь.
Почему чтение завершилось мгновенно, а запись работает долго?
Чтение и преобразования строят план, а нода результата выполняет его. Время записи включает чтение источника и преобразования. См. ленивые вычисления.
Что делать при нехватке памяти или медленной выгрузке?
При нехватке памяти уменьшите число потоков, проверьте размеры партиций и сократите данные до операций с полным набором. При свободных ресурсах измерьте эффект увеличения потоков, проверьте индекс колонки сегментации и размер пачки записи. См. производительность.
Почему «Стоп» не останавливает задачу сразу?
Обычная остановка ждёт завершения текущей ноды. Для немедленного прерывания используется принудительная остановка; перед повтором проверьте уже записанные данные. См. остановку проекта.
Почему после ошибки в таблице осталась только часть данных?
В режиме append пачки сохраняются по мере записи. Повтор может создать дубли. Проверьте загруженный диапазон и выберите способ восстановления согласно режиму записи.
Почему источник читается дважды?
Две ноды результата могут выполнять общую часть плана независимо. Проверьте возможность повторного использования кэша или сохранения промежуточного результата. См. несколько нод результата.
Почему база получает запросы, хотя чтение считается ленивым?
До основной выгрузки DVT получает метаданные и готовит разбиение. Для метаданных Dask обе ноды чтения V3 выбирают максимум одну строку. Отдельный режим получения метаданных Read Query использует запрос без строк или DESCRIBE, а Read Table получает структуру через SQLAlchemy Inspector. Для оценки размера строки возможна выборка до 1000 строк. См. служебные операции.
Означают ли первые 1000 строк в просмотре, что выгружены только они?
Нет. Это ограничение окна просмотра, а не всей обработки. Сохранённый результат может содержать больше строк; всё содержимое можно экспортировать в CSV. См. просмотр датафреймов.