Konfigurimi i Spark në YARN

Habr, përshëndetje! Dje në takim kushtuar Apache Spark, nga djemtë nga Rambler&Co, kishte mjaft pyetje nga pjesëmarrësit në lidhje me konfigurimin e këtij mjeti. Ne vendosëm të ndjekim hapat e tij dhe të ndajmë përvojën tonë. Tema nuk është e lehtë - prandaj ju ftojmë të ndani përvojën tuaj në komente, ndoshta edhe ne kuptojmë dhe përdorim diçka të gabuar.

Një hyrje e vogël se si e përdorim Spark. Kemi një program tre mujor "Specialist i të dhënave të mëdha", dhe gjatë modulit të dytë pjesëmarrësit tanë punojnë në këtë instrument. Prandaj, detyra jonë, si organizatorë, është të përgatisim grupin për përdorim në një rast të tillë.

E veçanta e përdorimit tonë është se numri i njerëzve që punojnë njëkohësisht në Spark mund të jetë i barabartë me të gjithë grupin. Për shembull, në një seminar, kur të gjithë provojnë diçka në të njëjtën kohë dhe përsërisin pas mësuesit tonë. Dhe kjo nuk është shumë - ndonjëherë deri në 40 persona. Ndoshta nuk ka shumë kompani në botë që përballen me një rast të tillë përdorimi.

Tjetra, unë do t'ju tregoj se si dhe pse kemi zgjedhur disa parametra të konfigurimit.

Le të fillojmë nga fillimi. Spark ka 3 opsione për të ekzekutuar në një grup: i pavarur, duke përdorur Mesos dhe duke përdorur YARN. Ne vendosëm të zgjidhnim opsionin e tretë sepse na kishte kuptim. Ne tashmë kemi një grup hadoop. Pjesëmarrësit tanë tashmë e njohin mirë arkitekturën e saj. Le të përdorim fije.

spark.master=yarn

Më tej më interesante. Secila prej këtyre 3 opsioneve të vendosjes ka 2 opsione vendosjeje: klient dhe grup. I bazuar dokumentacionin dhe lidhje të ndryshme në internet, mund të konkludojmë se klienti është i përshtatshëm për punë interaktive - për shembull, përmes fletores jupyter, dhe grupi është më i përshtatshëm për zgjidhje prodhimi. Në rastin tonë, ne ishim të interesuar për punë interaktive, prandaj:

spark.deploy-mode=client

Në përgjithësi, tani e tutje Spark do të punojë disi në YARN, por kjo nuk ishte e mjaftueshme për ne. Meqenëse ne kemi një program për të dhëna të mëdha, ndonjëherë pjesëmarrësit nuk kishin mjaftueshëm nga ato që u morën në kuadrin e një ndarjeje të barabartë të burimeve. Dhe pastaj gjetëm një gjë interesante - shpërndarjen dinamike të burimeve. Me pak fjalë, çështja është kjo: nëse keni një detyrë të vështirë dhe grupi është i lirë (për shembull, në mëngjes), atëherë përdorimi i këtij opsioni Spark mund t'ju japë burime shtesë. Aty llogaritet nevoja sipas një formule dinake. Ne nuk do të hyjmë në detaje - funksionon mirë.

spark.dynamicAllocation.enabled=true

Ne vendosëm këtë parametër dhe pas fillimit, Spark u rrëzua dhe nuk filloi. Ashtu është, sepse duhej ta lexoja dokumentacionin më me kujdes. Ai thotë se në mënyrë që gjithçka të jetë në rregull, duhet të aktivizoni edhe një parametër shtesë.

spark.shuffle.service.enabled=true

Pse është e nevojshme? Kur puna jonë nuk kërkon më kaq shumë burime, Shkëndija duhet t'i kthejë ato në pishinën e përbashkët. Faza që kërkon më shumë kohë në pothuajse çdo detyrë MapReduce është faza Shuffle. Ky parametër ju lejon të ruani të dhënat që krijohen në këtë fazë dhe të lëshoni ekzekutuesit në përputhje me rrethanat. Dhe ekzekutuesi është procesi që llogarit gjithçka mbi punëtorin. Ka një numër të caktuar bërthamash procesori dhe një sasi të caktuar memorie.

Ky parametër është shtuar. Gjithçka dukej se funksiononte. U bë e dukshme që pjesëmarrësve në fakt iu dhanë më shumë burime kur kishin nevojë për to. Por u shfaq një problem tjetër - në një moment pjesëmarrësit e tjerë u zgjuan dhe gjithashtu donin të përdornin Spark, por gjithçka ishte e zënë atje dhe ata ishin të pakënaqur. Ato mund të kuptohen. Filluam të shikojmë dokumentacionin. Doli se ka një sërë parametrash të tjerë që mund të përdoren për të ndikuar në proces. Për shembull, nëse ekzekutuesi është në modalitetin e gatishmërisë, pas çfarë kohe mund të merren burimet prej tij?

spark.dynamicAllocation.executorIdleTimeout=120s

Në rastin tonë, nëse ekzekutuesit tuaj nuk bëjnë asgjë për dy minuta, atëherë ju lutemi kthejini ata në pishinën e përbashkët. Por ky parametër nuk ishte gjithmonë i mjaftueshëm. Ishte e qartë se personi nuk kishte bërë asgjë për një kohë të gjatë dhe burimet nuk po liroheshin. Doli se ekziston edhe një parametër i veçantë - pas çfarë kohe për të zgjedhur ekzekutuesit që përmbajnë të dhëna të memorizuara. Si parazgjedhje, ky parametër ishte pafundësi! E korrigjuam.

spark.dynamicAllocation.cachedExecutorIdleTimeout=600s

