Условие

Какой метод версионирования данных позволяет отслеживать изменения в реальном времени? Как он работает технически?

Решение

CDC — Change Data Capture

Это группа техник, которая фиксирует каждое изменение в исходной таблице (INSERT/UPDATE/DELETE) и передаёт его в DWH или в стриминг.

Способы реализации CDC

Метод	Принцип	Минусы
Триггеры	Триггер на INSERT/UPDATE/DELETE пишет лог в служебную таблицу	Нагрузка на источник
Timestamp-колонка	Скан строк, где `updated_at > last_etl`	Не ловит DELETE
WAL/binlog reading	Чтение журнала транзакций (Debezium, Oracle GoldenGate)	Сложная инфраструктура
Snapshot diff	Сравнение текущего и предыдущего слепка	Дорого по IO

Связь с SCD-2

CDC — это источник событий для SCD-2. Каждое CDC-событие триггерит закрытие старой строки и вставку новой в dim. Без CDC версии в SCD-2 пришлось бы вычислять через ежедневный snapshot diff.

Архитектура «реального времени»

PostgreSQL ─→ Debezium ─→ Kafka ─→ ClickHouse / Iceberg
   (WAL)        (CDC)              (DWH со SCD-2)

Пример вывода Debezium

{
  "before": {"id": 7, "tariff": "Black"},
  "after":  {"id": 7, "tariff": "Premium"},
  "op": "u",
  "ts_ms": 1700000000000
}

Этого достаточно, чтобы построить SCD-2.

Подводные камни

Ретенция WAL — если Kafka долго не читает, источник может почистить лог и события потеряются.
Schema evolution — если в источнике добавили колонку, CDC-pipeline должен это пережить.
Идемпотентность — события могут прийти повторно (at-least-once), нужно дедуплицировать по (table, pk, op, ts).
Initial snapshot — перед стримом нужно загрузить текущее состояние, иначе только дельта без базы.

Эталонный ответ

CDC (Change Data Capture) — отслеживание изменений в реальном времени. Реализация: чтение WAL/binlog (Debezium), триггеры, timestamp-сканы. Это основа для SCD-2 и стриминговых DWH.

CDC (Change Data Capture): как отслеживать изменения в реальном времени