Пятница, 23:00. В кластере запускается тяжелая регламентная выгрузка из 1С в корпоративное хранилище. Транзакции замирают, диски воют под IOPS-ами. В это же время антифрод-система бодро одобряет покупку по украденной кредитке, потому что ее вектор признаков опирается на утренний слепок базы. Если ваш алгоритм крутится на данных с лагом в 24 часа, у вас нет антифрода. У вас есть невероятно дорогой дашборд посмертной аналитики для финансового департамента, прикрытый модным словом AI.
Настроить CDC из 1С в реальном времени для ML — задача выживания для бизнеса. Фродеры обчищают счета за минуты, а не ждут следующего ETL-цикла. Но прямой коннект ML-джобы к боевой учетке — это гарантированные блокировки в пик нагрузки.
CDC из 1С в реальном времени для ML: битва за прод
Когда дата-инженеры приходят к DBA с требованием отдавать данные учетки без задержек, им обычно предлагают два классических, но абсолютно нерабочих костыля.
Первый костыль — триггеры на таблицах 1С. Это хрестоматийный пример карго-культа. Вы вешаете триггер на каждое изменение, пишете событие в отдельную таблицу-очередь, а оттуда забираете поллингом. На бумаге архитектура выглядит железобетонно. В реальности под пиковой нагрузкой триггеры съедают CPU СУБД, ломают тяжелые батчевые операции самой 1С и снижают пропускную способность записи в базу вдвое.
Второй костыль — чтение с физической реплики. Снимаем нагрузку с мастера, читаем с read-only узла. Отличный вариант для BI-отчетов, но для real-time пайплайнов это тупик. Постоянно поллить гигантские таблицы тяжелыми SQL-запросами — значит гарантированно получать задержки в минуты, а не миллисекунды. Плюс вы все равно нагружаете реплику так, что она начинает отставать от мастера.
Единственный путь, который выживает в высоконагруженных инсталляциях — потоковая репликация WAL в фичи через Debezium. Плагин pgoutput читает журнал транзакций PostgreSQL строго асинхронно. Мастер-база физически не замечает, что из нее тянут гигабайты данных: нагрузка на диск минимальна, CPU занят своими делами. Вы получаете события об изменениях строк за миллисекунды.
Но здесь скрыта главная точка отказа всей архитектуры — replication slot bloat. Логический слот репликации требует, чтобы консьюмер подтверждал получение LSN (Log Sequence Number). Если ваш кластер Kafka моргнул или Debezium упал с ошибкой парсинга, PostgreSQL перестает удалять старые WAL-файлы. Он будет копить их до тех пор, пока на сервере не кончится место. Когда директория pg_wal забивает диск на 100%, база ложится намертво, утягивая за собой весь бизнес. Мониторинг лага репликации и жесткие алерты на размер слота здесь критичнее, чем метрики самих ML-моделей.
Сырые байты 1С: маппинг метаданных и мутабельная история
Схема движения данных прозрачна: 1С пишет в PostgreSQL, Debezium читает WAL и пушит события в топики Kafka, откуда потоковый движок вроде Apache Flink собирает агрегаты и кладет их в feature store. Но как только вы открываете первый JSON от Debezium, наступает суровая реальность платформы 1С.
Вам прилетает изменение в таблице _Document15. Что это? Заказ клиента? Списание со счета? Платформа 1С хранит метаданные отдельно, а физические таблицы называет техническими идентификаторами. Вам нужен жесткий слой маппинга, который налету переводит технические имена в бизнес-сущности на основе конфигурации 1С. Если программисты 1С делают реструктуризацию, ваш стриминг должен узнать об этом первым, иначе Debezium упадет с ошибкой несоответствия схем.
Вторая проблема — мутабельность исторических данных. В мире 1С документ никогда не бывает неизменным. Бухгалтер может зайти в транзакцию трехлетней давности, сделать «перепроведение» или поставить «пометку на удаление». Если ваш фич-пайплайн ожидает только append-only логику, скоринг сойдет с ума. Debezium честно отдает флаги update и delete, но транслировать их в пересчет агрегатов — задача потокового движка. Flink должен держать окна состояния и уметь делать ретракции — вычитать старое значение суммы транзакций из профиля клиента и прибавлять новое.
Здесь мы вплотную подходим к training-serving skew. Если дата-саентисты обучают градиентный бустинг на вылизанных ночных SQL-дампах, а в проде модель питается сырым и рваным потоком из Kafka, распределение фич разъедется. Модель начнет галлюцинировать. Решение: онлайн- и офлайн-фичи обязаны генерироваться из единого лога по принципу Kappa-архитектуры. Данные из Kafka оседают в холодном хранилище Data Lake ровно в том виде, в котором прилетели. Обучение идет по этим же историческим стримам с соблюдением point-in-time correctness: модель на этапе тренировки должна видеть состояние данных ровно на момент совершения исторической транзакции.
По сети события тоже не летают идеально. Бэкпрешер и сетевые ретраи гарантируют, что вы получите дубли. Если после моргания сети Debezium дважды закинет событие пополнения счета, ваша модель решит, что у клиента вдвое больше денег, и пропустит фродовый перевод. Идемпотентность должна быть зашита аппаратно: каждая транзакция имеет уникальный LSN из PostgreSQL. Feature store обязан делать upsert по этому ключу, жестко отсекая дубликаты.
До внедрения такого пайплайна задержка обновления профиля клиента составляла 12-24 часа. После перевода на CDC end-to-end latency от нажатия кнопки «Провести» в 1С до пересчета вектора признаков составляет 300 миллисекунд по 99-му перцентилю. Модель получает свежие данные до того, как фронтенд успеет отрисовать спиннер загрузки.
Порог окупаемости стриминга
Прежде чем тащить в прод распределенную стриминговую инфраструктуру, честно оцените бизнес-кейс. CDC окупается только там, где цена опоздания исчисляется миллионами: динамическое ценообразование на распродажах, жесткий транзакционный антифрод, моментальный кредитный скоринг. Если ваша задача — просто обновить рекомендации товаров в корзине, вам с головой хватит микробатча на 1-5 минут через стандартные фоновые задания 1С.
Если же реалтайм неизбежен, прогоните инфраструктуру по чек-листу:
- Настроен ли агрессивный мониторинг логических слотов и автоматический kill консьюмера при превышении лимита диска?
- Реализована ли автоматическая синхронизация словаря метаданных 1С со схемами в Schema Registry?
- Поддерживает ли ваш потоковый движок обработку ретракций для корректного пересчета агрегатов при «перепроведении» документов?
Оставлять антифрод слепым на сутки — непозволительная роскошь. Запускайте пилот realtime-фич-пайплайна, снимайте нагрузку с учетки, а бюджет на инфраструктуру и лицензии считаем по /calculator.