Политика хранения записей тем Kafka не ясна

В Kafka Docs я заинтересовался и попробовал два следующих типа хранения вместе

log.retention.bytes:

Максимальный размер журнала перед его удалением Тип: long По умолчанию: -1 Допустимые значения: Важность: высокий Режим обновления: для всего кластера

log.retention.ms

Количество миллисекунд для хранения файла журнала перед его удалением (в миллисекундах). Если не установлено, используется значение в log.retention.minutes. Если установлено значение -1, ограничение по времени не применяется. Тип: long По умолчанию: null Допустимые значения: Важность: high Режим обновления: для всего кластера

AS

  1. log.retention.bytes = 1 ГБ
  2. log.retention.ms = 7 дней

Проблемная ситуация

В настоящее время в моей теме есть все сообщения, относящиеся к двум разным файлам журнала, оба размером менее 1 ГБ.

Допустим, в файлах log.1 содержится 400 МБ сообщений, самое старое сообщение - 7 дней назад.

который находится вверху

Размер файла log.2 составляет 500 МБ с последним сообщением ›7 дней назад.

Я понимаю, что kafka очистит все записи, принадлежащие файлу log.2, другими словами, удалит этот журнал из темы.

Что происходит с записями в log.1 старше 7 дней?


apache-kafka retention
person Anirudh    schedule 23.12.2019    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Есть два свойства, которые определяют хранение сообщений в Kafka - log.retention.bytes и log.retention.ms (для каждой темы на уровне раздела). Стратегия удаления данных работает на FIFO базовой, т.е. сообщение, которое было помещено в тему первым, будет удалено первым.

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

log.retention.bytes = 1Gb (per topic per partition)
log.retention.ms = 7 days (per topic)

Это означает, что любой из ограничений, который будет превышен первым, приведет к очистке данных в Kafka.

Например, предположим, что размер сообщений в вашей теме занимает 500 МБ (что меньше log.retention.bytes), но старше 7 дней (т.е. больше, чем log.retention.ms по умолчанию). В этом случае данные старше 7 дней будут удалены (на FIFO основе).

Аналогичным образом, если для данной темы пространство, занятое сообщениями, превышает log.retention.bytes, но не старше log.retention.ms, в этом случае данные также будут очищены (на FIFO основе).

Концепция истечения срока действия данных называется Cleanup & сообщения по теме не удаляются сразу после их использования / истечения срока действия. В фоновом режиме происходит следующее: при превышении любого из ограничений сообщения помечаются как удаленные. В Kafka есть 3 политики очистки логов - DELETE (по умолчанию), COMPACT, DELETE AND COMPACT. Kafka Log Cleaner выполняет сжатие журналов, пул фоновых потоков сжатия.

Чтобы включить сжатие для темы, используйте конфигурацию темы log.cleanup.policy=compact. Чтобы установить задержку начала сжатия записей после их записи, используйте тему config log.cleaner.min.compaction.lag.ms. Записи не будут уплотняться до истечения этого периода. Эта настройка дает потребителям время, чтобы получить каждую запись. Это может быть причиной того, что старые сообщения не удаляются немедленно. Вы можете проверить значение свойства для задержки уплотнения.

Ссылки ниже могут быть полезны:

person Kumar Rohit    schedule 23.12.2019
comment
Проблема в том, что эти 500 МБ относятся к одному и тому же файлу журнала на сервере kafka и содержат сообщения старше 7 дней? Они просто остаются там? - person Anirudh; 23.12.2019
comment
Концепция истечения срока действия данных называется Cleanup, и сообщения по теме не удаляются сразу после их использования / истечения срока действия. В фоновом режиме происходит следующее: при превышении любого из ограничений сообщения помечаются как удаленные. В Kafka есть 3 политики очистки логов - DELETE (по умолчанию), COMPACT, DELETE AND COMPACT. Kafka Log Cleaner выполняет сжатие журналов, пул фоновых потоков уплотнения. medium.com/@sunny_81705/ & cloudurable.com/blog/kafka-architecture-log-compaction / - person Kumar Rohit; 23.12.2019
comment
Чтобы включить сжатие для темы, используйте конфигурацию темы log.cleanup.policy=compact. Чтобы установить задержку начала сжатия записей после их записи, используйте тему config log.cleaner.min.compaction.lag.ms. Записи не будут уплотняться до истечения этого периода. Эта настройка дает потребителям время для получения каждой записи. Это может быть причиной того, что ваши старые сообщения не удаляются. Вы можете проверить значение свойства для задержки уплотнения log.cleaner.min.compaction.lag.ms. - person Kumar Rohit; 23.12.2019
comment
Это может помочь: https://stackoverflow.com/a/51477919/4245859 - person Bitswazsky; 23.12.2019
comment
Я получил это ... но мой сценарий на самом деле представляет собой сочетание двух файлов журналов, оба из которых имеют записи старше 7 дней, один из которых частично старше 7 дней, а другой полностью старше 7 дней ... обновил мою формулировку проблемы в вопросе. - person Anirudh; 23.12.2019
comment
@Bitswazsky, я думаю, @Anirudh интересуется, почему просроченные сообщения не удаляются. Скорее всего, потому, что cleanup еще не вступил в игру. - person Kumar Rohit; 23.12.2019
comment
@Anirudh Пожалуйста, проверьте мой комментарий выше. Это может быть полезно. - person Bitswazsky; 23.12.2019
comment
Спасибо, но этот комментарий не помогает, так как в вашем комментарии речь идет только о log.retention.bytes, а не о log.retention.bytes и log.retention.ms вместе. - person Anirudh; 23.12.2019
comment
Kafka закроет сегмент журнала либо при достижении предельного размера, либо при достижении предельного времени, в зависимости от того, что наступит раньше. По умолчанию для log.segment.ms нет настройки, что приводит к закрытию только сегментов журнала по размеру. - person Bitswazsky; 23.12.2019
comment
@Anirudh, Небольшая поправка с моей стороны, log.retention.bytes работает на уровне раздела, а не на уровне темы. Для этого вы можете обратиться к этому руководству здесь - learningjournal.guru / курсы / kafka / kafka-foundation-training / - person Kumar Rohit; 23.12.2019

