dette dokument giver et kort overblik over, hvordan Spark kører på klynger, for at gøre det lettere at forståde involverede komponenter. Læs gennem ansøgningsindgivelsesvejledningen for at lære om lancering af applikationer på en klynge.
Spark-applikationer kører som uafhængige sæt processer på en klynge, koordineret af SparkContext – objektet i dit hovedprogram (kaldet driverprogrammet).
specifikt, for at køre på en klynge, kan Sparkkonteksten oprette forbindelse til flere typer klyngeadministratorer(enten Sparks egen enkeltstående klyngestyring, Mesos eller garn), som tildeler ressourcer på tværs af applikationer. Når den er tilsluttet, erhverver Spark eksekutorer på noder i klyngen, som erprocesser, der kører beregninger og gemmer data til din applikation.Derefter sender den din applikationskode (defineret af JAR-eller Python-filer, der sendes til Sparkkontekst) tiludførerne. Endelig sender Sparkkontekst opgaver til eksekutorerne til at køre.
der er flere nyttige ting at bemærke om denne arkitektur:
- hver applikation får sine egne eksekutorprocesser, som holder op i hele varigheden af heleapplikation og kør opgaver i flere tråde. Dette har fordelen ved at isolere applikationerfra hinanden, både på planlægningssiden (hver driver planlægger sine egne opgaver) og eksekverside (opgaver fra forskellige applikationer kører i forskellige JVM ‘ er). Det betyder dog også, atdata ikke kan deles på tværs af forskellige Spark-applikationer (forekomster af Gnistkontekst) uden at skrive dem til et eksternt lagersystem.
- Spark er agnostisk for den underliggende klyngechef. Så længe det kan erhverve eksekveringsprocesser, og disse kommunikerer med hinanden, er det relativt nemt at køre det selv på acluster manager, der også understøtter andre applikationer (f.eks.
- driverprogrammet skal lytte efter og acceptere indgående forbindelser fra sine eksekutorer hele vejen igennemdens levetid (se f.eks.driver.port i netværkskonfigurationafsnittet). Som sådan skal driverprogrammet være netværksadresserbart fra arbejdernoderne.
- da driveren planlægger opgaver på klyngen, skal den køres tæt på arbejdsnoderne, helst på det samme lokale netværk. Hvis du gerne vil sende anmodninger tilcluster eksternt, er det bedre at åbne en RPC til driveren og få den til at indsende operationer fra nærheden end at køre en driver langt væk fra arbejdernoderne.
Cluster Manager typer
systemet understøtter i øjeblikket flere cluster managers:
- Standalone – en simpel cluster manager inkluderet med Spark, der gør det nemt at oprette en klynge.
- Apache Mesos – en generel cluster manager, der også kan køre Hadoop MapReduceand service applikationer.
- Hadoop garn – resource manager i Hadoop 2.
- Kubernetes – et open source-system til automatisering af implementering, skalering og styring af containeriserede applikationer.
der findes et tredjepartsprojekt (ikke understøttet af Spark-projektet) for at tilføje support forNomad som klyngeadministrator.
indsendelse af ansøgninger
ansøgninger kan indsendes til en klynge af enhver type ved hjælp af scriptet spark-submit.Ansøgningsvejledningen beskriver, hvordan du gør dette.
overvågning
hvert driverprogram har et internet-brugergrænseflade, typisk på port 4040, der viser oplysninger om kørselsopgaver, eksekutorer og lagringsbrug. Du skal blot gå til i en internetsøgemaskine for at få adgang til denne brugergrænseflade. Overvågningsvejledningen beskriver også andre overvågningsmuligheder.
jobplanlægning
Spark giver kontrol over ressourceallokering både på tværs af applikationer (på clustermanager-niveau) og inden for applikationer (hvis der sker flere beregninger på samme Gnistkontekst).Jobplanlægningsoversigten beskriver dette mere detaljeret.
ordliste
følgende tabel opsummerer udtryk, du vil se brugt til at henvise til klyngekoncepter:
| Term | Betydning |
|---|---|
| ansøgning | brugerprogram bygget på Spark. Består af et driverprogram og eksekutorer på klyngen. |
| Application jar | en krukke, der indeholder brugerens Spark-applikation. I nogle tilfælde vil brugerne gerne oprette en “uber jar”, der indeholder deres applikation sammen med dens afhængigheder. Brugerens krukke bør aldrig omfatte Hadoop eller Spark biblioteker, men disse vil blive tilføjet på runtime. |
| driverprogram | processen kører programmets hovedfunktion () og opretter Sparkkontekst |
| Cluster manager | en ekstern tjeneste til erhvervelse af ressourcer på klyngen (f. eks. standalone manager, Mesos, YARN) |
| Deploy mode | skelner mellem, hvor driverprocessen kører. I” cluster ” – tilstand lancerer rammen driveren inde i klyngen. I” klient ” – tilstand lancerer indsenderen driveren uden for klyngen. |
| arbejder node | enhver node, der kan køre programkode i klyngen |
| eksekutor | en proces lanceret for et program på en arbejdstager node, der kører opgaver og holder data i hukommelsen eller disk opbevaring på tværs af dem. Hver ansøgning har sine egne eksekutorer. |
| opgave | en enhed af arbejde, der vil blive sendt til en eksekutor |
| Job | en parallel beregning bestående af flere opgaver, der bliver skabt som reaktion på en Gnisthandling (f. eks. save, collect); du kan se dette udtryk brugt i førerens logfiler. |
| Stage | hvert job bliver opdelt i mindre sæt opgaver kaldet faser, der afhænger af hinanden (svarende til kortet og reducere stadier i MapReduce); du vil se dette udtryk brugt i førerens logfiler. |