Действительно ли мне нужна семантика exactly-once от Kafka-коннектора Flink?

Kafka-синк Flink может гарантировать exactly-once, но эта гарантия привязана к завершению чекпойнта — а значит, задержка вывода ограничена интервалом чекпойнта, а не реальной скоростью потока данных.

Сколько на самом деле стоит exactly-once

Kafka-синк Flink достигает exactly-once через транзакцию two-phase commit, привязанную к циклу чекпойнтов — он буферизует записи и коммитит их в Kafka только после успешного завершения чекпойнта. Консьюмер, читающий с уровнем изоляции по умолчанию read_committed, видит этот вывод с задержкой на весь интервал чекпойнта, а не почти в реальном времени.

Когда at-least-once плюс идемпотентные записи так же корректны, но дешевле

Если запись ниже по потоку изначально идемпотентна — upsert по стабильному id, а не добавление в конец или инкремент счётчика — доставка at-least-once без накладных расходов на транзакции даёт точно такое же конечное состояние, как exactly-once, но без налога задержки на интервал чекпойнта. Повторная доставка просто перезаписывает тот же ключ тем же значением.

Где exactly-once — единственно верный ответ

У неидемпотентного синка — инкремент счётчика, добавление в лог аудита, где дублирующая строка портит итоги — нет безопасного fallback на at-least-once: повторно доставленная запись там — реальный баг корректности, а не просто шум. Это и есть настоящая точка принятия решения: идемпотентен ли синк, а не общее предпочтение более сильных гарантий везде подряд.