Habr, hej! IgĂ„r pĂ„ , frĂ„n killarna frĂ„n Rambler&Co, det var ganska mĂ„nga frĂ„gor frĂ„n deltagare relaterade till konfigurering av det hĂ€r verktyget. Vi bestĂ€mde oss för att följa i hans fotspĂ„r och dela vĂ„r erfarenhet. Ămnet Ă€r inte lĂ€tt - sĂ„ vi inbjuder dig att dela din upplevelse i kommentarerna, kanske vi ocksĂ„ förstĂ„r och anvĂ€nder nĂ„got fel.
En liten introduktion till hur vi anvÀnder Spark. Vi har ett tre mÄnaders program , och under den andra modulen arbetar vÄra deltagare med detta instrument. VÄr uppgift som arrangörer Àr dÀrför att förbereda klustret för anvÀndning i ett sÄdant fall.
Det speciella med vÄr anvÀndning Àr att antalet personer som samtidigt arbetar pÄ Spark kan vara lika med hela gruppen. Till exempel pÄ ett seminarium, nÀr alla provar nÄgot samtidigt och upprepar efter vÄr lÀrare. Och det hÀr Àr inte mycket - ibland upp till 40 personer. Det finns förmodligen inte mÄnga företag i vÀrlden som stÄr inför ett sÄdant anvÀndningsfall.
DÀrefter kommer jag att berÀtta hur och varför vi valde vissa konfigurationsparametrar.
LÄt oss börja frÄn början. Spark har 3 alternativ att köra pÄ ett kluster: fristÄende, med Mesos och med GARN. Vi bestÀmde oss för att vÀlja det tredje alternativet eftersom det var vettigt för oss. Vi har redan ett hadoop-kluster. VÄra deltagare Àr redan vÀl bekanta med dess arkitektur. LÄt oss anvÀnda GARN.
spark.master=yarnMer intressant. Vart och ett av dessa tre distributionsalternativ har tvÄ distributionsalternativ: klient och kluster. Baserad och olika lÀnkar pÄ Internet, kan vi dra slutsatsen att klienten Àr lÀmplig för interaktivt arbete - till exempel genom Jupyter anteckningsbok, och kluster Àr mer lÀmpad för produktionslösningar. I vÄrt fall var vi intresserade av interaktivt arbete, dÀrför:
spark.deploy-mode=clientI allmÀnhet, frÄn och med nu kommer Spark pÄ nÄgot sÀtt att fungera pÄ YARN, men detta rÀckte inte för oss. Eftersom vi har ett program om big data har deltagarna ibland inte rÀckt till med det som erhÄllits inom ramen för en jÀmn resursdelning. Och sÄ hittade vi en intressant sak - dynamisk resursallokering. Kort sagt, poÀngen Àr denna: om du har en svÄr uppgift och klustret Àr ledigt (till exempel pÄ morgonen), kan det hÀr alternativet Spark ge dig ytterligare resurser. DÀr berÀknas nödvÀndigheten enligt en listig formel. Vi gÄr inte in pÄ detaljer - det fungerar bra.
spark.dynamicAllocation.enabled=trueVi stÀllde in den hÀr parametern och vid start kraschade Spark och startade inte. Det stÀmmer, för jag var tvungen att lÀsa den mer försiktigt. Det stÄr att för att allt ska vara ok mÄste du Àven aktivera en extra parameter.
spark.shuffle.service.enabled=trueVarför behövs det? NÀr vÄrt jobb inte lÀngre krÀver sÄ mycket resurser bör Spark lÀmna tillbaka dem till den gemensamma poolen. Det mest tidskrÀvande steget i nÀstan alla MapReduce-uppgifter Àr Shuffle-steget. Denna parameter lÄter dig spara data som genereras i detta skede och slÀppa exekutorerna i enlighet dÀrmed. Och exekutören Àr processen som berÀknar allt pÄ arbetaren. Den har ett visst antal processorkÀrnor och en viss mÀngd minne.
Denna parameter har lagts till. Allt verkade fungera. Det blev mÀrkbart att deltagarna faktiskt fick mer resurser nÀr de behövde dem. Men ett annat problem uppstod - vid nÄgot tillfÀlle vaknade andra deltagare och ville ocksÄ anvÀnda Spark, men allt var upptaget dÀr, och de var missnöjda. De kan förstÄs. Vi började titta pÄ dokumentationen. Det visade sig att det finns en rad andra parametrar som kan anvÀndas för att pÄverka processen. Till exempel, om executorn Àr i standby-lÀge, efter vilken tid kan resurser tas frÄn den?
spark.dynamicAllocation.executorIdleTimeout=120sI vÄrt fall, om dina exekutorer inte gör nÄgot under tvÄ minuter, vÀnligen lÀmna tillbaka dem till den gemensamma poolen. Men denna parameter var inte alltid tillrÀcklig. Det var tydligt att personen inte gjort nÄgot pÄ lÀnge och resurser frigjordes inte. Det visade sig att det ocksÄ finns en speciell parameter - efter vilken tid ska man vÀlja exekutorer som innehÄller cachad data. Som standard var denna parameter oÀndlig! Vi rÀttade till det.
spark.dynamicAllocation.cachedExecutorIdleTimeout=600sDet vill sÀga, om dina exekutorer inte gör nÄgot pÄ 5 minuter, ge dem till den gemensamma poolen. I det hÀr lÀget har hastigheten för att slÀppa och utfÀrda resurser för ett stort antal anvÀndare blivit anstÀndig. MÀngden missnöje har minskat. Men vi bestÀmde oss för att gÄ lÀngre och begrÀnsa det maximala antalet exekutörer per ansökan - i huvudsak per programdeltagare.
spark.dynamicAllocation.maxExecutors=19Nu finns det förstÄs missnöjda mÀnniskor pÄ andra sidan - "klustret Àr inaktivt, och jag har bara 19 exekutörer", men vad kan du göra? Vi behöver nÄgon form av korrekt balans. Man kan inte göra alla glada.
Och ytterligare en liten historia relaterad till detaljerna i vĂ„rt fall. PĂ„ nĂ„got sĂ€tt var flera personer försenade till en praktisk lektion, och av nĂ„gon anledning startade inte Spark för dem. Vi tittade pĂ„ mĂ€ngden gratisresurser â det verkar finnas dĂ€r. Gnistan ska starta. Lyckligtvis hade dokumentationen redan lagts till underbarken nĂ„gonstans vid den tiden, och vi kom ihĂ„g att nĂ€r Spark lanserades letar Spark efter en port att börja pĂ„. Om den första porten i omrĂ„det Ă€r upptagen, flyttas den till nĂ€sta i ordning. Om det Ă€r gratis, fĂ„ngar det. Och det finns en parameter som anger det maximala antalet försök för detta. Standard Ă€r 16. Antalet Ă€r mindre Ă€n antalet personer i vĂ„r grupp i klassen. Följaktligen, efter 16 försök, gav Spark upp och sa att jag inte kunde starta. Vi har korrigerat denna instĂ€llning.
spark.port.maxRetries=50DÀrefter ska jag berÀtta om nÄgra instÀllningar som inte Àr sÀrskilt relaterade till detaljerna i vÄrt fall.
För att starta Spark snabbare rekommenderas det att arkivera jars-mappen som finns i SPARK_HOME-hemkatalogen och lÀgga den pÄ HDFS. DÄ kommer han inte att slösa tid pÄ att lasta dessa jarniks av arbetare.
spark.yarn.archive=hdfs:///tmp/spark-archive.zipDet rekommenderas ocksÄ att anvÀnda kryo som en serialiserare för snabbare drift. Den Àr mer optimerad Àn standarden.
spark.serializer=org.apache.spark.serializer.KryoSerializerOch det finns ocksÄ ett lÄngvarigt problem med Spark att den ofta kraschar frÄn minnet. Ofta hÀnder detta i det ögonblick dÄ arbetarna har rÀknat ut allt och skickar resultatet till föraren. Vi gjorde denna parameter större för oss sjÀlva. Som standard Àr det 1 GB, vi gjorde det till 3.
spark.driver.maxResultSize=3072Och sist, som efterrÀtt. Hur man uppdaterar Spark till version 2.1 pÄ HortonWorks-distribution - HDP 2.5.3.0. Den hÀr versionen av HDP innehÄller en förinstallerad version 2.0, men vi bestÀmde oss en gÄng för oss sjÀlva att Spark utvecklas ganska aktivt, och varje ny version fixar nÄgra buggar plus ger ytterligare funktioner, inklusive för python API, sÄ vi bestÀmde oss för vad som mÄste göras Àr en uppdatering.
Laddade ner versionen frÄn den officiella webbplatsen för Hadoop 2.7. Packade upp den och lade den i HDP-mappen. Vi installerade symbollÀnkarna efter behov. Vi lanserar den - den startar inte. Skriver ett vÀldigt konstigt fel.
java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfigEfter att ha googlat fick vi reda pÄ att Spark bestÀmde sig för att inte vÀnta tills Hadoop föddes, och bestÀmde oss för att anvÀnda den nya versionen av jersey. De argumenterar sjÀlva med varandra om detta Àmne i JIRA. Lösningen var att ladda ner . Placera detta i jars-mappen i SPARK_HOME, zippa det igen och ladda upp det till HDFS.
Vi kom runt det hÀr felet, men ett nytt och ganska strömlinjeformat uppstod.
org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch application masterSamtidigt försöker vi köra version 2.0 â allt Ă€r ok. Försök gissa vad som hĂ€nder. Vi tittade i loggarna för denna applikation och sĂ„g nĂ„got i stil med detta:
/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jarI allmÀnhet löste sig inte hdp.version av nÄgon anledning. Efter att ha googlat hittade vi en lösning. Du mÄste gÄ till GARN-instÀllningarna i Ambari och lÀgga till en parameter dÀr till anpassad garnsida:
hdp.version=2.5.3.0-37Denna magi hjÀlpte, och Spark tog fart. Vi testade flera av vÄra Jupyter bÀrbara datorer. Allt fungerar. Vi Àr redo för första Spark-lektionen pÄ lördag (imorgon)!
UPD. Under lektionen kom ett annat problem upp. Vid nÄgot tillfÀlle slutade YARN att tillhandahÄlla containrar till Spark. I YARN var det nödvÀndigt att korrigera parametern, som som standard var 0.2:
yarn.scheduler.capacity.maximum-am-resource-percent=0.8 Det vill sÀga att endast 20 % av resurserna deltog i resursfördelningen. Efter att ha Àndrat parametrarna laddade vi om GARN. Problemet löstes och resten av deltagarna kunde ocksÄ köra sparkkontext.
KĂ€lla: will.com
