Le cluster Spark ne s'adapte pas aux petites données

Question

J'évalue actuellement Spark 2.1.0 sur un petit cluster (3 Nodes avec 32 CPU et 128 GB Ram) avec un benchmark en régression linéaire (Spark ML). Je n'ai mesuré que l'heure du calcul des paramètres (sans compter le démarrage, le chargement des données, ...) et reconnu le comportement suivant. Pour les petits jeux de données 0,1 Mio - 3 Mio, le temps mesuré n'augmente pas vraiment et reste à environ 40 secondes. Ce n'est qu'avec des jeux de données plus volumineux, tels que les points de données de 300 Mio, que le temps de traitement est passé à 200 secondes. Il semble donc que le cluster ne s'adapte pas du tout aux petits jeux de données.

J'ai également comparé le petit ensemble de données sur mon PC local avec le cluster en utilisant seulement 10 travailleurs et 16 Go de RAM. Le temps de traitement de la grappe est plus grand d'un facteur 3. Donc est-ce considéré comme un comportement normal de SPARK et explicable par la surcharge de communication ou est-ce que je fais quelque chose de mal (ou la régression linéaire n'est-elle pas vraiment représentative)?

Le cluster est un cluster autonome (sans Yarn ou Mesos) et les benchmarks ont été soumis avec 90 travailleurs, chacun avec 1 core et 4 Go de RAM.

Spark soumettre: étincelle ./spark-submit de --master: // serveur: 7077 du client de référence --deploy mode --total-exécuteur-cœurs 90 --executor mémoire 4g - num-executors 90 .../Benchmark.jar pathToData

Answer 1

La taille et la configuration optimales de la grappe varient en fonction des données et de la nature du travail. Dans ce cas, je pense que votre intuition est correcte, le travail semble prendre plus de temps à compléter sur un ensemble de données plus petit, en raison de l'excès de frais compte tenu de la taille du cluster (noyaux et exécuteurs).

Notez que l'augmentation de la quantité de données de deux ordres de grandeur augmente le temps de traitement de seulement 5 fois. Vous augmentez les données vers une taille optimale pour votre configuration de cluster. Spark est un excellent outil pour traiter beaucoup de données, mais il ne sera pas compétitif avec l'exécution d'un seul processus sur une seule machine si les données vont s'adapter. Cependant, il peut être beaucoup plus rapide que d'autres outils de traitement distribués basés sur disque, où les données ne tiennent pas sur une seule machine. Je parlais il y a quelques années et l'orateur a donné l'analogie que Spark est comme une locomotive faisant du vélo: - la moto va gagner si la charge est légère, plus rapide et plus agile, mais Avec une lourde charge, la locomotive pourrait mettre un certain temps à se mettre à la vitesse supérieure, mais elle sera plus rapide à la fin. (J'ai bien peur d'oublier le nom des intervenants, mais c'était lors d'une réunion de Cassandra à Londres, et le conférencier venait d'une entreprise du secteur de l'énergie).

Answer 2

Je suis d'accord avec l'évaluation de @ ImDarrenG et généralement aussi avec l'analogie locomotive/bicyclette.

Avec Je recommande fortement une petite quantité de données,

A) cache l'ensemble des données et

B) la diffusion de l'ensemble de données à chaque nœud (en particulier si vous avez besoin de faire quelque chose comme votre 300M table jointe aux petits ensembles de données)

Une autre chose à considérer est le nombre de fichiers (si vous n'êtes pas déjà mis en cache), car si vous lisez dans un seul fichier non inscriptible, seulement 1 core sera capable de lisez ce fichier. Cependant, une fois que vous mettez en cache le jeu de données (fusion ou repartitionnement selon le cas), les performances ne onger être lié par disque/sérialiser les lignes.