Programmering

Opplæring: Spark applikasjonsarkitektur og klynger

Få hele boka
Dataanalyse med gnist ved bruk av Python (Addison-Wesley Data & Analytics-serien) MSRP $ 44,99 Se den

Denne artikkelen er et utdrag fra Pearson Addison-Wesley-boken "Data Analytics with Spark Using Python" av Jeffrey Aven. Gjengitt her med tillatelse fra Pearson © 2018. For mer informasjon, besøk informit.com/aven/infoworld.

Før du begynner reisen din som Apache Spark-programmerer, bør du ha en solid forståelse av Spark-applikasjonsarkitekturen og hvordan applikasjoner kjøres i en Spark-klynge. Denne artikkelen undersøker komponentene i et Spark-program nøye, ser på hvordan disse komponentene fungerer sammen, og ser på hvordan Spark-applikasjoner kjører på frittstående og YARN-klynger.

Anatomi av en gnistapplikasjon

Et Spark-program inneholder flere komponenter, som alle eksisterer enten du kjører Spark på en enkelt maskin eller over en klynge på hundrevis eller tusenvis av noder.

Hver komponent har en bestemt rolle i utførelsen av et Spark-program. Noen av disse rollene, for eksempel klientkomponentene, er passive under utførelsen; andre roller er aktive i gjennomføringen av programmet, inkludert komponenter som utfører beregningsfunksjoner.

Komponentene i et Spark-program er:

  • sjåføren
  • mesteren
  • klyngesjefen
  • utførerne

De kjører alle på arbeidernoder, aka arbeidere.

Figur 1 viser alle Spark-komponentene i sammenheng med en frittstående applikasjon.

Pearson Addison-Wesley

Alle Spark-komponenter - inkludert driver-, master- og executor-prosesser - kjøres på virtuelle Java-maskiner. En JVM er en runtime-motor på tvers av plattformer som kan utføre instruksjoner samlet i Java bytecode. Scala, som Spark er skrevet i, samles til bytekode og kjører på JVM-er.

Det er viktig å skille mellom Sparks applikasjonskomponenter for kjøretid og stedene og nodetypene de kjører på. Disse komponentene kjøres forskjellige steder ved hjelp av forskjellige distribusjonsmodi, så ikke tenk på disse komponentene i fysisk node eller forekomst. For eksempel, når du kjører Spark på GARN, vil det være flere varianter av figur 1. Imidlertid er alle komponentene på bildet fortsatt involvert i applikasjonen og har de samme rollene.

Gnistfører

Livet til en gnistapplikasjon starter og avsluttes med gnistdriveren. Driveren er prosessen som klienter bruker for å sende inn søknader i Spark. Sjåføren er også ansvarlig for å planlegge og koordinere gjennomføringen av Spark-programmet og returnere status og / eller resultater (data) til klienten. Driveren kan fysisk bo på en klient eller på en node i klyngen, som du vil se senere.

SparkSession

Spark-driveren er ansvarlig for å opprette SparkSession. SparkSession-objektet representerer en forbindelse til en Spark-klynge. SparkSession startes i begynnelsen av en Spark-applikasjon, inkludert de interaktive skallene, og brukes for hele programmet.

Før Spark 2.0 inkluderte inngangspunkter for Spark-applikasjoner SparkContext, brukt til Spark-kjerneapplikasjoner; SQLContext og HiveContext, brukt med Spark SQL-applikasjoner; og StreamingContext, brukt til Spark Streaming-applikasjoner. SparkSession-objektet introdusert i Spark 2.0 kombinerer alle disse objektene til et enkelt inngangspunkt som kan brukes til alle Spark-applikasjoner.

Gjennom SparkContext- og SparkConf-underordnede objekter inneholder SparkSession-objektet alle kjøretidskonfigurasjonsegenskapene som er satt av brukeren, inkludert konfigurasjonsegenskaper som master, applikasjonsnavn og antall utførere. Figur 2 viser SparkSession-objektet og noen av dets konfigurasjonsegenskaper i a pyspark skall.

Pearson Addison-Wesley

SparkSession navn

Objektnavnet for SparkSession-forekomsten er vilkårlig. Som standard kalles SparkSession-instantiering i Spark interaktive skall gnist. For konsistens instantierer du alltid SparkSession som gnist; navnet er imidlertid opp til utviklerens skjønn.

Koden nedenfor viser hvordan du oppretter en SparkSession i et ikke-interaktivt Spark-program, for eksempel et program sendt inn ved hjelp av gnist-sende.

fra pyspark.sql importerer SparkSession

gnist = SparkSession.builder \

.master ("spark: // sparkmaster: 7077") \

.appName ("My Spark Application") \

.config ("spark.submit.deployMode", "klient") \

.getOrCreate ()

