Куда выгружать данные из 1С для BI: ClickHouse, PostgreSQL, MS SQL или 1С:Шина, Kafka, Artemis

Зачем выгружать данные из 1С для BI в отдельный контур 

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

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

Прямое подключение BI к 1С создает дополнительные риски: 

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

Что дает отдельная аналитическая база или витрина

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

В результате компания: 

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

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

Почему нельзя выбирать технологию без требований 

При построении BI-архитектуры нужно определить, где хранить данные и как организовать обмен между системами. Для этого используют разные технологии. PostgreSQL, MS SQL и ClickHouse — СУБД, которые применяют для хранения и аналитической обработки данных, а Kafka, Artemis и 1С:Шина — инструменты для передачи сообщений и событий между системами. 

Перед выбором технологии учитывают: 

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

После этого выбирают архитектуру и уже под нее — базу данных, витрины и при необходимости транспортный слой данных.

База данных или шина: в чем разница для BI-архитектуры 

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

Что делает аналитическая база данных 

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

Поэтому данные выгружают в отдельную аналитическую базу, в которой можно: 

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

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

Типовая схема: 

1С и другие источники → аналитическая база → витрины → BI 

Что делает шина данных или брокер сообщений 

Шина данных необходима для обмена событиями без прямых связей между каждым приложением. Она разделяет источник данных и потребителей: 1С передает информацию один раз, а подключенные системы получают ее для своей обработки. 

К примеру, после изменения заказа в 1С событие передается в несколько решений: одно обновляет остатки, другое запускает бизнес-процесс, третье сохраняет информацию для аналитики. 

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

Когда нужна база, а когда шина

База данных и шина решают разные задачи: транспортный слой отвечает за передачу изменений между системами, а аналитическая база — за хранение и подготовку сведений для BI. 

PostgreSQL, MS SQL или ClickHouse: какую базу выбрать для данных из 1С 

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

PostgreSQL для данных из 1С 

Когда подходит 

PostgreSQL выбирают, когда аналитику необходимо структурировать и нормализовать хранение данных, скажем, в рамках 3-й нормальной формы, когда каждая атомарная сущность выгружается в свою таблицу и все таблицы связываются между собой. В работе с PostgreSQL стараются избегать денормализации данных. 

Такой подход к организации данных (2NF, 3NF, Data Vault) экономит место на диске и упрощает изменение структуры данных, но требует сложных SQL-запросов с большим количеством JOIN, что увеличивает время выполнения отчетов. PostgreSQL подходит для построения хранилищ данных (DWH) со сложной моделью данных, версионностью и большим количеством связей между сущностями. 

Что получает бизнес 

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

MS SQL для данных из 1С 

Когда подходит 

MS SQL выбирают компании, где уже используется инфраструктура Microsoft и есть специалисты по SQL Server. В этом случае аналитический контур можно встроить в текущую ИТ-среду: использовать существующие процессы администрирования, настройки доступа и инструменты контроля работы базы. MS SQL применяют для хранения информации из 1С, подготовки витрин и подключения BI, когда компании важно сохранить единый технологический стек. 

Что получает бизнес 

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

ClickHouse для данных из 1С 

Когда подходит 

ClickHouse используют, когда бизнесу нужны готовые аналитические витрины (большие аналитические таблицы с множеством колонок), что позволяет строить быстрые аналитические запросы по большим объемам исторической информации. Например, если требуется анализировать продажи за несколько лет, сравнивать показатели по регионам, товарам и клиентам или регулярно пересчитывать крупные витрины, ClickHouse помогает сократить время выполнения таких запросов. 

Также Clickhouse используется как СУБД для построения Data Mart (витрин данных). При этом часто источником данных для таких витрин являются базы данных на PostgreSQL, в которых данные разложены в соответствии с той или иной формой нормализации. 

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

Одним из известных классических способов организации таких денормализованных витрин данных в Clickhouse является метод Ф. Пуппини «Унифицированная схема звезда» (Puppini Bridge). 

Что получает бизнес 

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

Когда нужны 1С:Шина, Kafka или Artemis 

Если изменения из 1С необходимо передавать не только в BI, но и в CRM, склад или другие сервисы, прямых связей между всеми приложениями быстро становится много. Для таких задач используют 1С:Шину, Kafka или Artemis — выбор зависит от количества участников обмена, объема сообщений и требований к скорости доставки. 

Когда выбирают 1С:Шину 

1С:Шина — интеграционная шина для обмена информацией между решениями 1С и другими системами. 

Ее применяют, когда нужно: 

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

Например, после оформления продажи в 1С:ERP информация поступает в систему управления складом, CRM или сервис доставки. Обмен настраивают с учетом логики работы 1С, поэтому специалисты, которые уже сопровождают учетную систему, могут участвовать в доработке и поддержке интеграции. 

Что получает бизнес 

Компания сокращает количество ручных операций при передаче данных и может быстрее подключать новые системы к обмену с 1С. 

Когда выбирают Kafka 

