CDC vs batch loading на собеседовании Data Engineer

Зачем спрашивают на собесе DE

CDC становится стандартом для near-real-time pipelines. На собесе DE: «отличие log-based и query-based CDC», «когда выбрать batch». Senior — нюансы Debezium, schema evolution, consistency.

Batch loading: подход

Запускается по расписанию (cron, Airflow), забирает данные за последний период.

SELECT * FROM source.orders
WHERE updated_at >= '2026-05-01' AND updated_at < '2026-05-02';

Плюсы:

• Простота реализации.
• Тестируется и отлаживается легко.
• Идемпотентен (повторный запуск с тем же фильтром — то же).
• Хорошо для мигрант OLTP → DWH ночью.

Минусы:

• Latency = период (час, день).
• Нагрузка на источник во время extraction.
• Потерянные DELETE — без is_deleted колонки не отследишь.
• Late-arriving data требует lookback window.

CDC: суть

Change Data Capture — отслеживание изменений в источнике в реальном времени.

Source DB → CDC tool → Kafka → DWH/Lake

Каждое INSERT/UPDATE/DELETE превращается в событие в Kafka.

Свойства:

• Sub-second latency.
• Минимальная нагрузка на источник (читает WAL).
• Естественное отслеживание DELETE.
• At-least-once семантика.

Log-based vs query-based CDC

Log-based CDC. Читает transaction log БД (WAL в Postgres, binlog в MySQL, redo log в Oracle).

Tools:

• Debezium (стандарт, open source).
• AWS DMS, Striim, Qlik Replicate.

Плюсы:

• Минимальная нагрузка на источник (read-only WAL).
• Захватывает DELETE и UPDATE с before-image.
• Точность 100%.

Минусы:

• Требует доступ к log (admin permission на БД).
• Конфигурация сложная.
• Schema changes требуют внимания.

Query-based CDC. Периодически SELECT'ит источник по updated_at или version.

SELECT * FROM source.orders WHERE updated_at > $last_processed

Плюсы:

• Простая реализация (любая БД).
• Не требует прав на log.

Минусы:

• Не ловит DELETE без soft-delete.
• Нагрузка на источник растёт.
• Late updates пропускаются.
• Не ловит несколько UPDATE на ту же строку между sync'ами.

Сравнение

Когда что выбирать

Batch:

• Аналитика на старых данных (вчерашние и дальше).
• DWH-моделирование (medallion bronze → silver).
• Большие объёмы (миллиарды строк / день) — за ночь дешевле.
• Простые pipeline'ы.

Query-based CDC:

• Околореальный sync, но без сложной инфраструктуры.
• Источник — managed БД без admin доступа.
• Источник без транзакций / WAL.

Log-based CDC:

• Real-time analytics, dashboards.
• Microservices с event-driven архитектурой.
• Точная история изменений (audit, GDPR).
• High-volume источники.

Гибрид. Часто: log-based CDC для критичных таблиц + ночной batch для тяжёлой агрегации.

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

Query-based на DELETE-важных таблицах. Пропускаешь удаления.

Не handle schema changes. Новые / удалённые колонки в источнике — pipeline ломается без обработки.

Большие batch без partitioning. OOM на DWH при INSERT 100M строк за раз.

Late events в batch без lookback. Пропускаешь поздние обновления.

CDC в одного consumer. Если consumer падает — данные накапливаются. Идемпотентность + monitoring lag.

Использовать Kafka retention слишком короткий. Если consumer offline на день — потерял события. retention ≥ recovery time.

Связанные темы

• CDC и Debezium на собесе DE
• Kafka consumer groups для DE
• Идемпотентность пайплайна для DE
• ETL vs ELT для DE
• Подготовка к собесу Data Engineer

FAQ

Debezium для всех БД?

Postgres, MySQL, MongoDB, Oracle, SQL Server — есть connectors. Для специфичных (CH, BigQuery как источник) — другие подходы.

CDC заменяет ETL?

Не полностью. Тяжёлые трансформации, joining многих источников, business rules — всё равно ETL/ELT в DWH.

Это официальная информация?

Нет. Статья основана на документации Debezium, Confluent, Kafka.

Тренируйте Data Engineering — откройте тренажёр с 1500+ вопросами для собесов.