Работали ли вы с CDC (Change Data Capture)
Что проверяют
Понимаете ли вы, чем поток изменений отличается от ночной выгрузки, и представляете ли его цену. CDC часто пишут в резюме, а на деле имели дело с инкрементальной загрузкой по полю с датой, и вопрос как раз отделяет одно от другого.
Как отвечать
Начните с двух подходов. Запросный: периодически выбираем строки, где метка обновления больше предыдущей. Логовый: читаем журнал транзакций базы, то есть WAL в PostgreSQL, binlog в MySQL, поток изменений в MongoDB. Промышленный CDC это второй вариант, обычно через Debezium и брокер сообщений.
Дальше по пунктам, которые спросят следом:
- начальный снимок: сначала полная выгрузка таблицы, затем переход на поток без разрыва;
- семантика доставки: как минимум однократная, значит приёмник обязан быть идемпотентным, ключ дедупликации это первичный ключ плюс позиция в журнале;
- порядок: гарантирован в пределах партиции, поэтому ключом партиционирования берут первичный ключ таблицы;
- удаления: приходят отдельным событием, при запросном подходе не видны вообще;
- приземление: сырые события кладут как есть, а витрину собирают слиянием по ключу или историей версий строки.
Где спотыкаются
Называют CDC выборку по полю с датой обновления. Так теряются удаления, правки задним числом и промежуточные состояния строки между запусками, а для витрины с историей это критично.
Считают доставку точной и не делают дедупликацию. После перезапуска коннектор переигрывает события с последней сохранённой позиции, и неидемпотентная загрузка удваивает строки в приёмнике.
Забывают про слот репликации на стороне базы. Пока потребитель стоит, база обязана хранить для него журнал, и место на диске кончается вместе со всей базой, а не только с конвейером. Отставание слота мониторят наравне с самим сервисом.