Opetusohjelma: Spark-sovelluksen arkkitehtuuri ja klusterit

Hanki koko kirja

Data-analyysi Sparkilla Pythonin avulla (Addison-Wesley Data & Analytics -sarja) MSRP 44,99 dollaria Katso

Tämä artikkeli on ote Jeffrey Avenin Pearson Addison-Wesley -kirjasta "Data-analyysi Sparkin avulla Pythonilla". Painettu uudelleen täällä Pearsonin luvalla © 2018. Lisätietoja on osoitteessa informit.com/aven/infoworld.

Ennen kuin aloitat matkan Apache Spark -ohjelmoijana, sinulla on oltava vankka käsitys Spark-sovellusarkkitehtuurista ja siitä, miten sovellukset suoritetaan Spark-klusterissa. Tässä artikkelissa tarkastellaan tarkasti Spark-sovelluksen komponentteja, tarkastellaan, miten nämä komponentit toimivat yhdessä, ja miten Spark-sovellukset toimivat erillisissä ja YARN-klustereissa.

Spark-sovelluksen anatomia

Spark-sovellus sisältää useita komponentteja, jotka kaikki ovat olemassa riippumatta siitä, käytätkö Sparkia yhdellä koneella vai satojen tai tuhansien solmujen joukossa.

Jokaisella komponentilla on erityinen rooli Spark-ohjelman suorittamisessa. Jotkut näistä rooleista, kuten asiakaskomponentit, ovat passiivisia suorituksen aikana; muut roolit ovat aktiivisia ohjelman suorittamisessa, mukaan lukien komponentit, jotka suorittavat laskentatoimintoja.

Spark-sovelluksen komponentit ovat:

• kuski
• mestari
• klusterin johtaja
• toimeenpanijat

Ne kaikki juoksevat työntekijäsolmuilla, eli työntekijöillä.

Kuvassa 1 on esitetty kaikki Spark-komponentit erillisen Spark-sovelluksen yhteydessä.

Pearson Addison-Wesley

Kaikki Spark-komponentit - mukaan lukien ohjain-, pää- ja toteutusprosessit - suoritetaan Java-virtuaalikoneissa. JVM on alustojen välinen ajonaikainen moottori, joka voi suorittaa Java-tavukoodiin kootut ohjeet. Scala, johon Spark on kirjoitettu, kootaan tavukoodiksi ja toimii JVM: llä.

On tärkeää erottaa Sparkin ajonaikaiset sovelluskomponentit sekä sijainnit ja solmutyypit, joilla ne toimivat. Nämä komponentit toimivat eri paikoissa käyttämällä eri käyttöönottotiloja, joten älä ajattele näitä komponentteja fyysisten solmujen tai ilmentymien termeillä. Esimerkiksi kun Sparkia käytetään YARNilla, kuvassa 1 olisi useita muunnelmia. Kaikki kuvassa olevat komponentit ovat kuitenkin edelleen mukana sovelluksessa ja niillä on samat roolit.

Kipinä kuljettaja

Spark-sovelluksen käyttöikä alkaa ja päättyy Spark-ohjaimella. Ohjain on prosessi, jota asiakkaat käyttävät hakemusten jättämiseen Sparkissa. Kuljettaja vastaa myös Spark-ohjelman suunnittelusta ja koordinoinnista sekä tilan ja / tai tulosten (tietojen) palauttamisesta asiakkaalle. Kuljettaja voi fyysisesti asua asiakkaalla tai klusterin solmussa, kuten näet myöhemmin.

SparkSession

Spark-kuljettaja on vastuussa SparkSessionin luomisesta. SparkSession-objekti edustaa yhteyttä Spark-klusteriin. SparkSession on instantioitu Spark-sovelluksen alussa, mukaan lukien interaktiiviset kuoret, ja sitä käytetään koko ohjelmassa.

Ennen Spark 2.0: ta Spark-sovellusten lähtökohtiin sisältyi SparkContext, jota käytetään Spark-ydinsovelluksiin; SQLContext ja HiveContext, joita käytetään Spark SQL -sovellusten kanssa; ja StreamingContext, jota käytetään Spark Streaming -sovelluksiin. Spark 2.0: ssa esitelty SparkSession-objekti yhdistää kaikki nämä objektit yhdeksi sisääntulopisteeksi, jota voidaan käyttää kaikissa Spark-sovelluksissa.

SparkContext- ja SparkConf-aliobjektien kautta SparkSession-objekti sisältää kaikki käyttäjän asettamat ajonaikaiset kokoonpano-ominaisuudet, mukaan lukien määritysominaisuudet, kuten pääkäyttäjän, sovelluksen nimen ja suorittajien lukumäärän. Kuva 2 esittää SparkSession-objektin ja joitain sen kokoonpano-ominaisuuksista kohdassa a pyspark kuori.

