használatával tegyük fel, hogy van olyan helyzet, amikor az egyik adatkészlet nagyon kicsi, a másik adatkészlet pedig meglehetősen nagy, és a kettő közötti összekapcsolási műveletet szeretné végrehajtani. Ebben az esetben a broadcast csatlakozásra kell mennünk, hogy a kis adatkészlet beleférjen a broadcast változóba. A broadcast változó használatának szintaxisa df1.csatlakozik(adás (df2)). Itt van egy második adatkeret, amely nagyon kicsi, és ezt az adatkeretet broadcast változóként tartjuk meg.
Kód:
val broadcastVar = sc.broadcast (tömb(1, 2, 3))
broadcastVar.érték
res0: Array = Array(1, 2, 3)
val accum = sc.longAccumulator(“saját akkumulátor”)
sc.parallelize (Array(1, 2, 3, 4)).foreach (x = > accum.hozzáad (x))
accum.value
res2: Long = 10
Cache és Persist
- A Spark saját gyorsítótárazási mechanizmusokat biztosít, mint például a persist() és a cache().
- cache() és persist() tárolja az adatkészletet a memóriában.
- ha van egy kis adatkészlet, amelyet többször kell használni a programban, gyorsítótárazzuk azt az adatkészletet.
- Cache() – mindig a memóriában
- Persist() – memória és lemezek
a Spark saját gyorsítótárazási mechanizmust biztosít, mint például a Persist és a Caching. A Persist és a gyorsítótár mechanizmusok az adatkészletet a memóriába tárolják, amikor szükség van rá, ahol van egy kis adatkészlet, és ezt az adatkészletet többször használják a programban. Ha RDD-t alkalmazunk.Cache() mindig tárolja az adatokat a memóriában, és ha alkalmazzuk RDD.Persist () ezután az adatok egy része tárolható a memóriában, néhány tárolható a lemezen.
5. ByKey művelet
- A keverések nehéz műveletek, amelyek sok memóriát fogyasztanak.
- A Spark kódolása közben a Felhasználónak mindig meg kell próbálnia elkerülni a véletlenszerű működést.
- A nagy keverés OutOfMemory hibát okozhat; az ilyen hiba elkerülése érdekében a felhasználó növelheti a párhuzamosság szintjét.
- használja a reduceByKey-t a groupByKey helyett.
- helyesen particionálja az adatokat.
mint tudjuk, a Spark átalakítása során sok ByKey műveletünk van. ByKey műveletek generál sok shuffle. A keverés nehéz művelet, mert sok memóriát fogyasztanak. A Spark kódolása közben a Felhasználónak mindig meg kell próbálnia elkerülni a véletlenszerű műveletet, mert a véletlenszerű művelet rontja a teljesítményt. Ha nagy a keverés, akkor a felhasználó a hibát a memóriából kaphatja meg. Ebben az esetben a hiba elkerülése érdekében a felhasználónak növelnie kell a párhuzamosság szintjét. A groupBy helyett a Felhasználónak a reduceByKey-t kell választania, mert a groupByKey sok keverést hoz létre, ami akadályozza a teljesítményt, míg a reduceByKey nem keveri annyira az adatokat. Ezért a reduceByKey gyorsabb, mint a groupByKey. Bármely ByKey művelet használatakor a felhasználónak helyesen kell particionálnia az adatokat.
6. Fájlformátum kiválasztása
- A Spark számos formátumot támogat, például CSV, JSON, XML, parketta, ORC, AVRO stb.
- A Spark feladatok optimalizálhatók a parketta fájl kiválasztásával, amely gyors tömörítéssel biztosítja a nagy teljesítményt és a legjobb elemzést.
- parketta fájl natív Spark amely hordozza a metaadatok együtt a lábléc.
a Spark számos fájlformátummal rendelkezik, például CSV, JSON, XML, parketta, ORC, AVRO stb. A Spark feladat optimalizálható a parketta fájl kiválasztásával, lendületes tömörítéssel. Parketta fájl natív Spark, amely magában hordozza a metaadatok együtt a lábléc, mint tudjuk parketta fájl natív spark amely a bináris formátumban, valamint az adatokat is hordoz a lábléc ez is hordozza a metaadatok és a lábléc, így amikor bármilyen parketta fájlt, látni fogja .metaadatfájl ugyanabban a könyvtárban az adatfájllal együtt.
Kód:
val peopleDF = spark.olvasd.json (“példák / src / main/resources / people.json”)
peopleDF.írj.parketta (“emberek.parketta”)
val parquetFileDF = szikra.olvasd.parketta (“emberek.parketta”)
val usersDF = spark.olvasd.formátum (“avro”).terhelés (“példák / src / main/resources / users.avro”)
usersDF.válassza a(“név”, “favorite_color”) lehetőséget.írj.formátum (“avro”).Mentés (“namesAndFavColors.avro”)
szemétgyűjtés Tuning
- A JVM szemétgyűjtés problémát jelenthet, ha nagy a nem használt objektumok gyűjteménye.
- a GC tuning első lépése a statisztikák gyűjtése a – verbose kiválasztásával a spark feladatok benyújtása közben.
- ideális helyzetben megpróbáljuk a GC általános költségeit < a heap memória 10% – ában tartani.
mint tudjuk, alatta a Spark feladat fut a JVM platform, így JVM szemétgyűjtés lehet problematikus, ha van egy nagy gyűjteménye egy fel nem használt objektum, így az első lépés a tuning szemétgyűjtés gyűjteni statika kiválasztásával a lehetőséget a Spark submit verbose. Általában ideális helyzetben a szemétgyűjtő memóriánkat a halom memória kevesebb mint 10% – ánál kell tartanunk.
8. A párhuzamosság szintje
- a párhuzamosság nagyon fontos szerepet játszik a spark munkák hangolásakor.
- minden partíció ~ feladathoz egyetlen mag szükséges a feldolgozáshoz.
- kétféle módon lehet fenntartani a párhuzamosságot:
- Újraparticionálás: egyenlő számú partíciót ad nagy keveréssel
- összeolvadás: általában csökkenti a partíciók számát kevesebb keveréssel.
bármely elosztott környezetben a párhuzamosság nagyon fontos szerepet játszik a Spark munka hangolásakor. Amikor egy Spark jobot elküldenek, létrehozza az asztalt, amely szakaszokat tartalmaz, és a feladatok a partíciótól függenek, így minden partíció vagy feladat a rendszer egyetlen magját igényli a feldolgozáshoz. A párhuzamosság fenntartásának két módja van: a felosztás és az összeolvadás. Amikor az Újraparticionálási módszert alkalmazza, egyenlő számú partíciót ad, de sokat keveredik, ezért nem tanácsos az Újraparticionálás, ha az összes adatot meg akarja csapni. A Coalesce általában csökkenti a partíciók számát, és kevesebb adatcserét eredményez.
ezek a tényezők a szikra optimalizálásához, ha megfelelően használják, akkor –
