Hej Habr! I gĂ„r pĂ„ , var der en del spĂžrgsmĂ„l fra deltagerne, relateret til konfigurationen af dette vĂŠrktĂžj, fra folkene hos Rambler&Co. Vi besluttede at dele vores erfaringer ogsĂ„. Emnet er ikke let â derfor opfordrer vi ogsĂ„ til at dele erfaringer i kommentarerne, mĂ„ske misforstĂ„r vi ogsĂ„ noget eller bruger det forkert.
En lille introduktion â hvordan vi bruger Spark. Vi har et tre-mĂ„neders program , og i hele den anden modul arbejder vores deltagere pĂ„ dette vĂŠrktĂžj. Derfor er vores opgave som arrangĂžrer at forberede et cluster til brug i forbindelse med et sĂ„dant case.
Det sĂŠrlige ved vores brug er, at antallet af personer, der arbejder pĂ„ Spark samtidigt, kan vĂŠre lig med hele gruppen. For eksempel, pĂ„ seminaret, nĂ„r alle samtidigt prĂžver noget og fĂžlger efter vores instruktĂžr. Det er en del mennesker â nogle gange omkring 40. MĂ„ske er der ikke sĂ„ mange virksomheder i verden, der stĂ„r over for et sĂ„dant brugsscenario.
DernĂŠst vil jeg fortĂŠlle, hvordan og hvorfor vi valgte bestemte konfigurationsparametre.
Lad os begynde fra starten. Spark har 3 mÄder at arbejde pÄ et cluster: standalone, ved at bruge Mesos og ved at bruge YARN. Vi valgte den tredje mulighed, fordi den gav mening for os. Vi har allerede et Hadoop-cluster. Vores deltagere er allerede godt bekendt med dets arkitektur. Lad os bruge YARN.
spark.master=yarnHerefter bliver det interessant. Hver af disse 3 distributionsmuligheder har 2 implementeringsmetoder: client og cluster. Baseret pĂ„ og forskellige links pĂ„ internettet, kan vi konkludere, at client er velegnet til interaktivt arbejde â f.eks. gennem jupyter notebook, mens cluster er mere passende til produktionslĂžsninger. I vores tilfĂŠlde var vi interesseret i interaktivt arbejde, derfor:
spark.deploy-mode=clientFra dette Ăžjeblik begynder Spark egentlig allerede at fungere pĂ„ YARN, men det var ikke nok for os. Da vi arbejder med store data, mangler deltagerne nogle gange det, der opnĂ„s ved en jĂŠvn fordeling af ressourcer. Her fandt vi en interessant lĂžsning â dynamisk ressourceallokering. Kort sagt gĂ„r det ud pĂ„, at hvis du har en krĂŠvende opgave og klyngen er ledig (f.eks. om morgenen), kan Spark ved hjĂŠlp af denne indstilling give dig ekstra ressourcer. Behovet beregnes efter en smart formel. Vi gĂ„r ikke i detaljer â den fungerer ganske godt.
spark.dynamicAllocation.enabled=trueVi satte denne parameter, og da vi startede Spark, klagede det og kunne ikke starte. Det var korrekt, fordi vi skulle have lÊst mere omhyggeligt. Der stÄr, at for at alt skal vÊre i orden, er det nÞdvendigt at aktivere en ekstra parameter.
spark.shuffle.service.enabled=trueHvad er den nÞdvendig for? NÄr vores job ikke lÊngere krÊver sÄ mange ressourcer, skal Spark returnere dem til den samlede pulje. Den mest ressourcekrÊvende fase i nÊsten enhver MapReduce-opgave er Shuffle-fasen. Denne parameter gÞr det muligt at gemme data, der genereres i denne fase, og dermed frigÞre eksekutorerne. En eksekutor er en proces, der beregner alt pÄ en worker. Den har et bestemt antal CPU-kerner og en bestemt mÊngde hukommelse.
Vi tilfĂžjede denne parameter. Alt syntes at fungere. Det blev tydeligt, at deltagerne faktisk fik tildelt flere ressourcer, nĂ„r de havde brug for det. Men der opstod et andet problem â pĂ„ et tidspunkt vĂ„gnede de andre deltagere og ville ogsĂ„ bruge Spark, men der var allerede optaget, og de var utilfredse. Man kan forstĂ„ dem. Vi begyndte at kigge i dokumentationen. Der viste sig at vĂŠre et par andre parametre, som kan pĂ„virke processen. For eksempel, hvis eksekutoren er i ventetilstand â efter hvor lang tid kan man tage ressourcerne tilbage?
spark.dynamicAllocation.executorIdleTimeout=120sI vores tilfĂŠlde â hvis dine executors ikke laver noget i lĂžbet af to minutter, skal du venligst returnere dem til den fĂŠlles pulje. Men selv denne parameter var ikke altid tilstrĂŠkkelig. Det kunne ses, at personen ikke havde gjort noget i lang tid, men ressourcerne blev ikke frigivet. Det viste sig, at der ogsĂ„ er en speciel parameter â efter hvor lang tid der skal vĂŠlges executors, der indeholder cachede data. Som standard stod denne parameter pĂ„ â uendelig! Vi har rettet det.
spark.dynamicAllocation.cachedExecutorIdleTimeout=600sSĂ„ hvis dine executors ikke laver noget i lĂžbet af 5 minutter, sĂ„ returner dem til den fĂŠlles pulje. PĂ„ denne mĂ„de er hastigheden for frigivelse og tildeling af ressourcer til et stort antal brugere blevet anstĂŠndig. Antallet af utilfredse er faldet. Men vi besluttede at gĂ„ videre og begrĂŠnse det maksimale antal executors pr. application â i princippet pr. deltager i programmet.
spark.dynamicAllocation.maxExecutors=19Nu er der selvfĂžlgelig utilfredse pĂ„ den anden side â "klassen stĂ„r stille, og jeg har kun 19 executors", men hvad kan man gĂžre â der skal vĂŠre en korrekt balance. Det er ikke muligt at gĂžre alle glade.
Og en lille historie, der er relateret til vores specifikke sag. En dag kom flere personer for sent til praktisk undervisning, og deres Spark startede af en eller anden grund ikke. Vi sĂ„ pĂ„ antallet af ledige ressourcer â der syntes at vĂŠre nok. Spark skulle starte. Heldigvis var dokumentationen allerede et sted gemt i hukommelsen, og vi huskede, at nĂ„r Spark starter, leder den efter en port, den kan starte pĂ„. Hvis den fĂžrste port i omrĂ„det er optaget, gĂ„r den videre til den nĂŠste. Hvis den er ledig, tager den den. Og der er en parameter, der angiver det maksimale antal forsĂžg for dette. Som standard er det 16. Antallet er mindre end folkene i vores gruppe til undervisningen. Derfor efter 16 forsĂžg opgav Spark og sagde, at den ikke kunne starte. Vi har rettet denne parameter.
spark.port.maxRetries=50Lad mig videre fortÊlle om nogle indstillinger, der ikke er sÄ meget relateret til vores specifikke sag.
For hurtigere opstart af Spark anbefales det at zippe mappen jars, der ligger i hjemmemappen SPARK_HOME, og lÊgge den pÄ HDFS. SÄ vil den ikke bruge tid pÄ at indlÊse disse jar-filer pÄ arbejderne.
spark.yarn.archive=hdfs:///tmp/spark-archive.zipFor faster operation, it is also recommended to use Kryo as the serializer. It is more optimized than the default one.
spark.serializer=org.apache.spark.serializer.KryoSerializerThere is also a long-standing problem with Spark, which often crashes due to memory issues. This often happens when the workers have calculated everything and send the result to the driver. We increased this parameter. By default, it is 1GB, we set it to 3.
spark.driver.maxResultSize=3072And lastly, as a dessert. How to upgrade Spark to version 2.1 on the HortonWorks distribution - HDP 2.5.3.0. This HDP version comes with a pre-installed version 2.0, but we once decided that Spark is developing quite actively, and each new version fixes some bugs and adds features, including for the Python API, so we decided to do the update.
We downloaded the version from the official website for Hadoop 2.7. We unpacked it and placed it in the HDP folder. We created the symlinks as needed. When we start it, it doesnât launch. It shows a very unclear error.
java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfigAfter 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 in JIRA. The solution was to download . Place it in the jars folder in SPARK_HOME, zip it again, and upload it to HDFS.
We bypassed this error, but a new and quite vague one arose.
org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch the application master.At the same time, we tried to run version 2.0 â everything was fine. Can you guess what the issue is? We looked into the logs of this application and saw something like this:
/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jarIn general, for some reason, hdp.version did not resolve. After googling, we found the solution. We need to go to Ambari, access the YARN settings, and add the parameter in custom yarn-site:
hdp.version=2.5.3.0-37This magic helped, and Spark took off. We tested several of our Jupyter notebooks. Everything works. We are ready for the first Spark class on Saturday (tomorrow)!
UPD. During the class, another problem arose. At some point, YARN stopped issuing containers for Spark. We had 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 sige, at kun 20 % af ressourcerne deltog i fordelingen af ressourcer. Vi Êndrede indstillingerne og genstartede YARN. Problemet blev lÞst, og de Þvrige deltagere kunne ogsÄ starte spark-kontexten.
Kilde: habr.com
