Temps d'exécution Spark vs nombre de nœuds sur AWS EMR

Question

Je suis nouveau sur Spark. J'ai essayé d'exécuter une application simple sur Amazon EMR (approximation Python pi trouvé here) avec 1 nœud de travail et dans une deuxième phase avec 2 nœuds de travail (m4.large). Le temps écoulé pour terminer la tâche est d'environ 25 secondes chaque fois. Naively, je m'attendais à quelque chose comme un gain de 1.5x avec 2 nœuds. Suis-je naïf? Est-ce normal?

Answer 1

Faisons une expérience simple:

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))) 

Le résultat que je reçois en utilisant du matériel assez vieux:

100 loops, best of 3: 132 ms per loop 

Cela devrait être un temps de traitement prévu pour une seule partition et la valeur que nous obtenons est comparable à l'heure de planification des tâches.

Conclusion? Ce que vous mesurez est la latence du cluster et de l'application (initialisation du contexte, délais de planification, démontage du contexte) et non un temps de traitement.

Answer 2

Cette question est assez large, donc ma réponse sera aussi large, mais vous obtiendrez l'image.

Plus de machines ne signifie pas toujours des calculs plus rapides et surtout pas sur une approximation Pi.

Vous ne devez pas oublier les éventuels goulets d'étranglement: E/S réseau, asymétrie des données, transformations coûteuses, partitionnement, etc. C'est pourquoi l'analyse comparative et la surveillance doivent être effectuées. Vous pouvez également compter le temps que le contexte Spark doit configurer et démonter, ce qui peut être une grande partie de votre temps de calcul.

Plus un m4.large est une machine assez puissante à utiliser à cet effet. Si vous installez des ganglions sur votre cluster EMR, vous remarquerez que l'étincelle utilise à peine ses ressources, ce qui vous amène à penser à l'optimisation lors du lancement d'une application Spark sur EMR.

Maintenant, pour répondre à votre question. Oui, ce comportement est normal pour l'application que vous lancez.

Voici un article que j'ai écrit il y a un moment sur improving latency on a single node apache spark cluster qui pourrait vous donner plus d'informations à propos de ce sujet.