Архитектура Debezium

В предыдущем уроке мы узнали, что log-based CDC читает журнал транзакций базы данных. Но как это реализуется на практике? Debezium — это платформа с открытым исходным кодом, которая делает CDC доступным и надежным.

Что такое Debezium?

Debezium — это распределенная платформа для Change Data Capture, построенная на Apache Kafka Connect. Она предоставляет коннекторы для популярных СУБД:

• PostgreSQL (pgoutput plugin)
• MySQL / MariaDB (binlog)
• MongoDB (oplog)
• SQL Server (CDC feature)
• Oracle (LogMiner)
• Db2, Cassandra, Vitess и другие

Ключевое преимущество Debezium — единый формат событий независимо от исходной СУБД. Потребители получают одинаковую структуру данных, будь то PostgreSQL или MongoDB.

Три режима развертывания

Debezium можно развернуть тремя способами, каждый из которых подходит для разных сценариев.

1. Kafka Connect (рекомендуемый)

Когда использовать: В большинстве случаев. Особенно если в вашем стеке уже есть Kafka.

Debezium работает как коннектор внутри Kafka Connect — фреймворка для интеграции с Kafka. Kafka Connect берет на себя:

• Масштабирование (добавляйте workers)
• Отказоустойчивость (автоматический failover)
• Управление offsets (где остановились при чтении WAL)
• REST API для управления коннекторами

{
  "name": "postgres-connector",
  "config": {
    "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
    "database.hostname": "postgres",
    "database.port": "5432",
    "database.user": "postgres",
    "database.password": "postgres",
    "database.dbname": "inventory",
    "topic.prefix": "inventory",
    "plugin.name": "pgoutput"
  }
}

2. Debezium Server

Когда использовать: Когда в стеке нет Kafka, а события нужно отправлять в облачные сервисы.

Debezium Server — это standalone приложение, которое читает WAL и отправляет события напрямую в:

• Google Cloud Pub/Sub
• Amazon Kinesis
• Azure Event Hubs
• Apache Pulsar
• Redis Streams
• HTTP webhook

Конфигурация через application.properties:

debezium.source.connector.class=io.debezium.connector.postgresql.PostgresConnector
debezium.source.database.hostname=postgres
debezium.source.database.port=5432
debezium.source.database.user=postgres
debezium.source.database.password=postgres
debezium.source.database.dbname=inventory

# Отправка в Pub/Sub
debezium.sink.type=pubsub
debezium.sink.pubsub.project.id=my-project

3. Embedded Engine

Когда использовать: Когда нужен максимальный контроль или минимальная задержка.

Debezium можно встроить как библиотеку в ваше Java-приложение:

// Embedded Debezium в Java приложении
try (DebeziumEngine<ChangeEvent<String, String>> engine =
        DebeziumEngine.create(Json.class)
            .using(props)
            .notifying(record -> {
                // Ваша логика обработки события
                System.out.println(record.value());
            })
            .build()) {

    executor.execute(engine);
}

Преимущества: нет внешних зависимостей, минимальная latency, полный контроль над обработкой.

Недостатки: вы сами отвечаете за offset management, масштабирование, отказоустойчивость.

Архитектура Kafka Connect

Поскольку Kafka Connect — рекомендуемый режим, разберем его детальнее.

Компоненты Kafka Connect

Workers — JVM процессы, которые выполняют коннекторы. В distributed mode workers образуют кластер и распределяют нагрузку.

Connectors — конфигурация задачи (какую БД читать, какие таблицы). Один коннектор может порождать несколько tasks.

Tasks — единицы работы. Например, один task на каждую таблицу. Tasks распределяются между workers.

Internal Topics:

• connect-configs — конфигурации коннекторов
• connect-offsets — позиции чтения (где остановились в WAL)
• connect-status — статусы коннекторов и tasks

REST API для управления

Kafka Connect предоставляет REST API на порту 8083:

# Список коннекторов
curl http://localhost:8083/connectors

# Создать коннектор
curl -X POST http://localhost:8083/connectors \
  -H "Content-Type: application/json" \
  -d @connector-config.json

# Статус коннектора
curl http://localhost:8083/connectors/postgres-connector/status

# Перезапустить task
curl -X POST http://localhost:8083/connectors/postgres-connector/tasks/0/restart

# Удалить коннектор
curl -X DELETE http://localhost:8083/connectors/postgres-connector

Поток CDC событий

Полный путь события от изменения в БД до потребителя:

Ключевые моменты

1. Replication Slot — PostgreSQL резервирует WAL сегменты, пока Debezium их не прочитает. Гарантия: ни одно изменение не будет потеряно.

2. pgoutput — встроенный плагин PostgreSQL (с версии 10). Не требует установки дополнительного ПО.

3. Offset Storage — Kafka Connect сохраняет позицию чтения. При перезапуске Debezium продолжит с того же места.

