В современном бизнесе все более актуальным становится подход принятия решений на основе данных (data-driven), позволяющий минимизировать влияние человеческого фактора и снизить уровень оценочных суждений, заменяя их управленческими решениями, основанными не на эмоциях, а на фактах. Однако data driven — это не просто анализ прошлых и текущих данных, а возможность прогнозировать будущее, опираясь на все доступные данные.

В современной компании обычно имеется огромное количество данных, которые могут улучшить качество бизнес-аналитики по ее деятельности: метрики веб-сайтов, информация из систем ERP и CRM, данные из производственных систем, рабочие планы и прочие данные из Excel, базы данных, сведения из систем MES, BPM и других источников. Для дата-инженеров задача извлечения данных из альтернативных источников в общем случае относительно понятна и обычно проблем не вызывает, однако, например при работе в экосистеме «1С», имеется ряд ограничений.

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

Рис. 1. Пример корпоративного информационного ландшафта

Для экосистемы «1С» имеется несколько основных механизмов извлечения данных.

  • Выгрузка автоматически или вручную. Данные могут быть выгружены в форматы Excel, CSV и DBF.
  • Выгрузка по открытому веб-протоколу OData. Протокол можно использовать в качестве REST API для доступа к данным.
  • Прямой доступ к базе данных через SQL. Выполнение запросов к данным напрямую из реляционной базы данных.
  • Веб-сервисы. Для интеграции с другими системами можно разрабатывать собственные веб-сервисы.
  • «1С: Шина». Применение встроенной в «1С» шины для обмена данными между системами.
  • Собственные системы выгрузки. Разработка индивидуальных решений для извлечения данных из «1С» во внешние для этой экосистемы базы данных.

Для успешной выгрузки данных в Excel и формат CSV необходимо наличие в конфигурации «1С» отчета, позволяющего формировать данные по документам, справочникам и движениям регистров. Результаты отчета можно сохранить в формате Excel или CSV, что позволяет загружать их в системы бизнес-аналитики или анализировать в Excel. Основная проблема заключается в том, что отчеты формируются вручную, что требует значительных ресурсов — требуется ежедневно выполнять рутинные операции формирования отчета, его сохранения и загрузки в систему BI. Конечно, все эти процессы можно автоматизировать, например, с помощью программных роботов или программирования, однако каждый новый источник данных потребует разработки нового отчета и автоматизации процесса его выгрузки. В случае больших баз данных «1С» с миллионами транзакций выгрузка даже нескольких сотен тысяч строк может стать серьезной проблемой.

OData представляет собой доступный «из коробки» REST API для извлечения данных из «1С». Это решение упрощает доступ к данным и позволяет интегрировать «1С» с другими системами, что значительно расширяет возможности анализа и использования данных. Для небольших и простых баз OData — вполне рабочий инструмент, однако с увеличением объема данных этот механизм становится не эффективным.

Для успешной публикации базы «1С» на веб-сервере необходимо не только выделить ресурсы на размещение базы на сервере, но и разработать программный код, отправляющий запросы к OData-сервису и обрабатывающий ответы. Однако работа с OData сопряжена с рядом проблем.

  • Обработка больших объемов данных. При наличии значительного объема данных потребуется организация выборки данных порциями, что может привести к необходимости передачи большого количества параметров в get-запросе и повлечь за собой исчерпание лимита длины URL в 255 символов.
  • Отслеживание изменений. Реализация системы отслеживания изменений в OData не всегда очевидна и требует дополнительных усилий.
  • Производительность. Поскольку «1С» — достаточно медленная система, может потребоваться сложная конструкция распараллеливания процесса выгрузки данных.

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

В экосистеме «1С» имеется возможность взаимодействия через протоколы HTTPS по запросам GET, POST, PUT и пр., что позволяет через внешний интерфейс веб-сервера вызывать заданные программистом «1С» методы. Для этого требуется разработка специального программного кода, который будет либо предоставлять готовые наборы данных, либо принимать запросы и выполнять соответствующие действия для возврата данных. Для обработки данных из веб-сервиса «1С» потребуется сервис, который будет получать из «1С» данные и загружать их в целевую базу данных. Для работы с веб-сервисами «1С» требуется внешний сервис или программный код, который инициирует обращения и обрабатывает полученные данные. При большом объеме данных необходимо реализовать инкрементальную выгрузку, что требует механизма отслеживания изменений в «1С». Кроме этого публикация базы «1С» на веб-сервере может вызвать беспокойство у сотрудников службы безопасности, так как в «1С» могут храниться персональные и чувствительные данные, доступ к которым должен быть строго ограничен.

Прямой доступ к базе данных «1С» — один из древних способов получения данных, известный еще с версии «1С 7.7» и для извлечения данных предполагающий подключение напрямую к физической базе Microsoft SQL Server или PostgreSQL. Однако кроме наличия прямого подключения необходимы коннекторы для преобразования названий таблиц и полей в метаданные «1С» — данные в «1С» хранятся в машиночитаемом виде. При прямом способе извлечения данных оказываются недоступны многие функции «1С», такие как виртуальные таблицы остатков и оборотов, работа с субконто и доступ к данным «через точку». Мало того, прямой доступ к СУБД может быть запрещен лицензионным соглашением с компанией «1С». Среди других недостатков прямого доступа можно еще назвать отсутствие механизмов отслеживания изменений — нет возможности определить последние изменения в базе, что требует извлечения данных «от начала времен», а также вероятность возникновения неконтролируемой нагрузки на СУБД, приводящей к задержкам в работе пользователей.

