Spark Transformations sono valutati lazy - quando chiamiamo l'azione esegue tutte le trasformazioni basate sul grafico di lineage.Spark Transformation - Perché è pigro e qual è il vantaggio?
Qual è il vantaggio di aver valutato Transformations Lazy?
Migliorerà lo performance e meno il valore di memory consumption rispetto a valutare con entusiasmo?
Esiste uno svantaggio nel valutare la trasformazione pigro?
Per le trasformazioni, Spark le aggiunge a un DAG di calcolo e solo quando il driver richiede alcuni dati, questo DAG viene effettivamente eseguito.
Un vantaggio di questo è che Spark può prendere molte decisioni di ottimizzazione dopo aver avuto la possibilità di esaminare il DAG nella sua interezza. Questo non sarebbe possibile se eseguisse tutto appena l'ha ottenuto.
Ad esempio: se esegui ogni trasformazione con impazienza, che cosa significa? Beh, significa che dovrai materializzare tutti i tanti set di dati intermedi nella memoria. Questo evidentemente non è efficiente, per esempio aumenterà i costi del GC. (Perché in realtà non ti interessano questi risultati intermedi in quanto tali: sono solo astrazioni convettive per te mentre scrivi il programma.) Quindi, invece, quello che fai è - dici a Spark quale è la risposta finale che ti interessa e trova il modo migliore per arrivarci.
Considera un file di registro di 1 GB in cui sono presenti messaggi di errore, di avviso e di informazioni ed è presente in HDFS come blocchi di 64 o 128 MB (non è rilevante in questo contesto). Prima devi creare un RDD chiamato "input "di questo file di testo. Quindi, si crea un altro RDD chiamato "errori" applicando il filtro sull'RDD "input" per recuperare solo le righe contenenti i messaggi di errore e quindi chiamare l'azione first() sul file "error" RDD. Spark ottimizzerà qui l'elaborazione del file di registro arrestandosi non appena trova la prima occorrenza di un messaggio di errore in una qualsiasi delle partizioni. Se lo stesso scenario fosse stato ripetuto con una valutazione entusiasta, Spark avrebbe filtrato tutte le partizioni del file di registro anche se si era interessati solo al primo messaggio di errore.
Da https://www.mapr.com/blog/5-minute-guide-understanding-significance-apache-spark
valutazione pigro significa che se dite Spark di operare su un insieme di dati, si ascolta quello che gli chiedi di fare, scrive giù qualche scorciatoia per esso in modo che non dimentica e quindi non fa assolutamente nulla. Continuerà a non fare nulla, finché non lo chiederai per la risposta finale. [...]
Attende fino a quando non hai finito di fornirlo agli operatori, e solo quando gli chiedi di darti la risposta definitiva lo valuta, e sembra sempre limitare il lavoro che deve fare.
Risparmia tempo e potenza di elaborazione indesiderata.