Topics

Количество разделов — управление производительностью и масштабируемостью кластера. Единицы параллелизма в Kafka. Разделы определяют скорость и масштабирование.

• Для производителей (Producers): несколько разделов позволяет отправлять данные параллельно. Больше разделов — выше общая пропускная способность на запись.
• Для потребителей (Consumers): ключевой момент. В одной группе потребителей (consumer group) каждый раздел может обрабатываться только одним потребителем. Количество разделов определяет максимальное число потребителей в группе, которые могут работать параллельно.

Пример: для 10 разделов можно запустить до 10 потребителей, и каждый будет обрабатывать свой раздел. Если потребителей больше, чем разделов, то лишние потребители будут простаивать и тратить ресурсы впустую .

Дополнительные факторы

• Гарантируется порядок сообщений только внутри одного раздела. Если критичен порядок событий (например, все действия одного пользователя должны обрабатываться последовательно),  используется ключ сообщения (key). Все сообщения с одним ключом всегда попадают в один и тот же раздел, сохраняя порядок.
• Каждый раздел это доп. нагрузка (больше файлов, больше метаданных, больше времени на выборы лидера). Слишком большое количество разделов может привести к нестабильности и деградации производительности .
• Количество разделов можно только увеличить, но не уменьшить. Увеличение числа разделов приводит к перебалансировке потребителей и может изменить способ распределения сообщений по ключам, что нарушит порядок.

Практические рекомендации

• Для большинства новых тем начинать с 6–12 разделов. Это  хороший баланс между производительностью и управляемостью.
• Расчет от потребностей. Если один раздел обрабатывает 10 МБ/с, а нужно 100 МБ/с, то потребуется как минимум 10 разделов .
• Учет роста. Число разделов должно быть с запасом на 2-3 года роста.
• Согласование с потребителями. Количество разделов кратно (или равно) максимальному числу потребителей, которое планируется запускать для параллельной обработки .

Выбор "Number of partitions" — это всегда компромисс между желаемой производительностью, требованиями к порядку данных и операционными затратами на поддержку кластера.

Список. 

• Delete
• Compact
• Compact, Delete

Политика управления сроком жизни данных. По умолчанию delete.

Политика delete (Удаление)

Удаление старых данных по истечении заданного времени или при превышении лимита размера.

Как это работает: удаление когда старше retention.ms (по умолчанию 7 дней), или когда общий размер раздела превышает retention.bytes. Происходит в фоновом режиме с заданным интервалом.

Когда применять: потоки событий и логов, где важна вся история. Например, логи приложений, метрики, трекинговые события. Здесь каждое сообщение самоценно, и старые данные со временем теряют актуальность .

Политика compact (Сжатие)

Эта политика работает по принципу "сохранить только последнее известное состояние" для каждого ключа сообщения .

    Как это работает: Вместо удаления по времени, Kafka в фоновом режиме "сжимает" лог. Для каждого уникального ключа (key) в разделе она оставляет только последнее по времени сообщение, а все промежуточные удаляет .

    Важное условие: Сообщения в таких топиках обязаны иметь ключ (key). Сообщения без ключа будут удалены при сжатии .

    Когда применять: Это идеальный инструмент для топиков, которые хранят состояние или конфигурации. Например:

        Таблица с актуальными данными пользователей (адрес, почта) .

        Информация о текущем статусе заказа.

        Список доступных товаров на складе.

        Внутренний топик Kafka __consumer_offsets, где хранятся текущие смещения потребителей, по умолчанию использует именно эту политику .

🤝 Комбинированная политика delete,compact

Вы можете применить обе политики одновременно, указав их через запятую: cleanup.policy=delete,compact .

В этом случае Kafka сначала удаляет старые данные по времени/размеру, а затем сжимает оставшийся лог. Это полезно, когда вам нужно, с одной стороны, ограничить общий объем данных, а с другой — гарантировать, что для каждого ключа в пределах этого срока хранения сохранится только последнее значение .
⚙️ Важные нюансы

    Изменяемость: Политику можно изменить для уже существующего топика без перезапуска кластера .

    Смена политики: Переключение с delete на compact возможно, но требует осторожности. При включении сжатия сообщения без ключа будут потеряны .

    Производительность: Сжатие требует дополнительных ресурсов ЦП и ввода-вывода, так как в фоне работает специальный "чистильщик" (Log Cleaner) . При неправильной настройке он может повлиять на производительность брокера.

💎 Как выбрать?

Руководствуйтесь простым вопросом: важна ли для вас полная история событий или только их текущее состояние? Если история — выбирайте delete. Если состояние — выбирайте compact.