CDC и Debezium: как передавать изменения, а не выгружать всю таблицу заново?

Допустим, заказы интернет-магазина 🟧 хранятся в MySQL, а отчёты строятся в ClickHouse🏠. Данные между ними нужно регулярно обновлять.

Можно каждый раз копировать всю таблицу. Но с ростом данных это занимает больше времени и нагружает источник.

Здесь пригодится Debezium — инструмент, который отслеживает изменения в базе и передаёт их дальше. Такой подход называется CDC — Change Data Capture

Как он понимает, что изменилось? 🤔

В MySQL есть binlog — журнал🗂, в котором фиксируются изменения. При соответствующей настройке Debezium читает его и формирует события:

📍появился заказ — добавлена запись;
📍статус поменялся с создан на оплачен — запись обновлена;
📍заказ удалили из таблицы — запись удалена.

При первом запуске обычно снимают начальный снимок выбранных таблиц, а дальше передают изменения из журнала. Как это работает (можно прочитать через гугл переводчик)

🔄А как данные попадут в ClickHouse?

Один из вариантов: Debezium отправляет события в Kafka, а отдельный обработчик или готовый коннектор читает их и записывает результат в ClickHouse.

Здесь у каждого своя задача: Debezium замечает изменения, Kafka хранит и передаёт события, а загрузчик применяет их в хранилище. Пример архитектуры.

Кстати, почему бы просто не выбирать строки по updated_at?⏰

Так тоже можно. Но поле должно корректно обновляться при каждом изменении. А если строку физически удалили, запрос по updated_at её уже не найдёт. В журнале остаётся событие удаления, Debezium может его передать.

Но подключить Debezium недостаточно, чтобы данные сами стали правильными ☑️

Нужно продумать, как загрузчик обработает обновления и удаления, что произойдёт при повторном получении события и как заметить задержку.

Для небольшого справочника с обновлением раз в сутки обычная выгрузка может быть проще. А если большая таблица постоянно меняется и эти изменения нужны в аналитике с небольшой задержкой, стоит разобраться с Debezium 👊

А вас спрашивали на собесах про CDC?🧑‍💼