Pearson Addison-Wesley

SparkSession-nimi

SparkSession-ilmentymän objektin nimi on mielivaltainen. Oletusarvoisesti SparkSession-interventio Spark-interaktiivisissa kuoreissa on nimetty kipinä. Johdonmukaisuuden varmistamiseksi SparkSession välitetään aina nimellä kipinä; nimi on kuitenkin kehittäjän harkinnan mukaan.

Alla oleva koodi osoittaa, kuinka SparkSession luodaan ei-interaktiivisessa Spark-sovelluksessa, kuten ohjelmassa, joka on lähetetty kipinä-lähettää.

pyspark.sql-tuonnista SparkSession
kipinä = SparkSession.builder \
  .master ("kipinä: // sparkmaster: 7077") \
 .appName ("My Spark -sovellus") \
  .config ("spark.submit.deployMode", "asiakas") \
  .getOrCreate ()
numlines = spark.sparkContext.textFile ("tiedosto: /// opt / kipinä / lisenssit") \
  .Kreivi()
tulosta ("Rivien kokonaismäärä on" + str (numlines))

Sovellusten suunnittelu

Yksi kuljettajan päätoiminnoista on sovelluksen suunnittelu. Kuljettaja ottaa sovelluksen käsittelyn syötteen ja suunnittelee ohjelman suorittamisen. Kuljettaja vie kaikki pyydetyt muunnokset(tietojen käsittelytoiminnot) ja Toiminnot (lähdepyynnöt tai kehottaa suorittamaan ohjelmia) ja luo solmuista suunnatun asyklisen kaavion (DAG), joista kukin edustaa muunnos- tai laskennallista vaihetta.

Suunnattu asyklinen kaavio (DAG)

DAG on matemaattinen rakenne, jota käytetään yleisesti tietojenkäsittelytieteessä edustamaan tietovirtoja ja niiden riippuvuuksia. DAG: t sisältävät pisteitä (tai solmuja) ja reunoja. Pisteet tietovirran yhteydessä ovat vaiheet prosessivirrassa. DAG: n reunat yhdistävät pisteet toisiinsa suunnatusti ja siten, että pyöreitä viitteitä on mahdotonta.

Spark-sovelluksen DAG koostuu tehtäviä ja Tasot. Tehtävä on pienin aikataulutettavan työn yksikkö Spark-ohjelmassa. Vaihe on joukko tehtäviä, jotka voidaan suorittaa yhdessä. Vaiheet ovat riippuvaisia ​​toisistaan; toisin sanoen on vaiheen riippuvuudet.

Prosessin ajoituksen kannalta DAG: t eivät ole ainutlaatuisia Sparkille. Niitä käytetään esimerkiksi muissa big data -ekosysteemiprojekteissa, kuten Tez, Drill ja Presto, aikatauluttamiseen. DAG: t ovat Sparkille perustavanlaatuisia, joten on syytä tuntea käsite.

Sovellusten orkestrointi

Kuljettaja koordinoi myös DAG: ssä määriteltyjen vaiheiden ja tehtävien suorittamista. Keskeisiä kuljettajatoimintoja, jotka liittyvät tehtävien ajoitukseen ja suorittamiseen, ovat seuraavat:

• Seuraa käytettävissä olevia resursseja tehtävien suorittamiseen.
• Aikatauluta tehtävät suoritettavaksi "lähellä" tietoja mahdollisuuksien mukaan (tietopaikan käsite).

Muut toiminnot

Spark-ohjelman suunnittelun ja organisoinnin lisäksi kuljettaja on vastuussa myös sovelluksen tulosten palauttamisesta. Nämä voivat olla palautuskoodit tai tiedot toiminnossa, joka pyytää tietojen palauttamista asiakkaalle (esimerkiksi interaktiivinen kysely).

Ohjain palvelee myös sovelluksen käyttöliittymää portissa 4040, kuten kuvassa 3 on esitetty. Tämä käyttöliittymä luodaan automaattisesti; se on riippumaton toimitetusta koodista tai siitä, miten se on lähetetty (toisin sanoen interaktiivinen pysparktai ei-vuorovaikutteinen kipinä-lähettää).

Pearson Addison-Wesley

Jos seuraavat sovellukset käynnistetään samalla isännällä, sovelluksen käyttöliittymässä käytetään peräkkäisiä portteja (esimerkiksi 4041, 4042 ja niin edelleen).

