Урок: Архитектура и клъстери на приложения на Spark

Вземете пълната книга
Анализ на данни с Spark с помощта на Python (Addison-Wesley Data & Analytics Series) MSRP $ 44,99 Вижте го

Тази статия е откъс от книгата на Пиърсън Адисън-Уесли „Анализ на данни с искри с помощта на Python“ от Джефри Авън. Препечатано тук с разрешение от Pearson © 2018. За повече информация посетете informit.com/aven/infoworld.

Преди да започнете пътуването си като програмист на Apache Spark, трябва добре да разберете архитектурата на приложението Spark и как приложенията се изпълняват в Spark клъстер. Тази статия разглежда внимателно компонентите на приложение Spark, разглежда как тези компоненти работят заедно и разглежда как приложенията Spark работят на самостоятелни и YARN клъстери.

Анатомия на приложение Spark

Приложението Spark съдържа няколко компонента, всички от които съществуват, независимо дали използвате Spark на една машина или в клъстер от стотици или хиляди възли.

Всеки компонент има определена роля в изпълнението на програма Spark. Някои от тези роли, като клиентските компоненти, са пасивни по време на изпълнение; други роли са активни при изпълнението на програмата, включително компоненти, изпълняващи изчислителни функции.

Компонентите на приложението Spark са:

  • шофьорът
  • господарят
  • клъстерния мениджър
  • изпълнителите

Всички те работят на работни възли, известни още като работници.

Фигура 1 показва всички компоненти на Spark в контекста на самостоятелно приложение на Spark.

Пиърсън Адисън-Уесли

Всички компоненти на Spark - включително драйверите, главния и изпълнителния процеси - се изпълняват във виртуални машини Java. JVM е междуплатформен механизъм за изпълнение, който може да изпълнява инструкции, компилирани в байт код на Java. Scala, в която е написана Spark, се компилира в байт код и работи на JVM.

Важно е да се прави разлика между компонентите за изпълнение на Spark и местоположенията и типовете възли, на които те се изпълняват. Тези компоненти се изпълняват на различни места, използвайки различни режими на внедряване, така че не мислете за тези компоненти във физически възел или екземпляр. Например, когато стартирате Spark на YARN, ще има няколко варианта на Фигура 1. Въпреки това, всички показани компоненти все още участват в приложението и имат същите роли.

Искров драйвер

Животът на приложението Spark започва и завършва с драйвера Spark. Драйверът е процесът, който клиентите използват за подаване на заявления в Spark. Водачът е отговорен и за планирането и координирането на изпълнението на програмата Spark и връщането на статуса и / или резултатите (данните) на клиента. Драйверът може физически да се намира на клиент или на възел в клъстера, както ще видите по-късно.

SparkSession

Драйверът на Spark е отговорен за създаването на SparkSession. Обектът SparkSession представлява връзка с клъстер Spark. SparkSession се създава в началото на приложение на Spark, включително интерактивните черупки, и се използва за цялата програма.

Преди Spark 2.0, входните точки за приложенията на Spark включват SparkContext, използван за основните приложения на Spark; SQLContext и HiveContext, използвани с Spark SQL приложения; и StreamingContext, използван за приложенията на Spark Streaming. Обектът SparkSession, въведен в Spark 2.0, комбинира всички тези обекти в една входна точка, която може да се използва за всички приложения на Spark.

Чрез своите подчинени обекти SparkContext и SparkConf обектът SparkSession съдържа всички свойства на конфигурацията по време на изпълнение, зададени от потребителя, включително свойства на конфигурацията като главен, име на приложение и брой изпълнители. Фигура 2 показва обекта SparkSession и някои от неговите конфигурационни свойства в pysparkчерупката.

Пиърсън Адисън-Уесли

Име на SparkSession

Името на обекта за екземпляра SparkSession е произволно. По подразбиране се именува екземплярът на SparkSession в интерактивните черупки на Spark spark. За последователност, винаги създавате екземпляр на SparkSession като spark; името обаче зависи от преценката на разработчика.

Кодът по-долу показва как да създадете SparkSession в неинтерактивно приложение Spark, като например програма, изпратена с помощта spark-submit.

от pyspark.sql импортиране на SparkSession

искра = SparkSession.builder \

  .master ("искра: // sparkmaster: 7077") \

  .appName ("Моето приложение Spark") \

  .config ("spark.submit.deployMode", "клиент") \

  .getOrCreate ()

numlines = spark.sparkContext.textFile ("файл: /// opt / spark / licenses") \

  .броя()

