Qlik Replicate vs Oracle GoldenGate: CDC для банка

Два инструмента — две философии

Oracle GoldenGate и Qlik Replicate решают одну задачу — Change Data Capture, перенос изменений из источника в целевое хранилище. Но спроектированы они под разных людей и разные сценарии, и именно это определяет выбор в банке.

GoldenGate исторически — инструмент DBA: глубоко нативный для Oracle, мощный, с тонким контролем через процессы Extract / Pump / Replicat и (в новых версиях) микросервисную архитектуру. За эту мощь платят сложностью: исторически это командная строка и скрипты, крутая кривая обучения, потребность в выделенной экспертизе. Веб-консоль в свежих релизах ситуацию улучшила, но порог входа остаётся высоким.

Qlik Replicate — инструмент инженера данных: единый веб-UI, где источник и приёмник настраиваются без единой строки скрипта (подход Click-2-Replicate), а большую часть конфигурации инструмент берёт на себя. По публичным оценкам пользователей это выражается в разнице удобства: на G2 ease-of-use у Qlik Replicate 8.4 против 7.4 у GoldenGate.

Для банка этот контраст переводится в эксплуатацию: GoldenGate требует DBA-команды на сопровождение CDC, Qlik позволяет запускать и перезапускать потоки силами generalist-инженеров и даже младших специалистов поддержки. Эта статья — продолжение обзорного разбора болей CDC в банке; здесь мы концентрируемся на сравнении именно с GoldenGate. Все примеры обезличены.

Агентless против footprint в Oracle-эстейте

Главное архитектурное различие — где «живёт» инструмент. Qlik Replicate агентless: не требует установки проприетарных агентов на сервер-источник или target, подключается удалённо стандартным клиентом и читает транзакционный лог. Для банка это значит, что на критичный продакшен-Oracle ничего ставить не нужно — присутствие инструмента минимально.

Здесь важно быть точным, чтобы не уйти в маркетинг. Расхожий тезис «GoldenGate обязательно ставить на сервер-источник» — упрощение. У GoldenGate есть режимы downstream mining и remote capture, которые позволяют вынести захват с продакшен-сервера: источник по LOG_ARCHIVE_DEST_n отгружает redo на отдельную mining-БД, где и работает Integrated Extract. То есть offload возможен.

Но честная разница в том, какой ценой. Downstream-режим GoldenGate требует отдельной открытой read-write mining-БД нужной версии, корректно настроенных standby redo log, конфигурации redo transport и аутентификации, и в целом остаётся компонентом внутри Oracle-эстейта под управлением DBA. Qlik читает логи полностью удалённо и не нуждается ни в mining-БД, ни в перенастройке redo transport на источнике. Для банка с жёстким контролем изменений на core-системах это меньше движущихся частей и меньше согласований.

Универсальность против Oracle-центричности

GoldenGate силён прежде всего на Oracle-to-Oracle. Гетерогенные сценарии у него есть, но это отдельные, Oracle-центричные линейки продукта со своим лицензированием: отдельная редакция для не-Oracle БД, отдельная — GoldenGate for Big Data, отдельная и весьма дорогая — для mainframe. Универсальность достижима, но собирается из нескольких лицензируемых компонентов и остаётся в орбите Oracle-администрирования.

Qlik Replicate изначально универсален: один UI и одна подписка покрывают Oracle, SQL Server, PostgreSQL, SAP, mainframe, Kafka и десятки других источников и таргетов. Если в roadmap банка есть и Oracle-to-Oracle (например, переезд на Exadata), и гетерогенные потоки в озеро данных, и потенциально SAP или Kafka в будущем — Qlik даёт одну платформу на всё. GoldenGate в той же задаче потребовал бы нескольких продуктов и компетенций.

Стоимость владения — честно, без выдуманных процентов

Точные проценты экономии TCO в публичных источниках не подтверждаются, поэтому мы их не приводим. Зато подтверждается структура стоимости GoldenGate — и она существенна для банка.

