Antag, at du har en situation, hvor et datasæt er meget lille, og et andet datasæt er ret stort, og du vil udføre tilslutningsoperationen mellem disse to. I så fald skal vi gå til broadcast join, så det lille datasæt kan passe ind i din udsendelsesvariabel. Syntaksen for at bruge udsendelsesvariablen er df1.tilslutte(broadcast (df2)). Her har vi en anden dataframe, der er meget lille, og vi holder denne dataramme som en udsendelsesvariabel.
kode:
val broadcastVar = sc.broadcast (Array(1, 2, 3))
broadcastVar.værdi
res0: Array = Array(1, 2, 3)
val accum = sc . longAccumulator (“min akkumulator”)
sc.parallelisere (Array(1, 2, 3, 4)).foreach (> accum.
accum.værdi
res2: Long = 10
Cache og vedvarende
- Spark leverer sine egne cachemekanismer som vedvarende() og cache().
- cache() og vedvarende() gemmer datasættet i hukommelsen.
- når du har et lille datasæt, der skal bruges flere gange i dit program, cache vi det datasæt.
- Cache() – altid i hukommelsen
- vedvarende() – hukommelse og diske
Spark leverer sin egen cachemekanisme som vedvarende og Caching. Vedvarende og Cache mekanismer vil gemme datasættet i hukommelsen, når der er krav, hvor du har et lille datasæt, og at datasættet bliver brugt flere gange i dit program. Hvis vi anvender RDD.Cache () det vil altid gemme data i hukommelsen, og hvis vi anvender RDD.Fortsæt () så kan en del af data gemmes i hukommelsen, nogle kan gemmes på disken.
5. ByKey Operation
- Shuffles er tunge operationer, der bruger meget hukommelse.
- under kodning i Spark skal brugeren altid forsøge at undgå shuffle-drift.
- høj blanding kan give anledning til en OutOfMemory-fejl; for at undgå en sådan fejl kan brugeren øge parallelitetsniveauet.
- brug reduceByKey i stedet for groupByKey.
- del dataene korrekt.
som vi ved under vores transformation af Spark har vi mange ByKey-operationer. ByKey operationer generere masse shuffle. Shuffles er tung drift, fordi de bruger meget hukommelse. Mens kodning i Spark, en bruger bør altid forsøge at undgå enhver shuffle operation, fordi shuffle operation vil forringe ydeevnen. Hvis der er høj blanding, kan en bruger få fejlen ud af hukommelsen. I dette tilfælde skal en bruger øge parallelitetsniveauet for at undgå denne fejl. I stedet for groupBy skal en bruger gå til reduceByKey, fordi groupByKey skaber en masse shuffling, der hæmmer ydeevnen, mens reduceByKey ikke blander dataene så meget. Derfor er reduceByKey hurtigere sammenlignet med groupByKey. Når en ByKey-operation bruges, skal brugeren partitionere dataene korrekt.
6. Valg af filformat
- Spark understøtter mange formater, f.eks.
- Spark jobs kan optimeres ved at vælge parketfilen med snappy kompression, som giver den høje ydeevne og den bedste analyse.
- Parketfil er hjemmehørende i Spark, som bærer metadataene sammen med dens sidefod.
Spark leveres med mange filformater som f.eks. Et Gnistjob kan optimeres ved at vælge parketfilen med snappy kompression. Parketfil er hjemmehørende i Spark, der bærer metadataene sammen med dens sidefod, da vi ved, at parketfil er hjemmehørende i spark, som er i det binære format, og sammen med dataene bærer den også sidefoden, den bærer også metadataene og dens sidefod, så når du opretter en parketfil, du vil se .metadatafil på samme mappe sammen med datafilen.
kode:
val peopleDF = gnist.læse.json (“eksempler/src/main/ressourcer/mennesker.json”)
peopleDF.skrive.parket (“mennesker.parket”)
val parketfiledf = gnist.læse.parket (“mennesker.parket”)
val usersDF = gnist.læse.format (“avro”).belastning (“eksempler/src/main/ressourcer/brugere.avro”)
usersDF.Vælg (“navn”,”favorite_color”).skrive.format (“avro”).Gem (“namesAndFavColors.avro”)
Garbage Collection Tuning
- JVM garbage collection kan være et problem, når du har stor samling af ubrugte genstande.
- det første skridt i GC tuning er at indsamle statistik ved at vælge – verbose mens du sender spark jobs.
- i en ideel situation forsøger vi at holde GC-omkostninger < 10% af heap-hukommelsen.
som vi ved nedenunder kører vores Spark-job på JVM-platformen, så JVM-affaldssamling kan være problematisk, når du har en stor samling af et ubrugt objekt, så det første skridt i tuning af affaldssamling er at samle statik ved at vælge indstillingen i din Spark submit verbose. Generelt bør vi i en ideel situation holde vores affaldssamlingshukommelse mindre end 10% af heap-hukommelsen.
8. Niveau af parallelisme
- parallelisme spiller en meget vigtig rolle, mens du indstiller gnistjob.
- hver partition ~ opgave kræver en enkelt kerne til behandling.
- der er to måder at opretholde paralleliteten på:
- Repartition: giver lige mange partitioner med høj shuffling
- Coalesce: reducerer generelt antallet af partitioner med mindre shuffling.
i ethvert distribueret miljø spiller parallelisme en meget vigtig rolle, mens du indstiller dit Gnistjob. Hver gang et Spark-job indsendes, opretter det skrivebordet, der indeholder faser, og opgaverne afhænger af partition, så hver partition eller opgave kræver en enkelt kerne i systemet til behandling. Der er to måder at opretholde paralleliteten på – omfordeling og sammenblanding. Når du anvender Repartitionsmetoden, giver den dig lige mange partitioner, men det vil blande meget, så det er ikke tilrådeligt at gå til Repartition, når du vil lash alle data. Coalesce vil generelt reducere antallet af partitioner og skaber mindre blanding af data.
disse faktorer for gnistoptimering, hvis de anvendes korrekt, kan –
