Habr, tere! Eile edasi , Rambler&Co kuttidelt oli osalejatelt päris palju küsimusi seoses selle tööriista seadistamisega. Otsustasime tema jälgedes käia ja oma kogemusi jagada. Teema pole lihtne - seega kutsume teid oma kogemusi kommentaarides jagama, ehk saame ka millestki aru ja kasutame valesti.
Väike sissejuhatus, kuidas me Sparki kasutame. Meil on kolmekuuline programm ja kogu teise mooduli jooksul töötavad meie osalejad selle instrumendi kallal. Sellest tulenevalt on meie kui korraldajate ülesanne valmistada klaster ette sellisel juhul kasutamiseks.
Meie kasutuse eripära on see, et Sparkis samaaegselt töötavate inimeste arv võib olla võrdne kogu grupiga. Näiteks seminaril, kui kõik proovivad midagi korraga ja kordavad meie õpetaja järel. Ja seda pole palju - mõnikord kuni 40 inimest. Tõenäoliselt pole maailmas palju ettevõtteid, kes sellise kasutusjuhtumiga silmitsi seisavad.
Järgmisena räägin teile, kuidas ja miks me valisime teatud konfiguratsiooniparameetrid.
Alustame päris algusest. Sparkil on klastris käitamiseks kolm võimalust: eraldiseisev, Mesos ja YARN. Otsustasime valida kolmanda variandi, kuna see oli meie jaoks mõistlik. Meil on juba hadoop-klaster. Meie osalejad on selle arhitektuuriga juba hästi kursis. Kasutame LÕNGA.
spark.master=yarnVeelgi huvitavam. Kõigil nendel kolmel juurutussuvandil on kaks juurutusvalikut: klient ja klaster. Põhineb ja erinevaid linke Internetis, võime järeldada, et klient sobib interaktiivseks tööks - näiteks jupyteri sülearvuti kaudu ja klaster sobib rohkem tootmislahendusteks. Meie puhul olime huvitatud interaktiivsest tööst, seetõttu:
spark.deploy-mode=clientÜldiselt töötab Spark nüüdsest kuidagi LÕNGA peal, kuid sellest meile ei piisanud. Kuna meie programm räägib suurandmetest, siis vahel ei piisanud osalejatele sellest, mis ressursside ühtlase jaotamise raames saadi. Ja siis leidsime huvitava asja – dünaamilise ressursside jaotamise. Lühidalt on asja mõte järgmine: kui sul on raske ülesanne ja klaster on vaba (näiteks hommikul), siis selle valiku kasutamine võib Spark anda sulle lisaressursse. Vajadust arvutatakse seal kavala valemi järgi. Me ei lasku detailidesse – see toimib hästi.
spark.dynamicAllocation.enabled=trueSeadistasime selle parameetri ja käivitamisel kukkus Spark kokku ja ei käivitunud. See oli õige, sest ma pidin seda lugema hoolikamalt. See ütleb, et selleks, et kõik oleks korras, peate lubama ka lisaparameetri.
spark.shuffle.service.enabled=trueMiks seda vaja on? Kui meie töö enam nii palju ressursse ei nõua, peaks Spark need ühisvaramusse tagasi viima. Peaaegu iga MapReduce'i ülesande kõige aeganõudvam etapp on segamise etapp. See parameeter võimaldab salvestada selles etapis genereeritud andmed ja vabastada vastavalt täitjad. Ja täitja on protsess, mis arvutab kõik töötaja pealt välja. Sellel on teatud arv protsessorituumasid ja teatud hulk mälu.
See parameeter on lisatud. Kõik näis toimivat. Sai märgata, et osalejatele anti tegelikult rohkem ressursse, kui nad neid vajasid. Tekkis aga veel üks probleem – mingi hetk ärkasid teised osalejad üles ja tahtsid ka Sparki kasutada, aga seal oli kõik kinni ja nad olid õnnetud. Neid saab mõista. Hakkasime dokumente vaatama. Selgus, et on mitmeid muid parameetreid, mille abil saab protsessi mõjutada. Näiteks kui täitja on ooterežiimis, siis mis aja möödudes saab sealt ressursse võtta?
spark.dynamicAllocation.executorIdleTimeout=120sMeie puhul, kui teie käsutäitjad kahe minuti jooksul midagi ei tee, siis palun tagastage nad ühisbasseini. Kuid sellest parameetrist ei piisanud alati. Oli selge, et inimene polnud pikka aega midagi teinud ja ressursse ei vabanenud. Selgus, et on ka spetsiaalne parameeter - mis aja pärast valida vahemällu salvestatud andmeid sisaldavad täitjad. Vaikimisi oli see parameeter lõpmatus! Parandasime ära.
spark.dynamicAllocation.cachedExecutorIdleTimeout=600sSee tähendab, et kui teie käsutäitjad 5 minuti jooksul midagi ei tee, andke nad ühiskasutusse. Selles režiimis on suure hulga kasutajate jaoks ressursside vabastamise ja väljastamise kiirus muutunud korralikuks. Rahulolematuse hulk on vähenenud. Kuid otsustasime minna kaugemale ja piirata maksimaalset täitjate arvu rakenduse kohta – sisuliselt programmis osaleja kohta.
spark.dynamicAllocation.maxExecutors=19Nüüd on muidugi teisel pool rahulolematuid - "klaster on jõude ja mul on ainult 19 täitjat," aga mis teha? Vajame mingit õiget tasakaalu. Kõiki ei saa õnnelikuks teha.
Ja veel üks väike lugu, mis on seotud meie juhtumi spetsiifikaga. Millegipärast jäid mitmed inimesed praktilisse tundi hiljaks ja millegipärast Spark nende jaoks ei startinud. Vaatasime vabade vahendite hulka – tundub, et see on olemas. Spark peaks algama. Õnneks oli selleks ajaks dokumentatsioon juba kuhugi alamkorteksisse lisatud ja meenus, et Sparki käivitades otsib ta pordi, millelt alustada. Kui vahemiku esimene port on hõivatud, liigub see järjekorras järgmisele. Kui see on tasuta, siis see jäädvustab. Ja seal on parameeter, mis näitab selle katsete maksimaalset arvu. Vaikimisi on 16. Arv on väiksem kui meie rühma inimeste arv klassis. Seetõttu loobus Spark pärast 16 katset ja ütles, et ma ei saa alustada. Oleme seda parameetrit parandanud.
spark.port.maxRetries=50Järgmisena räägin teile mõnest seadest, mis pole meie juhtumi spetsiifikaga eriti seotud.
Sparki kiiremaks käivitamiseks on soovitatav arhiveerida SPARK_HOME kodukataloogis asuv kaust jars ja panna see HDFS-i. Siis ta ei raiska aega nende jarnikute laadimisele tööliste poolt.
spark.yarn.archive=hdfs:///tmp/spark-archive.zipSamuti on kiiremaks töötamiseks soovitatav kasutada kryot serialisaatorina. See on optimeeritud kui vaikeseade.
spark.serializer=org.apache.spark.serializer.KryoSerializerJa Sparkiga on ka pikaajaline probleem, et see jookseb sageli mälust kokku. Tihti juhtub see hetkel, kui töötajad on kõik välja arvutanud ja tulemuse juhile saatnud. Tegime selle parameetri enda jaoks suuremaks. Vaikimisi on see 1 GB, me tegime selle 3.
spark.driver.maxResultSize=3072Ja lõpuks magustoiduna. Kuidas värskendada Sparki versioonile 2.1 HortonWorksi distributsioonis – HDP 2.5.3.0. See HDP versioon sisaldab eelinstallitud versiooni 2.0, kuid otsustasime kunagi ise, et Spark areneb üsna aktiivselt ja iga uus versioon parandab mõned vead, lisaks pakub lisafunktsioone, sealhulgas pythoni API jaoks, nii et otsustasime, mida on vaja tehtud on uuendus.
Laaditi alla versioon Hadoop 2.7 ametlikult veebisaidilt. Pakkige see lahti ja asetage HDP kausta. Paigaldasime sümbolid vastavalt vajadusele. Käivitame selle – see ei käivitu. Kirjutab väga kummalise vea.
java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfigPärast guugeldamist saime teada, et Spark otsustas Hadoopi sündimist mitte oodata ja otsustas kasutada särgi uut versiooni. Nad ise vaidlevad JIRAS sel teemal omavahel. Lahendus oli allalaadimine . Asetage see SPARK_HOME purkide kausta, pakkige see uuesti kokku ja laadige HDFS-i üles.
Saime sellest veast mööda, kuid tekkis uus ja üsna sujuvam.
org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch application masterSamal ajal proovime käivitada versiooni 2.0 - kõik on ok. Proovige arvata, mis toimub. Vaatasime selle rakenduse logisid ja nägime midagi sellist:
/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jarÜldiselt millegipärast hdp.version ei lahenenud. Peale guugeldamist leidsime lahenduse. Peate minema Ambaris LÕNGA seadetesse ja lisama seal kohandatud lõnga saidile parameetri:
hdp.version=2.5.3.0-37See maagia aitas ja Spark tõusis õhku. Testisime mitmeid oma jupyteri sülearvuteid. Kõik töötab. Oleme laupäeval (homme) esimeseks Sparki tunniks valmis!
DUP. Tunnis tuli ilmsiks veel üks probleem. Mingil hetkel lõpetas YARN Sparkile konteinerite pakkumise. YARNis oli vaja parandada parameetrit, mis vaikimisi oli 0.2:
yarn.scheduler.capacity.maximum-am-resource-percent=0.8
See tähendab, et ainult 20% ressurssidest osales ressursside jagamises. Pärast parameetrite muutmist laadisime LÕNGA uuesti. Probleem lahendati ja ka ülejäänud osalejad said sädekonteksti käivitada.
Allikas: www.habr.com