«1С: Шина» (Сервисная шина данных) — новое понятие для экосистемы «1С». Этот сервис потенциально может стать альтернативой Apache Kafka, особенно при интеграции нескольких баз «1С», а также неплохим выбором для системы гарантированной доставки сообщений. Сервис предоставляет встроенные механизмы интеграции и упрощает настройку процедур выгрузки данных, поддерживая JDBC-драйверы для работы с СУБД. Вместе с тем «1С: Шина» в первую очередь служит транспортом для доставки сообщений и в ней нет универсальных механизмов для подготовки и отправки сообщений — все это необходимо разрабатывать самостоятельно (какие-либо решения категории No-Code отсутствуют). Нет также специализированных инструментов для отслеживания изменений, и здесь снова потребуется разработка дополнительных решений. На текущий момент система требует хранения данных в Регистре сведений и фоновых заданиях для отправки сообщений в «1С: Шину». Если у компании имеется сильная команда «1С»-программистов и ресурсы на разработку, то «1С: Шина» может стать неплохим решением для организации системы выгрузки данных, аналогично RabbitMQ или Apache Kafka.

Рис. 2. Роль программиста в традиционной компании

Создание собственной системы выгрузки данных из «1С» во внешние базы данных — задача, которую лучше всего решают только опытные программисты «1С», обладающие глубокими знаниями по этой экосистеме. Если такие специалисты имеют навыки работы с различными СУБД, очередями сообщений, хранилищами данных и системами бизнес-аналитики, то вероятность успешной разработки собственной системы выгрузки данных возрастает. Однако программисты всегда заняты — каждый «узкий» специалист всегда становится «бутылочным горлышком» (рис. 2) процесса принятия решений, производства или оказания услуг. Программистов часто не хватает для выполнения всех текущих задач в компании, и программисты «1С» не исключение.

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

Идея разработки инструмента «Экстрактор 1С» возникла в результате выполнения ряда разных проектов с примерно одинаковыми требованиями: пользователи хотели самостоятельно настраивать выгрузки, без привлечения программистов; поддержка любых версий «1С»; обеспечение высокой производительности; отслеживание изменений в «1С» с возможностью выгрузки только измененных данных.

Рис. 3. Программист в современной компании

Требовалось создать систему, в которой программист не был бы «узким горлом» (рис. 3).

Как улучшить бизнес-аналитику?
Рис. 4. Архитектура «Экстрактор 1С»

«Экстрактор 1С» представляет собой приложение для платформы «1С» — расширение (встройка) конфигурации, предоставляющее пользователям возможность выбора объектов для выгрузки из баз «1С» или формирования произвольных запросов, которые можно использовать в качестве источника данных (рис. 4). Пользователь может выполнять трансформацию данных, вычисляя дополнительные поля и модифицируя выгружаемые данные с помощью функций "1С". Кроме этого можно создавать и изменять таблицы-приемники в СУБД или темах Apache Kafka, сопоставляя поля и их типы, а также настраивая структуру таблиц, индексы и ключи. Обеспечивается отслеживание изменений для выгружаемых объектов «1С», а также установка выгрузки объектов по расписанию в СУБД или в очередь, с возможностью настройки интервала от одного дня до одной секунды.

Источники данных для «Экстрактора 1С» могут включать: объекты «1С» или их комбинации, связанные в рамках факт-измерений; произвольные запросы «1С», включая временные и виртуальные таблицы; программные обработчики, где в качестве источника служит код «1С»; CSV-файлы с доступом через сетевой ресурс для сервиса «Сервер 1С»; Excel-файлы.

Приемниками данных могут быть: СУБД (ClickHouse как на серверах пользователя, так и в облачных конфигурациях; PostgreSQL с доступом через ODBC или http-сервис db-proxy-service для «1С» на Linux; Microsoft SQL Server); очередь сообщений Apache Kafka, поддерживающая выгрузку через компонент Confluent (REST API), с автоматическим созданием схемы и тем. Для высоконагруженных баз данных в «Экстракторе 1С» предусмотрен дополнительный сервис http_redis, который позволяет хранить очередь изменений «1С» во внешней базе данных, такой как Redis (аналог PicoData) или Apache Ignite (аналог DataGrid).

В режиме самообслуживания пользователи без привлечения программистов могут выбирать и настраивать объекты «1С» для выгрузки данных, в автоматическом режиме создавать и модифицировать таблицы-приемников. Отслеживание изменений полностью автоматизировано. Имеются инструменты для трансформации данных и формирования моделей выгрузки на основе фактов и измерений. Благодаря параллельной обработке потоков обеспечивается высокая производительность выгрузки.

***

Сегодня «Экстрактор 1С» используется в 230 компаниях в России и СНГ, позволяя различным компаниям автоматизировать выполнение процессов ETL для обеспечения работы бизнес-аналитиков в режиме самообслуживания со всеми доступными данных, включая и сведения из закрытой экосистемы «1С».

Денис Смирнов (denis@denvic.ru) — генеральный директор, компания «Денвик». Статья подготовлена на основе материалов выступления на форуме «Управление данными 2024».