Spark Transformation - Pourquoi son paresseux et quel est l'avantage?
Spark Transformations sont évalués paresseusement - lorsque nous appelons l'action, il exécute toutes les transformations basées sur le graphe de lignage.
Quel est l'avantage de faire évaluer les Transformations Lazilyy?
Cela améliorera-t-il le performance et moins de memory consumption comparer à évalué avec impatience?
Y a-t-il un inconvénient à faire évaluer la transformation paresseusement?
Pour les transformations, Spark les ajoute à un DAG de calcul et ce n'est que lorsque le pilote demande des données que ce DAG est réellement exécuté.
Un avantage de ceci est que Spark peut prendre de nombreuses décisions d'optimisation après avoir eu la possibilité de regarder le DAG dans son intégralité. Cela ne serait pas possible s'il exécutait tout dès qu'il l'a obtenu.
Par exemple - si vous avez exécuté chaque transformation avec impatience, qu'est-ce que cela signifie? Eh bien, cela signifie que vous devrez matérialiser autant de jeux de données intermédiaires en mémoire. Ce n'est évidemment pas efficace - d'une part, cela augmentera vos coûts de GC. (Parce que vous n'êtes vraiment pas intéressé par ces résultats intermédiaires en tant que tels. Ce ne sont que des abstractions pratiques pour vous lors de l'écriture du programme.) Donc, ce que vous faites à la place est - vous dites Spark what est la réponse éventuelle qui vous intéresse et qui détermine le meilleur moyen d'y arriver.
Considérez un fichier journal de 1 Go dans lequel vous avez des messages d'erreur, d'avertissement et d'information et il est présent dans HDFS sous forme de blocs de 64 ou 128 Mo (peu importe dans ce contexte). Vous créez d'abord un RDD appelé "entrée" de ce texte fichier. Ensuite, vous créez un autre RDD appelé "erreurs" en appliquant un filtre sur le RDD "entrée" pour extraire uniquement les lignes contenant des messages d'erreur, puis appelez l'action first () sur le RDD "erreur". Spark optimisera ici le traitement du fichier journal en s'arrêtant dès qu'il trouvera la première occurrence d'un message d'erreur dans l'une des partitions. Si le même scénario avait été répété lors d'une évaluation désirée, Spark aurait filtré toutes les partitions du fichier journal même si vous n'étiez intéressé que par le premier message d'erreur.
De https://www.mapr.com/blog/5-minute-guide-understanding-significance-Apache-spark
Une évaluation paresseuse signifie que si vous dites Spark d'opérer sur un ensemble de données, il écoute ce que vous lui demandez de faire, écrit un raccourci pour qu'il n'oublie pas, puis ne fait absolument rien. Il continuera de ne rien faire, jusqu'à ce que vous lui demandiez la réponse finale. [...]
Il attend que vous ayez fini de lui donner des opérateurs, et ce n'est que lorsque vous lui demandez de vous donner la réponse finale qu'il évalue, et il cherche toujours à limiter la quantité de travail qu'il doit faire.
Il économise du temps et de la puissance de traitement indésirable.