Боль: в банке нельзя «остановить, чтобы добавить»
В банке есть системы, которые нельзя останавливать даже на пять минут: лояльность, кэшбэк, онлайн-контур, который в момент авторизации карты отдаёт сумму бонуса. Если CDC-инструмент устроен так, что подключение новой таблицы требует остановки уже работающих потоков, то каждое внедрение уезжает в ночные тех-окна и выходные. При активном потоке бизнес-задач это превращается в постоянное узкое горлышко: накаты копятся, time-to-market растягивается на недели.
Эта статья — практический разбор боли из обзора CDC в банке: как добавлять потоки без даунтайма. Все примеры обезличены.
Откуда берётся даунтайм у классических инструментов
Корень проблемы — централизованный, разделяемый capture. Когда один процесс захвата обслуживает все потоки сразу (например, единый Logger с одной сессией чтения лога на весь экземпляр Oracle и регистрационной моделью источников), онбординг новой таблицы — это операция над общим механизмом, а не независимое действие. Отсюда необходимость согласованных перезапусков, которые задевают работающие потоки. Подробный архитектурный разбор — в сравнении Qlik Replicate vs Informatica PowerExchange.
Как Qlik добавляет поток на лету
В Qlik Replicate единица работы — независимый таск: своя пара «источник → target», свой набор таблиц, свой жизненный цикл. Новый таск создаётся и стартует, не затрагивая уже работающие: они продолжают читать лог и применять изменения без паузы. Для банка это прямая разница между «накатываем по ночам в окно» и «подключили днём за минуты».
Технически новый таск при старте делает Full Load нужных таблиц и затем переходит в CDC с точки, зафиксированной на старте захвата, — без вмешательства в позиции и состояние соседних потоков. Никакой общей «остановки всего», чтобы зарегистрировать ещё одну таблицу, не требуется.
Self-service: добавлять без участия DBA на каждый чих
Чтобы онбординг был по-настоящему быстрым, узким местом не должна становиться выдача прав. Для CDC из Oracle на новые таблицы нужно supplemental logging. Есть два режима эксплуатации:
- Self-service. Учётной записи Replicate выдаются права на добавление supplemental logging на уровне таблиц (например, грант на
ALTERнужных объектов). Тогда инженер разворачивает логирование на новую таблицу на лету, без отдельного обращения к DBA. - Через DBA. Если политика безопасности не разрешает инструменту
ALTER, DBA выполняет точные командыALTER TABLE ... ADD SUPPLEMENTAL LOG DATAв тех-окно — но это касается только новой таблицы и не требует остановки работающих потоков.
Важно: само добавление supplemental logging на новую таблицу не останавливает CDC по другим таблицам. Узкое место смещается с «остановить всё» к «оформить грант на один объект» — и это уже управляемо.
Сотни тасков: массовое управление через Enterprise Manager
Когда потоков становятся сотни, встаёт встречная задача: как разом останавливать и запускать группы тасков, когда DBA планирует работы на источнике. Это закрывает Qlik Enterprise Manager (AEM) через теги.
- Кастомный тег (например, по источнику или процессу) навешивается на все связанные таски.
- В нужный момент — фильтр по тегу и Bulk-операция Stop All / Start All.
- Те же действия доступны через REST API — можно встроить в runbook или оркестратор.
То есть «остановить всё связанное с источником на время работ» — это осознанное массовое действие по тегу, а не вынужденный даунтайм ради добавления одной таблицы. Подробнее об оркестрации сотен тасков будет отдельный разбор по Enterprise Manager.
Чек-лист безопасного онбординга в проде
- Зафиксировать точку старта CDC по полю
SOURCE_TIMESTAMP_APPLIEDв control-таблицеattrep_status— чтобы при необходимости рестартовать ровно с неё. - Заранее решить модель supplemental logging: self-service грант или DBA-окно на конкретную таблицу.
- Новый таск стартовать в рабочее время — он независим и не влияет на соседние потоки.
- Для групповых операций повесить теги в Enterprise Manager и проверить Bulk Start/Stop на тестовой группе.
- Настроить алерты по латентности нового потока отдельно, чтобы не «потерять» его в общем мониторинге.
Мостик к lakehouse
Быстрый онбординг потоков ценен только если их есть куда лить. Аналитический таргет должен выдерживать сотни параллельных потоков записи и отдавать real-time аналитику. Qlik Replicate стримит CDC-поток в lakehouse на Apache Doris / VeloDB с обновлениями по Unique Key — единый стек «ingestion + lakehouse» от источника до витрины.