Прямой ответ
Повторная обработка потока — чтение ранее обработанных сообщений с более раннего смещения. Возможность определяется сроком хранения данных в топике и идемпотентностью обработки.
Сброс смещения группы выполняется утилитой:
kafka-consumer-groups.sh --bootstrap-server localhost:9202 \
--group orders-processor --topic orders \
--reset-offsets --to-datetime 2026-10-20T00:00:00.000 \
--execute
Сброс выполняется при остановленной группе, иначе новое смещение перезаписывается текущим состоянием.
| Способ сброса | Поведение |
|---|---|
--to-earliest |
С начала доступных данных |
--to-latest |
С конца, ранее обработанные пропускаются |
--to-datetime |
С момента по времени |
--shift-by N |
На N сообщений назад либо вперёд |
--to-offset N |
К явно указанному смещению |
Повторная обработка выполняется отдельной группой, чтобы не затрагивать рабочую:
consumer = KafkaConsumer(
"orders",
group_id="orders-replay-2026-10-22",
bootstrap_servers=BOOTSTRAP,
auto_offset_reset="earliest",
enable_auto_commit=False,
)
Отдельная группа читает поток независимо, поэтому рабочая обработка не останавливается и её смещение не изменяется.
Три условия корректной повторной обработки.
Данные доступны. Срок хранения в топике ограничивает глубину повторной обработки; о хранении — в статье про event sourcing.
Обработка идемпотентна. Повторное применение события не меняет результат дважды; о механизме — в статье про семантику доставки.
Результат записывается изолированно. Повторный расчёт не должен перезаписывать рабочий результат до подтверждения корректности.
Изоляция повторного запуска и его стоимость
Повторная обработка создаёт нагрузку, сопоставимую с исходной обработкой, поэтому три аспекта требуют планирования.
Нагрузка на брокер. Чтение большого объёма данных создаёт сетевой трафик и нагрузку на диск. Ограничение скорости чтения снижает влияние на рабочую обработку.
Нагрузка на приёмник. Запись результата при повторном расчёте удваивает нагрузку на внешнюю систему, поэтому запись выполняется в отдельное хранилище либо с ограничением скорости.
Состояние обработки. Повторный расчёт начинается с пустого состояния, поэтому агрегаты накапливаются заново. О состоянии задания — в статье про обработку во Flink.
Практическое следствие: повторный расчёт записывается в отдельный результат, сравнивается с рабочим и только после подтверждения заменяет его. Прямая перезапись рабочего результата приводит к потере данных при ошибке в изменённой логике.
Четыре причины повторной обработки.
Изменение логики расчёта. Формула показателя исправлена, и история требует пересчёта.
Ошибка в прежней обработке. Часть событий обработана некорректно, и требуется исправление.
Восстановление после потери результата. Хранилище результата повреждено, а поток событий позволяет пересчитать.
Запуск нового потребителя. Новый сервис требует данные за прошлый период, поэтому читает поток с раннего смещения.
Отдельный аспект — глубина повторной обработки. Срок хранения данных в топике определяет максимальную глубину. Если требуется пересчёт за период, превышающий срок хранения, используется резервная копия журнала либо архивное хранилище.
Практика: выполнение повторной обработки
1. Используйте отдельную группу для повторного запуска. Рабочая обработка не останавливается, а её смещение не изменяется.
2. Записывайте результат в отдельное хранилище. Прямая перезапись рабочего результата приводит к потере данных при ошибке.
3. Ограничивайте скорость чтения. Нагрузка на брокер и приёмник при повторном расчёте сопоставима с исходной обработкой.
4. Проверяйте идемпотентность обработки. Повторное применение события не должно менять результат дважды.
5. Сравнивайте повторный расчёт с рабочим. Расхождение объясняется до замены рабочего результата.
6. Учитывайте срок хранения данных. Глубина повторной обработки ограничена сроком хранения в топике.
7. Фиксируйте причину и период повторной обработки. Запись позволяет повторить расчёт и объяснить расхождение в данных.
Рекомендации:
- Не выполняйте сброс смещения рабочей группы без остановки. Новая позиция перезаписывается текущим состоянием, поэтому сброс не применяется.
- Различайте повторную обработку и восстановление после сбоя. Восстановление выполняется из контрольной точки автоматически, повторная обработка запускается явно.
- Учитывайте стоимость хранения журнала. Глубина повторной обработки определяется сроком хранения, поэтому срок выбирается по требованию к пересчёту.
- Проверяйте поведение при изменении формата события. Старые события могут иметь прежний формат, поэтому обработка должна поддерживать обе версии.
- Документируйте процедуру повторной обработки. Последовательность действий и порядок замены результата фиксируются, поскольку пропуск шага приводит к потере данных.
Практический сценарий: повторный расчёт перезаписал рабочий результат
Контекст: после изменения формулы показателя повторная обработка запустилась с той же группой и записью в рабочее хранилище.
- Диагностика. Рабочий результат оказался частично заменён значениями, рассчитанными по новой формуле, при этом часть истории содержала прежние значения. Сравнить результаты было невозможно, поскольку исходные значения перезаписаны.
- Причина. Повторная обработка выполнялась рабочей группой с записью в рабочее хранилище. Сброс смещения применился к рабочей группе, поэтому часть событий обработана дважды, а исходный результат утрачен.
- Действия. (а) Восстановили рабочий результат из резервной копии хранилища; (б) перевели повторную обработку на отдельную группу с записью в отдельное хранилище; (в) добавили сравнение повторного расчёта с рабочим и явный шаг замены результата после подтверждения; (г) ограничили скорость чтения при повторной обработке, чтобы не влиять на рабочую нагрузку; (д) зафиксировали процедуру повторной обработки в документации с запретом использования рабочей группы.
- Результат. Повторный расчёт выполняется изолированно, а замена рабочего результата выполняется явно после сравнения.
Вывод: повторная обработка рабочей группой с записью в рабочее хранилище приводит к смешению результатов и утрате исходных значений. Изоляция повторного запуска отдельной группой и отдельным хранилищем с явным шагом замены сохраняет возможность сравнения и отмены.
FAQ
Можно ли выполнить повторную обработку без остановки рабочего потребителя? Да, отдельной группой консументов. Рабочая группа продолжает обработку, а повторный запуск читает поток независимо.
Что ограничивает глубину повторной обработки? Срок хранения данных в топике. Для более раннего периода требуется резервная копия журнала либо архивное хранилище.
Нужно ли останавливать группу для сброса смещения? Да. При активной группе новое смещение перезаписывается текущим состоянием, поэтому сброс не применяется.
Чем повторная обработка отличается от восстановления после сбоя? Восстановление выполняется автоматически из контрольной точки с сохранённого состояния. Повторная обработка запускается явно и начинается с пустого состояния.
Источники: Apache Kafka design and offset operations, Martin Fowler — Event Sourcing — ссылки в шапке.