CDC и event sourcing на собеседовании Data Engineer

Зачем CDC на собесе DE

CDC (Change Data Capture) — техника, при которой изменения в OLTP-БД захватываются и реплицируются в DWH / data lake / другую систему. Альтернатива классическому batch-extract: вместо «select * from orders каждый час» — лог изменений в real-time.

На собесе Data Engineer CDC спрашивают, когда команда работает на real-time стеке: Тинькофф (Kafka + Debezium), Ozon (real-time inventory), любая команда с микросервисной архитектурой. Понимание CDC отличает senior от middle DE.

Типы CDC

1. Trigger-based:

Триггеры в источнике на INSERT/UPDATE/DELETE → пишут в shadow-таблицу
Pull-извлекаем shadow → транслируем
Просто, но нагружает source DB

2. Timestamp-based:

Колонка updated_at в каждой таблице
Pull: «дай мне строки с updated_at > last_run»
Минусы: не ловит DELETE, требует disciplined updated_at

3. Log-based (modern):

Читаем binlog / WAL / oplog напрямую
Real-time, не нагружает source
Стандарт для production CDC

Tools:

Debezium — Kafka Connect + log-readers для Postgres / MySQL / MongoDB / Oracle
Maxwell — для MySQL
AWS DMS — managed, для AWS-стека
Fivetran HVR — enterprise

Подробнее — CDC и Debezium на собесе DE, CDC vs batch loading.

Debezium

Самый популярный open-source CDC tool.

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

Запускается как Kafka Connect connector
Читает binlog (MySQL) / WAL (Postgres) / oplog (Mongo)
Публикует change events в Kafka topic
Topic-per-table convention

Event format:

{
  "before": null,
  "after": {"id": 42, "name": "Иван"},
  "op": "c",  // c=create, u=update, d=delete
  "ts_ms": 1715520000000
}

Consumers:

DWH через Snowpipe / BigQuery Subscriptions / dbt-streaming
ClickHouse через MaterializedPostgreSQL engine
Другие микросервисы (event-driven)

Schema evolution

Что когда source меняет схему? Колонку добавили / тип изменили / колонку удалили.

Стратегии:

Schema Registry (Confluent / Apicurio) — versioned schemas в Kafka
Backward compatible: новые колонки опциональны, типы расширяемые
Forward compatible: consumer должен уметь читать новую схему
Full compatible: и то и другое

В Debezium schema встроена в каждый message — consumers видят evolution.

Event sourcing

Парадигма: вместо «текущее состояние в БД» — «лог событий, текущее состояние = проекция».

Пример:

Order: created → paid → shipped → delivered
В классической OLTP: одна строка orders с полем status
В event sourcing: events OrderCreated, PaymentReceived, OrderShipped → проекция = status

Плюсы:

Полная история (audit, debugging)
Time-travel queries (что было неделю назад)
Event-driven архитектура: другие сервисы подписываются на events

Минусы:

Сложнее querying (current state нужно собирать)
Eventual consistency
Storage overhead

Outbox pattern

Атомарно записать transaction в БД + event в Kafka — невозможно (распределённая транзакция). Outbox решает.

Идея:

В одной DB-transaction: записать business data + event в таблицу outbox
CDC (Debezium) читает outbox → публикует в Kafka
После публикации event помечается consumed

Преимущество: транзакционная гарантия, что event не теряется и не дублируется.

CDC и DWH

Two patterns:

1. Replication (mirror):

CDC events → апплицируем напрямую в DWH таблицу
DWH таблица = exact copy source
Минусы: нет истории, нет slowly changing dimensions

2. Append + dbt:

CDC events → append в raw layer
dbt incremental модели строят current state и snapshots
Плюсы: history, гибкость

Стандарт в 2026 — паттерн 2 (через dbt).

Типичные вопросы

«Когда CDC vs batch extract?»

CDC: real-time или near-real-time потребности (антифрод, аналитика для саппорта). Batch: nightly reporting, ML feature engineering. Часто гибрид: CDC для critical-path, batch для остального.

«Что такое outbox pattern?»

Решение проблемы dual-write (БД + Kafka не транзакционны вместе). Пишем event в outbox-таблицу в same transaction, CDC читает outbox → публикует в Kafka.

«Debezium падает. Что делаешь?»

Триаж: offset потерян или connector упал? Если connector — restart. Если offset потерян — full snapshot. Backfill в DWH из source.

«CDC vs change-feed в современных DB?»

PostgreSQL logical replication, MySQL binlog — основа для Debezium. Modern DBs (CockroachDB, MongoDB) имеют built-in change-feeds.

Частые ошибки

CDC без outbox. Dual-write проблема: event может теряться или дублироваться
Игнор schema evolution. Когда source меняется — consumer ломается без registry
Считать, что CDC = real-time guarantee. Network / Kafka delays — eventual consistency
Mirror pattern для DWH. Теряется история, slow changing dimensions невозможны
CDC для всего. Для статичных reference-таблиц (валюты, страны) batch достаточно

FAQ

CDC и transactional consistency?

В источнике — гарантирована. В DWH — eventual. Между сервисами — нужен outbox + idempotent consumers.

Postgres logical replication vs Debezium?

Logical replication — встроенная в Postgres репликация. Debezium использует её плюс integration с Kafka. Для не-Kafka стека можно logical replication напрямую.

Performance impact CDC на источник?

Log-based (Debezium) — минимальный. Trigger-based — заметный overhead. Timestamp-based — зависит от индексов.

Event sourcing для всех систем?

Нет. Хорош для domain с rich state changes (orders, payments, audit). Overkill для CRUD на reference data.

CDC и encryption?

Encryption-at-rest в Kafka. TLS для transport. PII в events — маскирование / tokenization до публикации.

Смотрите также

Тренироваться в Telegram