Configurazione di Spark nantu à YARN

Habr, salutu! Ieri nantu incontru dedicatu à Apache Spark, da i picciotti di Rambler & Co, ci era parechje dumande da i participanti ligati à a cunfigurazione di stu strumentu. Avemu decisu di seguità i so passi è di sparte a nostra sperienza. U tema ùn hè micca faciule - cusì vi invitamu à sparte a vostra sperienza in i cumenti, forse avemu ancu capitu è ​​aduprà qualcosa di sbagliatu.

Una piccula introduzione à cumu usemu Spark. Avemu un prugramma di trè mesi "Specialista Big Data", è in tuttu u secondu modulu i nostri participanti travaglianu nant'à stu strumentu. Dunque, u nostru compitu, cum'è urganizatori, hè di preparà u cluster per l'usu in un tali casu.

A peculiarità di u nostru usu hè chì u numeru di persone chì travaglianu simultaneamente in Spark pò esse uguali à u gruppu sanu. Per esempiu, in un seminariu, quandu tutti pruvate qualcosa à u stessu tempu è ripete dopu à u nostru maestru. È questu ùn hè micca assai - qualchì volta finu à 40 persone. Probabilmente ùn ci hè micca parechje cumpagnie in u mondu chì facenu un tali casu d'usu.

Dopu, vi dicu cumu è perchè avemu sceltu certi paràmetri di cunfigurazione.

Cuminciamu da u principiu. Spark hà 3 opzioni per eseguisce nantu à un cluster: standalone, usendu Mesos, è use YARN. Avemu decisu di sceglie a terza opzione perchè hà fattu sensu per noi. Avemu digià un cluster Hadoop. I nostri participanti sò digià cunnisciuti bè cù a so architettura. Avemu aduprà YARN.

spark.master=yarn

In più più interessante. Ognuna di queste 3 opzioni di implementazione hà 2 opzioni di implementazione: cliente è cluster. Basatu ducumentazione è parechji ligami nantu à Internet, pudemu cuncludi chì u cliente hè adattatu per u travagliu interattivu - per esempiu, attraversu un notebook jupyter, è u cluster hè più adattatu per suluzioni di produzzione. In u nostru casu, eramu interessati à u travagliu interattivu, dunque:

spark.deploy-mode=client

In generale, da avà Spark hà da travaglià in qualchì modu nantu à YARN, ma questu ùn era micca abbastanza per noi. Siccomu avemu un prugramma di big data, qualchì volta i participanti ùn anu micca abbastanza di ciò chì hè stata ottenuta in u quadru di un tagliu ancu di risorse. È dopu avemu trovu una cosa interessante - l'assignazione dinamica di risorse. In corta, u puntu hè questu: se avete un compitu difficiule è u cluster hè liberu (per esempiu, in a matina), allora utilizendu sta opzione Spark pò dà risorse supplementari. A necessità hè calculata quì secondu una formula astuta. Ùn andemu micca in dettagli - funziona bè.

spark.dynamicAllocation.enabled=true

Avemu stabilitu stu paràmetru, è à l'iniziu Spark s'hè lampatu è ùn hà micca cuminciatu. Hè ghjustu, perchè aghju avutu à leghje documentazione cun più cura. Dice chì, per chì tuttu sia bè, avete ancu bisognu di attivà un paràmetru supplementu.

spark.shuffle.service.enabled=true

Perchè hè necessariu? Quandu u nostru travagliu ùn hà più bisognu di tante risorse, Spark deve rinvià à a piscina cumuna. U stadiu più tempu in quasi ogni compitu MapReduce hè u stadiu Shuffle. Stu paràmetru vi permette di salvà i dati chì sò generati in questa fase è liberate l'esecutori in cunseguenza. È l'esecutore hè u prucessu chì calcula tuttu nantu à u travagliu. Hà un certu nùmeru di core di processore è una certa quantità di memoria.

Stu paràmetru hè statu aghjuntu. Tuttu paria di travaglià. Hè diventatu notu chì i participanti sò stati dati più risorse quandu anu bisognu. Ma un altru prublema hè ghjuntu - à un certu puntu l'altri participanti si sveglianu è vulianu ancu aduprà Spark, ma tuttu era occupatu quì, è eranu infelici. Puderanu esse capitu. Avemu cuminciatu à guardà a documentazione. Ci hè stata chì ci sò parechje altre paràmetri chì ponu esse usatu per influenzà u prucessu. Per esempiu, se l'esecutore hè in modu standby, dopu à quale tempu pò esse pigliatu risorse da ellu?

spark.dynamicAllocation.executorIdleTimeout=120s

In u nostru casu, se i vostri esecutori ùn facenu nunda per dui minuti, allora tornanu à a piscina cumuna. Ma stu paràmetru ùn era micca sempre abbastanza. Era chjaru chì a persona ùn avia fattu nunda per un bellu pezzu, è e risorse ùn sò micca stati liberati. Hè risultatu chì ci hè ancu un paràmetru speciale - dopu à quale tempu per selezziunà esecutori chì cuntenenu dati in cache. Per automaticamente, stu paràmetru era infinitu ! Avemu currettu.

spark.dynamicAllocation.cachedExecutorIdleTimeout=600s

Questu hè, se i vostri esecutori ùn facenu nunda per 5 minuti, dà à a piscina cumuna. In questu modu, a velocità di liberazione è emissione di risorse per un gran numaru d'utilizatori hè diventata decente. A quantità di scontente hè diminuitu. Ma avemu decisu di andà più luntanu è limità u numeru massimu di esecutori per applicazione - essenzialmente per participant à u prugramma.

spark.dynamicAllocation.maxExecutors=19

Avà, sicuru, ci sò persone insatisfete da l'altra parte - "u cluster hè inattivu, è aghju solu esecutori 19", ma chì pudete fà? Avemu bisognu di qualchì equilibriu currettu. Ùn pudete micca fà felici à tutti.

È una altra piccula storia ligata à e specificità di u nostru casu. Qualchì manera, parechje persone eranu tardi per una lezione pratica, è per una certa ragione Spark ùn hà micca cuminciatu per elli. Avemu vistu a quantità di risorse gratuiti - pare chì ci hè. Spark deve principià. Fortunatamente, à quellu tempu, a documentazione era digià aghjuntu à a subcortica in un locu, è avemu ricurdatu chì quandu hè stata lanciata, Spark cerca un portu da quale principià. Se u primu portu in a gamma hè occupatu, si move à u prossimu in ordine. S'ellu hè liberu, cattura. È ci hè un paràmetru chì indica u numeru massimu di tentativi per questu. U predeterminatu hè 16. U numeru hè menu di u numeru di persone in u nostru gruppu in classi. Dunque, dopu à 16 tentativi, Spark rinunziò è disse chì ùn pudia micca principià. Avemu currettu stu paràmetru.

spark.port.maxRetries=50

In seguitu vi dicu di qualchi paràmetri chì ùn sò micca assai ligati à e specifiche di u nostru casu.

Per inizià Spark più veloce, hè cunsigliatu di archivià u cartulare jars situatu in u cartulare di casa SPARK_HOME è mette in HDFS. Allora ùn perderà micca u tempu à carricà sti jarniks da i travagliadori.

spark.yarn.archive=hdfs:///tmp/spark-archive.zip

Hè ricumandemu ancu di utilizà kryo cum'è un serializatore per una operazione più veloce. Hè più ottimizatu cà u predeterminatu.

spark.serializer=org.apache.spark.serializer.KryoSerializer

È ci hè ancu un prublema di longa durata cù Spark chì spessu sbatte da a memoria. Spessu questu succede à u mumentu chì i travagliadori anu calculatu tuttu è mandà u risultatu à u cunduttore. Avemu fattu stu paràmetru più grande per noi. Per automaticamente, hè 1GB, avemu fattu 3.

spark.driver.maxResultSize=3072

È infine, cum'è un dessert. Cumu aghjurnà Spark à a versione 2.1 nantu à a distribuzione HortonWorks - HDP 2.5.3.0. Questa versione di HDP cuntene una versione 2.0 preinstallata, ma una volta avemu decisu per noi stessi chì Spark si sviluppa in modu abbastanza attivu, è ogni nova versione corregge alcuni bug più furnisce funzioni supplementari, cumpresu per l'API python, cusì avemu decisu, ciò chì ci vole. esse fattu hè un aghjurnamentu.

Scaricatu a versione da u situ ufficiale per Hadoop 2.7. Unzipped it è mette in u cartulare HDP. Avemu installatu i ligami simbolichi quantu necessariu. Lanciamu - ùn principia micca. Scrive un errore assai stranu.

java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfig

Dopu à Google, avemu scupertu chì Spark hà decisu di ùn aspittà finu à chì Hadoop hè natu, è hà decisu di utilizà a nova versione di maglia. Iddi stessi discute cun l'altri annantu à questu tema in JIRA. A suluzione era di scaricà versione di maglia 1.17.1. Pone questu in u cartulare jars in SPARK_HOME, zip di novu è caricate in HDFS.

Avemu righjuntu stu errore, ma hè ghjuntu un novu è piuttostu simplificatu.

org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch application master

À u listessu tempu, pruvemu di eseguisce a versione 2.0 - tuttu hè bè. Pruvate à indovinà ciò chì succede. Avemu guardatu i logs di sta applicazione è avemu vistu qualcosa cum'è questu:

/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jar

In generale, per una certa ragione hdp.version ùn hè micca risolta. Dopu à Google, avemu trovu una suluzione. Avete bisognu à andà à i paràmetri di YARN in Ambari è aghjunghje un paràmetru quì à u situ di filatu persunalizatu:

hdp.version=2.5.3.0-37

Sta magia hà aiutatu, è Spark s'hè alluntanatu. Avemu pruvatu parechji di i nostri laptops jupyter. Tuttu travaglia. Semu pronti per a prima lezione di Spark u sabbatu (dumane) !

DUP. Durante a lezziò, un altru prublema hè vinutu à a luce. À un certu puntu, YARN hà cessatu di furnisce cuntenituri per Spark. In YARN era necessariu di curregà u paràmetru, chì per automaticamente era 0.2:

yarn.scheduler.capacity.maximum-am-resource-percent=0.8

Questu hè, solu u 20% di e risorse hà participatu à a distribuzione di risorse. Dopu avè cambiatu i paràmetri, avemu ricaricatu YARN. U prublema hè stata risolta è u restu di i participanti anu ancu capaci di eseguisce u cuntestu di spark.

Source: www.habr.com