2016-11-08 2 views
1

Я новичок в Spark. Я попытался запустить простое приложение на Amazon EMR (Python pi approximation найдено here) с 1 рабочим узлом и на втором этапе с 2 рабочими узлами (m4.large). Истекшее время для выполнения задачи составляет приблизительно 25 секунд каждый раз. Наивно, я ожидал чего-то вроде 1,5-кратного усиления с двумя узлами. Я наивна? Это нормально?Время срабатывания искры против количества узлов на AWS EMR

ответ

1

Давайте сделаем простой эксперимент:

from functools import reduce 
from operator import add 
import timeit 

# Taken from the linked example. 

n = 100000 

def f(_): 
    x = random() * 2 - 1 
    y = random() * 2 - 1 
    return 1 if x ** 2 + y ** 2 < 1 else 0 

%timeit -n 100 reduce(add, (f(x) for x in range(n))) 

В результате я получаю, используя довольно старое оборудование:

100 loops, best of 3: 132 ms per loop 

Это должно быть ожидаемое время обработки для одного раздела и значения, которое мы получаем сравнит на время планирования задачи.

Заключение? То, что вы измеряете, - это задержки в кластере и приложениях (инициализация контекста, задержки при планировании, отключение контекста), а не время обработки.

1

Этот вопрос довольно широк, поэтому мой ответ будет таким же широким, но вы получите картину.

Другие машины не всегда означают ускорение вычислений и особенно не в приближении Pi.

Вы не должны забывать о возможных узких местах: сетевом вводе-выводе, сбое данных, дорогих преобразованиях, разбиении и т. Д.

Вот почему бенчмаркинг и мониторинг должны быть выполнены. Также вы можете рассчитывать на то, что контекст Spark должен настраиваться и сбрасываться, что может быть большой частью вашего вычислительного времени.

Плюс m4.large - довольно мощная машина для этой цели. Если вы настроите ганглии на свой EMR-кластер, вы заметите, что искра едва использует свои ресурсы, что заставляет вас думать о настройке при запуске приложения Spark на EMR.

Теперь, чтобы ответить на ваш вопрос. Да, это поведение является нормальным для запуска приложения.

Это сообщение, которое я написал (а) ранее improving latency on a single node apache spark cluster, которые могут дать вам больше информации о этом вопросе.

+0

Спасибо Элиас. Я понимаю, что важны вопросы, касающиеся данных, форматов данных и сложности задачи, но я думал, что конкретная проблема аппроксимации pi была не очень сложной * в отношении этих проблем (например: где сетевой ввод-вывод?). Откуда вы знаете время, потраченное Спарком на создание и срыв? Имеет ли ганглии такую ​​информацию? – Patrick

+0

Я упомянул проблему узких мест в сети, но это не должно быть ваше дело. Я считаю, что вам нужно знать об этом. Вы можете измерить настройку и разрыв соединения с ssh, написав простое приложение, которое это делает, и у вас может быть эмпирическое представление о том, сколько ему нужно. Никакой магии нет. – eliasah

Смежные вопросы