Инкрементальная выгрузка данных из 1С в BI: как настроить передачу изменений и не потерять данные

При этом каждый запуск обрабатывает и перезаписывает весь массив данных, даже если изменился 1–2% записей. 

Необходимость выполнять такую выгрузку несколько раз в день — например, для регулярного обновления показателей в BI, — приводит к росту нагрузки на систему. 

Она начинает конкурировать за ресурсы с пользовательскими операциями,что вызывает зависания интерфейса и взаимоблокировки. 

В таких условиях единственное верное решение — перестроить архитектуру интеграции и передавать только дельту данных. 

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

Что такое инкрементальная выгрузка и как она работает

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

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

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

Эти подходы решают разные задачи и дополняют друг друга. На практике их используют в рамках одного процесса обновления данных. 

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

 Изменения делятся на три типа: 

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

Настройка интеграции в формате инкрементальной загрузки дает бизнесу два основных преимущества:

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

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

Как на практике отслеживают изменения в данных

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

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

▎ 1. По глубине — временному периоду 

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

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

Ограничения: не гарантирует полноту данных. Ограничен выбранным периодом: изменения за его пределами в выгрузку не попадут. Например, если документ изменили за рамками скользящего окна выгрузки, система его не учтет. Чтобы снизить этот риск, период искусственно увеличивают, что снова приводит к росту объема данных и времени обработки.

▎ 2. По триггерам — событиям.  

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

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

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

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

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

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

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

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

Что нужно учитывать при внедрении инкрементального обмена

От чего зависит надежность инкрементальной выгрузки:

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

▎ 1. Отслеживание изменений

На этом этапе полнота выгрузки зависит от того, все ли нужные изменения система зафиксировала и включила в очередное обновление. 

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

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

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

▎ 2. Инструменты повышения надежности доставки 

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

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

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

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

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

Контроль корректности передачи. После выгрузки необходимо сверять количество строк, контрольные суммы и статусы обработки. Это помогает убедиться, что данные дошли полностью и не изменились по пути.

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

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

Как автоматизировать процесс инкрементальной выгрузки данных из 1С:

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

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

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

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

Он позволяет:

• автоматически выгружать данные из 1С в любые внешние хранилища: ClickHouse, PostgreSQL, Microsoft SQL Server, MySQL и другие;
• фиксировать изменения и передавать только актуальную дельту данных;
• отслеживать удаленные записи, чтобы избежать рассинхронизации;
• восстанавливать процесс после сбоев за счет повторной доставки непринятых пакетов;
• контролировать целостность передачи данных между 1С и хранилищем;
• работать с несколькими базами 1С в рамках единого контура интеграции;
• настраивать расписание обновления данных для BI без участия разработчиков;
• оптимально использовать ресурсы системы. В ходе нагрузочных испытаний при интенсивности нагрузки до нескольких десятков тысяч операций в минуту не вызывает деградации производительности базы 1С.