Sparki seadistamine YARN-il

Tere, Хабр! Eelmine päev toimus mitmik, mis käsitles Apache Sparki, Rambler&Co meestelt, osalejatelt tuli päris palju küsimusi seoses selle tööriista konfigureerimisega. Otsustasime selle põhjal jagada oma kogemusi. Teema on keeruline — seetõttu kutsume jagama oma kogemusi ka kommentaarides, võib-olla me ei mõista ja kasuta ka midagi valesti.

Pisike sissejuhatus — kuidas me Spark'i kasutame. Meil on kolm kuud kestev programm „Suure andmete spetsialist“, ja kogu teises moodulis töötavad meie osalejad selle tööriistaga. Seega on meie ülesanne, kui korraldajatena, ette valmistada klaster selle kasutamiseks sellistes tingimustes.

Meie kasutamise eripära seisneb selles, et spark'iga samaaegselt töötavate inimeste arv võib olla võrdne kogu grupiga. Näiteks seminaril, kui kõik ühiselt midagi proovivad ja kordavad meie õpetaja järgi. Ja see pole sugugi väike — vahel kuni 40 inimest. Ilmselt ei ole maailmas paljusid ettevõtteid, kes sellise kasutusstsenaariumiga silmitsi seisavad.

Järgmine räägin, kuidas ja miks me valisime erinevad konfiguratsiooniparametrid.

Alustame algusest. Sparkil on 3 võimalust töötada klastris: standalone, Mesose abil ja YARNi abil. Otsustasime valida viimase variandi, kuna see oli meie jaoks loogiline. Meil on juba olemas Hadoopi klaster. Meie liikmed on selle arhitektuuriga juba hästi tuttavad. Kasutame YARNi.

spark.master=yarn

Edasi on huvitavam. Igal kolmel disainivõimalusel on kaks jõudlust: client ja cluster. Lähtuvalt dokumentatsioonis ja erinevatest linkidest internetis võib järeldada, et client sobib interaktiivseks tööks — näiteks Jupyteri märkmikus, samas kui cluster sobib paremini tootmislahendustele. Meie puhul huvitas meid interaktiivne töötamine, seega:

spark.deploy-mode=client

Põhimõtteliselt hakkab Spark alates sellest hetkest YARN-is mingil moel tööle, kuid see ei olnud meile piisav. Kuna meil on programm suurte andmete kohta, siis mõnikord ei piisanud osalistest ressursside jaotustest. Siit leidsime huvitava asja — dünaamiline ressursside jaotamine. Lihtsalt öeldes: kui teil on keeruline ülesanne ja klaster on vaba (näiteks hommikul), võib Spark selle võimaluse abil teile lisarekursse anda. Vajaduse arvutamine toimub saladuslikul valemil. Sügavale detailidesse ei lasku — see töötab hästi.

spark.dynamicAllocation.enabled=true

Me seadsime selle parameetri ja kui käivitasime Sparki, nurises ta ja ei käivitanud. Õigesti, sest oli vaja lugeda dokumentatsiooni tähelepanelikumalt. Seal on märgitud, et kõik peab olema korras, peame sisse lülitama ka täiendava parameetri.

spark.shuffle.service.enabled=true

Miks see vajalik on? Kui meie töö lihtsustub ja ei vaja enam nii palju ressursse, peab Spark need tagasi üldisse basseinisse andma. Kõige töömahukam etapp peaaegu igas MapReduce ülesandes on Shuffle etapp. See parameeter võimaldab salvestada andmeid, mis tekivad sellel etapil, ja seega vabastada executoreid. Executor on protsess, mis kõike töötleb töötajas. Tal on teatav arv protsessorituumasid ja teatav kogus mälu.

Lisatud see parameeter. Kõik tundub töötavat. On märgatav, et osalejatele antakse tõeliselt rohkem ressursse, kui neid vajavad. Kuid tekkis teine probleem — mingil hetkel ärkasid teised osalejad ja soovisid samuti Spark'i kasutada, aga kõik oli hõivatud ja nad olid rahulolematud. Nende tundeid on lihtne mõista. Hakkasime dokumentatsiooni uurima. Selgus, et seal on veel mitmeid parameetreid, millega saab protsessile mõju avaldada. Näiteks, kui executor on oote-režiimis — kui kaua võib oodata, kuni ressursid temalt ära võtta?

spark.dynamicAllocation.executorIdleTimeout=120s

Meie puhul, kui teie executors ei tee midagi kahe minuti jooksul, siis palun tagastage need üldsesse puuli. Kuid isegi see parameeter ei olnud alati piisav. Oli näha, et inimene ei ole pikka aega midagi teinud, kuid ressursse ei vabastatud. Selgus, et on olemas veel eriline parameeter — päeva jooksul, kui kaua tohib hoida executors, mis sisaldavad vahemälus andmeid. Vaikimisi oli selle parameetri väärtus — infinity! Me parandasime selle.

spark.dynamicAllocation.cachedExecutorIdleTimeout=600s

