Для поддержки exactly-once отправки сообщений мы на стороне Flink'а используем механизмы чекпоинтов и сейвпоинтов. Потери возможны если у нас простой больше времени жизни лога операций, но с этим за полгода работы с CDC ещё пока не сталкивались. Частично отсутствие дублей обеспечивает сам Flink. А те дубли, которые мы сами можем себе сделать (например, при повторной загрузке одного и того же батча), мы отлавливаем с помощью delete+insert стратегии dbt. Если то же самое событие снова пройдёт пайплайн обработки данных, то оно сначала удалится из таблицы, а потом заново запишется. Таким образом в итоге данные не изменятся, сохраняется идемпотентность. Получается такое разделение труда: проблемы Flink'а решает Flink, проблемы dbt решает dbt. Если на стороне аналитического хранилища происходят какие-то технические неполадки, то статусы потом легко обновляются повторным прогоном дагов airflow, уже после восстановления работы хранилища.
Спасибо за интересный вопрос!
Для поддержки exactly-once отправки сообщений мы на стороне Flink'а используем механизмы чекпоинтов и сейвпоинтов. Потери возможны если у нас простой больше времени жизни лога операций, но с этим за полгода работы с CDC ещё пока не сталкивались.
Частично отсутствие дублей обеспечивает сам Flink. А те дубли, которые мы сами можем себе сделать (например, при повторной загрузке одного и того же батча), мы отлавливаем с помощью delete+insert стратегии dbt. Если то же самое событие снова пройдёт пайплайн обработки данных, то оно сначала удалится из таблицы, а потом заново запишется. Таким образом в итоге данные не изменятся, сохраняется идемпотентность. Получается такое разделение труда: проблемы Flink'а решает Flink, проблемы dbt решает dbt.
Если на стороне аналитического хранилища происходят какие-то технические неполадки, то статусы потом легко обновляются повторным прогоном дагов airflow, уже после восстановления работы хранилища.