Kafka - Spark Streaming Integration: повторное использование DStreams и Task - PullRequest
Новая
       42

Kafka - Spark Streaming Integration: повторное использование DStreams и Task

1 голос
/ 12 мая 2019

Я пытаюсь понять внутреннюю часть потоковой передачи Spark (не структурированной потоковой передачи), в частности то, как задачи видят DStream.Я перебираю исходный код Spark в scala, здесь .Я понимаю стек вызовов: 

ExecutorCoarseGrainedBackend (main) -> Executor (launchtask) -> TaskRunner (Runnable).run() -> task.run(...)

Я понимаю, что DStream действительно является хеш-картой RDD, но я пытаюсь понять, как задачи видят DStream.Я знаю, что в основном существует 2 подхода к интеграции Kafka Spark:

  • Приемник на основе API-интерфейсов высокого уровня Kafka Consumer

    Здесь новая (микро) партия создается в каждом интервале (скажем, 5 секунд), скажем, с 5 разделами (=> 1-секундный интервал блока) с помощью задачи Приемник и передается по потоку Обычный задач.

    Вопрос: Рассматривая наш пример, где каждая микробатка создается каждые 5 секунд;имеет ровно 5 разделов, и все эти разделы всех микробасов должны быть точно одинаково обработаны DAG вниз по потоку, это одна и та же обычная задача, многократно используемая для одного и того же идентификатора раздела каждогомикробатч (RDD) как долгосрочное задание?например,

    Если ubatch1 разделов (P1, P2, P3, P4, P5) в момент T0 назначено идентификаторам задач (T1, T2, T3, T4, T5) , будет ubatch2 разделов (P1 ', P2', P3 ', P4', P5 ') во время T5 также назначается для того же набора задач (T1, T2, T3, T4, T5) или будут новые задачи (T6, T7, T8, T9, T10) быть создан для ubatch2 ?

    Если последнее так, то не будет ли это чрезмерной производительностью, если каждые 5 секунд отправлять новые задания по сети исполнителям, когда вы уже знаете, что есть задачи, выполняющие точно такую ​​же функцию иповторно используется как долго выполняемые задачи?

  • Direct с использованием низкоуровневых API-интерфейсов Kafka

    Здесь разделы Kafka отображаютсяк разделу искры и, следовательно, задача.Опять же, рассматривая 5 разделов Kafka для темы t , мы получаем 5 разделов Spark и соответствующие им задачи.

    Вопрос: Скажите, у ubatch1 в T0 есть разделы (P1, P2, P3, P4, P5) назначен задачам (T1, T2, T3, T4, T5). Будет ubatch2 разделов (P1 ', P2', P3 ', P4', P5 ') во время T5 также назначается для того же набора задач (T1, T2, T3, T4, T5) или будут новые задачи (T6, T7, T8, T9, T10) будет создано для ubatch2 ?

1 Ответ

0 голосов
/ 15 мая 2019

После просмотра исходного кода Apache Spark, вот окончательный ответ:

Это довольно интуитивный подход.

  1. Мы используем SparkStreamingContext (ssc) из SparkContext , чтобы создать и сохранить нашу последовательность преобразований в потоке в форме окончания Dag DStreamв ForEachDStream DStream, где каждый DStream является контейнером RDD, т. е. Hashmap
  2. ForEachDStream зарегистрирован в DStreamGraph ssc .
  3. При ssc.start (-) при выполнении JobScheduler помещает наш сохраненный план в цикл обработки событий, который выполняется каждый интервал ubatch с , создавая / извлекаяRDD для каждого DStream и от каждого DStream в то время, и сохранение его в HashMap для corr.DStream для RememberDuration продолжительности времени (например, для управления окнами)
  4. и в процессе создает группу RDD, заканчивающуюся действием, указанным в ForEachDStream , который затем отправляетновая работа для планировщика DAG.

Этот цикл повторяется через каждые интервалы ubatch секунд.

...