Habr, hallo! Gister op , van die ouens van Rambler&Co, was daar nogal baie vrae van deelnemers wat verband hou met die konfigurasie van hierdie instrument. Ons het besluit om in sy voetspore te volg en ons ervaring te deel. Die onderwerp is nie maklik nie - daarom nooi ons jou uit om jou ervaring in die kommentaar te deel, miskien verstaan en gebruik ons ook iets verkeerd.
'n Klein inleiding tot hoe ons Spark gebruik. Ons het 'n drie maande program , en regdeur die tweede module werk ons deelnemers aan hierdie instrument. Gevolglik is ons taak, as organiseerders, om die kluster voor te berei vir gebruik binne so 'n geval.
Die eienaardigheid van ons gebruik is dat die aantal mense wat gelyktydig aan Spark werk, gelyk kan wees aan die hele groep. Byvoorbeeld, by 'n seminaar, wanneer almal iets op dieselfde tyd probeer en na ons onderwyser herhaal. En dit is nie baie nie - soms tot 40 mense. Daar is waarskynlik nie baie maatskappye in die wêreld wat so 'n gebruiksgeval in die gesig staar nie.
Vervolgens sal ek jou vertel hoe en hoekom ons sekere konfigurasie-parameters gekies het.
Kom ons begin van die begin af. Spark het 3 opsies om op 'n groep te loop: selfstandig, met behulp van Mesos, en die gebruik van YARN. Ons het besluit om die derde opsie te kies omdat dit vir ons sin gemaak het. Ons het reeds 'n hadoop-kluster. Ons deelnemers is reeds goed vertroud met die argitektuur daarvan. Kom ons gebruik YARN.
spark.master=yarnVerder meer interessant. Elk van hierdie 3 ontplooiingsopsies het 2 ontplooiingsopsies: kliënt en groepering. Gebaseer en verskeie skakels op die internet, kan ons tot die gevolgtrekking kom dat die kliënt geskik is vir interaktiewe werk - byvoorbeeld deur jupyter-notaboek, en cluster is meer geskik vir produksie-oplossings. In ons geval was ons geïnteresseerd in interaktiewe werk, dus:
spark.deploy-mode=clientOor die algemeen sal Spark van nou af op een of ander manier op YARN werk, maar dit was nie genoeg vir ons nie. Aangesien ons 'n program oor groot data het, het die deelnemers soms nie genoeg gehad van wat verkry is binne die raamwerk van 'n eweredige sny van hulpbronne nie. En toe vind ons 'n interessante ding - dinamiese hulpbrontoewysing. Kortliks, die punt is dit: as jy 'n moeilike taak het en die groep is gratis (byvoorbeeld in die oggend), dan kan die gebruik van hierdie opsie Spark jou bykomende hulpbronne gee. Noodsaaklikheid word daar volgens 'n slinkse formule bereken. Ons gaan nie in besonderhede in nie - dit werk goed.
spark.dynamicAllocation.enabled=trueOns het hierdie parameter gestel en by opstart het Spark neergestort en nie begin nie. Dis reg, want ek moes dit lees versigtiger. Dit verklaar dat jy ook 'n bykomende parameter moet aktiveer om alles in orde te maak.
spark.shuffle.service.enabled=trueHoekom is dit nodig? Wanneer ons werk nie meer soveel hulpbronne verg nie, moet Spark dit na die gemeenskaplike swembad terugbesorg. Die mees tydrowende stadium in byna enige MapReduce-taak is die Shuffle-stadium. Hierdie parameter laat jou toe om die data wat op hierdie stadium gegenereer word te stoor en die eksekuteurs dienooreenkomstig vry te stel. En die eksekuteur is die proses wat alles op die werker bereken. Dit het 'n sekere aantal verwerkerkerne en 'n sekere hoeveelheid geheue.
Hierdie parameter is bygevoeg. Dit het gelyk of alles werk. Dit het opvallend geword dat deelnemers eintlik meer hulpbronne gegee is wanneer hulle dit nodig gehad het. Maar 'n ander probleem het ontstaan - op 'n stadium het ander deelnemers wakker geword en wou ook Spark gebruik, maar alles was daar besig, en hulle was ongelukkig. Hulle kan verstaan word. Ons het na die dokumentasie begin kyk. Dit het geblyk dat daar 'n aantal ander parameters is wat gebruik kan word om die proses te beïnvloed. Byvoorbeeld, as die eksekuteur in bystandsmodus is, na watter tyd kan hulpbronne daaruit geneem word?
spark.dynamicAllocation.executorIdleTimeout=120sIn ons geval, as jou eksekuteurs vir twee minute niks doen nie, stuur hulle asseblief terug na die gemeenskaplike swembad. Maar hierdie parameter was nie altyd genoeg nie. Dit was duidelik dat die persoon lankal niks gedoen het nie, en hulpbronne word nie vrygestel nie. Dit het geblyk dat daar ook 'n spesiale parameter is - na watter tyd om eksekuteurs te kies wat gekasdata bevat. By verstek was hierdie parameter oneindig! Ons het dit reggestel.
spark.dynamicAllocation.cachedExecutorIdleTimeout=600sDit wil sê, as jou eksekuteurs vir 5 minute niks doen nie, gee hulle vir die gemeenskaplike swembad. In hierdie modus het die spoed van vrystelling en uitreiking van hulpbronne vir 'n groot aantal gebruikers ordentlik geword. Die hoeveelheid ontevredenheid het afgeneem. Maar ons het besluit om verder te gaan en die maksimum aantal eksekuteurs per aansoek te beperk – in wese per programdeelnemer.
spark.dynamicAllocation.maxExecutors=19Nou is daar natuurlik ontevrede mense aan die ander kant - "die groep is ledig, en ek het net 19 eksekuteurs," maar wat kan jy doen? Ons het 'n soort korrekte balans nodig. Jy kan nie almal gelukkig maak nie.
En nog 'n klein storie wat verband hou met die besonderhede van ons saak. Op een of ander manier was verskeie mense laat vir 'n praktiese les, en om een of ander rede het Spark nie vir hulle begin nie. Ons het gekyk na die hoeveelheid gratis hulpbronne – dit blyk daar te wees. Vonk moet begin. Gelukkig was die dokumentasie teen daardie tyd reeds iewers by die subkorteks gevoeg, en ons het onthou dat wanneer dit geloods word, Spark soek na 'n hawe om op te begin. As die eerste poort in die reeks besig is, skuif dit na die volgende een in volgorde. As dit gratis is, neem dit vas. En daar is 'n parameter wat die maksimum aantal pogings hiervoor aandui. Die verstek is 16. Die getal is minder as die aantal mense in ons groep in die klas. Gevolglik, na 16 pogings, het Spark moed opgegee en gesê dat ek nie kon begin nie. Ons het hierdie instelling reggestel.
spark.port.maxRetries=50Volgende sal ek jou vertel van 'n paar instellings wat nie baie verband hou met die besonderhede van ons saak nie.
Om Spark vinniger te begin, word dit aanbeveel om die jars-lêergids in die SPARK_HOME-tuisgids te argiveer en dit op HDFS te plaas. Dan sal hy nie tyd mors om hierdie jarniks deur werkers te laai nie.
spark.yarn.archive=hdfs:///tmp/spark-archive.zipDit word ook aanbeveel om kryo as 'n serializer te gebruik vir vinniger werking. Dit is meer geoptimaliseer as die verstek een.
spark.serializer=org.apache.spark.serializer.KryoSerializerEn daar is ook 'n langdurige probleem met Spark dat dit dikwels uit die geheue ineenstort. Dikwels gebeur dit op die oomblik wanneer die werkers alles bereken het en die resultaat aan die bestuurder stuur. Ons het hierdie parameter vir onsself groter gemaak. By verstek is dit 1 GB, ons het dit 3 gemaak.
spark.driver.maxResultSize=3072En laastens, as nagereg. Hoe om Spark op te dateer na weergawe 2.1 op HortonWorks-verspreiding - HDP 2.5.3.0. Hierdie weergawe van HDP bevat 'n vooraf-geïnstalleerde weergawe 2.0, maar ons het eenkeer self besluit dat Spark besig is om taamlik aktief te ontwikkel, en elke nuwe weergawe maak 'n paar foute reg en bied addisionele kenmerke, insluitend vir die python API, so ons het besluit , wat moet gedoen word, is 'n opdatering.
Het die weergawe van die amptelike webwerf vir Hadoop 2.7 afgelaai. Het dit uitgepak en in die HDP-lêergids geplaas. Ons het die simskakels geïnstalleer soos nodig. Ons begin dit - dit begin nie. Skryf 'n baie vreemde fout.
java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfigNadat ons gegoogle het, het ons uitgevind dat Spark besluit het om nie te wag totdat Hadoop gebore is nie, en besluit het om die nuwe weergawe van trui te gebruik. Hulle stry self met mekaar oor hierdie onderwerp in JIRA. Die oplossing was om af te laai . Plaas dit in die jars-lêergids in SPARK_HOME, rits dit weer en laai dit op na HDFS.
Ons het hierdie fout omseil, maar 'n nuwe en taamlik vaartbelynde een het ontstaan.
org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch application masterTerselfdertyd probeer ons weergawe 2.0 laat loop - alles is ok. Probeer raai wat aangaan. Ons het na die logboeke van hierdie toepassing gekyk en iets soos hierdie gesien:
/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jarOor die algemeen het hdp.version om een of ander rede nie opgelos nie. Nadat ons gegoogle het, het ons 'n oplossing gevind. Jy moet na die YARN-instellings in Ambari gaan en 'n parameter daar byvoeg by die pasgemaakte garingwerf:
hdp.version=2.5.3.0-37Hierdie magie het gehelp, en Spark het opgestyg. Ons het verskeie van ons jupyter-skootrekenaars getoets. Alles werk. Ons is reg vir die eerste Vonkles Saterdag (môre)!
DUP. Tydens die les het nog 'n probleem aan die lig gekom. Op 'n stadium het YARN opgehou om houers vir Spark te verskaf. In YARN was dit nodig om die parameter reg te stel, wat by verstek 0.2 was:
yarn.scheduler.capacity.maximum-am-resource-percent=0.8
Dit wil sê, slegs 20% van hulpbronne het aan die verspreiding van hulpbronne deelgeneem. Nadat ons die parameters verander het, het ons YARN herlaai. Die probleem is opgelos en die res van die deelnemers kon ook vonkkonteks hardloop.
Bron: will.com