numlines = spark.sparkContext.textFile ("fil: /// opt / spark / lisenser") \

.telle()

print ("Totalt antall linjer er" + str (numlines))

Søknadsplanlegging

En av sjåførens hovedfunksjoner er å planlegge applikasjonen. Sjåføren tar applikasjonsbehandlingsinndataene og planlegger gjennomføringen av programmet. Sjåføren tar alle de forespurte transformasjoner(data manipulering operasjoner) og handlinger (forespørsler om utdata eller ber om å utføre programmer) og lager en rettet asyklisk graf (DAG) av noder, som hver representerer et transformasjons- eller beregningstrinn.

Regissert asyklisk graf (DAG)

En DAG er en matematisk konstruksjon som ofte brukes i informatikk for å representere datastrømmer og deres avhengighet. DAG-er inneholder hjørner (eller noder) og kanter. Vertices i en dataflytskontekst er trinn i prosessflyten. Kanter i en DAG forbinder hjørner med hverandre i en rettet retning og på en slik måte at det er umulig å ha sirkulære referanser.

En gnistapplikasjon DAG består av oppgaver og trinn. En oppgave er den minste enheten for planleggbar arbeid i et Spark-program. En scene er et sett med oppgaver som kan kjøres sammen. Stadier er avhengige av hverandre; med andre ord, det er det sceneavhengigheter.

I prosessplanlegging er DAG ikke unike for Spark. For eksempel brukes de i andre big data-økosystemprosjekter, som Tez, Drill og Presto for planlegging. DAG-er er grunnleggende for Spark, så det er verdt å være kjent med konseptet.

Søknadsorkestrering

Sjåføren koordinerer også kjøringen av trinn og oppgaver definert i DAG. Viktige driveraktiviteter involvert i planlegging og drift av oppgaver inkluderer følgende:

  • Holde oversikt over tilgjengelige ressurser for å utføre oppgaver.
  • Planlegge oppgaver for å kjøre "nær" dataene der det er mulig (begrepet datalokalitet).

Andre funksjoner

I tillegg til å planlegge og organisere gjennomføringen av et Spark-program, er sjåføren også ansvarlig for å returnere resultatene fra en applikasjon. Dette kan være returkoder eller data i tilfelle en handling som ber om at data skal returneres til klienten (for eksempel et interaktivt spørsmål).

Driveren betjener også applikasjonsgrensesnittet på port 4040, som vist i figur 3. Dette brukergrensesnittet opprettes automatisk; den er uavhengig av koden som er sendt inn eller hvordan den ble sendt (det vil si interaktiv bruk av pysparkeller ikke-interaktiv ved bruk gnist-sende).

Pearson Addison-Wesley

Hvis påfølgende applikasjoner starter på samme vert, brukes påfølgende porter for applikasjonsgrensesnittet (for eksempel 4041, 4042 og så videre).

Gnistarbeidere og utførere

Spark executors er prosessene som Spark DAG-oppgaver kjøres på. eksekutører reserverer CPU- og minneressurser på slavernoder, eller arbeidere, i en Spark-klynge. En eksekutor er dedikert til en bestemt Spark-applikasjon og avsluttes når applikasjonen er fullført. Et Spark-program består normalt av mange eksekutører, som ofte jobber parallelt.

Vanligvis har en arbeiderknute - som er vert for utførelsesprosessen - et endelig eller fast antall eksekutører som er tildelt når som helst. Derfor har en klynge - et kjent antall noder - et endelig antall eksekutører som er tilgjengelige for å kjøre til enhver tid. Hvis et program krever eksekutører som overstiger den fysiske kapasiteten til klyngen, er de planlagt å starte når andre eksekutører fullfører og frigjør ressursene.

Som nevnt tidligere er JVMs vert for Spark-eksekutører. JVM for en eksekutor tildeles a haug, som er et dedikert minneområde der du kan lagre og administrere objekter.

Mengden minne som er forpliktet til JVM-bunken for en eksekutor, er satt av eiendommen spark.executor.memory eller som --eksekutør-minne argument til pyspark, gnistskall, eller gnist-sende kommandoer.

Utførere lagrer utdata fra oppgaver i minnet eller på disken. Det er viktig å merke seg at arbeidere og utførere bare er klar over oppgavene som er tildelt dem, mens sjåføren er ansvarlig for å forstå det komplette oppgavesettet og de respektive avhengighetene som en applikasjon inneholder.

Ved å bruke Spark-applikasjonsgrensesnittet på port 404x fra driververt, kan du inspisere eksekutører for applikasjonen, som vist i figur 4.

Pearson Addison-Wesley

For Spark frittstående klyngedistribusjoner, eksponerer en arbeiderknute et brukergrensesnitt på port 8081, som vist i figur 5.

Pearson Addison-Wesley

The Spark master and cluster manager