Kafka — брокер сообщений и платформа потоковой передачи событий для высоконагруженных интеграций. 

Kafka используют, когда несколько систем должны получать одни и те же изменения, а объем обмена быстро растет. 

Например, изменение заказа из 1С может одновременно передаваться: 

• в складскую систему для обновления остатков; 
• в CRM для работы с клиентом; 
• в аналитическую базу для подготовки BI-отчетов; 
• в другие сервисы, которые используют эту информацию. 

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

Что получает бизнес 

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

Когда выбирают Artemis 

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

Artemis выбирают, когда требуется гарантированная доставка через очереди, а объем и скорость обмена ниже, чем в потоковых архитектурах. Например, компания передает справочники, заказы или статусы между 1С и CRM. Если система-получатель временно недоступна, брокер сохраняет сообщение и доставляет его после восстановления соединения. 

Что получает бизнес 

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

Что учитывать при выборе инструмента обмена 

Перед выбором 1С:Шины, Kafka или Artemis важно оценить требования к обмену и возможности команды разработки, которая будет настраивать и поддерживать решение. 

При выборе учитывают: 

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

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

Сравнение решений для BI-архитектуры: ClickHouse, PostgreSQL, MS SQL, 1С:Шина, Kafka и Artemis 

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

Как выбрать архитектуру под свой сценарий BI 

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

Если достаточно регулярного обновления отчетов 

Для стандартных BI-отчетов достаточно реляционной базы — PostgreSQL или MS SQL. Решение подходит, когда компания строит витрины по продажам, закупкам, остаткам и другим показателям, а обновление происходит по расписанию. 

Если нужны быстрые отчеты по большой истории 

Когда объем витрин растет, а пользователи работают с тяжелыми отчетами и сложными расчетами, рассматривают ClickHouse. Он лучше подходит для аналитики по большим объемам исторической информации. 

Если изменения из 1С должны поступать в несколько источников 

Если изменения из 1С должны одновременно поступать в несколько систем, используют шину данных или брокер сообщений. 

Выбор зависит от сценария: 

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

Если есть несколько потребителей данных 

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

Например, после изменения заказа в 1С: 

• склад обновляет остатки; 
• CRM получает сведения для работы с клиентом; 
• BI сохраняет показатели для отчетов. 

Подключать новые системы становится проще, а количество прямых связей между источниками уменьшается. 

Если нужны и обмен, и аналитика 

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

• брокер сообщений или шина передает изменения; 
• PostgreSQL, MS SQL, ClickHouse или DWH хранят информацию и обеспечивают работу аналитических запросов. 

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

Какие ошибки избегать при выборе 

• Выбирать ClickHouse только потому, что он быстрый. 
  Колоночная база показывает преимущества на подготовленных витринах и больших объемах. Если перенести в нее данные без учета структуры запросов, результат может оказаться хуже ожидаемого. 
• Использовать Kafka, когда событийный обмен не нужен. 
  Если отчеты обновляются раз в день, брокер сообщений добавит сложность, но не даст заметной пользы. 
• Строить BI напрямую через шину. 
  Шина и брокеры сообщений передают изменения, но не заменяют хранилище для отчетов. Для аналитики используют подготовленные витрины и базы. 
• Не учитывать сопровождение. 
  При выборе решения важно оценить не только возможности технологии, но и наличие специалистов, которые смогут ее поддерживать. 

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

Как Денвик Аналитика помогает построить контур данных для BI 

После того как выбраны архитектура, база данных и способ обмена, остается собрать их в единый рабочий контур. Важно не только определить, куда выгружать информацию из 1С, но и организовать стабильное обновление, подготовку витрин и подключение BI без ручных операций. Для этих задач Денвик Аналитика использует разные инструменты — в зависимости от требований к хранению данных и интеграции систем. 

Автоматическая выгрузка данных из 1С для BI 

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

Экстрактор 1С помогает настроить автоматическую выгрузку необходимых объектов и изменений из рабочих баз 1С в аналитические хранилища и BI-системы. Информация может поступать в различные СУБД (PostgreSQL, MS SQL, ClickHouse и др.) и затем использоваться в BI-системах и других решениях — в зависимости от выбранной архитектуры. Компания получает регулярное обновление данных для аналитики без ручной выгрузки и дополнительной нагрузки на рабочую базу 1С. 

Объединение информации для аналитики 

Для BI-отчетов нужно использовать не только сведения из 1С. Например, к продажам и остаткам добавляют данные из CRM, складских систем, интернет-магазина и Excel-файлов. 

DVT помогает настроить загрузку и обработку информации из разных источников: объединить записи, очистить данные, привести справочники к одному формату и подготовить витрины для BI. В визуальном редакторе можно задать правила загрузки, объединения и преобразования данных, а также контролировать результаты выполнения процессов. 

Внедрение BI-системы Yandex DataLens 

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

BI-система Yandex DataLens позволяет создавать отчеты и дашборды на основе данных из разных систем, используя единые правила расчета показателей. Сотрудники получают согласованные значения для анализа без ручной сверки между системами.