Сравнение команд удаления топика и политики хранения в Kafka

Удаление данных в Kafka происходит двумя совершенно разными способами: удаление целого топика или использование хранения для удаления старых сегментов лога из активного топика. Эффективное управление топиками Kafka имеет решающее значение для поддержания работоспособности системы, оптимизации хранилища и обеспечения целостности данных. Это включает не только создание и мониторинг топиков, но и понимание того, как корректно удалять данные, которые больше не нужны. Существует два основных механизма удаления данных: немедленное удаление топика и политики хранения на основе времени. Хотя оба в конечном итоге приводят к удалению данных, их функциональные различия, варианты использования и последствия значительно различаются.

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

Понимание удаления топика Kafka (`kafka-topics.sh --delete`)

Удаление топика в Kafka — это прямое и немедленное действие, предназначенное для полного удаления топика, включая все его разделы, данные и метаданные, из кластера Kafka. Обычно это используется, когда топик устарел, создан по ошибке или больше не служит никакой цели в вашей системе.

Как работает удаление топика

Когда вы выполняете команду удаления топика, Kafka помечает топик для удаления. Фактический процесс удаления включает несколько шагов:

Пометка для удаления: Метаданные топика в ZooKeeper (или кворуме Kafka Raft для кластеров KRaft) обновляются, чтобы пометить его для удаления.
Действие контроллера: Контроллер Kafka (брокер с особой ролью) координирует удаление. Он инструктирует другие брокеры прекратить производство или потребление из разделов помеченного топика.
Очистка каталога логов: Каждый брокер, размещающий разделы для удаленного топика, в конечном итоге удалит связанные сегменты логов и файлы индексов со своего диска. Эта очистка является асинхронной и зависит от координации брокера/контроллера и очистки файловой системы на брокерах, которые размещали разделы.

Включение удаления топика

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

Чтобы включить удаление топика, установите следующее свойство в файле server.properties на каждом брокере Kafka:

delete.topic.enable=true

После изменения server.properties перезапустите брокеры Kafka, чтобы изменение вступило в силу.

Практический пример: Удаление топика

Чтобы удалить топик с именем my-obsolete-topic:

kafka-topics.sh --bootstrap-server localhost:9092 --delete --topic my-obsolete-topic

Пример вывода:

Deleting topic my-obsolete-topic.

Вы можете проверить, что топик помечен для удаления, перечислив топики:

kafka-topics.sh --bootstrap-server localhost:9092 --list

В случае успеха my-obsolete-topic может изначально все еще отображаться в списке (помечен для удаления), но должен полностью исчезнуть после завершения процесса очистки на всех брокерах.

Предупреждение: Удаление топика — это разрушительная и необратимая операция. После удаления данные исчезают. Всегда соблюдайте крайнюю осторожность и убедитесь, что у вас есть резервные копии или вы уверены, что данные больше не нужны.

Настройка политик хранения топиков Kafka

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

Как работают политики хранения

Брокеры Kafka непрерывно запускают процесс очистки логов, который периодически проверяет сегменты топиков на предмет данных, превысивших определенные лимиты хранения. Существует две основные конфигурации хранения:

retention.ms (Хранение на основе времени): Эта конфигурация определяет максимальное время (в миллисекундах), в течение которого Kafka будет хранить сегмент лога, прежде чем он станет доступным для удаления. Например, если retention.ms установлено на 604800000 (7 дней), любые сообщения старше 7 дней будут удалены.
retention.bytes (Хранение на основе размера): Эта конфигурация определяет максимальный размер (в байтах), до которого могут вырасти разделы топика на диске, прежде чем более старые сегменты логов будут удалены для освобождения места. Если retention.bytes достигнут, Kafka удалит самые старые сегменты, пока размер топика не окажется в пределах лимита, независимо от retention.ms.

Если настроены оба параметра retention.ms и retention.bytes, приоритет будет у той политики, которая сработает первой. Например, если данные достигают своего временного лимита до лимита размера, они будут удалены по retention.ms. Если лимит размера будет достигнут до временного лимита, retention.bytes инициирует удаление.

Примечание: Значение retention.ms, равное -1, указывает на бесконечное хранение (данные никогда не удаляются по времени).

Практический пример: Создание топика с хранением

Чтобы создать топик my-event-stream с периодом хранения 24 часа (86 400 000 миллисекунд):

kafka-topics.sh --bootstrap-server localhost:9092 \
                --create \
                --topic my-event-stream \
                --partitions 3 \
                --replication-factor 1 \
                --config retention.ms=86400000

Практический пример: Изменение хранения для существующего топика

