Programování

Výukový program: Spark architektura aplikací a clustery

Získejte celou knihu
Data Analytics with Spark using Python (Addison-Wesley Data & Analytics Series) MSRP $ 44,99 Zobrazit

Tento článek je výňatkem z knihy Pearson Addison-Wesley „Data Analytics with Spark Using Python“ od Jeffrey Aven. Přetištěno zde se svolením společnosti Pearson © 2018. Další informace najdete na stránce informit.com/aven/infoworld.

Než začnete svou cestu programátora Apache Spark, měli byste důkladně porozumět architektuře aplikace Spark a způsobu provádění aplikací v klastru Spark. Tento článek podrobně zkoumá komponenty aplikace Spark, zkoumá, jak tyto komponenty spolupracují, a zkoumá, jak aplikace Spark běží na samostatných a YARN klastrech.

Anatomie aplikace Spark

Aplikace Spark obsahuje několik komponent, z nichž všechny existují, ať už používáte Spark na jednom počítači nebo v klastru stovek nebo tisíců uzlů.

Každá komponenta má při provádění programu Spark určitou roli. Některé z těchto rolí, například klientské komponenty, jsou během provádění pasivní; při provádění programu jsou aktivní další role, včetně komponent provádějících výpočetní funkce.

Komponenty aplikace Spark jsou:

  • řidič
  • mistr
  • správce clusteru
  • exekutory

Všichni běží na pracovních uzlech, alias pracovnících.

Obrázek 1 ukazuje všechny komponenty Spark v kontextu samostatné aplikace Spark.

Pearson Addison-Wesley

Všechny komponenty Spark - včetně procesů ovladače, hlavního a prováděcího procesu - běží ve virtuálních strojích Java. JVM je multiplatformní runtime modul, který může provádět instrukce zkompilované do Java bytecode. Scala, do které je zapsán Spark, se kompiluje do bytecode a běží na JVM.

Je důležité rozlišovat mezi komponentami runtime aplikace Spark a umístěním a typy uzlů, na kterých běží. Tyto komponenty běží na různých místech pomocí různých režimů nasazení, takže na tyto komponenty nemyslete z hlediska fyzického uzlu nebo instance. Například při spuštění Spark na YARN by existovalo několik variant obrázku 1. Všechny zobrazené komponenty jsou však v aplikaci stále zapojeny a mají stejné role.

Řidič jiskry

Životnost aplikace Spark začíná a končí ovladačem Spark. Ovladač je proces, který klienti používají k odesílání aplikací ve Sparku. Řidič je také zodpovědný za plánování a koordinaci provádění programu Spark a za vrácení stavu a / nebo výsledků (dat) klientovi. Ovladač se může fyzicky nacházet na klientovi nebo na uzlu v klastru, jak uvidíte později.

SparkSession

Ovladač Spark je zodpovědný za vytvoření SparkSession. Objekt SparkSession představuje připojení ke clusteru Spark. SparkSession je instancován na začátku aplikace Spark, včetně interaktivních skořápek, a je používán pro celý program.

Před Sparkem 2.0 zahrnovaly vstupní body pro aplikace Spark SparkContext, používaný pro základní aplikace Spark; SQLContext a HiveContext, používané s aplikacemi Spark SQL; a StreamingContext, který se používá pro aplikace Spark Streaming. Objekt SparkSession představený ve verzi Spark 2.0 kombinuje všechny tyto objekty do jediného vstupního bodu, který lze použít pro všechny aplikace Spark.

Prostřednictvím svých podřízených objektů SparkContext a SparkConf obsahuje objekt SparkSession všechny konfigurační vlastnosti modulu runtime nastavené uživatelem, včetně konfiguračních vlastností, jako je hlavní server, název aplikace a počet exekutorů. Obrázek 2 ukazuje objekt SparkSession a některé jeho konfigurační vlastnosti v a pyspark skořápka.

Pearson Addison-Wesley

Název SparkSession

Název objektu pro instanci SparkSession je libovolný. Ve výchozím nastavení je pojmenována instance SparkSession v interaktivních skořápkách Spark jiskra. Z důvodu konzistence vždy vytvoříte instanci SparkSession jako jiskra; název však závisí na uvážení vývojáře.

Níže uvedený kód ukazuje, jak vytvořit SparkSession v neinteraktivní aplikaci Spark, jako je program odeslaný pomocí jiskra-předložit.

z pyspark.sql importovat SparkSession

spark = SparkSession.builder \

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

.appName ("Moje aplikace Spark") \

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

.getOrCreate ()

numlines = spark.sparkContext.textFile ("soubor: /// opt / spark / license") \

.počet()

print ("Celkový počet řádků je" + str (numlines))

Plánování aplikace

