CDC (Change Data Capture) — это методика отслеживания и захвата изменений в данных (вставок, обновлений, удалений) в источнике данных, чтобы эти изменения можно было в режиме реального времени или ближе к реальному времени перенаправлять в другие системы (например, в хранилища данных, системы аналитики, кэш или брокеры событий). CDC широко используется в ETL/ELT-архитектурах, при интеграции данных и при построении систем репликации и стриминга.

Основные цели и преимущества CDC

• **Обновление целевых систем в реальном или почти реальном времени.
  **

• Снижение объема передаваемых данных: вместо полной загрузки передаются только изменённые записи.

• **Обеспечение актуальности данных для аналитики и отчетности.
  **

• **Минимизация нагрузки на источник данных.
  **
• **Повышение эффективности пайплайнов данных.
  **

Что именно отслеживает CDC

CDC регистрирует следующие события в таблицах базы данных:

• INSERT — новые записи.

• UPDATE — изменения в существующих строках.

• DELETE — удаление строк.

Эти изменения затем сериализуются (обычно в JSON/Avro/Protobuf) и передаются в целевые системы через стриминг-платформы (например, Kafka), API, очереди сообщений, файловые системы или напрямую в DWH.

Подходы к реализации CDC

Существует несколько способов реализации CDC, каждый со своими достоинствами и ограничениями:

1. CDC на основе триггеров

Механизм: в СУБД создаются триггеры на INSERT, UPDATE, DELETE, которые записывают изменения в отдельную "лог-таблицу" (audit trail).

Плюсы:

• Гибкость.

• Возможность логировать любые поля и действия.

Минусы:

• Высокая нагрузка на СУБД.

• Может влиять на производительность транзакций.

• Усложнённая поддержка и масштабирование.

Пример:

CREATE TRIGGER trg_customer_update
AFTER UPDATE ON customers
FOR EACH ROW
BEGIN
INSERT INTO customer_log (id, old_name, new_name, changed_at)
VALUES (OLD.id, OLD.name, NEW.name, NOW());
END;

2. CDC на основе журналов транзакций (Transaction Log CDC)

Механизм: чтение из транзакционного лога базы данных, где фиксируются все операции изменений. Это самый надёжный и эффективный способ.

Поддерживается в:

• SQL Server (SQL Server CDC / Change Tracking).

• Oracle (LogMiner, GoldenGate).

• PostgreSQL (Logical Decoding + wal2json).

• MySQL (binlog + Debezium).

• MongoDB (oplog).

Плюсы:

• Независимость от прикладного кода.

• Низкая нагрузка на базу.

• Устойчивость и надёжность.

Минусы:

• Требует доступов на уровне системы.

• Зависит от архитектуры и формата логов СУБД.

• Обычно требует использования брокеров или CDC-движков.

3. CDC через временные метки и сравнение snapshot

Механизм: сравнение временных меток last_updated_at, modified_at, либо version колонок в таблицах между двумя загрузками.

Плюсы:

• Просто реализуется в системах, где такие поля уже есть.

• Можно использовать стандартные SQL-запросы.

Минусы:

• Требует строгого контроля за точностью временных меток.

• Не отслеживает DELETE.

• Возможны пропуски при несогласованности времени.

Пример:

SELECT \* FROM orders
WHERE updated_at > (SELECT MAX(updated_at) FROM orders_sync_log);

4. CDC через внешние инструменты и фреймворки

Существуют готовые решения и фреймворки, которые упрощают реализацию CDC:

• Debezium — фреймворк на базе Kafka Connect, поддерживает PostgreSQL, MySQL, MongoDB, SQL Server и другие СУБД.

• AWS DMS (Database Migration Service) — позволяет выполнять миграцию и CDC в облаке.

• Striim, Fivetran, Airbyte, Hevo — интеграционные SaaS-решения с CDC-возможностями.

• Apache NiFi — визуальный поток данных, может отслеживать изменения и трансформировать их.

Debezium (пример):

• Использует Kafka Connect.

• Читает логи изменений в базе.

• Публикует изменения в Kafka-топики.

Архитектура CDC в реальном мире

Обычный сценарий использования:

1. Источник данных (OLTP): PostgreSQL, MySQL и т.д.

2. CDC-движок: Debezium, AWS DMS или самописное решение.

3. Механизм доставки: Kafka, AWS Kinesis, Pub/Sub.

4. Буфер/хранилище (optional): Hadoop, Data Lake, Message Queue.

5. Потребители: Data Warehouse (Snowflake, Redshift), BI-системы, микросервисы, алертинг.

Особенности реализации CDC в разных СУБД

Вопросы надёжности при CDC

• **Идемпотентность потребителей.
  **
• **Обработка duplicate events.
  **
• **Гарантии доставки (at least once, exactly once).
  **
• **Хранение offset/position в логе.
  **
• **Обработка ошибок и dead letter queues.
  **

Что учитывать при внедрении CDC

• СУБД должна поддерживать нужный уровень доступа к логам.

• Убедитесь, что производительность источника не деградирует.

• Позаботьтесь о мониторинге и логировании событий.

• Оцените, нужна ли вам CDC в реальном времени или достаточно near-real-time.

• Тестируйте сценарии ошибок, повторных запусков и rollback.

CDC — это не просто техническая реализация синхронизации изменений. Это важный компонент архитектуры данных, позволяющий выстраивать устойчивые, масштабируемые и реактивные системы, где каждая запись становится событием, отражающим текущее состояние бизнеса в цифровом виде.