Хранение данных в Kafka: понимание и управление потоками событий

Хранение данных в Kafka отвечает на практический вопрос: как долго ваши потоки событий должны оставаться на диске, прежде чем Kafka сможет их удалить? Если настройки слишком свободные, брокеры могут исчерпать место. Если слишком агрессивные, медленный потребитель может потерять возможность воспроизвести данные.

Kafka хранит записи в логах разделов. Эти логи разделены на файлы сегментов, и очистка хранения удаляет старые закрытые сегменты. Эта деталь важна, потому что Kafka обычно не удаляет одну запись за раз в момент, когда она устаревает. Сегмент становится доступным для удаления только тогда, когда он соответствует настроенным правилам хранения.

Почему настройки хранения важны

Хранение — это компромисс между объемом хранилища, потребностями в воспроизведении и операционным риском.

Стоимость хранения: Длительное хранение для топиков с высоким объемом может потреблять много дискового пространства брокеров.
Восстановление потребителей: Ваше окно хранения должно быть длиннее самого длительного реалистичного простоя потребителя или окна повторной обработки.
Стабильность: Полные диски могут остановить прием записей брокерами и вызвать более серьезные проблемы в кластере.
Соответствие требованиям: Некоторые данные должны храниться минимальный период, в то время как другие данные следует удалять быстро.

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

Как Kafka удаляет старые данные

Топики Kafka разделены на разделы. Каждый раздел представляет собой упорядоченный лог только для добавления. Kafka записывает новые записи в активный сегмент и переключается на новый сегмент, когда текущий достигает настроенного размера или возраста.

Хранение применяется для каждого раздела. Если вы установите retention.bytes=1073741824, это примерно 1 ГиБ на раздел, а не 1 ГиБ для всего топика. Топик с 12 разделами может хранить около 12 ГиБ до учета реплик.

Когда настроены как временное, так и размерное хранение, Kafka может удалять подходящие старые сегменты, когда любой из лимитов требует очистки.

Временное хранение

Временное хранение сохраняет записи в течение настроенного периода.

На уровне брокера log.retention.ms устанавливает значение по умолчанию для топиков, которые его не переопределяют. На уровне топика retention.ms переопределяет это значение по умолчанию для одного топика.

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name orders \
  --alter \
  --add-config retention.ms=259200000

Этот пример устанавливает для orders три дня. Проверьте это с помощью:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name orders \
  --describe

Используйте временное хранение, когда ваше основное требование — окно воспроизведения, например, "потребители должны иметь возможность восстановиться после сбоя на выходных".

Размерное хранение

Размерное хранение ограничивает объем данных лога, который может хранить каждый раздел.

На уровне брокера log.retention.bytes устанавливает лимит по умолчанию для каждого раздела. На уровне топика retention.bytes переопределяет его для одного топика. Значение -1 означает отсутствие лимита размера от этой настройки.

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name high-volume-logs \
  --alter \
  --add-config retention.bytes=1073741824

Это устанавливает лимит в 1 ГиБ на раздел. Используйте размерное хранение, когда защита диска важнее фиксированного временного окна. Будьте осторожны с топиками с неравномерной нагрузкой, потому что всплеск трафика может сократить эффективное окно воспроизведения.

Значения по умолчанию брокера и переопределения топиков

Значения по умолчанию брокера находятся в server.properties и применяются к топикам, которые не устанавливают свои собственные значения хранения.

log.retention.ms=604800000
log.retention.bytes=-1
log.retention.check.interval.ms=300000

Изменение значений по умолчанию брокера обычно требует перезапуска брокера или динамического изменения конфигурации брокера, в зависимости от версии Kafka и инструментов развертывания. Изменения на уровне топика через kafka-configs.sh часто безопаснее, потому что разные топики редко нуждаются в одинаковом окне хранения.

Для нового топика установите хранение при его создании:

kafka-topics.sh --bootstrap-server localhost:9092 \
  --create \
  --topic audit-events \
  --partitions 6 \
  --replication-factor 3 \
  --config retention.ms=604800000 \
  --config retention.bytes=2147483648

Для существующего топика измените конфигурацию топика:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name audit-events \
  --alter \
  --add-config retention.ms=1209600000

Чтобы вернуться к значению по умолчанию брокера, удалите переопределение топика:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name audit-events \
  --alter \
  --delete-config retention.ms

Хранение и компактификация логов

Очистка в Kafka управляется с помощью cleanup.policy. Распространенные значения: delete, compact или оба как compact,delete.

delete удаляет старые сегменты лога на основе времени или размера хранения.
compact сохраняет последнее значение для каждого ключа и удаляет более старые значения для этого ключа со временем.
compact,delete позволяет применять как правила компактификации, так и правила удаления.

Компактификация полезна для топиков типа журнала изменений, например, обновлений профилей клиентов, ключом которых является идентификатор клиента. Это не общая замена хранению. Маркеры удаления и удаление при хранении имеют свое собственное поведение по времени, поэтому тестируйте компактифицированные топики, прежде чем полагаться на них для очистки.

Практический контрольный список хранения

Начните с самого длительного простоя потребителя, который вы можете допустить. Если группа потребителей может быть отключена в течение 48 часов, окно хранения в 24 часа слишком короткое.

Оцените потребности в диске перед изменением производственных топиков:

скорость поступления в секунду x количество секунд хранения x количество разделов x коэффициент репликации

Это только оценка, потому что сжатие, размер записи, индексы и накладные расходы сегментов влияют на реальное число. Тем не менее, это дает полезную отправную точку.

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

Самый безопасный подход по умолчанию прост: используйте хранение на уровне топика, документируйте, почему каждый топик с высоким объемом имеет свою настройку, и тестируйте более короткое хранение в стейджинге перед применением в производстве.