Jednou z hlavních funkcí ovladače je naplánovat aplikaci. Ovladač převezme vstup pro zpracování aplikace a naplánuje provedení programu. Řidič vezme všechny požadované transformace(operace manipulace s daty) a akce (požadavky na výstup nebo výzvy k provedení programů) a vytvoří směrovaný acyklický graf (DAG) uzlů, z nichž každý představuje transformační nebo výpočetní krok.

Směrovaný acyklický graf (DAG)

DAG je matematický konstrukt, který se běžně používá v informatice k reprezentaci datových toků a jejich závislostí. DAG obsahují vrcholy (nebo uzly) a hrany. Vrcholy v kontextu toku dat jsou kroky v toku procesu. Hrany v DAG spojují vrcholy navzájem v orientované orientaci a takovým způsobem, že je nemožné mít kruhové odkazy.

Spark aplikace DAG se skládá z úkoly a etapy. Úkol je nejmenší jednotka naplánovatelné práce v programu Spark. Fáze je sada úkolů, které lze spustit společně. Fáze jsou navzájem závislé; jinými slovy, existují jevištní závislosti.

Ve smyslu plánování procesu nejsou DAG pro Spark jedinečné. Například se používají v jiných projektech ekosystémů velkých dat, jako jsou Tez, Drill a Presto pro plánování. DAG jsou pro Spark zásadní, takže stojí za to se s tímto konceptem seznámit.

Orchestrace aplikace

Řidič také koordinuje chod etap a úkolů definovaných v DAG. Mezi klíčové činnosti řidiče zapojené do plánování a spouštění úkolů patří:

  • Sledování dostupných zdrojů k provádění úkolů.
  • Pokud je to možné, naplánujte úlohy tak, aby běžely „blízko“ k datům (koncept datové lokality).

Další funkce

Kromě plánování a orchestrace provádění programu Spark je ovladač také zodpovědný za vrácení výsledků z aplikace. Mohou to být návratové kódy nebo data v případě akce, která požaduje vrácení dat klientovi (například interaktivní dotaz).

Ovladač také obsluhuje uživatelské rozhraní aplikace na portu 4040, jak je znázorněno na obrázku 3. Toto uživatelské rozhraní se vytváří automaticky; je nezávislý na odeslaném kódu nebo na tom, jak byl odeslán (tj. interaktivní použití pysparknebo neinteraktivní pomocí jiskra-předložit).

Pearson Addison-Wesley

Pokud se následné aplikace spustí na stejném hostiteli, použijí se po sobě následující porty pro uživatelské rozhraní aplikace (například 4041, 4042 atd.).

Sparkujte pracovníky a exekutory

Exekutoři Spark jsou procesy, na kterých běží úlohy Spark DAG. vykonavatelé rezervují prostředky CPU a paměti na podřízených uzlech nebo pracovnících v clusteru Spark. Exekutor je věnován konkrétní aplikaci Spark a je ukončen po dokončení aplikace. Program Spark se obvykle skládá z mnoha exekutorů, kteří často pracují paralelně.

Pracovní uzel - který je hostitelem procesu exekutora - má obvykle konečný nebo pevný počet exekutorů přidělených v kterémkoli okamžiku. Proto má klastr, který je známým počtem uzlů, konečný počet exekutorů, které lze spustit v daném okamžiku. Pokud aplikace vyžaduje, aby exekutoři přesahovali fyzickou kapacitu klastru, je naplánováno jejich spuštění, když ostatní exekutoři dokončí a uvolní své prostředky.

Jak již bylo zmíněno dříve, JVM hostují vykonavatele Sparku. JVM pro exekutora je přiděleno a halda, což je vyhrazený paměťový prostor, do kterého lze ukládat a spravovat objekty.

Množství paměti vyhrazené pro haldu JVM pro exekutora je nastaveno vlastností jiskra. exekutor. paměť nebo jako --exekutor-paměť argument k pyspark, jiskranebo jiskra-předložit příkazy.

Exekutoři ukládají výstupní data z úkolů do paměti nebo na disk. Je důležité si uvědomit, že pracovníci a exekutoři jsou si vědomi pouze úkolů, které jim byly přiděleny, zatímco ovladač je zodpovědný za pochopení úplné sady úkolů a příslušných závislostí, které tvoří aplikaci.

Pomocí uživatelského rozhraní aplikace Spark na portu 404X hostitele ovladače, můžete zkontrolovat exekutory pro aplikaci, jak je znázorněno na obrázku 4.

Pearson Addison-Wesley

U samostatných nasazení klastru Spark pracovní uzel vystavuje uživatelské rozhraní na portu 8081, jak je znázorněno na obrázku 5.

Pearson Addison-Wesley

Spark master a správce klastrů

