Основное использование приложений потоковой передачи Spark

Мы создаем систему, состоящую из нескольких приложений Spark Streaming, каждое из которых имеет несколько приемников. Насколько я понял, для каждого ресивера нужно свое ядро ​​в кластере. Нам нужно несколько приемников для обработки пиков, но они не нужны нам постоянно. Приложения довольно малы, выполняя только одну задачу, чтобы (повторно) отправить их в кластер, не отвлекая другие задания и задачи.

1) Предполагая, что у нас есть 5 заданий с 5 приемниками в каждом, нам потребуется не менее 25 ядер в кластере только для работы приемников + ядра для обработки. Это правильно?

2) Есть ли возможность сделать более динамичное распределение ресурсов или одно ядро ​​жестко привязано к одному приемнику?

3) Я взглянул на сервер spark-rest, который предлагает возможность совместного использования контекста искры для разных заданий. Не могли бы вы подумать об одном SparkStreamingContext для всех (~ 100) заданий?

Мы запускаем кластер в автономном режиме вместе с кластером Cassandra на тех же узлах.


apache-spark spark-streaming spark-jobserver
person mniehoff    schedule 21.10.2015    source источник

Ответы (1)


arrow_upward
2
arrow_downward

  1. Если вы запускаете 5 отдельных приложений Spak, каждое из которых имеет 5 получателей, да, прием данных будет потреблять 5x5 = 25 ядер. Однако рассматривали ли вы подходы без приемника? ( § 2 документа https://spark.apache.org/docs/latest/streaming-kafka-integration.html )
  2. Spark имеет возможности динамического распределения в Yarn и на Mesos, но это касается исполнителей, а не получателей.
  3. Конвейерная обработка данных в рамках меньшего (количества) приложения (приложений) имеет смысл: если у вас есть ~ 100 приложений, каждое из которых выполняет простой ETL, вполне вероятно, что запуск и планирование этих приложений займет больше времени, чем выполнение хруста, который они на самом деле делают. Я могу ошибаться в этом, но тогда вам не нужно было бы более конкретно указывать, что они делают (возможно, в другом вопросе SO, после того, как вы немного сравнили?)
person Francois G    schedule 07.11.2015
comment
спасибо за ответ. 1. Прямой подход был бы вариантом, если бы мы использовали Kafka ;-) 2. Я узнал (спросив здесь), что динамическое распределение еще не поддерживается для Spark Streaming. По крайней мере, не автоматическое масштабирование, а только с реализацией его самостоятельно. 3. Теперь мы используем несколько потоков в одном приложении Spark. Пока это выглядит нормально, но у нас все еще есть несколько проблем с накладными расходами на запуск задач. Это требует некоторой оптимизации. - person mniehoff; 23.11.2015