print ("Общият брой на редовете е" + str (numlines))

Планиране на кандидатстване

Една от основните функции на драйвера е да планира приложението. Драйверът взема вход за обработка на приложението и планира изпълнението на програмата. Драйверът предприема всички заявени трансформации (операции за манипулиране на данни) и действия (заявки за изход или подкани за изпълнение на програми) и създава насочена ациклична графика (DAG) от възли, всяка от които представлява трансформационна или изчислителна стъпка.

Насочена ациклична графика (DAG)

DAG е математическа конструкция, която често се използва в компютърните науки за представяне на потоци от данни и техните зависимости. DAG съдържат върхове (или възли) и ръбове. Върховете в контекста на потока от данни са стъпки в потока на процеса. Ръбовете в DAG свързват върховете един с друг в насочена ориентация и по такъв начин, че е невъзможно да има кръгови препратки.

DAG на приложението Spark се състои от задачи и етапи . Задачата е най-малката единица планируема работа в програма Spark. Етапът е набор от задачи, които могат да се изпълняват заедно. Етапите са зависими един от друг; с други думи, има сценични зависимости .

В смисъл на планиране на процес, DAG не са уникални за Spark. Например, те се използват в други екосистемни проекти за големи данни, като Tez, Drill и Presto за планиране. DAG са основни за Spark, така че си струва да се запознаете с концепцията.

Оркестрация на приложения

Драйверът също така координира изпълнението на етапи и задачи, дефинирани в DAG. Основните дейности, свързани с планирането и изпълнението на задачите, включват следното:

  • Проследяване на наличните ресурси за изпълнение на задачи.
  • Планиране на задачи за изпълнение „близо“ до данните, когато е възможно (концепцията за местоположението на данните).

Други функции

В допълнение към планирането и организирането на изпълнението на програма Spark, водачът е отговорен и за връщането на резултатите от приложението. Това могат да бъдат кодове за връщане или данни в случай на действие, което изисква данните да бъдат върнати на клиента (например интерактивна заявка).

Драйверът също така обслужва потребителския интерфейс на приложението на порт 4040, както е показано на фигура 3. Този потребителски интерфейс се създава автоматично; той е независим от подадения код или как е бил подаден (т.е. интерактивно използване pyspark или неинтерактивно използване spark-submit).

Пиърсън Адисън-Уесли

Ако следващите приложения се стартират на същия хост, се използват последователни портове за потребителския интерфейс на приложението (например 4041, 4042 и т.н.).

Искрови работници и изпълнители

Изпълнителите на Spark са процесите, при които се изпълняват задачите на Spark DAG. изпълнителите запазват ресурсите на процесора и паметта на подчинени възли или работници в клъстер Spark. Изпълнителят е посветен на конкретно приложение Spark и се прекратява, когато приложението завърши. Програмата Spark обикновено се състои от много изпълнители, често работещи паралелно.

Обикновено работният възел - който е хост на процеса на изпълнение - има ограничен или фиксиран брой изпълнители, разпределени във всеки момент от времето. Следователно клъстерът, който е известен брой възли, има краен брой изпълнители, които могат да се изпълняват по всяко време. Ако приложението изисква изпълнители, надвишаващи физическия капацитет на клъстера, те са планирани да стартират, докато други изпълнители завършат и освободят своите ресурси.

Както бе споменато по-рано, JVM хостват изпълнители на Spark. На JVM за изпълнител е разпределена купчина , която е специално пространство в паметта, в което да се съхраняват и управляват обекти.

Количеството памет, извършено на куп JVM за изпълнител се определя от имуществото spark.executor.memoryили като --executor-memoryаргумент в полза на pyspark, spark-shellили spark-submitкоманди.

Изпълнителите съхраняват изходни данни от задачи в паметта или на диска. Важно е да се отбележи, че работниците и изпълнителите са наясно само с възложените им задачи, докато водачът е отговорен за разбирането на пълния набор от задачи и съответните зависимости, които съставляват приложение.

Използвайки потребителския интерфейс на приложението Spark на порт 404 x на хост драйвера, можете да проверите изпълнителите за приложението, както е показано на фигура 4.

Пиърсън Адисън-Уесли

За самостоятелно разполагане на клъстер на Spark работният възел излага потребителски интерфейс на порт 8081, както е показано на фигура 5.

Пиърсън Адисън-Уесли

Главният и клъстер мениджър на Spark

Драйверът Spark планира и координира набора от задачи, необходими за стартиране на приложение Spark. Самите задачи се изпълняват в изпълнители, които се хостват на работни възли.