4. Topic Naming — по умолчанию: {topic.prefix}.{schema}.{table}. Например: inventory.public.customers.

Версии в нашем курсе

В лабораторном окружении курса используются:

Примечание: Курс использует Debezium 3.4.0.Final — актуальную стабильную линейку Debezium 3.x (3.4 GA в декабре 2025). Линейка 3.x базируется на Kafka 4.1, требует Java 17+, добавляет per-table метрики (3.0+), exactly-once semantics для всех core connectors (3.3+) и parallel chunked snapshot (3.5+).

Выбор режима развертывания

Что дальше?

Теперь, когда вы понимаете архитектуру, пора запустить CDC на практике. В следующем уроке мы развернем лабораторное окружение с Docker Compose и создадим первый коннектор.

Вы научитесь:

• Запускать Kafka, PostgreSQL и Debezium Connect
• Создавать коннектор через REST API
• Наблюдать CDC события в Kafka

Ключевые выводы

1. Debezium — это платформа CDC с коннекторами для всех популярных СУБД
2. Kafka Connect — рекомендуемый режим развертывания (масштабируемость, отказоустойчивость, простота)
3. Debezium Server — для сценариев без Kafka (отправка в cloud сервисы)
4. Embedded Engine — для максимального контроля в Java-приложениях
5. pgoutput — встроенный плагин PostgreSQL, не требует установки
6. REST API — управление коннекторами через HTTP запросы

CDC Landscape 2025-2026: альтернативы Debezium

Debezium — самая распространённая open-source CDC платформа, но это не единственный игрок. К 2026 рынок CDC-инструментов разросся: managed SaaS, новые open-source проекты, специализированные решения. Этот раздел — быстрая навигация по экосистеме, чтобы при архитектурных решениях вы понимали реальные альтернативы.

Семь главных платформ (Q1 2026)

Conduit (Meroxa)

Conduit — open-source data streaming platform от Meroxa, написана на Go (в отличие от JVM-based Debezium). Цели:

• Lighter-weight: одна Go-бинарная, не требует Kafka Connect framework
• Pluggable: connectors можно писать на любом языке через WASM или standalone
• Pipeline-as-code: YAML/HCL описание потоков

Когда выбрать Conduit:

• Команды на Go-stack без Java-экспертизы
• Малые-средние нагрузки, где Kafka Connect overhead не оправдан
• Прототипы и edge-кейсы (Conduit запускается на одном Go-binary без JVM)

Когда не выбрать:

• Production-grade Postgres CDC с complex schema evolution — Debezium тут зрелее
• MongoDB Oplog, SQL Server CDC — покрытие коннекторов ниже

Estuary Flow

Estuary — managed real-time ETL platform с built-in CDC. Ключевые отличия от Debezium:

Debezium:                     Estuary Flow:
+----------+                  +-------------------+
| Postgres |->Connect->Kafka  | Postgres -> Flow  |
+----------+                  | (managed runtime) |
                              | -> derivations    |
                              | -> materializations
                              +-------------------+

Estuary продаёт unified batch+stream — та же pipeline обрабатывает и historical backfill, и live CDC. Transformations пишутся на TypeScript (“derivations”). У Estuary шире SaaS-connector library (Salesforce, Stripe, etc.), но native support для exotic СУБД (Vitess, Cassandra) меньше.

Streamkap

Позиционирование: sub-second latency CDC managed service. Цели:

• Replace batch ETL (Fivetran 5-15min lag -> sub-second)
• 0-config: Streamkap сама управляет slots, heartbeats, snapshot strategies
• Pricing per row vs per-hour инфры

Streamkap часто строится на Debezium under the hood — они managed-обёртка с своим control plane. Это делает их хорошим выбором для команд, которым нравится Debezium semantics, но не хочется операционной нагрузки.

Decodable

Real-time data platform с фокусом на Apache Flink + CDC (часто через Debezium). Fit:

• Complex stream processing (joins, windowed aggregations) inline
• SQL-first interface для data engineers, которые не хотят Java/Scala

Comparison matrix

Рамки выбора

Question: Self-host или managed?
  >50K events/sec, есть platform team -> self-host (Debezium / Conduit)
  <10K events/sec, маленькая команда   -> managed (Streamkap / Estuary)

Question: Multi-cloud или single?
  AWS-only      -> рассмотреть AWS DMS
  Multi-cloud   -> Debezium (open-source, portable)

Question: Нужны transformations inline?
  Простые SMT -> Debezium SMT chain
  Сложные joins/aggregations -> Decodable / Estuary derivations

Не путайте CDC tool с data platform. Debezium — это движок чтения transaction log. Estuary, Streamkap и т. д. — это полные платформы, которые включают CDC. Сравнение “Debezium vs Estuary” корректно только в контексте “что мы хотим, движок или платформу”.