Spark'i konfigureerimine YARNis.

Tere, Habr! Eile toimus Apache Sparkile pühendatud kohtumine, kus Rambler&Co poisid rääkisid, tekkis osalejate seas palju küsimusi, mis olid seotud selle tööriista konfigureerimisega. Otsustasime oma kogemusi jagada. Teema ei ole lihtne — seetõttu kutsub meid üles jagama kogemusi ka kommentaarides, võib-olla on meil ka midagi valesti arusaadud ja kasutatud.

Lühike sissejuhatus — kuidas me Spark'i kasutame. Meil on kolmekuuline programm „Andmeanalüüsi spetsialist“, ja kogu teises moodulis töötavad meie osalejad selle tööriistaga. Vastavalt sellele on meie ülesanne, kui korraldajad, valmistada klaster ette selle kasutamiseks sellises kontekstis.

Meie kasutamise eripära seisneb selles, et samal ajal võib Spark'iga töötavate inimeste arv võrdsuda kogu grupiga. Näiteks seminaril, kui kõik proovivad samaaegselt ja kordavad meie õpetaja jooniseid. Ja see on mitte vähe — mõnikord peaaegu 40 inimest. Ilmselt ei ole maailmas palju ettevõtteid, kes puutuvad kokku sellise kasutusskeemiga.

Järgmiseks räägin, kuidas ja miks me valisime teatud konfigureerimise parameetreid.

Alustame algusest. Spark'il on 3 võimalust töötada klastris: standalone, Mesos'i kasutamine ja YARN'i kasutamine. Otsustasime valida kolmanda variandi, kuna see oli meile loogiline. Meil on juba olemas Hadoop klaster. Meie osalejad on selle arhitektuuriga juba hästi tuttavad. Alustame YARN'iga.

spark.master=yarn

Edasi on huvitavam. Igal kolmel deploy variandil on 2 varianti: client ja cluster. Lähtudes dokumentatsioon ja erinevatest linkidest internetis, võib järeldada, et client sobib interaktiivseks tööks — näiteks jupyter notebook'i kaudu, samas kui cluster sobib rohkem tootmislahenduste jaoks. Meie puhul oli meil huvi interaktiivse töö järele, seega:

spark.deploy-mode=client

Üldiselt hakkab Spark sellest hetkest alates YARN-is töötama, kuid meile sellest ei piisanud. Kuna meie programm keskendub suurtele andmetele, siis mõnikord oli osalistel puudu see, mida saadi tasakaalustatud ressursside jaotamise käigus. Ja siit me leidsime huvitava asja — dünaamiline ressursside jaotamine. Lühidalt öeldes on asi järgmine: kui teil on raske ülesanne ja klaster on vaba (näiteks hommikuti), siis selle valiku abil võib Spark teile anda täiendavaid ressursse. Vajadus arvutatakse seal keerulise valemi abil. Sügavamale ei lasku, - see töötab hästi.

spark.dynamicAllocation.enabled=true

Me seadsime selle parameetri, ja Spark käivitamisel nurjus ja ei käivitunud. Õigesti, sest oli vaja lugeda dokumentatsioon täpsemalt. Seal on märgitud, et kõik peab olema korras, tuleb veel aktiveerida täiendav parameeter.

spark.shuffle.service.enabled=true

Miks see vajalik on? Kui meie töö ei vaja enam nii palju ressursse, peab Spark need tagasi tagasi üldisesse gruppi andma. Peaaegu igasuguste MapReduce ülesannete kõige töömahukam etapp on Shuffle etapp. See parameeter lubab säilitada andmeid, mis tekivad selle etapi käigus, ja vabastada vastavalt täitejõud. Täitejõud on protsess, mis töötleb kõike töötaja seadmes. Tal on mingisugune arv protsessorituumasid ja mingisugune hulk mälu.

Me lisasime selle parameetri. Kõik tundus töötavat. Oli märgatav, et osalistele anti tõepoolest rohkem ressursse, kui neid vajas. Kuid tekkis teine probleem - mingil hetkel ärkasid teised osalised ja soovisid samuti Spark'i kasutada, kuid kõik oli hõivatud, ja nad olid rahulolematud. Neid võib mõista. Hakkasime dokumentatsiooni vaatama. Seal selgus, et on veel mitmeid parameetreid, mille abil saab protsessile mõju avaldada. Näiteks kui täitejõud on ooterežiimil — kui kaua tohib ressursse tagasi võtta?

spark.dynamicAllocation.executorIdleTimeout=120s

Meie puhul, kui teie executors ei tee kahe minuti jooksul midagi, siis palun tagastage need ühisesse hulka. Kuid isegi see parameeter ei olnud alati piisav. Oli näha, et inimene ei tee juba ammu midagi ja ressursse ei vabastata. Selgus, et on olemas veel üks eriline parameeter — kui kaua peab mööduma, et valida executors, mis sisaldavad vahemällu salvestatud andmeid. Vaikesättega oli see — infinity! Me korrigeerisime seda.

