Habr, hej! I går , fra gutterne fra Rambler&Co, var der en del spørgsmål fra deltagere i forbindelse med konfigurationen af dette værktøj. Vi besluttede at følge i hans fodspor og dele vores erfaringer. Emnet er ikke let - så vi inviterer dig til at dele din oplevelse i kommentarerne, måske forstår og bruger vi også noget forkert.
En lille introduktion til, hvordan vi bruger Spark. Vi har et tre måneders program , og gennem det andet modul arbejder vores deltagere på dette instrument. Det er derfor vores opgave som arrangører at forberede klyngen til brug i en sådan sag.
Det særlige ved vores brug er, at antallet af personer, der samtidig arbejder på Spark, kan være det samme som hele gruppen. For eksempel på et seminar, hvor alle prøver noget på samme tid og gentager efter vores lærer. Og det er ikke meget - nogle gange op til 40 personer. Der er nok ikke mange virksomheder i verden, der står over for sådan en use case.
Dernæst vil jeg fortælle dig, hvordan og hvorfor vi valgte visse konfigurationsparametre.
Lad os starte helt fra begyndelsen. Spark har 3 muligheder for at køre på en klynge: standalone, ved hjælp af Mesos og ved hjælp af YARN. Vi besluttede at vælge den tredje mulighed, fordi det gav mening for os. Vi har allerede en hadoop-klynge. Vores deltagere er allerede godt bekendt med dens arkitektur. Lad os bruge GARN.
spark.master=yarnYderligere mere interessant. Hver af disse 3 implementeringsmuligheder har 2 implementeringsmuligheder: klient og klynge. Baseret og forskellige links på internettet, kan vi konkludere, at klienten er velegnet til interaktivt arbejde - for eksempel gennem jupyter notebook, og cluster er mere velegnet til produktionsløsninger. I vores tilfælde var vi interesserede i interaktivt arbejde, derfor:
spark.deploy-mode=clientGenerelt vil Spark fra nu af på en eller anden måde fungere på YARN, men det var ikke nok for os. Da vi har et program om big data, havde deltagerne nogle gange ikke nok af det opnåede inden for rammerne af en jævn opskæring af ressourcer. Og så fandt vi en interessant ting - dynamisk ressourceallokering. Kort sagt, pointen er dette: Hvis du har en vanskelig opgave, og klyngen er ledig (f.eks. om morgenen), så kan brugen af denne mulighed Spark give dig yderligere ressourcer. Nødvendigheden beregnes dér efter en snedig formel. Vi vil ikke gå i detaljer - det fungerer godt.
spark.dynamicAllocation.enabled=trueVi indstillede denne parameter, og ved opstart styrtede Spark ned og startede ikke. Det er rigtigt, for jeg var nødt til at læse den mere forsigtigt. Der står, at for at alt skal være ok, skal du også aktivere en ekstra parameter.
spark.shuffle.service.enabled=trueHvorfor er det nødvendigt? Når vores job ikke længere kræver så mange ressourcer, bør Spark returnere dem til den fælles pulje. Den mest tidskrævende fase i næsten enhver MapReduce-opgave er Shuffle-fasen. Denne parameter giver dig mulighed for at gemme de data, der genereres på dette trin, og frigive udførerne i overensstemmelse hermed. Og bobestyreren er den proces, der beregner alt på arbejderen. Den har et vist antal processorkerner og en vis mængde hukommelse.
Denne parameter er blevet tilføjet. Alt så ud til at virke. Det blev bemærket, at deltagerne faktisk fik flere ressourcer, når de havde brug for dem. Men et andet problem opstod - på et tidspunkt vågnede andre deltagere og ville også bruge Spark, men der var alt optaget, og de var utilfredse. De kan forstås. Vi begyndte at se på dokumentationen. Det viste sig, at der er en række andre parametre, som kan bruges til at påvirke processen. For eksempel, hvis udføreren er i standby-tilstand, efter hvilken tid kan der tages ressourcer fra den?
spark.dynamicAllocation.executorIdleTimeout=120sI vores tilfælde, hvis dine bobestyrere ikke gør noget i to minutter, så returner dem venligst til den fælles pool. Men denne parameter var ikke altid nok. Det var tydeligt, at personen ikke havde lavet noget i lang tid, og der blev ikke frigivet ressourcer. Det viste sig, at der også er en speciel parameter - efter hvilken tid skal man vælge eksekvere, der indeholder cachelagrede data. Som standard var denne parameter uendelig! Vi rettede det.
spark.dynamicAllocation.cachedExecutorIdleTimeout=600sDet vil sige, at hvis dine bobestyrere ikke gør noget i 5 minutter, så giv dem til fællespuljen. I denne tilstand er hastigheden af frigivelse og udstedelse af ressourcer for et stort antal brugere blevet anstændig. Mængden af utilfredshed er faldet. Men vi besluttede at gå længere og begrænse det maksimale antal eksekvere pr. ansøgning - i det væsentlige pr. programdeltager.
spark.dynamicAllocation.maxExecutors=19Nu er der selvfølgelig utilfredse folk på den anden side - "klyngen er tomgang, og jeg har kun 19 bobestyrere," men hvad kan du gøre? Vi har brug for en form for korrekt balance. Man kan ikke gøre alle glade.
Og endnu en lille historie relateret til de særlige forhold i vores sag. På en eller anden måde kom flere mennesker for sent til en praktisk lektion, og af en eller anden grund startede Spark ikke for dem. Vi kiggede på mængden af gratis ressourcer – det ser ud til at være der. Gnisten skal starte. Heldigvis var dokumentationen allerede på det tidspunkt blevet tilføjet til subcortex et eller andet sted, og vi huskede, at når den blev lanceret, leder Spark efter en port at starte på. Hvis den første port i området er optaget, flyttes den til den næste i rækkefølge. Hvis det er gratis, fanger det. Og der er en parameter, der angiver det maksimale antal forsøg for dette. Standard er 16. Antallet er mindre end antallet af personer i vores gruppe i klassen. Derfor gav Spark efter 16 forsøg op og sagde, at jeg ikke kunne starte. Vi har rettet denne parameter.
spark.port.maxRetries=50Dernæst vil jeg fortælle dig om nogle indstillinger, der ikke er meget relateret til vores sags detaljer.
For at starte Spark hurtigere, anbefales det at arkivere jars-mappen, der er placeret i SPARK_HOME-hjemmemappen, og lægge den på HDFS. Så vil han ikke spilde tid på at laste disse jarniks af arbejdere.
spark.yarn.archive=hdfs:///tmp/spark-archive.zipDet anbefales også at bruge kryo som en serializer for hurtigere drift. Den er mere optimeret end standarden.
spark.serializer=org.apache.spark.serializer.KryoSerializerOg der er også et langvarigt problem med Spark, at det ofte går ned fra hukommelsen. Ofte sker dette i det øjeblik, hvor arbejderne har beregnet alt og sender resultatet til chaufføren. Vi har gjort denne parameter større for os selv. Som standard er det 1 GB, vi lavede det til 3.
spark.driver.maxResultSize=3072Og til sidst som dessert. Sådan opdaterer du Spark til version 2.1 på HortonWorks-distribution - HDP 2.5.3.0. Denne version af HDP indeholder en forudinstalleret version 2.0, men vi besluttede engang for os selv, at Spark udvikler sig ret aktivt, og hver ny version retter nogle fejl plus giver yderligere funktioner, herunder til python API, så vi besluttede, hvad der skal gøres er en opdatering.
Downloadede versionen fra den officielle hjemmeside for Hadoop 2.7. Udpakkede det og lagde det i HDP-mappen. Vi installerede symbolerne efter behov. Vi starter den - den starter ikke. Skriver en meget uklar fejl.
java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfigEfter at have googlet fandt vi ud af, at Spark besluttede ikke at vente til Hadoop blev født, og besluttede at bruge den nye version af jersey. De skændes selv med hinanden om dette emne i JIRA. Løsningen var at downloade . Placer dette i jars-mappen i SPARK_HOME, zip det igen og upload det til HDFS.
Vi kom uden om denne fejl, men en ny og ret strømlinet en opstod.
org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch application masterSamtidig forsøger vi at køre version 2.0 - alt er ok. Prøv at gætte, hvad der foregår. Vi kiggede i logfilerne for denne applikation og så noget som dette:
/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jarGenerelt blev hdp.version af en eller anden grund ikke løst. Efter at have googlet fandt vi en løsning. Du skal gå til GARN-indstillingerne i Ambari og tilføje en parameter der til brugerdefineret garn-site:
hdp.version=2.5.3.0-37Denne magi hjalp, og Spark tog fart. Vi har testet flere af vores Jupyter bærbare computere. Alt fungerer. Vi er klar til den første Spark-lektion på lørdag (i morgen)!
DUP. I løbet af lektionen kom et andet problem frem. På et tidspunkt holdt YARN op med at levere containere til Spark. I YARN var det nødvendigt at rette parameteren, som som standard var 0.2:
yarn.scheduler.capacity.maximum-am-resource-percent=0.8
Det vil sige, at kun 20 % af ressourcerne deltog i ressourcefordelingen. Efter at have ændret parametrene genindlæste vi GARN. Problemet blev løst, og resten af deltagerne kunne også køre gnistkontekst.
Kilde: www.habr.com