#apache-kafka #apache-kafka-streams
#apache-kafka #apache-kafka-streams
Вопрос:
У меня есть некоторый базовый потоковый код Kafka, который считывает записи из одной темы, выполняет некоторую обработку и выводит записи в другую тему.
Как потоковая передача Kafka обрабатывает параллелизм? Все ли выполняется в одном потоке? Я не вижу, чтобы это упоминалось в документации.
Если он однопоточный, мне бы хотелось, чтобы варианты многопоточной обработки обрабатывали большие объемы данных.
Если он многопоточный, мне нужно понять, как это работает и как обрабатывать ресурсы, например, соединения с базой данных SQL должны совместно использоваться в разных потоках обработки.
Не рекомендуется ли встроенный потоковый API Kafka для сценариев с большим объемом по сравнению с другими опциями (Spark, Akka, Samza, Storm и т. Д.)?
Ответ №1:
Обновление октябрь 2020: я написал серию блогов из четырех частей об основах Kafka, которые я бы рекомендовал прочитать для подобных вопросов. В частности, для этого вопроса взгляните на часть 3, посвященную основам обработки.
На ваш вопрос:
Как потоковая передача Kafka обрабатывает параллелизм? Все ли выполняется в одном потоке? Я не вижу, чтобы это упоминалось в документации.
Это подробно задокументировано на http://docs.confluent.io/current/streams/architecture.html#parallelism-model . Я не хочу копировать-вставлять это здесь дословно, но я хочу подчеркнуть, что IMHO ключевым элементом для понимания является раздел разделов (см. Разделы темы Кафки, которые в потоках Кафки обобщаются на «потоковые разделы», поскольку не все обрабатываемые потоки данных будут проходить черезКафка) потому что раздел в настоящее время определяет параллелизм как Kafka (на стороне брокера / сервера), так и приложений потоковой обработки, которые используют API Kafka Streams (на стороне клиента).
Если он однопоточный, мне бы хотелось, чтобы варианты многопоточной обработки обрабатывали большие объемы данных.
Обработка раздела всегда будет выполняться только одним «потоком», что гарантирует, что вы не столкнетесь с проблемами параллелизма. Но, к счастью, …
Если он многопоточный, мне нужно понять, как это работает и как обрабатывать ресурсы, например, соединения с базой данных SQL должны совместно использоваться в разных потоках обработки.
…поскольку Kafka позволяет теме иметь много разделов, вы все равно получаете параллельную обработку. Например, если тема имеет 100 разделов, то до 100 потоковых задач (или, несколько упрощенно: до 100 разных машин, на каждой из которых запущен экземпляр вашего приложения) могут обрабатывать эту тему параллельно. Опять же, каждая потоковая задача получит эксклюзивный доступ к 1 разделу, который она затем обработает.
Не рекомендуется ли встроенный потоковый API Kafka для сценариев с большим объемом по сравнению с другими опциями (Spark, Akka, Samza, Storm и т. Д.)?
Механизм потоковой обработки Kafka определенно рекомендуется, а также фактически используется на практике для сценариев большого объема. Работа по сравнительному бенчмаркингу все еще ведется, но во многих случаях приложение на основе Kafka Streams оказывается быстрее. См. Блог LINE engineer: применение потоков Kafka для внутреннего конвейера доставки сообщений для статьи LINE Corp, одной из крупнейших социальных платформ в Азии (более 220 миллионов пользователей), где они описывают, как они используют Kafka и API Kafka Streams в производстве для обработки миллионов событий в секунду.
Комментарии:
1. Тем временем ссылка на блог линейного инженера не работает. Вы можете найти его здесь: engineering.linecorp.com/en/blog/detail/80
2. @MichaelG. Noll Как насчет совместного использования ресурсов между несколькими потоками одного экземпляра приложения streams. Если мой ValueMapper не является потокобезопасным, можно ли запускать экземпляр приложения с несколькими потоками?
3. ДА. Единицей работы в API потоков Kafka является «потоковая задача», а потоковая задача выполняется исключительно одним потоком. Это означает, что ваш ValueMapper не обязательно должен быть потокобезопасным. И да, можно запускать экземпляр приложения с несколькими потоками.
4. Я немного смущен @miguno. Происходит ли параллелизм на уровне брокера, не зависит ли он от количества разделов и конфигурации потребителя для этих разделов? Предположим, у меня есть три потребителя, три раздела на одном брокере. Я определяю значение num_stream_threads_config равным ПЯТИ. Что должно произойти?
5. Снова обновляю ссылку для LINE blog -> engineering.linecorp.com/en/blog /…
Ответ №2:
Конфигурация kstreams num.stream.threads позволяет переопределить количество потоков с 1. Однако может быть предпочтительнее просто запустить несколько экземпляров вашего потокового приложения, причем все они будут работать с одной и той же группой потребителей. Таким образом, вы можете развернуть столько экземпляров, сколько вам нужно, чтобы получить оптимальное разделение.
Комментарии:
1. Мой случай заключается в том, что потоковые задачи являются HTTP-вызовами и не требуют интенсивного использования процессора, но требуют интенсивного ожидания. Я хотел бы запустить настраиваемое количество потоков для каждой группы потребителей, например, для 100 разделов я бы запустил 5 приложений по 20 потоков, чтобы каждое приложение обрабатывало 20 разделов. Кажется, я не могу понять, как это сделать. Я предполагаю, что в этом случае я бы установил num.stream.threads равным 20?