Имеет ли смысл запустить Spark для своих побочных эффектов?

Question

Я хочу запустить работу Spark, где каждый RDD отвечает за отправку определенного трафика по сетевому соединению. Возвращаемое значение из каждого RDD не очень важно, но я мог бы попросить их вернуть количество отправленных сообщений. Важной частью является сетевой трафик, который в основном является побочным эффектом для запуска функции над каждым RDD.

Это хорошая идея для выполнения вышеуказанной задачи в Spark?

Я пытаюсь имитировать сетевой трафик из нескольких источников, чтобы протестировать инфраструктуру сбора данных на принимающей стороне. Вместо этого я мог вручную настроить несколько компьютеров для запуска отправителя, но я подумал, что было бы неплохо, если бы я мог использовать существующую распределенную инфраструктуру Spark.

Однако, похоже, Spark предназначен для программ «вычислять», а затем «возвращать» что-то, а не для программ, запускаемых для их побочных эффектов. Я не уверен, что это хорошая идея, и я бы оценил вклад других.

Чтобы быть ясно, я имею в виду что-то вроде следующего

IDs = sc.parallelize(range(0, n)) 

def f(x): 
    for i in range(0,100): 
     message = make_message(x, i) 
     SEND_OVER_NETWORK(message) 
    return (x, 100) 

IDsOne = IDs.map(f) 
counts = IDsOne.reduceByKey(add) 

for (ID, count) in counts.collect(): 
    print ("%i ran %i times" % (ID, count)) 

Answer 1

Вообще говоря, это не имеет смысла:

1. искра тяжеловес рамки. По своей сути это огромный механизм, который обеспечивает правильное распределение данных, сбор, восстановление и т. Д. Он оказывает значительное влияние на общую производительность и латентность, но не дает никаких преимуществ в случае задач только для побочных эффектов.

2. Спарковый параллелизм имеет относительно низкую степень детализации, причем раздел является основным элементом параллелизма. На этом уровне обработка становится синхронной. Вы не сможете перейти к следующему разделу, прежде чем завершить текущий.

   Скажем, в вашем случае есть один медленный SEND_OVER_NETWORK. Если вы используете map, вы почти полностью обрабатываете блок на целом разделе. Вы можете перейти на нижний уровень с mapPartitions, сделать асинхронным SEND_OVER_NETWORK и вернуться только тогда, когда весь раздел был обработан. Это лучше, но все же субоптимально.

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

3. Spark API разработан в основном для операций с побочными эффектами. Это затрудняет выражение операций, которые не вписываются в эту модель.

   Что более важно, так это то, что Spark гарантирует только, что каждая операция выполняется как минимум один раз (пусть игнорирует нуль-раз, если rdd никогда не материализуется). Если приложение требует, например, точно: как только семантика становится сложной, особенно если вы считаете, что точка 2.

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