Qu'est-ce que spark.driver.maxResultSize?
Le ref dit:
Limite de la taille totale des résultats sérialisés de toutes les partitions pour chaque Spark (par exemple collect)). Doit être d'au moins 1M, ou 0 pour illimité. Les travaux seront abandonnés si la taille totale est supérieure à cette Une limite élevée peut entraîner des erreurs de mémoire insuffisante dans le pilote (cela dépend de spark.driver.memory et de la surcharge de mémoire des objets dans la JVM). La définition d'une limite appropriée peut protéger le pilote contre les erreurs de mémoire insuffisante.
Que fait exactement cet attribut? Je veux dire au début (puisque je ne me bats pas avec un travail qui échoue en raison d'erreurs de mémoire insuffisante), j'ai pensé que je devrais augmenter cela.
Après réflexion, il semble que cet attribut définisse la taille maximale du résultat qu'un travailleur peut envoyer au conducteur, donc le laisser à la valeur par défaut (1G) serait la meilleure approche pour protéger le conducteur.
Mais cela se produira dans ce cas, le travailleur devra envoyer plus de messages, donc le surcoût sera juste que le travail sera plus lent?
Si je comprends bien, en supposant qu'un travailleur souhaite envoyer 4G de données au conducteur, puis avoir spark.driver.maxResultSize=1G, le travailleur enverra 4 messages (au lieu d'un avec illimité spark.driver.maxResultSize). Si c'est le cas, augmenter cet attribut pour protéger mon pilote contre l'assassinat de Yarn devrait être faux.
Mais la question ci-dessus demeure toujours .. Je veux dire que si je la mets à 1 M (le minimum), sera-ce l'approche la plus protectrice?
en supposant qu'un travailleur souhaite envoyer 4 Go de données au pilote, puis avoir spark.driver.maxResultSize = 1G, le travailleur enverra 4 messages (au lieu de 1 avec spark.driver.maxResultSize illimité).
Non. Si la taille estimée des données est supérieure à maxResultSize le travail donné sera abandonné. Le but ici est de protéger votre application contre la perte de pilote, rien de plus.
si je le mets à 1M (le minimum), sera-ce l'approche la plus protectrice?
Dans le sens oui, mais évidemment ce n'est pas utile dans la pratique. Une bonne valeur devrait permettre à l'application de se dérouler normalement mais protéger l'application des conditions inattendues.