Почему read-нагрузка напрямую в 1С — архитектурный антипаттерн

HR Data Domain · Май 2026 · Решение: CDC → HRDWH → витрина

1. Что такое 1С в нашем контексте

1С:Предприятие 8 — операционная ERP-система с архитектурой "сервер приложений + СУБД". У нас используются конфигурации ЗУП (кадры, ЗП), ДО (документооборот), УХ (управление холдингом).

ПараметрЗначение
АрхитектураКластер серверов приложений 1С + PostgreSQL (единая база)
Размер базы~1.5–2 ТБ на конфигурацию
Количество таблиц2 000+ (генерируются платформой, имена обфусцированы: _Reference123, _InfoRg456)
Доступ к БД напрямуюНевозможен — структура зашифрована платформой, имена таблиц/полей нечитаемы без метаданных конфигурации
МасштабированиеТолько вертикальное. Шардирование БД не поддерживается платформой
КластеризацияДобавление серверов приложений (балансировка сессий). БД остаётся единой точкой

Почему нельзя ходить в базу 1С напрямую

2. Решение: CDC → HRDWH → витрина

1С:ЗУП PG 1.5-2 TB 2000+ таблиц CDC push Kafka Airflow + dbt DQ-проверки WAP-паттерн HRDWH Trino + Iceberg + Ceph 510 GB, 7 слоёв RLS + masking Redash Микросервисы MCP / AI HR BP / C&B 0 read от потребителей

Принцип: 1С генерирует CDC-события (push). Потребители читают из витрины HRDWH. Прямого доступа к базе 1С нет ни у кого, кроме самой платформы 1С.

3. Сравнение: прямой доступ vs ДВХ-витрина

Критерий❌ Прямой read в 1С✅ Через HRDWH
Возможность доступаНевозможен — схема обфусцирована, таблицы нечитаемыВитрина с понятной схемой, документированная
Нагрузка на источникКаждый запрос = I/O на PG 1.5 ТБНоль. CDC push, 1С не знает о потребителях
Скорость ответаНепредсказуемая. Full scan 2000+ таблиц<2 сек на 10M строк (Trino columnar)
МасштабированиеНет шардирования. Единая БД. Только вертикальноГоризонтально: +worker в Trino
КластеризацияТолько серверы приложений. БД = единый bottleneckTrino кластер + Ceph distributed storage
Контроль качестваНет. Данные as-is из операционной системы7 DQ-измерений, Circuit Breaker, карантин
ПерсонализацияНевозможна на уровне PG под 1СRow-Level Security в Trino
Маскирование ПДНетColumn-level masking
АудитТолько журнал регистрации 1С (не SQL-уровень)Query log: кто, когда, что запросил
При сбое источникаВсе потребители лежатДанные в Ceph, потребители работают
СвежестьReal-time (если бы был доступ)Near real-time: CDC lag 1-5 мин
MCP/AI-агентыНевозможно подключить к обфусцированной схемеСтандартный SQL, понятная схема, RLS

4. Замеры скорости (реальные)

Стек: Trino 440 (single node) + Iceberg + MinIO. MacBook Pro M3 Pro, Docker. В проде с 3 worker-ами — быстрее.

Операция1M строк10M строк
11 DQ-проверок (один аналитический запрос)0.9 сек1.7 сек
SELECT с фильтром (WHERE + AND, 3 условия)0.9 сек1.0 сек
INSERT (генерация + запись Parquet)3.7 сек10.6 сек
Для сравнения с 1С: Аналогичный аналитический запрос (JOIN 3 таблицы + агрегация) в 1С на базе 1.5 ТБ занимает 30-120 секунд в зависимости от текущей нагрузки. В конце месяца (расчёт ЗП) — таймауты. Реализовать контур DQ-проверок внутри 1С невозможно: платформа не предоставляет инструментов для автоматизированного тестирования данных на уровне SQL.

Почему DQ-проверки нельзя сделать в 1С:

5. Риски прямой read-нагрузки

РискВероятностьВлияниеМитигация (HRDWH)
Деградация 1С — аналитика забирает I/O у операционных процессовВысокаяКритичноеCDC push. Ноль read от потребителей
Невозможность масштабирования — нет шардирования, единая БД 1.5 ТБВысокаяКритичноеTrino: горизонтальное масштабирование
Грязные данные у потребителей — нет слоя проверки между 1С и дашбордомВысокаяКритичноеWAP + Circuit Breaker + 7 DQ-измерений
Single Point of Failure — сбой/обновление 1С = все без данныхСредняяКритичноеДанные в Ceph. Потребители автономны
Нарушение 152-ФЗ — нет маскирования ПД на уровне 1ССредняяКритичноеColumn masking + RLS в Trino
Нет персонализации — все видят все данныеВысокаяВысокоеRow-Level Security по оргструктуре
Нет аудита — невозможно расследовать утечкуСредняяВысокоеTrino query log
Дублирование логики — каждый потребитель интерпретирует данные по-своемуВысокаяВысокоеЕдиная витрина = единая правда

6. Почему MCP подключается к витрине, а не к 1С

КритерийMCP → 1СMCP → HRDWH витрина
ВозможностьНевозможно — схема обфусцированаСтандартный SQL, документированная схема
БезопасностьДоступ ко всей БД 1.5 ТБRLS + masking. Агент видит только разрешённое
НагрузкаAI генерирует десятки запросов — каждый в единую БДЗапросы в Trino. 1С не затронута
Качество ответаСырые операционные данные без проверкиПроверенные данные из витрины
АудитНет контроля что агент запрашивалПолный query log
Витрина для MCP — это как API для микросервисов. Микросервисы не ходят напрямую в базу другого сервиса (нарушение инкапсуляции, связанность, при изменении схемы всё ломается). Вместо этого — контракт. Витрина HRDWH = data contract для потребителей.

7. Контроль качества (чего нет в 1С)

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

ИзмерениеЧто проверяемПример
AccuracyФормат соответствует эталонуПаспорт: ^\d{4}\s\d{6}$
ValidityЗначение в допустимом диапазонеЗарплата > 0
CompletenessОбязательные поля заполненыФИО IS NOT NULL
UniquenessНет дубликатовemployee_id UNIQUE
TimelinessДанные свежиеloaded_at < 24h
ConsistencyСсылочная целостностьemployee_id EXISTS IN hr_personal
AccessibilityДанные доступныSELECT без ошибок

Подробнее о реализации DQ-проверок, паттерне WAP и архитектуре HRDWH — см. основной TDR: HR DQ Control Tower.

Резюме: Прямой read в 1С невозможен технически (обфусцированная схема) и нецелесообразен архитектурно (единая БД без шардирования, OLTP-оптимизация, отсутствие RLS/masking/DQ). Решение — контролируемая выгрузка через CDC в HRDWH с полным контуром проверки качества.