See tähendab, et kui 5 minuti jooksul teie executors ei tee midagi, tagastage need üldsesse puuli. Sel viisil on suurte kasutajate arvu jaoks ressursi vabastamise ja jagamise kiirus saanud korralikuks. Rahulolematute arv on vähenenud. Kuid otsustasime minna edasi ja piirata maksimaalset executorside arvu ühe rakenduse kohta — põhimõtteliselt ühe programmi osaleja kohta.

spark.dynamicAllocation.maxExecutors=19

Nüüd on muidugi tekkinud rahulolematud ka teiselt poolt — "kluster seisab, aga mul on ainult 19 executors", aga mis teha — vajalik on leida mingi õige tasakaal. Kõiki õnnelikuks teha ei õnnestu.

Ja veel üks väike lugu, mis on seotud meie juhtumi eripäradega. Ühel korral hilinesid mõned inimesed praktilisele tunnile ning nende Spark ei käivitunud. Vaatasime vabaressursse – kõik näis olevat korras. Spark peaks käivituma. Õnneks oli selleks ajaks dokumentatsioon juba kuskil alateadvuses, ja meenutasime, et Spark otsib käivitamise ajal endale porti. Kui esimene port vahemikus on hõivatud, siis liigub ta järgmise juurde. Kui see on vaba, siis haarab ta selle. Ja seal on seade, mis määrab maksimaalse katsete arvu selle jaoks. Vaikesätetena on see 16. See number on väiksem kui meie grupis praktilisel tunnil osalejate arv. Seega, pärast 16 katset viskas Spark selle asja käest ja ütles, et ei saa käivituda. Muutsime seda seadet.

spark.port.maxRetries=50

Räägin nüüd mõningatest seadistustest, mis ei ole enam tugevalt seotud meie juhtumi eripäradega.

Selleks, et Spark käivituks kiiremini, on soovitus tihendada jars kaust, mis asub SPARK_HOME kodu kataloogis, ja paigutada see HDFS-i. Nii ei pea ta kulutama aega nende jar-failide laadimisele töötajatele.

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

Selleks, et saavutada kiiremat tööd, soovitatakse kasutada serialiseerijana kryo. See on paremini optimeeritud kui vaikimisi variant.

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

Ja on veel üks vana probleem Sparkis, et see kipub sageli mälu ületama. See juhtub sageli hetkel, kui töölised on kõik arvutused teinud ja saadavad tulemuse draiverile. Me muutsime selle parameetri suuremaks. Vaikimisi on see 1 GB, meil on 3.

spark.driver.maxResultSize=3072

Ja viimane asi, magustoiduks. Kuidas uuendada Spark 2.1 versiooniks HortonWorks'i jaotises HDP 2.5.3.0. See HDP versioon sisaldab eelnevalt installitud 2.0 versiooni, kuid me otsustasime, et Spark areneb üsna aktiivselt ning iga uus versioon lahendab mõningaid vigu ja annab täiendavaid võimalusi, sealhulgas python API jaoks, seega otsustasime, et uuendamine on vajalik.

Laaditud versioon ametlikult veebilehelt Hadoop 2.7 jaoks. Lahti pakkida, paigutada HDP kausta. Panime sümboolikud õigesti. Käivitame - ei käivitu. Näitab väga arusaamatut viga.

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

Otsisime Google'ist, et Spark otsustas mitte oodata, kuni Hadoop välja tuleb, ja kasutama hakata uut jersey versiooni. Nad tülitsevad selle üle JIRA-s. Lahenduseks oli - alla laadida jersey versioon 1.17.1. Panna see SPARK_HOME'i jars kausta, jälle zipida ja HDFS-i üles laadida.

Selle vea me ületasime, kuid ilmnes uus ja üsna keeruline.

org.apache.spark.SparkException: Yarn rakendus on juba lõpetatud! See võis olla lõpetatud või ei suutnud rakenduse pead käivitada

Samas proovime käivitada versiooni 2.0 - kõik on korras. Proovi arvata, mis siin toimub. Me vaatlesime selle rakenduse logisid ja nägime midagi sellist:

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

Ühesõnaga, mingil põhjusel hdp.version ei lahendunud. Otsides leidsime lahenduse. Ambari seadetes tuleb minna YARN-i seadetesse ja lisada custom yarn-site'i parameeter:

hdp.version=2.5.3.0-37

See maagia aitas ning Spark tõusis. Testisime mitmeid meie jupyter-notebook'e. Kõik töötab. Oleme valmis laupäevale (juba homme) toimuvale Spark'i esimeses tunnis!

UPD. Tunnis selgus veel üks probleem. Mõnel hetkel lõpetas YARN Spark'i konteinerite andmise. YARN-is pidi muutma parameetrit, mis vaikimisi oli 0.2:

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

See, only 20% of the resources were involved in resource distribution. After changing the parameters, we restarted YARN. The problem was solved, and the other participants were also able to launch the spark context.

Allikas: habr.com