Habr, hallo! Juster op , fan 'e jonges fan Rambler&Co, wiene d'r in protte fragen fan dielnimmers yn ferbân mei it konfigurearjen fan dit ark. Wy besletten om yn syn fuotstappen te folgjen en ús ûnderfining te dielen. It ûnderwerp is net maklik - dus wy noegje jo út om jo ûnderfining te dielen yn 'e opmerkingen, miskien begripe en brûke wy ek wat ferkeard.
In lytse ynlieding oer hoe't wy Spark brûke. Wy hawwe in trije moanne programma , en yn 'e twadde module wurkje ús dielnimmers oan dit ynstrumint. Sadwaande is it ús taak, as organisator, it kluster ta te rieden foar gebrûk yn sa'n gefal.
De eigenaardichheid fan ús gebrûk is dat it oantal minsken dy't tagelyk oan Spark wurkje, gelyk wêze kinne oan de hiele groep. Bygelyks op in seminar, as elkenien tagelyk wat besiket en werhellet nei ús learaar. En dit is net folle - soms oant 40 minsken. D'r binne wierskynlik net in protte bedriuwen yn 'e wrâld dy't sa'n gebrûksgefall hawwe.
Folgjende sil ik jo fertelle hoe en wêrom wy bepaalde konfiguraasjeparameters selekteare.
Litte wy fan it begjin ôf begjinne. Spark hat 3 opsjes om op in kluster te rinnen: standalone, Mesos brûke, en YARN brûke. Wy besletten om de tredde opsje te kiezen, om't it foar ús sin wie. Wy hawwe al in hadoop kluster. Us dielnimmers binne al goed bekend mei de arsjitektuer. Litte wy YARN brûke.
spark.master=yarnFierder mear nijsgjirrich. Elk fan dizze 3 ynsetopsjes hat 2 ynsetopsjes: kliïnt en kluster. Basearre en ferskate keppelings op it ynternet, kinne wy konkludearje dat klant is geskikt foar ynteraktyf wurk - bygelyks, troch jupyter notebook, en kluster is mear geskikt foar produksje oplossings. Yn ús gefal wiene wy ynteressearre yn ynteraktyf wurk, dus:
spark.deploy-mode=clientYn 't algemien sil Spark fan no ôf op ien of oare manier wurkje op YARN, mar dit wie net genôch foar ús. Sûnt wy hawwe in programma oer grutte data, soms de dielnimmers hawwe net genôch fan wat waard krigen yn it ramt fan in even slicing fan middels. En doe fûnen wy in nijsgjirrich ding - dynamyske tawizing fan boarnen. Koartsein, it punt is dit: as jo in drege taak hawwe en it kluster is fergees (bygelyks moarns), dan kin it brûken fan dizze opsje Spark jo ekstra boarnen jaan. De needsaak wurdt dêr berekkene neffens in listige formule. Wy sille net yngean op details - it wurket goed.
spark.dynamicAllocation.enabled=trueWy sette dizze parameter, en by it opstarten stoarte Spark en begon net. Dat kloppet, want ik moast it lêze foarsichtiger. It stelt dat om alles goed te wêzen, jo ek in ekstra parameter ynskeakelje moatte.
spark.shuffle.service.enabled=trueWêrom is it nedich? As ús baan net mear safolle middels fereasket, moat Spark se weromjaan nei it mienskiplike swimbad. It meast tiidslinend poadium yn hast elke MapReduce-taak is it Shuffle-poadium. Mei dizze parameter kinne jo de gegevens opslaan dy't op dit poadium wurde generearre en de útfierers dêrmei frijlitte. En de eksekuteur is it proses dat alles op 'e arbeider berekkent. It hat in bepaald oantal prosessor kearnen en in bepaald bedrach fan ûnthâld.
Dizze parameter is tafoege. Alles like te wurkjen. It waard opfallend dat dielnimmers eins mear middels krigen as se se nedich wiene. Mar der ûntstie in oar probleem - op in stuit waarden oare dielnimmers wekker en woene ek Spark brûke, mar dêr wie alles drok, en se wiene ûngelokkich. Se kinne wurde begrepen. Wy begûnen te sjen nei de dokumintaasje. It die bliken dat d'r in oantal oare parameters binne dy't brûkt wurde kinne om it proses te beynfloedzjen. Bygelyks, as de útfierer is yn standby modus, nei hokker tiid kinne middels wurde nommen út it?
spark.dynamicAllocation.executorIdleTimeout=120sYn ús gefal, as jo eksekuteurs twa minuten neat dogge, dan asjebleaft werom nei it mienskiplike swimbad. Mar dizze parameter wie net altyd genôch. It wie dúdlik dat de persoan hie net dien neat foar in lange tiid, en middels waarden net frijmakke. It die bliken dat d'r ek in spesjale parameter is - nei hokker tiid om útfierers te selektearjen dy't cached gegevens befetsje. Standert wie dizze parameter ûneinich! Wy hawwe it korrizjearre.
spark.dynamicAllocation.cachedExecutorIdleTimeout=600sDat is, as jo executors dogge neat foar 5 minuten, jou se oan 'e mienskiplike pool. Yn dizze modus is de snelheid fan it frijjaan en útjaan fan boarnen foar in grut oantal brûkers fatsoenlik wurden. It bedrach fan ûnfrede is ôfnommen. Mar wy besletten om fierder te gean en it maksimum oantal útfierers per applikaasje te beheinen - yn essinsje per programma-dielnimmer.
spark.dynamicAllocation.maxExecutors=19No binne d'r fansels ûntefreden minsken oan 'e oare kant - "it kluster is idle, en ik haw mar 19 eksekuteurs," mar wat kinne jo dwaan? Wy hawwe in soarte fan juste lykwicht nedich. Jo kinne net elkenien bliid meitsje.
En noch ien lyts ferhaal yn ferbân mei de spesifiken fan ús saak. Op ien of oare manier wiene ferskate minsken te let foar in praktyske les, en om ien of oare reden begon Spark net foar har. Wy seagen nei it bedrach fan fergese boarnen - it liket der te wêzen. Spark moat begjinne. Gelokkich, tsjin dy tiid wie de dokumintaasje al earne tafoege oan 'e subcortex, en wy betinken dat as it lansearre is, Spark siket nei in haven om te begjinnen. As de earste haven yn it berik drok is, giet it yn folchoarder nei de folgjende. As it fergees is, fange it. En d'r is in parameter dy't it maksimum oantal besykjen foar dit oanjout. De standert is 16. It oantal is minder as it oantal minsken yn ús groep yn 'e klasse. Dêrtroch joech Spark nei 16 besykjen op en sei dat ik net koe begjinne. Wy hawwe dizze parameter korrizjearre.
spark.port.maxRetries=50Folgjende sil ik jo fertelle oer guon ynstellingen dy't net heul relatearre binne oan 'e spesifiken fan ús saak.
Om Spark rapper te begjinnen, wurdt it oanrikkemandearre om de jars-map te argivearjen yn 'e SPARK_HOME-thúsmap en set it op HDFS. Dan sil er gjin tiid fergrieme mei it laden fan dizze jarniks troch arbeiders.
spark.yarn.archive=hdfs:///tmp/spark-archive.zipIt is ek oan te rieden om kryo te brûken as serializer foar flugger operaasje. It is mear optimalisearre as de standert.
spark.serializer=org.apache.spark.serializer.KryoSerializerEn d'r is ek in lang besteande probleem mei Spark dat it faak crasht út it ûnthâld. Faak bart dat op it momint dat de arbeiders alles hawwe berekkene en it resultaat nei de bestjoerder stjoere. Wy makken dizze parameter grutter foar ússels. Standert is it 1GB, wy makken it 3.
spark.driver.maxResultSize=3072En as lêste, as dessert. Hoe Spark bywurkje nei ferzje 2.1 op HortonWorks-distribúsje - HDP 2.5.3.0. Dizze ferzje fan HDP befettet in foarynstallearre ferzje 2.0, mar wy hawwe ienris foar ússels besletten dat Spark frij aktyf ûntwikkelet, en elke nije ferzje reparearret guon bugs en leveret ekstra funksjes, ynklusyf foar de python API, dus besleaten wy , wat moat dien wurde is in update.
Download de ferzje fan 'e offisjele webside foar Hadoop 2.7. Unzipped it en set it yn 'e HDP-map. Wy ynstalleare de symlinks as nedich. Wy lansearje it - it begjint net. Skriuwt in heul ûndúdlike flater.
java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfigNei googling fûnen wy dat Spark besleat net te wachtsjen oant Hadoop berne waard, en besleat de nije ferzje fan jersey te brûken. Se sels pleitsje mei-inoar oer dit ûnderwerp yn JIRA. De oplossing wie om te downloaden . Pleats dit yn 'e jars-map yn SPARK_HOME, zip it opnij en upload it nei HDFS.
Wy kamen om dizze flater hinne, mar in nije en nochal streamlined ûntstie.
org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch application masterTagelyk besykje wy ferzje 2.0 út te fieren - alles is ok. Besykje te rieden wat der bart. Wy seagen yn 'e logs fan dizze applikaasje en seagen sa'n ding:
/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jarYn it algemien, foar guon reden hdp.version net oplosse. Nei it googlejen fûnen wy in oplossing. Jo moatte nei de YARN-ynstellingen yn Ambari gean en dêr in parameter taheakje oan oanpaste yarn-side:
hdp.version=2.5.3.0-37Dizze magy holp, en Spark naam ôf. Wy testen ferskate fan ús jupyter-laptops. Alles wurket. Wy binne klear foar de earste Spark-les op sneon (moarn)!
DUP. Yn de les kaam noch in probleem oan it ljocht. Op in stuit stoppe YARN it leverjen fan konteners foar Spark. Yn YARN wie it nedich om de parameter te korrigearjen, dy't standert 0.2 wie:
yarn.scheduler.capacity.maximum-am-resource-percent=0.8
Dat is, mar 20% fan middels diene mei oan de distribúsje fan middels. Nei it feroarjen fan de parameters hawwe wy YARN opnij laden. It probleem waard oplost en de rest fan de dielnimmers wiene ek by steat om te rinne spark kontekst.
Boarne: www.habr.com