GoldenGate лицензируется по процессорной метрике (как Oracle Database EE) с применением core-factor: сервер на 16 ядер с фактором 0.5 считается как 8 процессоров. Публичный прайс-лист Oracle (значения list price, до скидок):

Сверху — ежегодная техподдержка примерно 22% от стоимости лицензии. То есть процессорные лицензии множатся на каждый источник и target, гетерогенность добавляет более дорогие редакции, а к капитальным расходам прибавляется стоимость выделенной DBA-экспертизы на сопровождение. Qlik Replicate продаётся по подписке, агентless и эксплуатируется generalist-инженерами — операционная составляющая TCO ниже именно за счёт отсутствия per-source процессорных лицензий и отдельной DBA-команды. Конкретные суммы зависят от ландшафта, поэтому сравнивать стоит на цифрах вашего контура, а не на универсальном проценте.

Где GoldenGate честно лучше

Чтобы это было сравнение, а не реклама, назовём сильные стороны GoldenGate прямо:

• Ультра-низкая латентность Oracle-to-Oracle. GoldenGate — отраслевой стандарт для mission-critical Oracle-репликации с задержкой в доли секунды и глубочайшей интеграцией с Oracle (включая специфичные типы и сценарии).
• HA/DR и zero-downtime миграции Oracle. Для активной отказоустойчивости, миграций без простоя и сценариев катастрофоустойчивости в чисто-Oracle мире GoldenGate заточен лучше — это его профильная задача.
• Высокие оценки зрелости. На Gartner Peer Insights GoldenGate оценён очень высоко (порядка 4.8 при сопоставимом числе отзывов с Qlik) — это зрелый, проверенный продукт, а не нишевый инструмент.
• Тонкий контроль и масштабирование. Микросервисная архитектура и параллельные Extract/Replicat дают максимальный контроль над пропускной способностью в high-volume Oracle-средах — для команд, у которых эта экспертиза есть.

Оба инструмента способны на sub-second латентность; вопрос не «кто быстрее в пределе», а какой профиль задачи и команды у банка.

Как выбирать для банка

Практичный водораздел выглядит так:

• Берите GoldenGate, если задача — чистый Oracle-to-Oracle с требованием ультра-низкой латентности, HA/DR или zero-downtime миграция, и у вас есть выделенная DBA-команда под сопровождение.
• Берите Qlik Replicate, если задача — CDC в хранилище/lakehouse, целевой лаг измеряется секундами и минутами, источников несколько типов, а сопровождать репликацию должны инженеры данных без отдельной DBA-команды. Это типичный профиль банковского DWH/RegTech-контура.

Для большинства банковских сценариев аналитики, отчётности, скоринга и антифрода важнее именно time-to-market, универсальность и низкий порог эксплуатации — поэтому здесь чаще выигрывает Qlik. Подробный разбор болей, которые при этом закрываются (проблема 101-го таска, тяжёлые таблицы, рестарт по timestamp, Audit Table), — в обзорной статье.

Мостик к lakehouse: ingestion + аналитический таргет

Любой CDC-инструмент решает только половину задачи — доставку изменений (ingestion). Вторая половина — аналитический таргет, который выдержит сотни параллельных потоков записи и одновременно отдаст быструю аналитику. Qlik Replicate органично стримит CDC-поток в lakehouse на Apache Doris / VeloDB: Doris принимает изменения с поддержкой обновлений по Unique Key и отдаёт real-time аналитику для BI, отчётности, скоринга, антифрода и RegTech. Получается единый стек «ingestion + lakehouse» от источника до витрины.

Источники

Конкурентные утверждения опираются на публичные источники:

• Oracle — GoldenGate pricing (процессорная метрика, list price)
• G2 — Oracle GoldenGate vs Qlik Replicate (ease-of-use 8.4 vs 7.4)
• Gartner Peer Insights — Qlik Replicate vs Oracle GoldenGate
• Oracle Docs — Configuring a Downstream Mining Database
• Qlik — Oracle CDC (agentless, log-based)
• AutoMQ — Oracle GoldenGate vs Qlik Replicate