arrow_upward
1
arrow_downward

Я перефразирую здесь из соответствующего раздела книги Kafka - Definitive Guide. Скорее всего, это развеет ваши сомнения.

log.retention.bytes: общее количество байтов сообщений, сохраняемых на раздел. Итак, если у нас есть тема с 8 разделами, а для log.retention.bytes установлено значение 1 ГБ, то объем данных, сохраняемых для темы, будет не более 8 ГБ. Это означает, что если мы когда-либо решим увеличить количество разделов для темы, общий объем сохраняемых данных также увеличится.

log.retention.ms. Наиболее распространенная конфигурация того, как долго Kafka будет хранить сообщения, - это время. Значение по умолчанию указывается в файле конфигурации с помощью параметра log.retention.hours и устанавливается равным 168 часам или одной неделе. Однако есть два других разрешенных параметра: log.retention.minutes и log.retention.ms. Все три из них определяют одну и ту же конфигурацию - время, по истечении которого сообщения могут быть удалены, - но рекомендуется использовать параметр log.retention.ms, поскольку меньший размер блока будет иметь приоритет, если указано более одного. Это гарантирует, что значение, установленное для log.retention.ms, всегда будет использоваться. Если указано более одного, меньший размер блока будет иметь приоритет.

Хранение по времени и времени последнего изменения. Хранение по времени выполняется путем проверки времени последнего изменения (mtime) каждого файла сегмента журнала на диске. При обычных операциях с кластером это время, когда сегмент журнала был закрыт, и представляет собой отметку времени последнего сообщения в файле. Однако при использовании административных инструментов для перемещения разделов между брокерами это время неточно и приведет к избыточному хранению для этих разделов.

Настройка срока хранения по размеру и времени: если вы указали значение для log.retention.bytes и log.retention.ms (или другой параметр для хранения по времени), сообщения могут быть удалены при соблюдении любого из критериев. Например, если для log.retention.ms установлено значение 86400000 (1 день), а для log.retention.bytes установлено значение 1000000000 (1 ГБ), сообщения возрастом менее 1 дня могут быть удалены, если общий объем сообщений в течение день больше 1 ГБ. И наоборот, если объем меньше 1 ГБ, сообщения могут быть удалены через 1 день, даже если общий размер раздела меньше 1 ГБ.

person Bitswazsky    schedule 23.12.2019
comment
И наоборот, если объем меньше 1 ГБ, сообщения могут быть удалены через 1 день, даже если общий размер раздела меньше 1 ГБ. Не понимаете, что вы имеете в виду? - person Anirudh; 23.12.2019
comment
Что ж, весь этот абзац пытается сказать, что, учитывая, что у нас установлены значения обоих этих параметров (1 день и 1 ГБ), данные могут быть удалены раньше, чем период хранения, если размер превышен. Точно так же данные также могут быть удалены, если предел размера еще не достигнут, но срок хранения превышен. Таким образом, из этих двух настроек вступит в силу тот, который будет удовлетворен первым. - person Bitswazsky; 23.12.2019
comment
Я понял, что ^^ .. однако то, что я спрашиваю, возможно, является крайним случаем, я обновил свою формулировку проблемы в вопросе, чтобы сделать ее более ясной. - person Anirudh; 23.12.2019