8 Tecniche di ottimizzazione delle prestazioni Utilizzando Spark

Supponiamo di avere una situazione in cui un set di dati è molto piccolo e un altro set di dati è piuttosto grande e si desidera eseguire l’operazione di join tra questi due. In tal caso, dovremmo andare per il join broadcast in modo che il piccolo set di dati possa adattarsi alla variabile broadcast. La sintassi per utilizzare la variabile broadcast è df1.partecipa (trasmissione (df2)). Qui abbiamo un secondo dataframe che è molto piccolo e stiamo mantenendo questo frame di dati come variabile broadcast.

Codice:

val broadcastVar = sc.trasmissione (matrice(1, 2, 3))

broadcastVar.valore

res0: Array = Array(1, 2, 3)

val accum = sc.longAccumulator (“Il mio accumulatore”)

sc.parallelizza (matrice(1, 2, 3, 4)).foreach (x = > accum.aggiungi (x))

accum.valore

res2: Long = 10

Cache e Persist

  • Spark fornisce i propri meccanismi di caching come persist() e cache().
  • cache () e persist () memorizzeranno il set di dati in memoria.
  • Quando hai un piccolo set di dati che deve essere usato più volte nel tuo programma, memorizziamo quel set di dati.
  • Cache () – Sempre in memoria
  • Persist() – Memoria e dischi

Spark fornisce il proprio meccanismo di caching come Persist e Caching. I meccanismi Persist e Cache memorizzeranno il set di dati nella memoria ogni volta che è necessario, in cui si dispone di un piccolo set di dati e tale set di dati viene utilizzato più volte nel programma. Se applichiamo RDD.Cache () memorizzerà sempre i dati in memoria e se applichiamo RDD.Persist() quindi una parte dei dati può essere memorizzata nella memoria alcuni possono essere memorizzati sul disco.

5. Operazione ByKey

  • I miscugli sono operazioni pesanti che consumano molta memoria.
  • Durante la codifica in Spark, l’utente dovrebbe sempre cercare di evitare l’operazione shuffle.
  • Il rimescolamento elevato può dar luogo a un errore di memoria; Per evitare tale errore, l’utente può aumentare il livello di parallelismo.
  • Usa reduceByKey invece di groupByKey.
  • Partizionare correttamente i dati.

Come sappiamo durante la nostra trasformazione di Spark abbiamo molte operazioni ByKey. Le operazioni ByKey generano molta confusione. I miscugli sono operazioni pesanti perché consumano molta memoria. Durante la codifica in Spark, un utente dovrebbe sempre cercare di evitare qualsiasi operazione shuffle perché l’operazione shuffle degraderà le prestazioni. Se c’è un alto rimescolamento, un utente può ottenere l’errore dalla memoria. In questo caso, per evitare quell’errore, un utente dovrebbe aumentare il livello di parallelismo. Invece di groupBy, un utente dovrebbe optare per reduceByKey perché groupByKey crea un sacco di rimescolamento che ostacola le prestazioni, mentre reduceByKey non mescola i dati tanto. Pertanto, reduceByKey è più veloce rispetto a groupByKey. Ogni volta che viene utilizzata qualsiasi operazione ByKey, l’utente deve partizionare correttamente i dati.

6. Selezione del formato file

  • Spark supporta molti formati, come CSV, JSON, XML, PARQUET, ORC, AVRO, ecc.
  • I lavori Spark possono essere ottimizzati scegliendo il file parquet con compressione snappy che offre le alte prestazioni e la migliore analisi.
  • Il file Parquet è nativo di Spark che trasporta i metadati insieme al suo piè di pagina.

Spark viene fornito con molti formati di file come CSV, JSON, XML, PARQUET, ORC, AVRO e altro ancora. Un lavoro Spark può essere ottimizzato scegliendo il file parquet con compressione snappy. Il file Parquet è nativo di Spark che trasporta i metadati insieme al suo piè di pagina come sappiamo il file parquet è nativo di spark che è nel formato binario e insieme ai dati porta anche il piè di pagina porta anche i metadati e il suo piè di pagina, quindi ogni volta che crei un file parquet, vedrai .file di metadati nella stessa directory insieme al file di dati.

Codice:

val peopleDF = spark.Leggete.json (“esempi / src / principale / risorse / persone.json”)

peopleDF.scrivere.parquet (“persone.parquet”)

val parquetFileDF = spark.Leggete.parquet (“persone.parquet”)

val usersDF = spark.Leggete.formato (“avro”).load (“esempi / src / main / risorse / utenti.avro”)

usersDF.seleziona (“nome”, “favorite_color”).scrivere.formato (“avro”).salva (“namesAndFavColors.avro”)

Garbage Collection Tuning

  • JVM garbage collection può essere un problema quando si dispone di una vasta collezione di oggetti inutilizzati.
  • Il primo passo nella messa a punto GC consiste nel raccogliere statistiche scegliendo – verbose durante l’invio dei lavori spark.
  • In una situazione ideale cerchiamo di mantenere le spese generali di GC < il 10% della memoria heap.

Come sappiamo sotto il nostro lavoro Spark è in esecuzione sulla piattaforma JVM, quindi la garbage collection JVM può essere un problema quando si dispone di una vasta collezione di un oggetto inutilizzato, quindi il primo passo nella messa a punto della garbage collection è raccogliere la statica scegliendo l’opzione nella Spark submit verbose. Generalmente, in una situazione ideale dovremmo mantenere la nostra memoria di garbage collection inferiore al 10% della memoria heap.

8. Livello di parallelismo

  • Il parallelismo svolge un ruolo molto importante durante l’ottimizzazione dei lavori spark.
  • Ogni attività partition ~ richiede un singolo core per l’elaborazione.
  • Ci sono due modi per mantenere il parallelismo:
    • Ripartizione: fornisce un numero uguale di partizioni con un elevato shuffling
    • Coalesce: generalmente riduce il numero di partizioni con meno shuffling.

In qualsiasi ambiente distribuito il parallelismo svolge un ruolo molto importante durante la messa a punto del lavoro Spark. Ogni volta che viene inviato un lavoro Spark, crea la scrivania che conterrà fasi e le attività dipendono dalla partizione, quindi ogni partizione o attività richiede un singolo nucleo del sistema per l’elaborazione. Ci sono due modi per mantenere il parallelismo: la ripartizione e la fusione. Ogni volta che applichi il metodo di ripartizione ti dà lo stesso numero di partizioni, ma mescolerà molto, quindi non è consigliabile andare per la ripartizione quando vuoi sferzare tutti i dati. Coalesce generalmente riduce il numero di partizioni e crea meno rimescolamento dei dati.

Questi fattori per l’ottimizzazione spark, se usati correttamente, possono –



+