Ovladač Spark plánuje a koordinuje sadu úkolů potřebných ke spuštění aplikace Spark. Samotné úkoly běží v exekutorech, které jsou hostovány na pracovních uzlech.

Hlavní a správce klastru jsou centrální procesy, které monitorují, rezervují a alokují prostředky distribuovaného klastru (nebo kontejnery, v případě YARN nebo Mesos), na nichž běží exekutoři. Hlavní a správce klastru mohou být samostatné procesy nebo se mohou spojit do jednoho procesu, jako je tomu při spuštění Sparku v samostatném režimu.

Spark master

Master Spark je proces, který požaduje prostředky v klastru a zpřístupňuje je ovladači Spark. Ve všech režimech nasazení hlavní vyjednává prostředky nebo kontejnery s pracovními uzly nebo podřízenými uzly a sleduje jejich stav a sleduje jejich postup.

Při spuštění Spark v samostatném režimu slouží proces Spark master webové uživatelské rozhraní na portu 8080 na hlavním hostiteli, jak je znázorněno na obrázku 6.

Pearson Addison-Wesley

Spark master versus Spark driver

Je důležité rozlišovat běhové funkce ovladače a masteru. Název mistr lze odvodit v tom smyslu, že tento proces řídí výkon aplikace - ale není tomu tak. Velitel jednoduše požádá o zdroje a zpřístupní je řidiči. Přestože hlavní monitoruje stav a stav těchto zdrojů, není zapojen do provádění aplikace a koordinace jejích úkolů a fází. To je práce řidiče.

Správce klastru

Správce klastru je proces odpovědný za monitorování pracovních uzlů a rezervování zdrojů v těchto uzlech na žádost hlavního. Hlavní pak tyto prostředky clusteru zpřístupní ovladači ve formě exekutorů.

Jak již bylo uvedeno dříve, správce klastrů může být oddělen od hlavního procesu. To je případ, kdy běží Spark na Mesos nebo YARN. V případě, že Spark běží v samostatném režimu, hlavní proces také vykonává funkce správce clusteru. Účinně funguje jako vlastní správce klastrů.

Dobrým příkladem funkce správce klastrů je proces YARN ResourceManager pro aplikace Spark běžící na klastrech Hadoop. ResourceManager plánuje, přiděluje a monitoruje stav kontejnerů běžících na YARN NodeManagers. Aplikace Spark pak používají tyto kontejnery k hostování procesů prováděcích programů, stejně jako hlavního procesu, pokud je aplikace spuštěna v režimu clusteru.

Sparkujte aplikace pomocí samostatného plánovače

V kapitole 2 „Nasazení Sparku“ jsem vysvětlil samostatný plánovač jako možnost nasazení pro Spark. Tam jsem do jednoho z cvičení v kapitole 2 nasadil plně funkční multinode samostatný klastr Spark. Jak již bylo zmíněno dříve, v klastru Spark běžícím v samostatném režimu provádí hlavní proces Spark také funkci správce klastru a řídí dostupné zdroje na clusteru a jejich udělení hlavnímu procesu pro použití v aplikaci Spark.

Sparkujte aplikace běžící na YARN

Hadoop je velmi populární a běžná platforma nasazení pro Spark. Někteří vědci z oboru věří, že Spark brzy nahradí MapReduce jako primární platformu pro zpracování aplikací v Hadoopu. Sparkové aplikace na YARN sdílejí stejnou běhovou architekturu, ale mají určité drobné rozdíly v implementaci.

ResourceManager jako správce clusteru

Na rozdíl od samostatného plánovače je správcem klastru v klastru YARN YARN ResourceManager. ResourceManager sleduje využití a dostupnost prostředků ve všech uzlech v klastru. Klienti odesílají aplikace Spark do YARN ResourceManageru. ResourceManager přiděluje první kontejner pro aplikaci, speciální kontejner s názvem ApplicationMaster.

ApplicationMaster jako mistr Spark

ApplicationMaster je hlavní proces Spark. Stejně jako hlavní proces v jiných nasazeních clusteru vyjednává ApplicationMaster prostředky mezi ovladačem aplikace a správcem clusteru (nebo v tomto případě ResourceManager); poté tyto prostředky (kontejnery) zpřístupní ovladači pro použití jako exekutory ke spouštění úkolů a ukládání dat pro aplikaci.

ApplicationMaster zůstává po celou dobu životnosti aplikace.

Režimy nasazení pro aplikace Spark běžící na YARN

Při odesílání aplikací Spark do klastru YARN lze použít dva režimy nasazení: režim klienta a režim klastru. Podívejme se na ně hned.

Klientský režim

