Oletetaan, että sinulla on tilanne, jossa yksi tietojoukko on hyvin pieni ja toinen tietojoukko on melko suuri, ja haluat suorittaa liitosoperaation näiden kahden välillä. Siinä tapauksessa, meidän pitäisi mennä broadcast liittyä niin, että pieni tietojoukko mahtuu broadcast muuttuja. Broadcast-muuttujan syntaksi on DF1.join(broadcast (df2)). Tässä meillä on toinen datakehys, joka on hyvin pieni ja pidämme tätä datakehystä lähetysmuuttujana.
Code:
val broadcastVar = sc.broadcast(Array(1, 2, 3))
broadcastVar.arvo
res0: Array = Array(1, 2, 3)
val accum = sc.longAccumulator (”My Accumulator”)
sc.parallelize(joukko(1, 2, 3, 4)).foreach(x = > accum.add (x))
accum.arvo
res2: Long = 10
Cache and continue
- Spark tarjoaa omat välimuistimekanisminsa kuten continue() ja cache().
- cache() ja continue() tallentavat aineiston muistiin.
- kun sinulla on pieni tietokokonaisuus, jota täytyy käyttää useita kertoja ohjelmassasi, me tallennamme sen.
- välimuisti() – aina muistissa
- jatkuvat() – muisti ja levyt
kipinä tarjoaa Oman välimuistimekanisminsa kuten säilyvyys ja Välimuisti. Jatkuvat ja Välimuisti mekanismit tallentaa tiedot muistiin aina, kun on vaatimus, jossa sinulla on pieni tietojoukko ja että tietojoukkoa käytetään useita kertoja ohjelmassa. Jos käytämme RDD: tä.Cache () se tallentaa tiedot aina muistiin, ja jos sovellamme RDD.Säily () sitten jokin osa tiedoista voidaan tallentaa muistiin jotkut voidaan tallentaa levylle.
5. Bykeyn operaatio
- Shuffles on raskas operaatio, joka kuluttaa paljon muistia.
- koodatessaan Sparkissa käyttäjän tulee aina yrittää välttää sekoitustoimintaa.
- Suuri sekoittaminen voi aiheuttaa Epäemorisen virheen; tällaisen virheen välttämiseksi käyttäjä voi lisätä yhdensuuntaisuuden tasoa.
- käytä reducebykeytä groupbykeyn sijaan.
- Osioi tiedot oikein.
kuten tiedämme kipinän muutostyön aikana, meillä on monia Bykeyn operaatioita. ByKey-toiminnot tuottavat paljon sekoitusta. Sekoitukset ovat raskas operaatio, koska ne kuluttavat paljon muistia. Kun koodaat Sparkissa, käyttäjän tulee aina yrittää välttää sekoitustoimintaa, koska sekoitustoiminto heikentää suorituskykyä. Jos sekoittaminen on suurta, käyttäjä voi saada virheen pois muistista. Tässä tapauksessa kyseisen virheen välttämiseksi käyttäjän olisi lisättävä yhdensuuntaisuuden tasoa. Groupbyn sijaan käyttäjän tulisi käyttää reducebykeytä, koska groupByKey luo paljon sekoitusta, joka haittaa suorituskykyä, kun taas reduceByKey ei sekoita tietoja yhtä paljon. Siksi reduceByKey on nopeampi verrattuna groupbykeyhin. Aina kun ByKey-toimintoa käytetään, käyttäjän tulee osioida tiedot oikein.
6. Tiedostomuodon valinta
- Spark tukee monia formaatteja, kuten CSV, JSON, XML, PARQUET, ORC, AVRO jne.
- Kipinätöitä voidaan optimoida valitsemalla parkettitiedosto, jossa on reipas pakkaus, joka antaa korkean suorituskyvyn ja parhaan analyysin.
- Parquet-tiedosto on peräisin Sparkilta, joka kuljettaa metatiedot alatunnisteensa mukana.
Sparkissa on monia tiedostomuotoja, kuten CSV, JSON, XML, PARQUET, ORC, AVRO ja paljon muuta. Kipinätyö voidaan optimoida valitsemalla parkettitiedosto reippaalla puristuksella. Parketti tiedosto on kotoisin Spark joka kuljettaa metatiedot yhdessä sen alatunnisteen kuten tiedämme parketti tiedosto on kotoisin spark joka on binaarimuodossa ja yhdessä tietojen se myös kuljettaa alatunnisteen se kuljettaa myös metatiedot ja sen alatunnisteen niin aina kun luot parketti tiedosto, näet .metatietotiedosto samassa hakemistossa yhdessä datatiedoston kanssa.
Code:
val peopleDF = spark.lukea.json (”examples/src/main/resources/people.json”)
peopleDF.kirjoittaa.parketti (”ihmiset.parquet”)
val parquetFileDF = spark.lukea.parketti (”ihmiset.parquet”)
val usersDF = spark.lukea.formaatti (”avro”).load (”examples/src/main/resources/users.avro”)
usersDF.valitse (”name”, ”favorite_color”).kirjoittaa.formaatti (”avro”).Tallenna (”namesAndFavColors.avro”)
Roskakeräyksen viritys
- JVM roskakeräys voi olla ongelma, kun on suuri kokoelma käyttämättömiä esineitä.
- GC-virityksen ensimmäinen vaihe on kerätä tilastoja valitsemalla-sanallisesti samalla kun lähetetään kipinätöitä.
- ideaalitilanteessa yritämme pitää GC-yleiskustannukset < 10% heap-muistista.
kuten tiedämme kipinätyömme alla olevan käynnissä JVM-alustalla, joten JVM garbage collection voi olla ongelmallinen, kun sinulla on suuri kokoelma käyttämätöntä esinettä, joten ensimmäinen askel roskien keräämisen virittämisessä on kerätä statiikkaa valitsemalla vaihtoehto kipinä-lähetyksessä monisanaisesti. Yleensä ideaalitilanteessa roskankeräysmuistin tulisi olla alle 10% kasamuistista.
8. Rinnakkaisuuden taso
- Parallelismilla on erittäin tärkeä rooli kipinätöiden virittämisessä.
- jokainen osio ~ tehtävä vaatii yhden ytimen käsittelyä varten.
- on olemassa kaksi tapaa säilyttää yhdensuuntaisuus:
- Repartition: antaa yhtä monta osiota, joissa on suuri sekoittuminen
- yhteenliittyminen: yleensä vähentää osioiden määrää, joissa sekoittuminen on vähäisempää.
missä tahansa hajautetussa ympäristössä rinnakkaisuus on erittäin tärkeä rooli, kun tuning Kipinätyö. Aina kun Kipinätyö lähetetään, se luo työpöydän, joka sisältää vaiheita, ja tehtävät riippuvat osiosta, joten jokainen osio tai tehtävä vaatii yhden järjestelmän ytimen käsittelyä varten. On olemassa kaksi tapaa säilyttää rinnakkaisuus-Repartition ja Coalesce. Aina kun käytät Repartition menetelmä se antaa sinulle yhtä monta osioita, mutta se sekoittaa paljon, joten se ei ole suositeltavaa mennä Repartition kun haluat ripsi kaikki tiedot. Coalesce vähentää yleensä osioiden määrää ja luo vähemmän tietojen sekoittumista.
oikein käytettynä nämä kipinän optimointikertoimet voivat –
