Сколько разделов мне нужно в Apache Kafka?

Apache Kafka — это наша ракета, а отдельные разделы обеспечивают порядок и структуру всех рабочих процессов на каждом этапе полета. Но сколько разделов нам следует создать? Хороший вопрос, на который следует ответить до того, как мы развернем Kafka в продакшн. А также вопрос, которому посвящена следующая запись в блоге. 3,2,1 — запуск. 🚀

Зачем вообще нужны разделы в Apache Kafka?

В Kafka мы используем разделы для ускорения обработки больших объемов данных. Поэтому вместо того, чтобы записывать все данные из темы в один раздел (и, соответственно, одному брокеру), мы разбиваем наши темы на разные разделы и распределяем эти разделы между нашими брокерами. В отличие от других систем обмена сообщениями, наши производители сами решают, в какой раздел записывать наши сообщения. Если мы используем ключи, то производитель распределяет данные так, чтобы данные с одинаковыми ключами попадали в один и тот же раздел. Таким образом, мы можем гарантировать порядок между сообщениями с одинаковым ключом. Если мы не используем ключи, то сообщения распределяются по разделам по кругу.

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

В общем, чем больше разделов, тем

• тем выше пропускная способность данных: И брокеры, и производители могут обрабатывать различные разделы совершенно независимо — и, следовательно, параллельно. Это позволяет этим системам лучше использовать имеющиеся ресурсы и обрабатывать больше сообщений. Важно: Количество разделов может быть значительно больше, чем количество брокеров. Это не является проблемой.

• больше потребителей, которые мы можем иметь в наших группах потребителей: Это также потенциально увеличивает пропускную способность данных, поскольку мы можем распределить работу между большим количеством систем. Но будьте осторожны: Чем больше у нас отдельных систем, тем больше деталей может выйти из строя и вызвать проблемы.

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

• более длительные простои: Если брокер Kafka закрывается чисто, то он уведомляет контроллер, и контроллер может переместить лидеры разделов к другим брокерам без простоя. Однако, если брокер выходит из строя, может возникнуть более длительный простой, поскольку нет лидера для многих разделов. Из-за ограничений Zookeeper потребитель может перемещать только один лидер за раз. Это занимает около 10 мс. При наличии тысяч лидеров, которые необходимо переместить, в некоторых случаях это может занять несколько минут. Если контроллер выходит из строя, то он должен считать лидеры всех разделов. Если это занимает около 2 мс на лидеры, то процесс займет еще больше времени. С KRaft эта проблема станет намного меньше.

• больше оперативной памяти потребляется клиентами: клиенты создают буферы для каждого раздела, и если клиент взаимодействует с большим количеством разделов, возможно, распределенных по многим темам (особенно в качестве производителя), то потребление оперативной памяти сильно возрастает.

Ограничения на разделы

Не существует жестких ограничений на количество разделов в кластерах Kafka. Но вот несколько общих правил:

• максимум 4000 разделов на одного брокера (всего; распределено по многим темам)
• максимум 200 000 разделов на кластер Kafka (в целом; распределено по многим темам)
• в результате максимум 50 брокеров на кластер Kafka.

Это сокращает время простоя в случае, если что-то пойдет не так. Но будьте осторожны: не стоит стремиться превысить эти пределы. Во многих приложениях «средних данных» все это вам не понадобится.

Правила большого пальца

Как уже было сказано в начале, не существует «правильного» ответа на вопрос о количестве разделов. Однако со временем установились следующие эмпирические правила:

• Никаких простых чисел: Несмотря на то, что во многих примерах в Интернете (или в учебных курсах) используются три раздела, в целом, это плохая идея использовать простые числа, поскольку простые числа очень трудно разделить между различным количеством брокеров и потребителей.

• Хорошо делимые числа: Поэтому всегда следует использовать числа, которые могут быть разделены на множество других чисел.

• Кратные числу потребителей: Это позволяет равномерно распределить разделы между потребителями в потребительской группе.

• Кратные брокерам: Это позволяет равномерно распределить разделы (и лидеров!) между всеми брокерами.

• Согласованность в кластере Kafka: Особенно когда мы хотим использовать потоки Kafka, мы понимаем, что имеет смысл сохранить количество разделов одинаковым для всех наших тем. Например, если мы собираемся выполнить объединение двух тем и эти две темы не имеют одинакового количества разделов, Kafka Streams необходимо предварительно переразделить тему. Это дорогостоящая проблема, которую мы хотели бы избежать, если это возможно.

• В зависимости от измерений производительности: Если мы знаем нашу целевую пропускную способность данных, а также знаем измеренную пропускную способность нашего Потребителя и Производителя на раздел, мы можем рассчитать, исходя из этого, сколько разделов нам нужно. Например, если мы знаем, что хотим переместить 100 МБ/с данных и можем достичь 10 МБ/с в Producer на раздел и 20 МБ/с в Consumer, нам потребуется не менее 10 разделов (и не менее 5 Consumers в Consumer Group).

• Не переусердствуйте: Это не соревнование по установке наибольшего количества разделов. Если вы обрабатываете только несколько десятков тысяч сообщений в день, вам не нужны сотни разделов.

Практические примеры

В моей консультационной практике 12 стало хорошим ориентиром для количества разделов. Для клиентов, которые обрабатывают очень мало данных с помощью Kafka (или которым нужно платить за каждый раздел), могут иметь смысл даже меньшие числа (2,4,6). Если вы обрабатываете большие объемы данных, то вам поможет таблица Excel Пере, которую он разместил на GitHub: kafka-cluster-size-calculator.

Эта статья была написана приглашенным автором из Community Stream: разработчики для разработчиков.

Хотите опубликоваться с нами или поделиться своими знаниями о Kafka?
Присоединяйтесь к нашему Discord, чтобы принять участие!

Как IT-тренер и частый блоггер Xeotek, Анатолий Зеленин обучает Apache Kafka сотни участников интерактивных тренингов. Уже более десяти лет его клиенты из среды DAX и среднего бизнеса Германии ценят его опыт и вдохновляющую манеру. В этом качестве он проводит тренинги и для клиентов Xeotek. Его книгу можно приобрести непосредственно у него, в Hanser-Verlag, Amazon. Вы можете связаться с Анатолием по его электронной почте. Кроме того, он является не только ИТ-консультантом, тренером и блоггером, но и исследует нашу планету как искатель приключений.