Каковы преимущества и недостатки использования CDC (Change Data Capture)?

А, ну это ж про ту самую магию, когда твоя база данных сама начинает стучать в дневочное окно и кричать: "Эй, тут у меня данные поменялись, забирай, пока горячие!" Это и есть CDC, Change Data Capture, если по-пацански.

Если честно, это просто ебушки-воробушки по сравнению с тем, чтобы постоянно долбить базу запросами "а что там нового?". Представь, что ты не стоишь над душой у официанта, а у тебя просто колокольчик на столе звякает, когда заказ готов. Вот CDC — это такой колокольчик для твоих данных.

Почему это офигенная тема:

1. Источник не обосрётся от нагрузки. Всё потому, что CDC не тыкает в базу палкой (SELECT * FROM ...), а тихонечко подслушивает её личный дневник — журнал транзакций (WAL в Постгресе, binlog в MySQL). База сама по себе пишет туда всё, что с ней происходит, а мы просто читаем. Нагрузка — ноль ебать. Источник даже не замечает, что его шпионят.
2. Доставка почти мгновенная. Изменения летят в аналитику или в другие системы с задержкой в секунды. Это не та история, где ты ночью запускаешь здоровенный INSERT ... SELECT, а утром начальство орет: "Почему в отчёте вчерашние цифры?". Тут near real-time, чувак. Пока ты кофе налил, данные уже везде, где нужно.
3. Полный аудит, мать его. Запоминается ВСЁ: что добавили, что изменили, что удалили. Можно посмотреть, как строка жила-поживала, кто её последний раз трогал и что именно там накосячил. Историю не перепишешь.
4. Надёжность, блять, на уровне. Журнал транзакций — это святое для самой СУБД, без него целостность данных не обеспечить. Если уж изменение туда попало, то оно оттуда никуда не денется, пока мы его не прочитаем. Потерь не будет.

Но и подводных камней, конечно, овердохуища:

1. Настроить — не щелкнуть кнопкой. Надо на источнике включить логирование, права настроить, публикации создать. Это не "установил и поехало". Тут надо э, бошка, думай.
2. Схема данных — головная боль отдельная. Если какой-нибудь разработчик возьмёт и ALTER TABLE сделает, добавит столбец, то твой коннектор (типа Debezium) и все системы дальше должны это изменение проглотить и не подавиться. Версионирование схем — это отдельный ад, чувак.
3. Зависим от милостей СУБД. Не все базы одинаково полезны для CDC. Особенно всякие managed-версии в облаках: там доступ к логам могут ограничивать или вообще отключить. Доверия ебать ноль, нужно заранее проверять.
4. Большие транзакции убьют всё. Если прилетает транзакция на обновление десяти миллионов строк, это может надолго застопорить чтение логов. Нужно специальные флаги в коннекторе выставлять или источник уговаривать так не делать.

Ну и как это выглядит на практике? Смотри, вот пример для связки PostgreSQL + Debezium:

Сначала настраиваем базу-донора, чтобы она была готова к "сдаче" данных:

-- Говорим Постгресу: "Дружище, за тобой будут следить за столиками sales и customers"
CREATE PUBLICATION airflow_pub FOR TABLE sales, customers;
-- А это чтобы при UPDATE и DELETE в лог попадало не только новое, но и старое состояние строки. Без FULL можно потерять контекст.
ALTER TABLE sales REPLICA IDENTITY FULL;

А потом конфигурируем самого шпиона — коннектор Debezium:

name=inventory-connector
connector.class=io.debezium.connector.postgresql.PostgresConnector
database.hostname=source-db-host
database.dbname=mydb
database.user=replicator
database.password=***
plugin.name=pgoutput
publication.name=airflow_pub
slot.name=debezium_slot

# А это волшебный пендель, который превращает сложное событие из лога в простой JSON с итоговым состоянием строки.
# Удобно для дальнейшей обработки, не нужно разбирать дебри.
transforms=unwrap
transforms.unwrap.type=io.debezium.transforms.ExtractNewRecordState
transforms.unwrap.drop.tombstones=true

Вот и вся магия. Настроил один раз (и правильно!), и потом данные сами текут рекой туда, куда надо. Главное — не налажать на старте, а то будет хиросима и нигерсраки в данных.