Одновременное задание Spark Stream из одного источника темы Kafka - PullRequest
0 голосов
/ 03 октября 2019

У нас есть простой искровой поток из темы кафки (с 8 разделами), созданный как показано ниже и представленный с 2 ​​исполнителями (по 4 ядра в каждом).

dataSet
   .writeStream()
   .trigger(Trigger.ProcessingTime(0))
   .format("kafka");
   .start();

Теперь рассмотрим этот сценарий:

  1. Один запрос поступает в раздел № 0 этой темы.
  2. Задание запуска будет начинаться с 8 заданий, и только одно из них выполняется (остальные успешно).
  3. Предположим, что обработка этого запроса занимает 1 минуту.
  4. В течение этой 1 минуты в эту тему поступает 100 запросов (во всех 8 разделах).
  5. Spark ожидает завершения текущего задания, а затем создает другое задание для обработки новых запросов.

Мы ожидаем, что Spark обработает другие запросы в другом задании во время обработки первого запроса,но этого не происходитТеперь предположим, что первое задание занимает 1 час вместо 1 минуты, в то время как остальные запросы ожидают обработки, пока 7 ядер простаивают! Это наша проблема.

Я уже пытался отправить это задание несколько раз (например, 4 раза) из 4 разных потоков , но поведение остается прежним. Также я попытался установить эту конфигурацию spark.streaming.concurrentJobs более чем на 1, но без изменений!

Поэтому мой вопрос заключается в том, что возможно ли иметь несколько заданий для одного потока kafkaнабор данных вообще? И если да, то как?

Мы используем Spark 2, Kafka 1 и Java 8.

1 Ответ

0 голосов
/ 08 октября 2019

Итак, после нескольких дней изучения и тестирования, я наконец понял, что ни одна из параллельных настроек задания или отправки заданий в разных потоках не является решением.

Единственное рабочее решение - создание разных потоков для каждого (или группы) разделов темы .

Коэффициент параллелизма в kafka - это раздел. И Spark (и kafka) обладает способностью читать только из определенных разделов. Поэтому, если в нашем разделе есть 4 темы, я делю свою работу Spark на 4 разные работы, каждая из которых слушает (назначает) один раздел, но все они погружаются в одну цель.

Так что теперь, если одна работа занятапри длительном процессе другие задания (здесь 3) все еще могут обрабатывать данные из назначенных им разделов, и им не нужно ждать завершения процесса в других разделах.

Конфигурация подобна приведенной ниже:

assign: {"topic-name":[0,1,2]}

вместо

subscribe: "topic-name"

Обратите внимание на конфигурационную структуру, это должен быть допустимый JSON и список тем должен быть указан в строке через запятую (недиапазон поддержки или исключить)

...