Kjo do të thotë, nëse ekzekutuesit tuaj nuk bëjnë asgjë për 5 minuta, jepini ato në pishinën e përbashkët. Në këtë mënyrë, shpejtësia e lëshimit dhe lëshimit të burimeve për një numër të madh përdoruesish është bërë e mirë. Sasia e pakënaqësisë është ulur. Por ne vendosëm të shkojmë më tej dhe të kufizojmë numrin maksimal të ekzekutuesve për aplikim - në thelb për pjesëmarrës të programit.

spark.dynamicAllocation.maxExecutors=19

Tani, natyrisht, ka njerëz të pakënaqur në anën tjetër - "grupi është i papunë, dhe unë kam vetëm 19 ekzekutues", por çfarë mund të bëni ju? Ne kemi nevojë për një lloj ekuilibri të saktë. Ju nuk mund t'i bëni të gjithë të lumtur.

Dhe një histori tjetër e vogël që lidhet me specifikat e rastit tonë. Disi, disa njerëz u vonuan për një mësim praktik dhe për disa arsye Shkëndija nuk filloi për ta. Ne shikuam sasinë e burimeve falas - duket se është atje. Shkëndija duhet të fillojë. Për fat të mirë, deri në atë kohë dokumentacioni ishte shtuar tashmë në nënkorteks diku, dhe ne kujtuam se kur nisim Spark, ai kërkon një port nga i cili të fillojë. Nëse porta e parë në gamë është e zënë, ajo kalon në tjetrën sipas renditjes. Nëse është falas, kap. Dhe ekziston një parametër që tregon numrin maksimal të përpjekjeve për këtë. Parazgjedhja është 16. Numri është më i vogël se numri i njerëzve në grupin tonë në klasë. Prandaj, pas 16 përpjekjesh, Spark hoqi dorë dhe tha që nuk mund të filloja. Ne e kemi korrigjuar këtë parametër.

spark.port.maxRetries=50

Më pas do t'ju tregoj për disa cilësime që nuk janë shumë të lidhura me specifikat e rastit tonë.

Për të nisur më shpejt Spark, rekomandohet të arkivoni dosjen e kavanozëve që ndodhet në drejtorinë kryesore SPARK_HOME dhe ta vendosni në HDFS. Atëherë ai nuk do të humbasë kohë duke i ngarkuar këto jarnik nga punëtorët.

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

Rekomandohet gjithashtu përdorimi i kryo si serializues për funksionim më të shpejtë. Është më i optimizuar se ai i paracaktuar.

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

Dhe ka gjithashtu një problem të gjatë me Spark që shpesh rrëzohet nga kujtesa. Shpesh kjo ndodh në momentin kur punëtorët kanë llogaritur gjithçka dhe ia dërgojnë rezultatin shoferit. Ne e bëmë këtë parametër më të madh për veten tonë. Si parazgjedhje, është 1 GB, ne e bëmë atë 3.

spark.driver.maxResultSize=3072

Dhe së fundi, si ëmbëlsirë. Si të përditësoni Spark në versionin 2.1 në shpërndarjen HortonWorks - HDP 2.5.3.0. Ky version i HDP përmban një version të para-instaluar 2.0, por ne dikur vendosëm vetë që Spark po zhvillohet mjaft aktivisht dhe çdo version i ri rregullon disa gabime plus ofron veçori shtesë, duke përfshirë për API-në e python, kështu që vendosëm se çfarë duhet të të bëhet është një përditësim.

U shkarkua versioni nga faqja zyrtare e internetit për Hadoop 2.7. Zhbllokoni atë dhe vendoseni në dosjen HDP. Ne instaluam simbolet sipas nevojës. Ne e nisim atë - nuk fillon. Shkruan një gabim shumë të çuditshëm.

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

Pasi kërkuam, zbuluam se Spark vendosi të mos priste derisa të lindte Hadoop dhe vendosi të përdorte versionin e ri të fanellës. Ata vetë debatojnë me njëri-tjetrin për këtë temë në JIRA. Zgjidhja ishte shkarkimi jersey version 1.17.1. Vendoseni këtë në dosjen kavanoza në SPARK_HOME, vendoseni sërish në zip dhe ngarkojeni në HDFS.

Ne e shmangëm këtë gabim, por u shfaq një i ri dhe mjaft i thjeshtë.

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

Në të njëjtën kohë, ne përpiqemi të ekzekutojmë versionin 2.0 - gjithçka është në rregull. Mundohuni të merrni me mend se çfarë po ndodh. Ne shikuam regjistrat e këtij aplikacioni dhe pamë diçka të tillë:

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

Në përgjithësi, për disa arsye versioni hdp. nuk u zgjidh. Pasi kërkuam, gjetëm një zgjidhje. Duhet të shkoni te cilësimet e YARN në Ambari dhe të shtoni një parametër atje në faqen e personalizuar të fijeve:

hdp.version=2.5.3.0-37

Kjo magji ndihmoi dhe Shkëndija u ngrit. Ne testuam disa nga laptopët tanë jupyter. Gjithçka po funksionon. Jemi gati për mësimin e parë të Shkëndijës të shtunën (nesër)!

DUP. Gjatë mësimit doli në pah një problem tjetër. Në një moment, YARN ndaloi së ofruari kontejnerë për Spark. Në YARN ishte e nevojshme të korrigjohej parametri, i cili si parazgjedhje ishte 0.2:

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

Kjo do të thotë, vetëm 20% e burimeve morën pjesë në shpërndarjen e burimeve. Pas ndryshimit të parametrave, ringarkuam YARN. Problemi u zgjidh dhe pjesa tjetër e pjesëmarrësve ishin gjithashtu në gjendje të drejtonin kontekstin e shkëndijës.

Burimi: www.habr.com

Shto një koment