Главният и клъстерният мениджър са централните процеси, които наблюдават, резервират и разпределят разпределените клъстерни ресурси (или контейнери, в случай на YARN или Mesos), върху които се изпълняват изпълнителите. Главният и клъстерният мениджър могат да бъдат отделни процеси или могат да се комбинират в един процес, какъвто е случаят при стартиране на Spark в самостоятелен режим.

Искра майстор

Spark master е процесът, който изисква ресурси в клъстера и ги прави достъпни за драйвера Spark. Във всички режими на разгръщане капитанът договаря ресурси или контейнери с работни възли или подчинени възли и проследява състоянието им и следи напредъка им.

Когато се изпълнява Spark в самостоятелен режим, главният процес на Spark обслужва уеб потребителски интерфейс на порт 8080 на главния хост, както е показано на фигура 6.

Пиърсън Адисън-Уесли

Spark master срещу Spark driver

Важно е да се разграничат функциите по време на изпълнение на драйвера и главното устройство. Може да се предположи, че името на главния име означава, че този процес управлява изпълнението на приложението, но това не е така. Капитанът просто иска ресурси и ги прави достъпни за водача. Въпреки че капитанът следи състоянието и състоянието на тези ресурси, той не участва в изпълнението на приложението и координацията на неговите задачи и етапи. Това е работата на шофьора.

Клъстер мениджър

Мениджърът на клъстери е процесът, отговорен за наблюдението на работните възли и резервирането на ресурси в тези възли при поискване от капитана. След това капитанът предоставя тези ресурси на клъстера на разположение на драйвера под формата на изпълнители.

Както беше отбелязано по-рано, клъстерният мениджър може да бъде отделен от главния процес. Такъв е случаят, когато стартирате Spark на Mesos или YARN. В случай, че Spark работи в самостоятелен режим, главният процес изпълнява и функциите на клъстерния мениджър. На практика той действа като собствен клъстер мениджър.

Добър пример за функцията на клъстерния мениджър е процесът YARN ResourceManager за Spark приложения, работещи на клъстери Hadoop. ResourceManager планира, разпределя и следи за състоянието на контейнери, работещи на YARN NodeManagers. След това приложенията Spark използват тези контейнери за хостване на процеси на изпълнител, както и главния процес, ако приложението се изпълнява в режим на клъстер.

Искрете приложения, използвайки самостоятелния планировчик

В глава 2, „Разполагане на Spark“, обясних самостоятелния планировчик като опция за разполагане на Spark. Там внедрих напълно функционален многоузелен самостоятелен клъстер Spark в едно от упражненията в Глава 2. Както беше отбелязано по-рано, в Spark клъстер, работещ в самостоятелен режим, главният процес Spark изпълнява и функцията за управление на клъстери, управлявайки наличните ресурси на клъстер и ги предоставя на главния процес за използване в приложение Spark.

Искрови приложения, работещи на прежда

Hadoop е много популярна и често срещана платформа за внедряване на Spark. Някои специалисти в индустрията вярват, че Spark скоро ще измести MapReduce като основна платформа за обработка на приложения в Hadoop. Искрените приложения на YARN споделят същата архитектура на изпълнение, но имат някои малки разлики в изпълнението.

ResourceManager като мениджър на клъстери

За разлика от Самостоятелния планировчик, мениджърът на клъстери в клъстер YARN е YARN ResourceManager. ResourceManager следи използването и наличността на ресурси във всички възли в клъстер. Клиентите подават заявления Spark до YARN ResourceManager. ResourceManager разпределя първия контейнер за приложението, специален контейнер, наречен ApplicationMaster.

ApplicationMaster като Spark master

ApplicationMaster е главният процес на Spark. Както прави главният процес в други разгръщания на клъстера, ApplicationMaster договаря ресурси между драйвера на приложението и мениджъра на клъстера (или ResourceManager в този случай); след това прави тези ресурси (контейнери) на разположение на драйвера за използване като изпълнители за изпълнение на задачи и съхраняване на данни за приложението.

ApplicationMaster остава за цял живот на приложението.

Режими за внедряване за приложения Spark, работещи на прежда

Два режима на внедряване могат да се използват при подаване на приложения Spark в YARN клъстер: клиентски режим и клъстер режим. Нека ги разгледаме сега.

Клиентски режим

