Политики очистки лога Kafka
Сравнительная таблица политик очистки лога Kafka (cleanup.policy)
| Параметр / Критерий | delete (Удаление) |
compact (Уплотнение) |
compact, delete (Комбинированный) |
|---|---|---|---|
| Основной принцип | Удаляет старые сегменты лога целиком, когда они выходят за рамки установленного лимита по времени или размеру. | Сохраняет только последнее сообщение для каждого уникального ключа. Старые сообщения с тем же ключом удаляются. | Сначала уплотняет данные по ключу, а затем удаляет старые данные, включая уплотненные, если они выходят за рамки лимита по времени. |
| На что ориентируется | Время (retention.ms) или размер (retention.bytes) топика. |
Ключ сообщения. | Ключ для уплотнения и время для окончательного удаления. |
| Что происходит с данными | Старые данные безвозвратно удаляются по истечении срока хранения. Вся история за пределами окна теряется. | Старые версии сообщений удаляются, но последняя версия для каждого ключа сохраняется потенциально навсегда. | Последняя версия по ключу сохраняется, но если ключ не обновлялся очень долго, он тоже может быть удален. |
| Ключи сообщений | Не обязательны. Политика работает независимо от наличия или отсутствия ключей. | Критически важны. Без ключей уплотнение бессмысленно, так как каждое сообщение будет считаться уникальным. | Критически важны, как и для compact. |
| "Надгробия" (Tombstones) | Не имеют специального значения. Сообщение с null-значением — это просто данные. |
Ключевой механизм. Сообщение с null-значением (tombstone) сигнализирует об удалении ключа. После уплотнения и ключ, и tombstone удаляются из лога. |
Работают так же, как в compact, но само "надгробие" тоже будет удалено по истечении delete.retention.ms. |
| Размер топика | Может расти и сокращаться циклично. Размер ограничен конфигурацией. | Растет до тех пор, пока не будут представлены все уникальные ключи. Затем размер стабилизируется (растет медленно). | Похож на compact, но гарантированно не будет расти бесконечно за счет старых, неактуальных ключей. |
| Гарантии по данным | Гарантируется, что данные будут храниться минимум указанное время/до достижения размера. | Гарантируется наличие последнего состояния для каждого ключа, который когда-либо был в топике (если не был удален через tombstone). | Гарантируется наличие последнего состояния для ключей, которые обновлялись в пределах окна хранения. |
Когда какой способ использовать?
1. delete (Политика по умолчанию)
Это самый распространенный и простой для понимания способ.
Подходит для:
- Сбор логов и метрик: Когда важны события за последний час/день/неделю, а более старые данные можно удалять (например, логи приложений, метрики производительности).
- Потоки событий (Event Sourcing): Когда каждое событие уникально и важно сохранить полную хронологию, но только за определенный период.
- Очереди задач: Когда сообщения обрабатываются и после этого становятся не нужны.
- Любые сценарии, где данные имеют "срок годности".
Простыми словами: Используйте
delete, когда вас волнует вопрос "Что происходило недавно?".
2. compact
Эта политика превращает топик Kafka в подобие таблицы в базе данных или key-value хранилища.
Подходит для:
- Хранение состояний или конфигураций: Например, текущие настройки сервиса, профили пользователей. Вам всегда нужно только последнее, актуальное значение.
- Change Data Capture (CDC): При репликации изменений из базы данных в Kafka. Каждая строка таблицы — это ключ, а ее состояние — значение.
- Восстановление состояния приложений: При перезапуске сервис может быстро прочитать уплотненный топик, чтобы восстановить свое внутреннее состояние до актуального.
- Сценарии, где нужно избежать дубликатов по ключу и хранить только финальный результат.
Простыми словами: Используйте
compact, когда вас волнует вопрос "Каково текущее состояние для этого ключа?".
3. compact, delete
Это гибридный подход, который решает специфическую проблему уплотненных топиков: бесконечный рост из-за "мертвых" ключей.
Подходит для:
- Уплотненные топики с временными данными: Например, вы храните состояние сессий пользователей (
compact). Но если пользователь не заходил год, вы хотите полностью удалить все данные о его сессии, чтобы не хранить их вечно (delete). - Отслеживание статуса заказов: Заказ имеет ключ, его статус обновляется (
compact). После того как заказ выполнен и прошел год, информацию о нем можно полностью удалить из топика (delete). - Соблюдение GDPR и других норм: Позволяет гарантировать, что данные (даже последние состояния) будут удалены по истечении определенного срока.
Простыми словами: Используйте
compact, delete, когда вам нужно "знать текущее состояние, но только для тех ключей, которые были активны недавно".
Важное замечание
Процесс уплотнения (compact) происходит в фоновом режиме и работает с "грязными" (dirty) сегментами лога. Это означает, что в любой момент времени в топике могут временно присутствовать старые версии сообщений (до того, как сегмент будет уплотнен). Потребители должны быть спроектированы так, чтобы корректно обрабатывать это, используя только последнее полученное сообщение для каждого ключа.