V klientském režimu běží proces ovladače na klientovi, který odesílá žádost. Je to v podstatě neřízené; pokud hostitel ovladače selže, aplikace selže. Režim klienta je podporován pro obě relace interaktivního prostředí (pyspark, jiskraa tak dále) a neinteraktivní odesílání aplikací (jiskra-předložit). Níže uvedený kód ukazuje, jak spustit a pyspark relace pomocí režimu nasazení klienta.

$ SPARK_HOME / bin / pyspark \

--master příze-klient \

- počet exekutorů 1 \

--driver-paměť 512m \

--exekutor-paměť 512m \

--exekutorská jádra 1

# NEBO

$ SPARK_HOME / bin / pyspark \

- mistrovská příze \

- klient nasazení v režimu \

- počet exekutorů 1 \

--driver-paměť 512m \

--exekutor-paměť 512m \

--exekutorská jádra 1

Obrázek 7 poskytuje přehled aplikace Spark spuštěné na YARN v klientském režimu.

Pearson Addison-Wesley

Kroky zobrazené na obrázku 7 jsou:

  1. Klient odešle aplikaci Spark správci klastru (YARN ResourceManager). Proces ovladače, SparkSession a SparkContext jsou vytvořeny a spuštěny na klientovi.
  2. ResourceManager přiřadí aplikaci ApplicationMaster (hlavní Spark).
  3. ApplicationMaster požaduje, aby kontejnery byly použity pro exekutory z ResourceManageru. S přiřazenými kontejnery se objeví exekutoři.
  4. Řidič umístěný na klientovi poté komunikuje s exekutory, aby zařadil zpracování úkolů a fází programu Spark. Řidič vrátí klientovi průběh, výsledky a stav.

Režim nasazení klienta je nejjednodušší režim, který lze použít. Postrádá však odolnost požadovanou pro většinu produkčních aplikací.

Režim clusteru

Na rozdíl od režimu nasazení klienta běží aplikace Spark spuštěná v režimu YARN Cluster samotný ovladač v clusteru jako podproces ApplicationMaster. To poskytuje odolnost: Pokud proces ApplicationMaster hostující ovladač selže, lze jej znovu vytvořit v jiném uzlu v klastru.

Níže uvedený kód ukazuje, jak odeslat žádost pomocí jiskra-předložit a režim nasazení klastru YARN. Protože ovladač je asynchronní proces spuštěný v clusteru, režim clusteru není pro aplikace interaktivního prostředí podporován (pyspark a jiskra).

$ SPARK_HOME / bin / spark-submit \

--master shluk příze \

- počet exekutorů 1 \

--driver-paměť 512m \

--exekutor-paměť 512m \

--exekutorská jádra 1

$ SPARK_HOME / examples / src / main / python / pi.py 10 000

# NEBO

- mistrovská příze \

- cluster nasazení \

- počet exekutorů 1 \

--driver-paměť 512m \

--exekutor-paměť 512m \

--exekutorská jádra 1

$ SPARK_HOME / examples / src / main / python / pi.py 10 000

Obrázek 8 poskytuje přehled aplikace Spark spuštěné na YARN v režimu clusteru.

Pearson Addison-Wesley

Kroky zobrazené na obrázku 8 jsou:

  1. Klient, uživatelský proces, který vyvolá jiskra-předložit, odešle aplikaci Spark správci klastru (YARN ResourceManager).
  2. ResourceManager přiřadí aplikaci ApplicationMaster (hlavní Spark). Proces ovladače je vytvořen ve stejném uzlu clusteru.
  3. ApplicationMaster požaduje kontejnery pro exekutory z ResourceManageru. exekutoři se objevují v kontejnerech přidělených ApplicationMasterovi ResourceManager. Řidič poté komunikuje s exekutory, aby zařadil zpracování úkolů a fází programu Spark.
  4. Řidič běžící na uzlu v klastru vrací klientovi průběh, výsledky a stav.

Webové uživatelské rozhraní aplikace Spark, jak je znázorněno výše, je k dispozici na hostiteli ApplicationMaster v klastru; odkaz na toto uživatelské rozhraní je k dispozici v uživatelském rozhraní YARN ResourceManager.

Místní režim se vrátil

V místním režimu běží ovladač, hlavní a exekutor v jediném JVM. Jak již bylo zmíněno dříve v této kapitole, je to užitečné pro vývoj, testování jednotek a ladění, ale pro provoz produkčních aplikací má omezené použití, protože není distribuováno a nemění měřítko. Kromě toho se ve výchozím nastavení neprovádějí neúspěšné úlohy v aplikaci Spark spuštěné v místním režimu. Toto chování však můžete přepsat.

Při spuštění Spark v místním režimu je uživatelské rozhraní aplikace k dispozici na // localhost: 4040. Hlavní a pracovní rozhraní uživatelského rozhraní nejsou k dispozici při spuštění v místním režimu.

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