web-dev-qa-db-fra.com

Déversement sur le disque et lecture aléatoire spark

Je suis confus à propos de spill to disk et shuffle write. En utilisant le gestionnaire de tri par défaut, nous utilisons un appendOnlyMap pour agréger et combiner les enregistrements de partition, non? Ensuite, lorsque la mémoire d'exécution se remplit, nous commençons à trier la carte, à la renverser sur le disque, puis à nettoyer la carte pour le prochain déversement (si cela se produit), mes questions sont les suivantes:

  • Quelle est la différence entre le déversement sur le disque et l'écriture aléatoire? Ils consistent essentiellement à créer des fichiers sur le système de fichiers local et aussi à enregistrer.

  • Les admissions sont différentes, donc les enregistrements de déversement sont triés car ils sont passés sur la carte, mais mélangent les enregistrements d'écriture non car ils ne passent pas de la carte.

  • J'ai l'idée que la taille totale du fichier renversé devrait être égale à la taille de l'écriture aléatoire, peut-être que je manque quelque chose, veuillez aider à comprendre cette phase.

Merci.

Giorgio

apache-sparkrddshuffle
10
Giorgio

spill to disk et shuffle write sont deux choses différentes

spill to disk - Déplacement des données de l'hôte RAM vers le disque hôte - est utilisé quand il n'y en a pas assez RAM sur votre machine , et il place une partie de son RAM sur le disque

http://spark.Apache.org/faq.html

Mes données doivent-elles tenir en mémoire pour utiliser Spark?

Non. Les opérateurs de Spark déversent des données sur le disque s'il ne tient pas en mémoire, ce qui lui permet de bien fonctionner sur toutes les données de taille. De même, les ensembles de données mis en cache qui ne tiennent pas en mémoire sont soit déversés sur le disque, soit recalculés à la volée lorsque cela est nécessaire, comme déterminé par le niveau de stockage du RDD.

shuffle write - Les données se déplacent d'exécuteur (s) vers un autre exécuteur (s) - est utilisé lorsque les données doivent se déplacer entre les exécuteurs (par exemple en raison de JOIN, groupBy, etc.)

plus de données peuvent être trouvées ici:

Un exemple de cas Edge qui pourrait aider à résoudre ce problème:

  • Vous avez 10 exécuteurs testamentaires
  • Chaque exécuteur avec 100 Go de RAM
  • La taille des données est de 1280 Mo et est partitionnée en 10 partitions
  • Chaque exécuteur détient 128 Mo de données.

En supposant que les données contiennent une clé, l'exécution de groupByKey réunira toutes les données dans une partition. Shuffle size sera de 9 * 128 Mo (9 exécuteurs transfèreront leurs données dans le dernier exécuteur), et il n'y aura pas de spill to disk car l'exécuteur dispose de 100 Go de RAM et seulement 1 Go de données

Concernant AppendOnlyMap :

Comme écrit dans le code AppendOnlyMap (voir ci-dessus) - cette fonction est une implémentation de bas niveau d'une simple table de hachage ouverte optimisée pour le cas d'utilisation de l'ajout uniquement, où les clés ne sont jamais supprimées, mais la valeur de chaque clé peut être modifié.

Le fait que deux modules différents utilisent la même fonction de bas niveau ne signifie pas que ces fonctions sont liées en haut niveau.

18
Yaron