să presupunem că aveți o situație în care un set de date este foarte mic și un alt set de date este destul de mare și doriți să efectuați operația de asociere între aceste două. În acest caz, ar trebui să mergem pentru asocierea la difuzare, astfel încât setul mic de date să se încadreze în variabila dvs. de difuzare. Sintaxa pentru a utiliza variabila de difuzare este df1.Alăturați-vă(difuzare (df2)). Aici avem un al doilea cadru de date care este foarte mic și păstrăm acest cadru de date ca variabilă de difuzare.
Cod:
val broadcastVar = sc.broadcast (Array(1, 2, 3))
broadcastVar.valoare
res0: Array = Array(1, 2, 3)
val accum = sc.acumulator lung („acumulatorul meu”)
sc.parallelize(Array(1, 2, 3, 4)).foreach (x = > accum.adăugați (x))
accum.valoare
res2: Long = 10
Cache și Persist
- Spark oferă propriile mecanisme de cache cum ar fi persist() și cache().
- cache() și persist() vor stoca setul de date în memorie.
- când aveți un set de date mic care trebuie utilizat de mai multe ori în programul dvs., memorăm în cache acel set de date.
- Cache() – întotdeauna în memorie
- Persist() – memorie și discuri
Spark oferă propriul mecanism de cache ca Persist și Cache. Persistă și mecanisme de Cache va stoca setul de date în memorie ori de câte ori există cerință, în cazul în care aveți un set de date mici și că setul de date este utilizat de mai multe ori în programul dumneavoastră. Dacă aplicăm RDD.Cache () acesta va stoca întotdeauna datele în memorie, și dacă vom aplica RDD.Persist () apoi o parte din date pot fi stocate în memorie unele pot fi stocate pe disc.
5. ByKey operațiune
- Shuffles sunt grele de operare care consumă o mulțime de memorie.
- în timp ce codifică în Spark, utilizatorul ar trebui să încerce întotdeauna să evite operarea shuffle.
- amestecare mare poate da naștere la o eroare OutOfMemory; pentru a evita o astfel de eroare, utilizatorul poate crește nivelul de paralelism.
- utilizați reduceByKey în loc de groupByKey.
- partiționați datele corect.
după cum știm în timpul transformării noastre de Spark avem multe operațiuni ByKey. Operațiunile ByKey genera mulțime de shuffle. Shuffles sunt grele de funcționare, deoarece acestea consumă o mulțime de memorie. În timp ce codifică în Spark, un utilizator ar trebui să încerce întotdeauna să evite orice operație de amestecare, deoarece operația de amestecare va degrada performanța. Dacă există amestecare mare, atunci un utilizator poate obține eroarea din memorie. În acest caz, pentru a evita această eroare, un utilizator ar trebui să crească nivelul de paralelism. În loc de groupBy, un utilizator ar trebui să meargă pentru reduceByKey, deoarece groupByKey creează o mulțime de amestecare care împiedică performanța, în timp ce reduceByKey nu amestecă datele la fel de mult. Prin urmare, reduceByKey este mai rapid în comparație cu groupByKey. Ori de câte ori se utilizează orice operație ByKey, utilizatorul ar trebui să partiționeze corect datele.
6. Selectarea formatului de fișier
- Spark acceptă multe formate, cum ar fi CSV, JSON, XML, parchet, ORC, AVRO etc.
- Spark locuri de muncă pot fi optimizate prin alegerea fișierul parchet cu compresie vioi, care oferă de înaltă performanță și cea mai bună analiză.
- fișierul de parchet este nativ pentru Spark, care poartă metadatele împreună cu subsolul său.
Spark vine cu mai multe formate de fișiere, cum ar fi CSV, JSON, XML, parchet, ORC, AVRO și mai mult. O lucrare Spark poate fi optimizată prin alegerea fișierului de parchet cu compresie rapidă. Fișierul parchet este nativ pentru Spark care poartă metadatele împreună cu subsolul său, după cum știm fișierul parchet este nativ pentru spark, care este în format binar și, împreună cu datele pe care le poartă și subsolul, poartă și metadatele și subsolul său, astfel încât ori de câte ori creați orice fișier parchet, veți vedea .fișier metadate pe același director, împreună cu fișierul de date.
Cod:
val peoplefd = scânteie.citește.json („Exemple/src/Principal/Resurse/oameni.json”)
peoplefd.scrie.parchet („oameni.parchet”)
val parquetFileDF = scânteie.citește.parchet („oameni.parchet”)
val usersDF = scânteie.citește.format („avro”).încărcare („Exemple/src/Principal/Resurse/utilizatori.avro”)
usersDF.selectați („Nume”,”favorite_color”).scrie.format („avro”).salvați („namesAndFavColors.avro”)
reglarea colectării gunoiului
- colectarea gunoiului JVM poate fi o problemă atunci când aveți o colecție mare de obiecte neutilizate.
- primul pas în GC tuning este de a colecta statistici prin alegerea – verbose în timp ce trimiterea de locuri de muncă spark.
- într-o situație ideală încercăm să păstrăm cheltuielile generale GC < 10% din memoria heap.
după cum știm sub lucrarea noastră Spark rulează pe platforma JVM, astfel încât colectarea gunoiului JVM poate fi o problemă atunci când aveți o colecție mare de un obiect neutilizat, astfel încât primul pas în reglarea colectării gunoiului este colectarea statică alegând opțiunea din Spark submit verbose. În general, într-o situație ideală ar trebui să păstrăm memoria noastră de colectare a gunoiului mai puțin de 10% din memoria heap.
8. Nivelul de paralelism
- paralelismul joacă un rol foarte important în timp ce tuning locuri de muncă scânteie.
- fiecare partiție ~ task necesită un singur nucleu pentru procesare.
- există două moduri de a menține paralelismul:
- repartiție: dă număr egal de partiții cu amestecare mare
- Coalesce: reduce în general numărul de partiții cu mai puțin amestecare.
în orice mediu distribuit paralelism joacă un rol foarte important în timp ce tuning de locuri de muncă scânteie. Ori de câte ori este trimisă o lucrare Spark, aceasta creează biroul care va conține etape, iar sarcinile depind de partiție, astfel încât fiecare partiție sau activitate necesită un singur nucleu al sistemului pentru procesare. Există două modalități de a menține paralelismul – repartiția și coalescența. Ori de câte ori aplicați metoda de repartiție vă oferă un număr egal de partiții, dar se va amesteca foarte mult, astfel încât nu este recomandabil să mergeți pentru repartiție atunci când doriți să bateți toate datele. Coalesce va reduce, în general, numărul de partiții și creează mai puțin amestecarea datelor.
acești factori pentru optimizarea scânteii, dacă sunt utilizați corect, pot –