Kipinätyöntekijät ja toimeenpanijat

Spark-toteuttajat ovat prosesseja, joissa Spark DAG -tehtävät suoritetaan. toteuttajat varaavat CPU- ja muistiresursseja orjasolmuille tai työntekijöille Spark-klusterissa. Suorittaja on omistettu tietylle Spark-sovellukselle ja se lopetetaan, kun sovellus on valmis. Spark-ohjelma koostuu yleensä monista toteuttajista, jotka työskentelevät usein rinnakkain.

Tyypillisesti työntekijäsolmussa, joka isännöi toteutusprosessia, on rajallinen tai kiinteä määrä toimeenpanijoita, jotka on jaettu milloin tahansa. Siksi klusterilla - joka on tunnettu lukumäärä solmuja - on rajallinen määrä toimeenpanijoita, jotka ovat käytettävissä ajaa kerrallaan. Jos sovellus vaatii suorittajia, jotka ylittävät klusterin fyysisen kapasiteetin, heidän on tarkoitus aloittaa, kun muut suorittajat täydentävät ja vapauttavat resurssit.

Kuten aiemmin mainittiin, JVM: t isännöivät Sparkin toimeenpanijoita. Suorittajan JVM: lle varataan a pino, joka on oma muistitila esineiden tallentamiseen ja hallintaan.

Omaisuus määrittää JVM-kasalle suorittajalle sidotun muistin määrän kipinä.suoritusmuisti tai kuten - suoritusmuisti argumentti pyspark, kipinän kuoritai kipinä-lähettää komentoja.

Suorittajat tallentavat tehtävien lähtötiedot muistiin tai levylle. On tärkeää huomata, että työntekijät ja toteuttajat ovat tietoisia vain heille osoitetuista tehtävistä, kun taas kuljettaja on vastuussa kaikkien tehtävien ja sovelluksen sisältävien riippuvuuksien ymmärtämisestä.

Käyttämällä Spark-sovelluksen käyttöliittymää portissa 404x kuljettajan isännän, voit tarkistaa sovelluksen suorittajat kuvan 4 mukaisesti.

Pearson Addison-Wesley

Spark-itsenäisten klusterien käyttöönotossa työntekijäsolmu paljastaa käyttöliittymän portissa 8081, kuten kuvassa 5 on esitetty.

Pearson Addison-Wesley

Spark-päällikkö ja klusterin johtaja

Spark-ohjain suunnittelee ja koordinoi Spark-sovelluksen suorittamiseen tarvittavia tehtäviä. Tehtävät suoritetaan itse suorittimissa, joita isännöidään työntekijöiden solmuissa.

Päällikkö ja klusterinhallinta ovat keskeisiä prosesseja, jotka valvovat, varaavat ja allokoivat hajautettuja klusteriresursseja (tai kontteja, jos kyseessä on YARN tai Mesos), joita toteuttajat suorittavat. Pää- ja klusterinhallinta voivat olla erillisiä prosesseja tai ne voivat yhdistyä yhdeksi prosessiksi, kuten tapahtuu, kun Sparkia käytetään erillisessä tilassa.

Kipinämestari

Spark-isäntä on prosessi, joka pyytää resursseja klusterista ja asettaa ne Spark-ohjaimen saataville. Kaikissa käyttöönottotiloissa päällikkö neuvottelee resursseista tai säiliöistä työntekijäsolmujen tai orjasolmujen kanssa, seuraa niiden tilaa ja seuraa niiden edistymistä.

Kun Sparkia käytetään itsenäisessä tilassa, Spark-pääprosessi palvelee web-käyttöliittymää isännän portissa 8080, kuten kuvassa 6 on esitetty.

Pearson Addison-Wesley

Spark master vs. Spark kuljettaja

On tärkeää erottaa kuljettajan ja isännän ajonaikaiset toiminnot. Nimi hallita voidaan päätellä tarkoittavan, että tämä prosessi ohjaa sovelluksen suorittamista - mutta näin ei ole. Päällikkö yksinkertaisesti pyytää resursseja ja asettaa nämä resurssit kuljettajan saataville. Vaikka päällikkö seuraa näiden resurssien tilaa ja kuntoa, se ei ole mukana sovelluksen toteuttamisessa eikä sen tehtävien ja vaiheiden koordinoinnissa. Se on kuljettajan tehtävä.

Klusterin johtaja

Klusterinhallinta on prosessi, joka vastaa työntekijäsolmujen valvonnasta ja resurssien varaamisesta näihin solmuihin päällikön pyynnöstä. Sitten päällikkö asettaa nämä klusteriresurssit kuljettajan saataville toteuttajien muodossa.

