# Topics **Создание темы (topic)** [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2026-09/scaled-1680-/image.png)](http://bobrobotirk.ru/uploads/images/gallery/2026-09/image.png)
ПолеТип данныхОписание
Topic Name СтрокаНазвание темы.
Number of partitionsЦелое числоКоличество разделов — управление производительностью и масштабируемостью кластера. Единицы параллелизма в Kafka. Разделы определяют скорость и масштабирование. - Для производителей (Producers): несколько разделов позволяет отправлять данные параллельно. Больше разделов — выше общая пропускная способность на запись. - Для потребителей (Consumers): ключевой момент. В одной группе потребителей (consumer group) каждый раздел может обрабатываться только одним потребителем. Количество разделов определяет максимальное число потребителей в группе, которые могут работать параллельно. **Пример**: для 10 разделов можно запустить до 10 потребителей, и каждый будет обрабатывать свой раздел. Если потребителей больше, чем разделов, то лишние потребители будут простаивать и тратить ресурсы впустую . **Дополнительные факторы** - Гарантируется порядок сообщений только внутри одного раздела. Если критичен порядок событий (например, все действия одного пользователя должны обрабатываться последовательно), используется ключ сообщения (key). Все сообщения с одним ключом всегда попадают в один и тот же раздел, сохраняя порядок. - Каждый раздел это доп. нагрузка (больше файлов, больше метаданных, больше времени на выборы лидера). Слишком большое количество разделов может привести к нестабильности и деградации производительности . - Количество разделов можно только увеличить, но не уменьшить. Увеличение числа разделов приводит к перебалансировке потребителей и может изменить способ распределения сообщений по ключам, что нарушит порядок. **Практические рекомендации** - Для большинства новых тем начинать с 6–12 разделов. Это хороший баланс между производительностью и управляемостью. - Расчет от потребностей. Если один раздел обрабатывает 10 МБ/с, а нужно 100 МБ/с, то потребуется как минимум 10 разделов . - Учет роста. Число разделов должно быть с запасом на 2-3 года роста. - Согласование с потребителями. Количество разделов кратно (или равно) максимальному числу потребителей, которое планируется запускать для параллельной обработки . Выбор "Number of partitions" — это всегда компромисс между желаемой производительностью, требованиями к порядку данных и операционными затратами на поддержку кластера.
Cleanup policyСписок. - 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.