spark.dynamicAllocation.cachedExecutorIdleTimeout=600s

See tähendab, et kui teie executors ei tee viie minuti jooksul midagi, siis andke need ühisesse hulka tagasi. Sellises režiimis on ressursside vabastamise ja jagamise kiirus suure arvu kasutajate jaoks muutunud korralikuks. Rahulolematute arv on vähenenud. Kuid me otsustasime minna edasi ja piirata maksimaalset executors’te arvu ühe rakenduse kohta — praktiliselt ühe programmi osaleja kohta.

spark.dynamicAllocation.maxExecutors=19

Nüüd, muidugi, tekkisid rahulolematud ka teiselt poolt — "klaster seisab, aga mul on ainult 19 executors", aga mis seal ikka — vajalik on leida õige tasakaal. Kõiki ei saa õnnelikuks teha.

Ja veel üks väike lugu, mis on seotud meie juhtumi spetsiifikaga. Kord hilines praktilisse tundidesse mitu inimest, ja neil ei hakanud Spark mingil põhjusel käima. Me vaatasime vabade ressursside arvu — tundus, et on olemas. Spark peaks käima hakkama. Õnneks oli dokumentatsioon juba mingil hetkel alateadvusse salvestunud ja me mäletasime, et Spark otsib käivitamisel endale porti, millega alustada. Kui esimene port vahemikust on hõivatud, siis siirdub ta järgmise juurde. Kui see on vaba, siis ta haarab selle. Ja on olemas parameeter, mis näitab maksimaalset katsete arvu selle jaoks. Vaikesättega on see 16. Arv on väiksem kui inimeste arv meie grupis tunnis. Seega, pärast 16 katset viskas Spark selle asja käest ja ütles, et ei saa käivituda. Me korrigeerisime seda parameetrit.

spark.port.maxRetries=50

Edasi räägin mõningatest seadistustest, mis ei ole enam tõeliselt seotud meie juhtumi spetsiifikaga.

Selleks, et Spark kiiremini käima saada, on soovitus arhiveerida jars-kaust, mis asub SPARK_HOME kodudirektooriumis, ja panna see HDFS-i. Nii ei pea ta nende jaride allalaadimisele töötajates aega raiskama.

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

Samuti on soovitatav kasutada kiirema töö jaoks serialiseerijana Kryo't. See on optimeeritum kui vaikimisi valitud.

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

Ja on veel üks vana probleem Sparkiga: see kukub sageli mälu tõttu kokku. See juhtub tihti siis, kui töötajad on kõik arvutanud ja saadavad tulemuse draiverile. Me tegime selle parameetri suuremaks. Vaikimisi on see 1Gb, meie tegime - 3.

spark.driver.maxResultSize=3072

Ja viimane, magustoiduna. Kuidas uuendada Spark versioonile 2.1 HortonWorks'i jaotuses - HDP 2.5.3.0. See versioon HDP sisaldab eelinstallitud versiooni 2.0, kuid kord otsustasime, et Spark areneb üsna aktiivselt ning iga uus versioon parandab mõningaid vigu ja toob lisavõimalusi, sealhulgas Python API jaoks, seega otsustasime, et uuendamine on vajalik.

Laadige alla versioon ametlikult veebilehelt Hadoop 2.7 jaoks. Pakkige lahti, kopeerige HDP kausta. Panime sümbollinkid nagu vaja. Käivitame - ei käivitu. Näitab väga ebaselget viga.

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

Gugeldades selgus, et Spark ei oota, kuni Hadoop end kokku parandab, ja otsustas kasutada uut jersey versiooni. Nad vaidlevad selle üle JIRA's. Lahenduseks oli - laadige alla jersey versioon 1.17.1. Kopeerige see SPARK_HOME'i jars kausta, tehke jälle zip ja laadige HDFS-i.

Selle vea vältisime, kuid tekkis uus ja üsna äärmuslik.

org.apache.spark.SparkException: Yarn application has already ended! See võis olla tapetud või ei suutnud käivituda rakenduse master.

Sellega proovime käivitada versiooni 2.0 - kõik on korras. Proovi arvata, milles probleem. Uurisime selle rakenduse logisid ja nägime midagi sellist:

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

Kokkuvõttes, mingil põhjusel hdp.version ei lahendunud. Gugeldades leidsime lahenduse. Peab minema Ambari seadistustesse YARNi ja lisama seal kohandatud yarn-site parameetri:

hdp.version=2.5.3.0-37

See maagia aitas ning Spark startis. Testisime mitmeid meie jupyteri märkmikke. Kõik töötab. Oleme valmis esimese tunniga Sparkis laupäeval (juba homme)!

UPD. Tunnis ilmnes veel üks probleem. Mingil hetkel YARN lõpetas konteinerite väljastamise Sparkile. YARN-is tuli parandada parameeter, mis oli vaikimisi 0.2:

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

See, only 20% of the resources participated in resource allocation. After changing the parameters, YARN was restarted. The issue was resolved, and the other participants were also able to launch the Spark context.

Allikas: habr.com