Kuten aiemmin todettiin, klusterinhallinta voi olla erillinen pääprosessista. Tämä pätee, kun Sparkia käytetään Mesosilla tai YARNilla. Sparkissa, joka toimii itsenäisessä tilassa, isäntäprosessi suorittaa myös klusterinhallinnan toiminnot. Käytännössä se toimii omana klusterinjohtajana.

Hyvä esimerkki klusterinhallintatoiminnosta on Hadoop-klustereilla toimivien Spark-sovellusten YARN ResourceManager -prosessi. ResourceManager aikatauluttaa, allokoi ja valvoo YARN NodeManagers -sovelluksessa toimivien konttien kuntoa. Kipinäsovellukset käyttävät sitten näitä säiliöitä suorittamaan suoritinprosesseja sekä pääprosessia, jos sovellus on käynnissä klusterimoodissa.

Kipinäsovellukset erillisellä ajastimella

Luvussa 2, "Sparkin käyttöönotto", selitin erillisen ajoituksen Sparkin käyttöönottovaihtoehtona. Siellä otin käyttöön täysin toimivan monisolmuisen Spark-itsenäisen klusterin yhdessä luvun 2 harjoituksista. Kuten aiemmin todettiin, Spark-klusterissa, joka toimii itsenäisessä tilassa, Spark-isäntäprosessi suorittaa myös klusterinhallintatoiminnon ja hallitsee käytettävissä olevia resursseja ja antamalla ne pääprosessille käytettäväksi Spark-sovelluksessa.

Kipinäsovellukset, jotka ovat käynnissä YARNissa

Hadoop on Sparkille erittäin suosittu ja yleinen käyttöönottoalusta. Jotkut alan asiantuntijat uskovat, että Spark syrjäyttää pian MapReducen ensisijaisena sovellusalustana Hadoopissa. YARNin kipinäsovelluksilla on sama ajonaikainen arkkitehtuuri, mutta niiden toteutuksessa on joitain pieniä eroja.

ResourceManager klusterin hallitsijana

Päinvastoin kuin Standalone-ajastimessa, YARN-klusterin klusterinhallinta on YARN ResourceManager. ResourceManager valvoo resurssien käyttöä ja saatavuutta kaikissa klusterin solmuissa. Asiakkaat lähettävät Spark-hakemukset YARN ResourceManagerille. ResourceManager varaa ensimmäisen säilön sovellukselle, erityisen säiliön nimeltä ApplicationMaster.

ApplicationMaster Spark-päällikkönä

ApplicationMaster on Spark-pääprosessi. Kuten pääprosessi tapahtuu muissa klusterien käyttöönotoissa, ApplicationMaster neuvottelee resursseista sovellusohjaimen ja klusterinhallinnan (tai tässä tapauksessa ResourceManagerin) välillä; Sitten se asettaa nämä resurssit (säilöt) kuljettajan käytettäväksi suorittimina tehtävien suorittamiseen ja sovelluksen tietojen tallentamiseen.

ApplicationMaster pysyy sovelluksen koko käyttöiän ajan.

YARN-ohjelmassa toimivien Spark-sovellusten käyttöönottotilat

Kaksi käyttöönottotilaa voidaan käyttää, kun lähetät Spark-sovelluksia YARN-klusterille: asiakastila ja klusteritila. Katsotaanpa niitä nyt.

Asiakastila

Asiakastilassa ohjainprosessi suoritetaan asiakkaan, joka lähettää hakemuksen. Se on käytännössä hallitsematon; jos ohjaimen isäntä epäonnistuu, sovellus epäonnistuu. Asiakastilaa tuetaan molemmissa interaktiivisissa shell-istunnoissa (pyspark, kipinän kuorija niin edelleen) ja ei-vuorovaikutteinen hakemusten jättäminen (kipinä-lähettää). Alla oleva koodi osoittaa, miten a pyspark istunto asiakkaan käyttöönottotilassa.

$ SPARK_HOME / bin / pyspark \
--mestarilanka-asiakas \
--nummat toteuttajat 1 \
--ajurimuisti 512m \
- suoritusmuisti 512m \
- suoritusytimet 1
# TAI
$ SPARK_HOME / bin / pyspark \
--mestarilanka \
--deploy-mode client \
--nummat toteuttajat 1 \
--ajurimuisti 512m \
- suoritusmuisti 512m \
- suoritusytimet 1

Kuvassa 7 on yleiskatsaus Spark-sovelluksesta, joka toimii YARNilla asiakastilassa.

Pearson Addison-Wesley

