Оптимизация приложения Kafka Streams с несколькими под-топологиями

Question

Я использую приложение Kafka Streams с тремя под-топологиями. Этапы деятельности примерно таковы:

1. stream Тема A
2. selectKey и перераспределение Тема A to Тема B
3. stream Тема B
4. foreach От темы B к теме C Producer
5. stream Тема C
6. Тема C to Тема D

Темы A, B и C материализуются, что означает, что если каждая тема имеет 40 разделов, мой максимальный параллелизм равен 120.

Сначала я запускал 5 потоковых приложений по 8 потоков на штуку. С этой настройкой я испытывал противоречивые результаты. Похоже, что некоторые под-топологии, использующие один и тот же поток, были более требовательны к процессору, чем другие, и через некоторое время я получил бы такую ​​ошибку: Member [client_id] in group [consumer_group] has failed, removing it from the group (kafka.coordinator.group.GroupCoordinator). Все будет перебалансировано, что может привести к снижению производительности до следующего сбоя и перебалансировки.

У меня следующие вопросы:

1. Как получается, что несколько под-топологий могут быть запущены в одном потоке? Очередь опроса?
2. Как каждый поток решает, как распределить вычислительные ресурсы для каждой из его под-топологий?
3. Как оптимизировать соотношение потоков к разделам в таких случаях, чтобы избежать периодических сбоев потребителей? например, обеспечит ли соотношение 1: 1 более стабильную производительность?
4. Если вы используете соотношение 1: 1, как вы гарантируете, что каждому потоку назначается собственный раздел-тема, а некоторые потоки не остаются без дела?

Answer 1

1. Поток будет опрашивать () по всем темам различных под-топологий и проверять записи topic метаданных, чтобы передать их в правильную задачу.

2. Каждая под-топология обрабатывается одинаково, т. Е. Доступные ресурсы распределяются равномерно, если хотите.

3. Соотношение 1: 1 полезно, только если у вас достаточно ядер. Я бы порекомендовал следить за загрузкой вашего процессора. Если оно слишком высокое (больше> 80%), вам следует добавить больше ядер / потоков.

4. Kafka Streams обрабатывает это автоматически.

Пара общих комментариев:

• вы можете увеличить max.poll.interval.ms config, чтобы потребитель не выпал из группы
• Вы можете уменьшить max.poll.records, чтобы получать меньше записей за poll() вызов, и, таким образом, уменьшить время между двумя последовательными вызовами до poll().
• обратите внимание, что max.poll.records не означает увеличения связи между сетью и брокером - если один запрос на выборку возвращает больше записей, чем конфигурация max.poll.records, данные просто буферизуются внутри потребителя, и следующая poll() будет обработана из буферизованных данных, избегая брокера туда и обратно