В клиентски режим процесът на драйвера се изпълнява от клиента, подаващ заявлението. По същество е неуправляван; ако хостът на драйвера не успее, приложението се провали. Режим Client се поддържа за двете интерактивни сесии черупки ( pyspark, spark-shellи така нататък) и неинтерактивно подаване на заявлението ( spark-submit). Кодът по-долу показва как да започнете pysparkсесия, като използвате клиентския режим за разполагане.

$ SPARK_HOME / bin / pyspark \

--master прежда-клиент \

--num-изпълнители 1 \

- драйвер-памет 512 м \

--executor-memory 512m \

--executor-ядра 1

# ИЛИ

$ SPARK_HOME / bin / pyspark \

--мастерска прежда \

--deploy-mode клиент \

--num-изпълнители 1 \

- драйвер-памет 512 м \

--executor-memory 512m \

--executor-ядра 1

Фигура 7 предоставя преглед на приложение Spark, работещо на YARN в клиентски режим.

Пиърсън Адисън-Уесли

Стъпките, показани на фигура 7, са:

  1. Клиентът изпраща приложение Spark на мениджъра на клъстери (YARN ResourceManager). Процесът на драйвера, SparkSession и SparkContext се създават и изпълняват на клиента.
  2. ResourceManager присвоява ApplicationMaster (Spark master) за приложението.
  3. ApplicationMaster иска контейнери да се използват за изпълнители от ResourceManager. С назначените контейнери, изпълнителите се хвърлят на хайвера си.
  4. След това водачът, разположен на клиента, комуникира с изпълнителите за маршалска обработка на задачи и етапи от програмата Spark. Драйверът връща напредъка, резултатите и състоянието на клиента.

Режимът за внедряване на клиента е най-простият режим за използване. Липсва обаче устойчивостта, необходима за повечето производствени приложения.

Клъстер режим

За разлика от клиентския режим на внедряване, с приложение Spark, работещо в режим YARN Cluster, самият драйвер работи на клъстера като подпроцес на ApplicationMaster. Това осигурява устойчивост: Ако процесът ApplicationMaster, хостващ драйвера, се провали, той може да бъде повторно създаден на друг възел в клъстера.

Кодът по-долу показва как да подадете заявление с помощта spark-submitи режима за разгръщане на клъстера YARN. Тъй като драйверът е асинхронен процес, изпълняващ се в клъстера, клъстерният режим не се поддържа за приложенията за интерактивна черупка ( pysparkи spark-shell).

$ SPARK_HOME / bin / spark-submit \

--master прежда-клъстер \

--num-изпълнители 1 \

- драйвер-памет 512 м \

--executor-memory 512m \

--executor-ядра 1

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

# ИЛИ

--мастерска прежда \

--deploy-mode клъстер \

--num-изпълнители 1 \

- драйвер-памет 512 м \

--executor-memory 512m \

--executor-ядра 1

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

Фигура 8 предоставя общ преглед на приложение Spark, работещо на YARN в режим на клъстер.

Пиърсън Адисън-Уесли

Стъпките, показани на фигура 8, са:

  1. Клиентът, потребителски процес, който извиква spark-submit, изпраща приложение Spark на мениджъра на клъстера (YARN ResourceManager).
  2. ResourceManager присвоява ApplicationMaster (Spark master) за приложението. Процесът на драйвера се създава на същия възел на клъстера.
  3. ApplicationMaster иска контейнери за изпълнители от ResourceManager. изпълнителите се раждат в контейнерите, разпределени на ApplicationMaster от ResourceManager. След това водачът комуникира с изпълнителите за маршалска обработка на задачи и етапи от програмата Spark.
  4. Драйверът, изпълняващ се на възел в клъстера, връща напредъка, резултатите и състоянието на клиента.

Потребителският интерфейс на приложението Spark, както е показано по-рано, е достъпен от хоста ApplicationMaster в клъстера; връзка към този потребителски интерфейс е достъпна от потребителския интерфейс на YARN ResourceManager.

Повторно посетен локален режим

В локален режим водачът, капитанът и изпълнителят се изпълняват в един JVM. Както беше отбелязано по-рано в тази глава, това е полезно за разработка, модулно тестване и отстраняване на грешки, но има ограничено приложение за стартиране на производствени приложения, тъй като не се разпространява и не се мащабира. Освен това неуспешните задачи в приложение Spark, работещо в локален режим, не се изпълняват повторно по подразбиране. Можете обаче да замените това поведение.

Когато стартирате Spark в локален режим, потребителският интерфейс на приложението е достъпен на // localhost: 4040. Главният и работният потребителски интерфейс не са налични при изпълнение в локален режим.