Kuvassa 7 esitetyt vaiheet ovat:

1. Asiakas lähettää Spark-sovelluksen klusterinhallinnalle (YARN ResourceManager). Ohjainprosessi, SparkSession ja SparkContext luodaan ja suoritetaan asiakkaalla.
2. ResourceManager määrittää sovellukselle ApplicationMasterin (Spark-isännän).
3. ApplicationMaster pyytää säiliöitä käytettäväksi suorittajille ResourceManagerilta. Kun kontit on osoitettu, teloittajat kutevat.
4. Asiakkaalla oleva kuljettaja on sitten yhteydessä toimeenpanijoiden kanssa tehtävien ja Spark-ohjelman vaiheiden käsittelyyn. Kuljettaja palauttaa edistymisen, tulokset ja tilan asiakkaalle.

Asiakkaan käyttöönottotila on yksinkertaisin käyttötila. Sillä ei kuitenkaan ole useimmissa tuotantosovelluksissa tarvittavaa joustavuutta.

Klusteritila

Päinvastoin kuin asiakkaan käyttöönottotilassa, Spark-sovelluksen ollessa YARN Cluster -tilassa, ohjain itse toimii klusterissa ApplicationMasterin aliprosessina. Tämä tarjoaa joustavuuden: Jos ohjainta isännöivä ApplicationMaster-prosessi epäonnistuu, se voidaan ilmentää uudelleen klusterin toisessa solmussa.

Alla oleva koodi näyttää, miten hakemus lähetetään käyttämällä kipinä-lähettää ja YARN-klusterin käyttöönottotila. Koska ohjain on asynkroninen prosessi, joka toimii ryhmässä, klusteritilaa ei tueta interaktiivisissa kuorisovelluksissa (pyspark ja kipinän kuori).

$ SPARK_HOME / bin / kipinä-lähetys \
--mestarilanka-klusteri \
--nummat toteuttajat 1 \
--ajurimuisti 512m \
- suoritusmuisti 512m \
- suoritusytimet 1
$ SPARK_HOME / esimerkit / src / main / python / pi.py 10000
# TAI
--mestarilanka \
--deploy-mode-klusteri \
--nummat toteuttajat 1 \
--ajurimuisti 512m \
- suoritusmuisti 512m \
- suoritusytimet 1
$ SPARK_HOME / esimerkit / src / main / python / pi.py 10000

Kuvassa 8 on yleiskatsaus Spark-sovelluksesta, joka toimii YARN: lla klusterimoodissa.

Pearson Addison-Wesley

Kuvassa 8 esitetyt vaiheet ovat:

1. Asiakas, käyttäjäprosessi, joka kutsuu kipinä-lähettää, lähettää Spark-sovelluksen klusterinhallinnalle (YARN ResourceManager).
2. ResourceManager määrittää sovellukselle ApplicationMasterin (Spark-isännän). Ohjainprosessi luodaan samalle klusterisolmulle.
3. ApplicationMaster pyytää säiliöitä suorittajille ResourceManagerilta. toimeenpanijat syntyvät ResourceManagerin ApplicationMasterille osoittamissa säiliöissä. Sitten kuljettaja on yhteydessä toimeenpanijoiden kanssa Spark-ohjelman tehtävien ja vaiheiden käsittelyyn.
4. Klusterin solmussa käynnissä oleva ohjain palauttaa edistymisen, tulokset ja tilan asiakkaalle.

Kuten aiemmin on esitetty, Spark-sovelluksen web-käyttöliittymä on saatavana klusterin ApplicationMaster-isännältä; linkki tähän käyttöliittymään on saatavana YARN ResourceManager -käyttöliittymästä.

Paikallinen tila palattu

Paikallisessa tilassa kuljettaja, päällikkö ja toteuttaja toimivat kaikki yhdessä JVM: ssä. Kuten aiemmin tässä luvussa todettiin, tästä on hyötyä kehityksessä, yksikötestauksessa ja virheenkorjauksessa, mutta sillä on rajoitettu käyttö tuotantosovellusten suorittamiseen, koska sitä ei jaeta eikä se ole mittakaavassa. Lisäksi paikalliskäytössä olevan Spark-sovelluksen epäonnistuneita tehtäviä ei suoriteta oletusarvoisesti uudelleen. Voit kuitenkin ohittaa tämän käyttäytymisen.

Kun Sparkia suoritetaan paikallisessa tilassa, sovelluksen käyttöliittymä on saatavana osoitteessa // localhost: 4040. Pää- ja työntekijän käyttöliittymät eivät ole käytettävissä, kun ne suoritetaan paikallisessa tilassa.