Как построить конвейер данных для BI: видео вебинара + ответы про 1С, ETL, DVT и DWH

Ответы на вопросы:

Да, такая архитектура вполне рабочая: первый слой — сырые или минимально обработанные данные из источников, второй — аналитические витрины, уже подготовленные под BI. Но два слоя — не ограничение платформы. В более сложном DWH мы можем разделить архитектуру на Raw/Staging → интеграционный слой → Data Marts. Экстрактор 1С отвечает прежде всего за стабильное получение данных из 1С, а DVT — за очистку, объединение, преобразование и формирование витрин. В документации Экстрактора даже отдельно отмечено, что сложные преобразования лучше переносить из слоя извлечения в последующий ETL.

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

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

Да. Мы не требуем сразу строить корпоративное 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. Такой подход не смешивает механику получения данных и бизнес-логику аналитики.

Это один из основных сценариев DVT. Например, из 1С приходит номенклатура и продажи, из CRM — лиды и сделки, из Excel — планы подразделений. В DVT можно привести типы полей к единому виду, нормализовать названия, удалить пустые значения, сопоставить справочники, выполнить Join/Union, рассчитать новые показатели и записать результат в одну витрину. То есть BI получает уже не четыре разрозненных источника, а подготовленную аналитическую модель.

Здесь нужно разделять техническое изменение и изменение бизнес-смысла. Добавление поля, изменение структуры объекта или обновление конфигурации требует проверки схемы и маппинга проекта. Экстрактор работает с метаданными 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 в централизованный слой подготовки данных. Если один и тот же показатель рассчитывается отдельно в DataLens, Power BI и ещё двух отчётах, со временем появляются четыре версии формулы. Мы предпочитаем схему: 1С → Экстрактор → DWH → DVT → витрина → BI. Экстрактор закрывает промышленное извлечение из 1С, DVT - ETL/ELT и витрины, BI остаётся слоем анализа и визуализации. Инжектор 1С добавляется, когда преобразованные данные нужно вернуть обратно в 1С. Продукты можно использовать независимо друг от друга.

Да. Можно взять только Экстрактор или DVT, а можно реализовать всю цепочку:
обследование источников → архитектура DWH → получение данных → ETL → модель → витрины → BI-дашборды → ввод в промышленную эксплуатацию. 
На нашем сайте отдельно представлены внедрения DataLens, Visiology и PIX BI, а сама линейка решений рассчитана на проекты от выгрузки 1С до готового BI-контура.
Но возможен любой ваш сценарий.

Да. Один процесс подготовки данных может формировать результат для нескольких целевых систем. Это позволяет использовать единую бизнес-логику подготовки и не создавать отдельные цепочки обработки под каждую СУБД.

Excel может использоваться как один из источников данных в общем аналитическом контуре. 

DVT позволяет:

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

Да. И это один из наиболее логичных сценариев внедрения. 
Например: 
1С + CRM + Excel → DVT → ClickHouse → существующий Power BI или: источники → DVT → PostgreSQL → существующий DataLens. 

DVT не требует менять BI. Он формирует подготовленные таблицы и витрины, к которым ваша текущая BI-система продолжает подключаться привычным способом.

В DVT есть авторизация и управление пользователями; документация описывает добавление пользователей, а интерфейс — проекты и папки. 

Да. Экстрактор поддерживает несколько типов источника: Объект, Запрос, Обработчик, множественную выгрузку объектов, а также файловые источники. Поэтому справочник, документ, регистр или сложный расчёт не обязаны выгружаться одинаково. 
Более того, в массовой выгрузке автоматическое сегментирование различается: для справочников может использоваться разбиение по наименованию, для документов и регистров — по периодам. Есть отдельные сценарии регистрации изменений по ссылке для документов.

Да. Несколько баз 1С могут выгружаться в одну аналитическую БД, а далее DVT может унифицировать структуру и собрать общую модель. 
В официальной документации есть отдельный пример консолидации данных из 1С:ERP и 1С:УНФ в одну базу-приёмник, включая добавление идентификатора исходной базы. 

Для группы компаний это может выглядеть так: 
ERP Москва + ERP Казань + УТ + УНФ → единый DWH → DVT → корпоративная витрина продаж.

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

Для объёма данных применяется инкрементальная выгрузка. Экстрактор регистрирует изменения, помещает их в очередь и выгружает только изменившиеся сегменты вместо полного ежедневного перечитывания всей базы. Расписание можно задавать на уровне проекта. 
Именно инкремент становится критичным, когда база уже измеряется сотнями гигабайт или терабайтами.

Да. ERP, Управление торговлей, Бухгалтерия, ЗУП, УНФ и другие конфигурации 1С 8 поддерживаются (в том числе и кастомные). 

Текущая линейка Экстрактора заявляет совместимость с конфигурациями 1С 8 на платформах 8.2, 8.3 и 8.5; на странице лицензий отдельно отмечено исключение для базовых версий. 
Кроме типовых конфигураций, можно работать и с доработанными решениями, поскольку Экстрактор ориентируется на метаданные конкретной информационной базы.

Да, конечно. Более того, это хороший первый шаг к отказу от ручной управленческой отчётности. 
Excel можно использовать как источник DVT, затем привести названия колонок и типы данных к единому формату, сопоставить подразделения и справочники, удалить некорректные строки, объединить файлы через Union и записать результат в централизованную таблицу. DVT напрямую поддерживает Excel и другие файловые форматы. 

Главная задача здесь — не визуализировать пять Excel, а превратить их в одну управляемую модель данных.

Первое правило - отказаться от постоянных полных выгрузок больших таблиц. 

Для этого в Экстракторе используются инкрементальное обновление, сегментирование, расписания и управляемая многопоточность. Для больших объёмов PostgreSQL и MS SQL поддерживаются массовые способы вставки, а для небольших инкрементов используются другие режимы записи. 

При этом физику нельзя отменить: любая выборка данных потребляет ресурсы. Поэтому задача не в обещании «нулевой нагрузки», а в том, чтобы получать только нужные изменения, небольшими управляемыми порциями и в подходящее время, не заставляя BI обращаться непосредственно к продуктивной 1С.

Рассматриваем. УНФ поддерживается. 

Размер компании здесь вторичен. Если есть задача регулярно получать продажи, остатки, финансы или другие данные из УНФ для BI, Экстрактор можно использовать и в таком сценарии. 

В документации даже есть пример, где данные из 1С:ERP и 1С:УНФ объединяются в одной аналитической БД. 

Для небольшой компании вопрос скорее в экономике проекта: нужен ли полноценный DWH либо достаточно небольшой схемы УНФ → Экстрактор → БД → BI.

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

Прежде всего нужно определить бизнес-цель. Например — сократить объём просроченной продукции и связанные с ней потери. 

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

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

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

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