Вчера BI читал данные из таблицы _AccumRg87428. После обновления конфигурации показатель пропал: физическая структура базы изменилась, а SQL-запрос остался прежним. Такое последствие прямого доступа описывает сравнение Infostart.
Вердикт зависит не от марки СУБД и не от выбранного сервиса. Прямой SQL подходит для нескольких простых выборок, которые контролирует специалист. ETL нужен, когда выгрузка работает по расписанию, преобразует данные, обслуживает несколько отчётов и должна продолжить работу после сбоя.
Задача — выбрать схему, которую не придётся караулить вручную. При этом аналитика не должна мешать пользователям 1С, а стоимость сопровождения должна быть понятна до запуска.
Прямой SQL быстрее запустить, но дороже сопровождать
При прямом доступе BI-система читает таблицы рабочей базы 1С в SQL Server или PostgreSQL. Между исходными данными и отчётом нет отдельного слоя выгрузки. Запрос сразу получает актуальные записи.
За коротким маршрутом скрывается устройство базы 1С. Объект конфигурации и физическая таблица SQL не совпадают. Denvic указывает, что данные одного объекта могут лежать в нескольких таблицах с техническими именами и служебными полями.
Ссылки между объектами тоже требуют расшифровки. Infostart показывает ещё две особенности: ссылочные значения хранятся как бинарные идентификаторы, а получение одного документа может потребовать нескольких соединений таблиц. Поэтому запрос, понятный автору сегодня, через год становится отдельным участком сопровождения.
Обновление платформы или реструктуризация базы меняет этот участок без согласования с BI. Представление перестаёт возвращать часть полей либо завершается ошибкой. Администратору приходится заново сопоставлять объекты 1С с физическими таблицами.
| Критерий | Что даёт прямой SQL | Чем за это платим |
|---|---|---|
| Актуальность | Отчёт читает текущее состояние рабочей базы | Аналитический запрос конкурирует с 1С за ресурсы СУБД |
| Сложные выборки | SQL поддерживает соединения, группировки и расчёты на стороне базы | Автор запроса должен понимать физическую структуру хранения 1С |
| Начальная настройка | Для одного отчёта не нужен отдельный процесс переноса данных | BI-системе нужны права доступа к SQL-серверу |
| Изменения конфигурации | Запрос можно быстро поправить под известную структуру | После реструктуризации таблиц запросы и представления приходится проверять заново |
| Сопровождение | Логика находится в знакомом SQL-коде | Расписание, журнал, повтор после ошибки и сверку данных нужно строить отдельно |
Прямой SQL сокращает путь до первого отчёта, но передаёт сопровождение администратору или разработчику интеграции.
Тяжёлый отчёт конкурирует с пользователями 1С
Рабочая база обслуживает проведение документов, фоновые задания и запросы пользователей. Аналитика приходит в ту же СУБД со своими соединениями, сортировками и агрегациями. Сравнение Infostart и материал Denvic предупреждают: тяжёлые запросы могут замедлить работу пользователей 1С.
Сначала проверьте, где возникает задержка. Повторный запуск помогает отделить ожидание данных от компоновки и вывода результата. Порядок такой проверки есть в материале о том, как локализовать задержку отчёта СКД.
Перенос запроса на ночную копию снимает конкуренцию с рабочими сеансами. Цена — задержка данных до следующего обновления. Сведения в утреннем отчёте отражают состояние базы на момент создания копии, а не на момент открытия отчёта.
Горячая реплика сокращает эту задержку, но требует дополнительных ресурсов. Реплику нужно поддерживать, контролировать её отставание и учитывать отказ отдельно от основной базы. Сам факт наличия второй СУБД проблему эксплуатации не закрывает.
Выбор между SQL Server и PostgreSQL тоже не определяет способ выгрузки. Обе СУБД могут обслуживать клиент-серверную 1С, а внешняя аналитическая база решает другую задачу. Если выбор движка ещё не сделан, сравните лицензирование и эксплуатационные свойства двух СУБД.
Для регулярной аналитики нужно принять отдельное решение: откуда читать данные.
- Рабочая база даёт минимальную задержку, но принимает нагрузку отчёта.
- Ночная копия отделяет аналитику от пользователей, но данные устаревают между копированиями.
- Реплика приближает отчёт к текущему состоянию, но добавляет инфраструктуру и контроль отставания.
Ни один вариант не подходит автоматически. Требуемая свежесть данных задаёт границу: если руководителю хватает вчерашнего закрытого дня, ночная копия проще реплики. Если отчёт управляет операциями в течение дня, задержку придётся сокращать и отдельно контролировать.
ETL отделяет передачу данных от отчёта
ETL — это управляемый процесс из трёх действий. Он забирает данные из 1С, преобразует их в промежуточном слое и загружает в хранилище. Такое определение и порядок этапов приводит DataFinder в сравнении инструментов интеграции 1С с BI.
В модели ELT порядок другой. Процесс сначала доставляет исходные данные в целевое хранилище, а затем преобразует их средствами этой базы. Такой вариант подходит, когда целевая платформа берёт вычисления на себя.
Для выбора между SQL и ETL различие важнее названий продуктов. Прямой запрос соединяет отчёт с физической базой 1С. ETL соединяет 1С с управляемым набором таблиц, а уже к ним подключаются отчёты.
Промежуточный слой принимает изменения структуры на себя. Если после обновления 1С поменялось поле, вы исправляете один процесс загрузки. Отчёты продолжают читать прежнюю витрину, если её контракт остался прежним.
Витрина — подготовленные таблицы для конкретной аналитической задачи. В них уже приведены типы, очищены значения и рассчитаны нужные показатели. Denvic отделяет такие таблицы от рабочей базы 1С: первая хранит данные для отчётов, вторая обслуживает учётные операции.
ETL не устраняет нагрузку сам по себе. Процесс всё равно читает данные из 1С и записывает их в другое хранилище. Его преимущество — в управлении этим чтением: запуске по расписанию, делении на пакеты, журнале шагов и повторе после ошибки.
Регулярная выгрузка состоит из двух режимов
Первый запуск обычно переносит весь выбранный набор данных. Infostart называет этот режим инициализацией. После него процесс переходит к регулярной загрузке.
Полная перезагрузка очищает целевые таблицы и заполняет их заново. По материалу Denvic такой способ подходит для небольших справочников и относительно статичных наборов. На растущих регистрах он повторно читает уже переданные записи и увеличивает окно обновления.
Инкрементальная загрузка переносит только добавленные и изменённые записи. DataFinder дополняет этот список удалениями: процесс должен уметь распознать их и отразить в целевой базе. Иначе отчёт продолжит учитывать то, чего в 1С уже нет.
Рабочий цикл выгрузки выглядит так:
- Начальная загрузка создаёт согласованное состояние целевых таблиц.
- Регулярный режим выбирает изменения после последной успешной точки.
- Процесс записывает начало шага и объём переданных строк в журнал.
- После ошибки загрузка возобновляется с известной точки либо повторяет пакет.
- Завершённый цикл сверяет количество записей или контрольные суммы на обеих сторонах.
Пункты с журналом и сверкой нельзя откладывать до первой аварии. Без них зелёный статус задания означает лишь то, что процесс завершился без пойманной ошибки. Он не доказывает, что BI получил полный набор.
Расписание не заменяет контроль
Специализированный инструмент умеет запускать выгрузку по расписанию. В сравнении Infostart эту возможность показывает «Экстрактор», который передаёт данные из 1С 8.3 в ClickHouse, PostgreSQL или Microsoft SQL. Но кнопка расписания закрывает только время старта.
Процесс должен отвечать ещё на четыре вопроса. Как он фиксирует последнюю успешную запись? Что делает с частично загруженным пакетом? Кому сообщает об ошибке? Как подтверждает полноту данных после завершения?
Denvic предлагает сквозной журнал: начало шага, количество переданных строк и завершение. Там же описаны уведомление администратора и сверка записей либо контрольных сумм между 1С и SQL. Эти механизмы превращают запуск по таймеру в контролируемую эксплуатацию.
Проверка нужна и после штатного завершения. Например, процесс мог получить пустой ответ из-за неверного фильтра, записать ноль строк и закончить без технической ошибки. Сверка заметит расхождение, а один статус задания — нет.
Граница проходит по цене сопровождения
Сравнивать SQL и ETL только по скорости первого запуска ошибочно. SQL часто выигрывает первый день: специалист пишет запрос, подключает BI и показывает результат. ETL требует подготовить целевые таблицы, режим обновления, журнал и обработку ошибок.
Дальше затраты меняются местами. Каждый новый отчёт копирует знания о таблицах 1С и правилах преобразования. При ETL эти знания остаются в одном процессе, а отчёты читают подготовленные наборы.
| Ситуация | Прямой SQL | ETL | Выбор |
|---|---|---|---|
| Один простой отчёт | Запрос можно поддерживать отдельно | Контур загрузки добавит лишнюю эксплуатационную работу | SQL |
| Несколько отчётов используют одни показатели | Логику придётся повторять в запросах или представлениях | Общая витрина хранит правила подготовки один раз | ETL |
| Данные нужны по расписанию | Планировщик придётся связать с журналом и уведомлениями | Расписание входит в общий процесс загрузки | ETL |
| Нужны очистка и преобразования | Логика остаётся внутри SQL-запросов к структуре 1С | Преобразования выполняются до загрузки или в целевой базе | ETL или ELT |
| После сбоя нужен автоматический повтор | Механизм восстановления нужно проектировать отдельно | Процесс можно разбить на повторяемые пакеты с контрольной точкой | ETL |
| Допустим прямой доступ к СУБД | BI читает базу без промежуточного слоя | Появляются ещё один сервис и целевое хранилище | SQL при простом отчёте |
| Аналитика мешает пользователям | Запрос придётся переносить на копию или реплику | Загрузку тоже нужно вынести в тихое окно, разбить на пакеты или направить на реплику | Выбор архитектуры чтения важнее инструмента |
SQL оправдан, пока один специалист видит весь контур и может исправить его после изменений. ETL окупает свою сложность, когда сопровождение нужно отделить от отдельных отчётов.
Таблица не задаёт пороги по размеру базы или времени выгрузки. В представленных материалах нет сопоставимых замеров с общей методикой. Поэтому границу лучше проводить по наблюдаемым требованиям: числу потребителей, наличию преобразований, расписанию и восстановлению после ошибки.
Коннектор не отменяет проектирование нагрузки
Готовый коннектор копирует данные из 1С в хранилище, но для него нужны вычислительные ресурсы, сетевой доступ и место под целевые таблицы. SK.Data отдельно относит настройку инфраструктуры и дополнительные расходы к ограничениям такого подхода.
Читайте с рабочей базы только тогда, когда запросы укладываются в допустимое окно нагрузки. Иначе перенесите запуск на часы низкой активности, разбейте чтение на пакеты или используйте реплику. Эти три приёма описывает Denvic.
Пакеты ограничивают объём одной операции. При ошибке не приходится повторять всю выгрузку, если процесс хранит подтверждённую точку. Но слишком частые параллельные пакеты снова создадут конкуренцию за ресурсы, поэтому их размер и число проверяют на вашей базе.
Заранее отделите начальную загрузку от регулярной. Первая читает накопленную историю и создаёт максимальную нагрузку. Вторая переносит изменения и должна укладываться в выбранный интервал обновления.
Как выбрать схему до начала работ
Берите прямой SQL, если нужен один контролируемый отчёт, преобразования невелики, доступ к СУБД допустим, а специалист готов проверять запрос после обновлений 1С. Подключение лучше направить к копии или реплике, если аналитика заметно влияет на рабочие сеансы.
Берите ETL, если данные уходят по расписанию, питают несколько отчётов, требуют очистки или должны восстановиться после сбоя без ручного поиска пропущенных записей. ELT подходит, когда преобразования удобнее выполнять внутри целевого хранилища.
Перед запуском зафиксируйте пять решений:
- Назовите требуемую свежесть данных: текущее состояние, обновление несколько раз за рабочий день или закрытый предыдущий день.
- Выберите место чтения: рабочая база, ночная копия или реплика.
- Разделите начальную загрузку истории и регулярный перенос изменений.
- Записывайте в журнал начало, результат каждого шага и точку продолжения.
- Сверяйте количество строк либо контрольные суммы между 1С и целевой базой.
Если хотя бы два отчёта повторяют одну логику подготовки, вы уже платите за отсутствие общего слоя. Перенесите правила в ETL или ELT, а отчётам отдайте согласованную витрину. Если отчёт один и его запрос понятен владельцу, прямой SQL останется более простой схемой.