Spark-driveren planlegger og koordinerer oppgavesettet som kreves for å kjøre et Spark-program. Oppgavene i seg selv kjøres i utførere, som er vert på arbeidernoder.

Masteren og klyngebehandleren er de sentrale prosessene som overvåker, reserverer og fordeler de distribuerte klyngeressursene (eller containerne, i tilfelle YARN eller Mesos) som eksekutørene kjører på. Masteren og klyngebehandleren kan være separate prosesser, eller de kan kombineres i en prosess, slik det er tilfelle når du kjører Spark i frittstående modus.

Gnistmester

Spark-master er prosessen som ber om ressurser i klyngen og gjør dem tilgjengelige for Spark-driveren. I alle distribusjonsmodi forhandler mesteren ressurser eller containere med arbeidernoder eller slavernoder og sporer status og overvåker fremdriften.

Når du kjører Spark i frittstående modus, serverer Spark-hovedprosessen et nettgrensesnitt på port 8080 på hovedverten, som vist i figur 6.

Pearson Addison-Wesley

Spark master versus Spark driver

Det er viktig å skille mellom kjøretidsfunksjonene til sjåføren og mesteren. Navnet herre kan utledes til å bety at denne prosessen styrer gjennomføringen av søknaden - men dette er ikke tilfelle. Mesteren ber bare om ressurser og gjør disse ressursene tilgjengelige for sjåføren. Selv om mesteren overvåker statusen og helsen til disse ressursene, er den ikke involvert i gjennomføringen av applikasjonen og koordineringen av oppgavene og stadiene. Det er sjåførens jobb.

Klyngesjef

Klyngebehandleren er prosessen som er ansvarlig for å overvåke arbeidernodene og reservere ressurser på disse nodene på forespørsel fra mesteren. Mesteren gjør deretter disse klyngeressursene tilgjengelige for driveren i form av utførere.

Som nevnt tidligere kan klyngebehandleren være atskilt fra hovedprosessen. Dette er tilfelle når du kjører Spark på Mesos eller YARN. I tilfelle Spark kjører i frittstående modus, utfører hovedprosessen også funksjonene til klyngebehandleren. Effektivt fungerer den som sin egen klyngesjef.

Et godt eksempel på cluster manager-funksjonen er YARN ResourceManager-prosessen for Spark-applikasjoner som kjører på Hadoop-klynger. ResourceManager planlegger, tildeler og overvåker helsen til containere som kjører på YARN NodeManagers. Spark-applikasjoner bruker deretter disse beholderne til å være vert for eksekveringsprosesser, så vel som hovedprosessen hvis applikasjonen kjører i clustermode.

Gnist applikasjoner ved hjelp av den frittstående planleggeren

I kapittel 2, “Distribuere gnist,” forklarte jeg den frittstående planleggeren som et distribusjonsalternativ for Spark. Der distribuerte jeg en fullt funksjonell multinode Spark frittstående klynge i en av øvelsene i kapittel 2. Som nevnt tidligere, i en Spark-klynge som kjører i frittstående modus, utfører Spark-masterprosessen også klyngebehandlerfunksjonen, og styrer tilgjengelige ressurser på klyngen og gi dem til hovedprosessen for bruk i et Spark-program.

Gnistapplikasjoner som kjører på YARN

Hadoop er en veldig populær og vanlig distribusjonsplattform for Spark. Noen eksperter i bransjen mener at Spark snart vil erstatte MapReduce som den primære behandlingsplattformen for applikasjoner i Hadoop. Gnistapplikasjoner på YARN har samme kjøretidsarkitektur, men har noen små forskjeller i implementeringen.

ResourceManager som klyngebehandler

I motsetning til den frittstående planleggeren er klyngebehandleren i en YARN-klynge YARN ResourceManager. ResourceManager overvåker ressursbruk og tilgjengelighet på tvers av alle noder i en klynge. Klienter sender inn Spark-søknader til YARN ResourceManager. ResourceManager tildeler den første beholderen for applikasjonen, en spesiell container kalt ApplicationMaster.

ApplicationMaster som Spark master

ApplicationMaster er Spark-masterprosessen. Som masterprosessen gjør i andre klyngedistribusjoner, forhandler ApplicationMaster ressurser mellom applikasjonsdriveren og klyngebehandleren (eller ResourceManager i dette tilfellet); den gjør deretter disse ressursene (containere) tilgjengelig for driveren for bruk som utførere for å kjøre oppgaver og lagre data for applikasjonen.

ApplicationMaster forblir i hele applikasjonens levetid.

Distribusjonsmodi for Spark-applikasjoner som kjører på YARN

To distribusjonsmodi kan brukes når du sender Spark-applikasjoner til en YARN-klynge: klientmodus og klyngemodus. La oss se på dem nå.

Klientmodus