Чтобы изменить хранение для существующего топика my-log-topic на 7 дней (604 800 000 миллисекунд) и добавить лимит размера 1 ГБ (1 073 741 824 байта):

kafka-configs.sh --bootstrap-server localhost:9092 \
                 --entity-type topics \
                 --entity-name my-log-topic \
                 --alter \
                 --add-config retention.ms=604800000,retention.bytes=1073741824

Чтобы удалить определенную настройку хранения (например, вернуться к значению по умолчанию брокера для retention.bytes):

kafka-configs.sh --bootstrap-server localhost:9092 \
                 --entity-type topics \
                 --entity-name my-log-topic \
                 --alter \
                 --delete-config retention.bytes

Просмотр конфигураций топика

Вы можете проверить текущую конфигурацию топика, включая его настройки хранения:

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

Ключевые различия и варианты использования

Особенность	Удаление топика (`--delete`)	Политика хранения (`retention.ms`/`retention.bytes`)
Тип действия	Ручное, немедленное, необратимое	Автоматическое, непрерывное, настраиваемое
Область	Удаляет весь топик (все данные и метаданные)	Удаляет старые сегменты данных в активном топике
Цель	Устранить устаревшие топики, исправить ошибки	Управлять жизненным циклом данных для активных топиков, контролировать использование хранилища
Риск потери данных	Высокий (все данные теряются мгновенно)	Контролируемый (удаляются только данные, превышающие политику)
Конфигурация	Уровень брокера `delete.topic.enable`, затем выполнение команды	Конфигурации уровня топика (`--config` или `--alter`)
Обратимость	Нет	Может быть изменена или отключена для будущих данных, но прошлые удаления необратимы

Когда использовать удаление топика

Устаревшие топики: Когда проект или служба выводятся из эксплуатации, и связанные с ними топики Kafka больше не нужны.
Очистка разработки/тестирования: Очистка временных топиков, созданных во время циклов разработки или тестирования.
Исправление ошибок: Если топик был создан с неправильными конфигурациями (например, слишком много разделов, неправильный коэффициент репликации) и проще воссоздать его с нуля.

Когда использовать политики хранения

Данные логирования/мониторинга: Для топиков, собирающих логи приложений, метрики или события аудита, где старые данные со временем теряют ценность.
Потоки событий: В событийно-ориентированных архитектурах, где события должны быть доступны в течение определенного периода для воспроизведения или синхронизации потребителей, но не бесконечно.
Управление ресурсами: Чтобы предотвратить потребление чрезмерного дискового пространства топиками на брокерах Kafka, обеспечивая стабильность кластера и экономическую эффективность.
Соответствие требованиям: Для соблюдения нормативных требований к хранению данных, которые предписывают удаление данных после определенного периода.

Лучшие практики и соображения

Включайте delete.topic.enable=true с осторожностью: Хотя это необходимо для удаления, помните, кто имеет доступ к выполнению операций удаления в производственной среде.
Автоматизируйте хранение: Для большинства активных топиков устанавливайте разумные политики хранения с самого начала, чтобы предотвратить неожиданные проблемы с дисковым пространством.
Мониторьте использование диска: Регулярно контролируйте использование диска брокерами Kafka. Если топики неожиданно растут, пересмотрите их политики хранения или исследуйте поведение производителей.
Тестируйте удаление/хранение: В непроизводственных средах моделируйте удаление топиков и наблюдайте, как ведут себя политики хранения, чтобы полностью понять их влияние.
Резервируйте критически важные данные: Для топиков, содержащих критически важные или долгосрочные архивные данные, рассмотрите внешние архивные решения (например, S3, HDFS), а не полагайтесь исключительно на бесконечное хранение Kafka, или убедитесь, что ваш retention.ms установлен на -1, а retention.bytes достаточно велик или равен -1.
Компактные топики: Для топиков с включенной компакцией логов (cleanup.policy=compact) retention.ms по-прежнему применяется для удаления старых сегментов (не отдельных сообщений), которые были скомпактированы, а min.cleanable.dirty.ratio контролирует, когда запускается компакция. Это отдельный механизм от стандартного хранения и используется для топиков, где важно последнее значение для данного ключа (например, логи изменений базы данных, профили пользователей).

Вывод

Удаляйте топик Kafka только тогда, когда производители, потребители и нижестоящие зависимости больше не нуждаются в нем. Для активных топиков устанавливайте retention.ms и retention.bytes обдуманно и контролируйте использование диска брокерами, чтобы старые данные устаревали до того, как давление на хранилище станет инцидентом.