Forståelse persistens i Apache Spark

Læsetid: 4 minutter

i denne blog vil vi forsøge at forstå begrebet persistens i Apache Spark i en meget lægmand sigt med scenario-baserede eksempler.
Bemærk: scenarierne er kun beregnet til din nemme forståelse.

Spark arkitektur

Bemærk: cachehukommelse kan deles mellem eksekutorer.

hvad betyder det ved vedvarende/caching en RDD?

Spark RDD persistens er en optimering teknik, der gemmer resultatet af RDD evaluering i cachehukommelsen. Ved hjælp af dette gemmer vi mellemresultatet, så vi kan bruge det yderligere, hvis det kræves. Det reducerer beregningen overhead.

når vi fortsætter en RDD, gemmer hver node partitionerne af den, som den beregner i hukommelsen, og genbruger dem i andre handlinger på den RDD (eller RDD afledt af den). Dette gør det muligt for fremtidige handlinger at være meget hurtigere (ofte med mere end 10 gange). Caching er et vigtigt værktøj til iterative algoritmer og hurtig interaktiv brug.

du kan markere en RDD, der skal vedvares ved hjælp af persist() eller cache() metoderne på den. Første gang det beregnes i en handling, opbevares det i cachehukommelsen på knudepunkterne. Sparks cache er fejltolerant-hvis en partition af en RDD går tabt, beregnes den automatisk ved hjælp af de transformationer, der oprindeligt oprettede den.

lad os sige, at jeg har denne transformation–

RDD3 => RDD2 => RDD1 => Text FileRDD4 => RDD3RDD5 => RDD3

RDD3 er oprettet fra RDD2 og RDD2 er oprettet fra RDD1. Hver gang vi foretager en transformation på RDD3, skal RDD2 og RDD1 beregnes igen og igen.

RDD4.collect()RDD5.collect()

her skal hele transformationskæden beregnes to gange.

men vi kan fortsætte denne RDD3 i cachehukommelsen på Arbejdernoden, så hver gang vi bruger den, behøver RDD2 og RDD1 ikke at blive beregnet igen.

RDD3.cache()RDD4.collect()//The first action which involves RDD3 will store it in cache memoryRDD5.collect()

her, for at beregne rdd5 Spark vil læse RDD3 fra cachehukommelsen og generere resultatet. Derfor beregnes RDD2 og RDD1 ikke for RDD5

Bemærk: rdd.cache () er det samme som rdd.persistere()

Persistensniveauer

lagerplads

– MEMORY_ONLY (standard) – samme som cache
rdd.fortsæt (lagringsniveau.MEMORY_ONLY) eller rdd.vedvarende ()

– MEMORY_AND_DISK – gemmer partitioner på disk, som ikke passer i hukommelsen (dette kaldes også spild)
rdd.fortsæt (lagringsniveau.MEMORY_AND_DISK)

– DISK_ONLY – gemmer alle partitioner på disken
RDD.fortsæt (lagringsniveau.DISK_ONLY)

– MEMORY_ONLY (standard) – dette er den enkleste og mest anbefalede at bruge. Det gemmer alle partitioner af RDD i cachehukommelsen.

– DISK_ONLY – lad os sige, at jeg har en RDD (navngivet RDD1), og beregningen af den RDD er meget kompliceret (tidskrævende, oprettet efter anvendelse af en ML-algoritme), og RDD er enorm i størrelse og tilgængelig cachehukommelse i Arbejdsnoden er mindre, så vi kan ikke gemme RDD i cachehukommelsen. I dette tilfælde kan vi gemme RDD i disken.

du undrer dig måske over, hvad der er meningen med lagring i disken?

bestemt, hvis vi gemmer RDD i disken, vil I/O forekomme, hvilket er tidskrævende. Men vi skal sikre, at om I/O tager lang tid eller omberegningen af RDD tager længere tid. Nu, hvis vi kan finde ud af, at I/O tager mindre tid end omberegningen af RDD, så er det i så fald bedre at gemme RDD i disken.

så når RDD1 er påkrævet næste gang i den efterfølgende transformation, vil Spark udføre en I/O-operation og bringe den til eksekutorens hukommelse.

RDD1.fortsæt (lagringsniveau.DISK_ONLY)

– MEMORY_AND_DISK – lad os sige, at jeg har 3 RDDs (ingen er cachelagret) i eksekutorens hukommelse, og der er ingen tilgængelig hukommelse tilbage. I mellemtiden kommer en anden RDD (siger RDD4) ind. Så Spark fjerner den mindst anvendte (LRU) RDD fra eksekutorens hukommelse og giver plads til, at den nye RDD kommer ind (i dette tilfælde RDD4).

lad os nu antage, at 3 Rddd ‘ er er cachelagret i hukommelsen, og når RDD4 ankommer, vil LRU ikke sparke nogen RDD ud af cachehukommelsen i Arbejdsnoden. Der kan være problemer med OOM.

men hvis vi bruger MEMORY_AND_DISK persistensniveau med RDD4, gemmes RDD4 på disken, hvis den ikke finder nok plads i cachehukommelsen.

RDD4.fortsæt (lagringsniveau.MEMORY_AND_DISK)

også, hvis en enorm RDD er cachelagret i hukommelsen, og der ikke er nok cachehukommelse, spildes de resterende partitioner, der ikke er i stand til at passe i cachehukommelsen, til disken, hvis vi bruger MEMORY_AND_DISK.

igen er udfordringen her I/O-operationer.

Bemærk: dataene på disken gemmes i tmp-placering.

Hukommelsesformat

serialisering – vi kan vælge at serialisere de data, der er gemt i cachehukommelsen.

MEMORY_ONLY_SER og MEMORY_AND_DISK_SER

vedvarende RDD i en seriel (binær) form hjælper med at reducere størrelsen af RDD, hvilket gør plads til mere RDD at blive vedvarende i cachehukommelsen. Så disse to hukommelsesformater er pladseffektive.

men problemet med dette er, at de er mindre tidseffektive, fordi vi er nødt til at pådrage os omkostningerne ved tid involveret i deserialisering af dataene.

så det er en udviklers valg, om ydeevne betyder noget eller opbevaring betyder noget. Definitivt ville præstationspåvirkningen ikke være meget, men det ville være et minut et.

Partitionsreplikation

gemmer partitionen på to noder.

DISK_ONLY_2
MEMORY_AND_DISK_2
MEMORY_ONLY_2
MEMORY_AND_DISK_SER_2
MEMORY_ONLY_SER_2

disse indstillinger gemmer en replikeret kopi af RDD i en anden Arbejderknudes cachehukommelse.

replikerede data på disken vil blive brugt til at genskabe partitionen, dvs. det hjælper med at beregne RDD igen, hvis den anden arbejderknude går ned.

ikke– vedvarende RDD

– for at stoppe vedvarende og fjerne fra hukommelse eller disk
– for at ændre en RDDS persistensniveau
rdd.unpersist ()

så sådan kan vi arbejde med vores cachehukommelse i Apache Spark.

dette er alt fra denne blog, håber du nød det, og det hjalp dig!! Hold forbindelsen til flere fremtidige blogs. Tak skal du have!!

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.