I klientmodus kjører driverprosessen på klienten som sender inn applikasjonen. Det er egentlig ikke-administrert; hvis driververten mislykkes, mislykkes applikasjonen. Klientmodus støttes for begge interaktive skalløkter (pyspark, gnistskall, og så videre) og ikke-interaktiv søknadsinnsending (gnist-sende). Koden nedenfor viser hvordan du starter en pyspark økt ved hjelp av klientdistribusjonsmodus.

$ SPARK_HOME / bin / pyspark \

--master garnklient \

--num-executors 1 \

- driver-minne 512m \

--eksekutorminne 512m \

--eksekutorkjerner 1

# ELLER

$ SPARK_HOME / bin / pyspark \

- master garn \

--deploy-modus klient \

--num-executors 1 \

- driver-minne 512m \

--eksekutorminne 512m \

--eksekutorkjerner 1

Figur 7 gir en oversikt over et Spark-program som kjører på YARN i klientmodus.

Pearson Addison-Wesley

Trinnene vist i figur 7 er:

  1. Klienten sender et Spark-program til klyngebehandleren (YARN ResourceManager). Driverprosessen, SparkSession og SparkContext opprettes og kjøres på klienten.
  2. ResourceManager tildeler en ApplicationMaster (Spark master) for applikasjonen.
  3. ApplicationMaster ber om at containere skal brukes til utførere fra ResourceManager. Med tildelte containere gyter utførerne.
  4. Føreren, som ligger på klienten, kommuniserer deretter med eksekutørene for å behandle oppgaver og stadier i Spark-programmet. Driveren returnerer fremdrift, resultater og status til klienten.

Klientdistribusjonsmodus er den enkleste modusen å bruke. Imidlertid mangler den elastisiteten som kreves for de fleste produksjonsapplikasjoner.

Klyngemodus

I motsetning til klientdistribusjonsmodus, med et Spark-program som kjører i YARN Cluster-modus, kjører selve driveren på klyngen som en underprosess av ApplicationMaster. Dette gir spenst: Hvis ApplicationMaster-prosessen som driver driveren mislykkes, kan den reinstanseres på en annen node i klyngen.

Koden nedenfor viser hvordan du sender inn en søknad ved hjelp av gnist-sende og distribusjonsmodus YARN-klyngen. Fordi driveren er en asynkron prosess som kjører i klyngen, støttes ikke klyngemodus for de interaktive skallapplikasjonene (pyspark og gnistskall).

$ SPARK_HOME / bin / spark-submit \

- master garn-klynge \

--num-executors 1 \

- driver-minne 512m \

--eksekutorminne 512m \

--utførerkjerner 1

$ SPARK_HOME / eksempler / src / main / python / pi.py 10000

# ELLER

- master garn \

--deploy-modus klynge \

--num-executors 1 \

- driver-minne 512m \

--eksekutorminne 512m \

--eksekutorkjerner 1

$ SPARK_HOME / eksempler / src / main / python / pi.py 10000

Figur 8 gir en oversikt over et Spark-program som kjører på YARN i klyngemodus.

Pearson Addison-Wesley

Trinnene vist i figur 8 er:

  1. Klienten, en brukerprosess som påkaller gnist-sende, sender inn et Spark-program til klyngebehandleren (YARN ResourceManager).
  2. ResourceManager tilordner en ApplicationMaster (Spark master) for applikasjonen. Driverprosessen opprettes på samme klyngenode.
  3. ApplicationMaster ber om containere for utførere fra ResourceManager. utførere gyter i containerne som er tildelt ApplicationMaster av ResourceManager. Sjåføren kommuniserer deretter med eksekutorene for å behandle oppgaver og stadier i Spark-programmet.
  4. Driveren, som kjører på en node i klyngen, returnerer fremgang, resultater og status til klienten.

Spark-applikasjonsnettgrensesnittet, som vist tidligere, er tilgjengelig fra ApplicationMaster-verten i klyngen. en lenke til dette brukergrensesnittet er tilgjengelig fra YARN ResourceManager UI.

Lokal modus på nytt

I lokal modus kjører sjåføren, mesteren og utføreren i en enkelt JVM. Som nevnt tidligere i dette kapittelet, er dette nyttig for utvikling, testing av enheter og feilsøking, men det har begrenset bruk for å kjøre produksjonsapplikasjoner fordi det ikke distribueres og ikke skaleres. Videre kjøres ikke mislykkede oppgaver i et Spark-program som kjører i lokal modus som standard på nytt. Du kan imidlertid overstyre denne oppførselen.

Når du kjører Spark i lokal modus, er applikasjonsgrensesnittet tilgjengelig på // localhost: 4040. Hoved- og arbeidergrensesnittene er ikke tilgjengelige når de kjører i lokal modus.

$config[zx-auto] not found$config[zx-overlay] not found