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

57
5

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

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

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

    Приемник на основе API высокого уровня Kafka Consumer

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

    Вопрос: Рассмотрим наш пример, где каждая микробатка создается каждые 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 секунд отправляются новые задачи по сети исполнителям, если вы уже знаете, что есть задачи, выполняющие одну и ту же задачу и могут быть использованы повторно в течение длительного времени? задачи?

    Прямое использование низкоуровневых потребительских API Kafka

    Здесь Kafka Partition отображается на Spark Partition и, следовательно, Task. Опять же, рассматривая 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?

спросил(а) 2019-05-12T21:12:00+03:00 1 год, 4 месяца назад
1
Решение
120

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

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

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

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

ответил(а) 2019-05-15T21:00:00+03:00 1 год, 4 месяца назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема