ProHoster > Blogg > Internett nyheter > Konfigurering av Spark pÄ YARN

Konfigurering av Spark pÄ YARN

Habr, hei! I gĂ„r pĂ„ meetupen om Apache Spark, fra gutta i Rambler&Co, var det ganske mange spĂžrsmĂ„l fra deltakerne om hvordan man konfigurerer dette verktĂžyet. Vi bestemte oss for Ă„ dele vĂ„r erfaring etter det. Temaet er komplisert — derfor oppfordrer vi ogsĂ„ til Ă„ dele erfaringer i kommentarene, kanskje vi ogsĂ„ misforstĂ„r eller bruker noe feil.

En liten introduksjon — hvordan vi bruker Spark. Vi har et tre mĂ„neders program “Store dataspesialist”, og i den andre modulen jobber deltakerne vĂ„re med dette verktĂžyet. Dermed er det vĂ„r oppgave, som arrangĂžrer, Ă„ forberede en klynge til bruk i en slik sammenheng.

En spesiell egenskap ved bruken vĂ„r er at antallet personer som jobber med Spark samtidig kan vĂŠre lik hele gruppen. For eksempel, pĂ„ et seminar, nĂ„r alle prĂžver Ă„ fĂžlge med pĂ„ hva lĂŠreren vĂ„r gjĂžr. Og det er ikke lite — noen ganger opp mot 40 personer. Det er sikkert ikke sĂ„ mange selskaper i verden som mĂžter et slikt bruksopplegg.

Videre vil jeg fortelle hvordan og hvorfor vi valgte de forskjellige konfigurasjonsparameterne.

La oss begynne fra starten. Spark har 3 mÄter Ä operere pÄ en klynge: standalone, ved Ä bruke Mesos eller ved Ä bruke YARN. Vi valgte det tredje alternativet fordi det virket logisk for oss. Vi har allerede en hadoop-klynge. Deltakerne vÄre er godt kjent med arkitekturen. La oss bruke YARN.

spark.master=yarn

Det blir enda mer interessant. Hver av disse 3 distribusjonsalternativene har 2 distribusjonsmoduser: client og cluster. Basert pĂ„ dokumentasjonen og forskjellige lenker pĂ„ nettet, kan man konkludere med at client-modus passer for interaktivt arbeid — for eksempel gjennom jupyter notebook, mens cluster-modus er mer passende for produksjonslĂžsninger. I vĂ„rt tilfelle var vi interessert i interaktivt arbeid, sĂ„:

spark.deploy-mode=client

Fra dette Ăžyeblikket begynner Spark Ă„ fungere pĂ„ YARN, men det var ikke nok for oss. Siden programmet vĂ„rt handler om store data, falt det noen ganger deltakerne kort nĂ„r det kom til den jevne fordelingen av ressurser. Og her fant vi noe interessant – dynamisk ressursallokering. Kort fortalt er essensen som fĂžlger: hvis du har en tung oppgave og klyngen er ledig (for eksempel om morgenen), kan Spark med denne opsjonen gi deg ekstra ressurser. Behovet beregnes etter en smart formel. Vi skal ikke gĂ„ nĂŠrmere inn pĂ„ detaljene – den fungerer ganske godt.

spark.dynamicAllocation.enabled=true

Vi satte denne parameteren, og da vi startet Spark, klaget den og startet ikke. Riktig, fordi vi burde ha lest dokumentasjonen nÞye. Det stÄr at for at alt skal vÊre greit, mÄ vi ogsÄ aktivere en ekstra parameter.

spark.shuffle.service.enabled=true

Hvorfor er den nÞdvendig? NÄr jobben vÄr ikke lenger krever sÄ mange ressurser, mÄ Spark returnere dem til det felles pulje. Den mest ressurskrevende fasen i nesten hver MapReduce-oppgave er Shuffle-fasen. Denne parameteren lar oss bevare dataene som dannes i denne fasen og dermed frigjÞre executors. En executor er en prosess som beregner alt pÄ arbeideren. Den har et visst antall prosesseringskjerner og en viss mengde minne.

Vi la til denne parameteren. Alt sĂ„ ut til Ă„ fungere. Det ble merkbart at deltakerne faktisk fikk tildelt flere ressurser nĂ„r de trengte det. Men et nytt problem oppsto – pĂ„ et tidspunkt vĂ„knet andre deltakere og Ăžnsket ogsĂ„ Ă„ bruke Spark, men alt var opptatt, og de var misfornĂžyde. Det er forstĂ„elig. Vi begynte Ă„ se i dokumentasjonen. Der viste det seg at det er flere parametere ved hjelp av hvilke vi kan pĂ„virke prosessen. For eksempel, hvis executor er i ventemodus – hvor lenge etter kan vi hente ressursene?

spark.dynamicAllocation.executorIdleTimeout=120s

I vĂ„rt tilfelle — hvis executorsene dine ikke gjĂžr noe i lĂžpet av to minutter, vennligst returner dem til den felles puljen. Men denne parameteren var ikke alltid tilstrekkelig. Det var tydelig at en person ikke gjorde noe pĂ„ lenge, men ressursene ble ikke frigjort. Det viste seg at det fantes en spesialparameter — hvor lenge det skulle gĂ„ fĂžr man tok tilbake executors som inneholdt bufrede data. Som standard sto denne parameteren pĂ„ — uendelig! Vi har justert den.

spark.dynamicAllocation.cachedExecutorIdleTimeout=600s

Det vil si, hvis executorsene dine ikke gjĂžr noe i lĂžpet av 5 minutter, returner dem til den felles puljen. I dette moduset ble hastigheten pĂ„ frigjĂžring og utlevering av ressurser til mange brukere tilfredsstillende. Antallet misfornĂžyde personer ble redusert. Men vi bestemte oss for Ă„ gĂ„ videre og begrense det maksimale antallet executors for Ă©n applikasjon — i prinsippet for Ă©n deltaker i programmet.

spark.dynamicAllocation.maxExecutors=19

NĂ„, selvsagt, har det dukket opp misfornĂžyde fra en annen side — “klusteret stĂ„r stille, og jeg har bare 19 executors”, men hva skal man gjĂžre — vi trenger en riktig balanse. Å gjĂžre alle glade vil ikke vĂŠre mulig.

Og en liten historie knyttet til spesifisiteten i vĂ„rt tilfelle. Noen personer kom for sent til praktisk undervisning, og Spark startet ikke av en eller annen grunn. Vi sĂ„ pĂ„ antallet frie ressurser — det sĂ„ ut til at det var nok. Spark burde starte. Heldigvis, pĂ„ det tidspunktet, hadde dokumentasjonen allerede festet seg i hukommelsen vĂ„r, og vi husket at nĂ„r Spark starter, leter det etter en port Ă„ starte pĂ„. Hvis den fĂžrste porten i omrĂ„det er opptatt, gĂ„r det videre til neste i rekken. Hvis den er ledig, tar det tak i den. Og det finnes en parameter som angir det maksimale antallet forsĂžk for dette. Som standard — er det 16. Tallet er mindre enn antallet personer i gruppen vĂ„r pĂ„ undervisningen. Dermed, etter 16 forsĂžk, ga Spark opp og sa at det ikke kunne starte. Vi har justert denne parameteren.

spark.port.maxRetries=50

Videre vil jeg fortelle om noen innstillinger som ikke er sÄ sterkt knyttet til spesifisiteten i vÄrt tilfelle.

For raskere oppstart av Spark er det anbefalt Ä komprimere mappen jars, som ligger i hjemmemappen SPARK_HOME, og legge den pÄ HDFS. Da vil den ikke bruke tid pÄ Ä laste ned disse jar-filene til arbeiderne.

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

For faster performance, it is also recommended to use Kryo as the serializer. It is more optimized than the default one.

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

There is also a long-standing problem with Spark that it often crashes due to memory issues. This frequently happens when workers have computed everything and send the result to the driver. We increased this parameter for ourselves. By default, it is 1GB, we made it 3.

spark.driver.maxResultSize=3072

Lastly, as a bonus. How to upgrade Spark to version 2.1 on the HortonWorks distribution — HDP 2.5.3.0. This HDP version contains a pre-installed version 2.0, but we once decided that Spark is actively developing, and each new version fixes certain bugs and adds additional capabilities, including for the Python API, so we decided it was time for an update.

We downloaded the version from the official website for Hadoop 2.7. Unzipped it, placed it in the HDP folder. We created symlinks as needed. We try to run it — it doesn't start. It gives a very unclear error.

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

After googling, we found out that Spark decided not to wait for Hadoop and opted to use a new version of Jersey. They are arguing about this matter in JIRA. The solution was to download Jersey version 1.17.1. Place it in the jars folder in SPARK_HOME, zip it again, and upload it to HDFS.

We bypassed this error, but a new one appeared that was quite vague.

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

At the same time, we tried running version 2.0 — everything is fine. Try to guess what the issue is. We looked into the logs of this application and saw something like:

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

In general, for some reason hdp.version was not resolved. After googling, we found a solution. We need to go into Ambari settings for YARN and add this parameter in custom yarn-site:

hdp.version=2.5.3.0-37

This magic worked, and Spark took off. We tested several of our Jupyter notebooks. Everything works. We are ready for the first Spark class on Saturday (already tomorrow)!

UPD. During the class, another problem emerged. At some point, YARN stopped issuing containers for Spark. We needed to adjust the parameter in YARN, which by default was set to 0.2:

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

Det vil si at bare 20 % av ressursene deltok i distribusjonen av ressursene. Ved Ä endre parameterne ble YARN omstartet. Problemet ble lÞst, og de andre deltakerne kunne ogsÄ starte spark-konteksten.

Kilde: habr.com

KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere đŸ”„ KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere | ProHoster