Habr, kaixo! Atzokoan , Rambler&Co-ko mutilen aldetik, parte-hartzaileen galdera dezente agertu ziren tresna hau konfiguratzearekin lotuta. Haren urratsei jarraitzea eta gure esperientzia partekatzea erabaki genuen. Gaia ez da erraza; beraz, zure esperientzia iruzkinetan partekatzera gonbidatzen zaitugu, agian zerbait gaizki ulertu eta erabiltzen dugu.
Spark nola erabiltzen dugun ezagutzeko sarrera txiki bat. Hiru hilabeteko egitaraua dugu , eta bigarren moduluan zehar gure partaideek tresna hau lantzen dute. Horren arabera, gure zeregina, antolatzaile garen heinean, klusterra horrelako kasu batean erabiltzeko prestatzea da.
Gure erabileraren berezitasuna da Spark-en aldi berean lan egiten duten pertsonen kopurua talde osoaren berdina izan daitekeela. Adibidez, mintegi batean, denek aldi berean zerbait probatzen dutenean eta gure irakaslearen ondoren errepikatzen dutenean. Eta hori ez da asko - batzuetan 40 pertsona. Seguruenik, munduan ez dago horrelako erabilera kasu bati aurre egiten dioten enpresa asko.
Jarraian, konfigurazio-parametro jakin batzuk nola eta zergatik hautatu ditugun esango dizut.
Has gaitezen hasiera-hasieratik. Spark-ek kluster batean exekutatzeko 3 aukera ditu: autonomoa, Mesos erabiliz eta YARN erabiliz. Hirugarren aukera aukeratzea erabaki genuen, guretzat zentzuzkoa zelako. Dagoeneko badugu hadoop kluster bat. Gure parte-hartzaileek dagoeneko ondo ezagutzen dute bertako arkitektura. Erabili dezagun YARN.
spark.master=yarnGehiago interesgarriagoa. 3 inplementazio aukera hauetako bakoitzak 2 inplementazio aukera ditu: bezeroa eta clusterra. Oinarritua eta Interneteko hainbat esteka, bezeroa lan interaktiborako egokia dela ondoriozta dezakegu, adibidez, jupyter koadernoaren bidez, eta cluster-a ekoizpen irtenbideetarako egokia dela. Gure kasuan, lan interaktiboa interesatzen zitzaigun, beraz:
spark.deploy-mode=clientOro har, hemendik aurrera Spark-ek YARN-en funtzionatuko du nolabait, baina hau ez zen nahikoa izan guretzat. Big datari buruzko programa bat daukagunez, batzuetan parte hartzaileek ez zuten nahikoa baliabideen zatiketa uniforme baten baitan lortutakoarekin. Eta orduan gauza interesgarri bat aurkitu genuen: baliabideen esleipen dinamikoa. Laburbilduz, kontua hau da: zeregin zaila baduzu eta klusterra doakoa bada (adibidez, goizean), aukera hau erabiliz Spark-ek baliabide gehigarriak eman diezazkizuke. Beharrezkoa formula maltzur baten arabera kalkulatzen da bertan. Ez gara xehetasunetan sartuko - ondo funtzionatzen du.
spark.dynamicAllocation.enabled=trueParametro hau ezarri genuen, eta abiaraztean Spark-ek huts egin zuen eta ez zen hasi. Hori bai, irakurri behar izan nuelako kontu handiagoz. Dena ondo egon dadin, parametro gehigarri bat ere gaitu behar duzula adierazten du.
spark.shuffle.service.enabled=trueZergatik behar da? Gure lanak jada hainbeste baliabide behar ez dituenean, Sparkek igerileku komunera itzuli beharko lituzke. MapReduce zereginetan denbora gehien hartzen duen etapa Nahasketa fasea da. Parametro honek fase honetan sortzen diren datuak gordetzeko eta horren arabera exekutatzaileak askatzeko aukera ematen du. Eta exekutatzailea langilearen gainean dena kalkulatzen duen prozesua da. Prozesadore-nukleo kopuru jakin bat eta memoria kopuru jakin bat ditu.
Parametro hau gehitu da. Dena funtzionatzen zuela zirudien. Nabarmena egin zen parte-hartzaileek behar zituztenean baliabide gehiago ematen zituztela. Baina beste arazo bat sortu zen - uneren batean beste parte-hartzaile batzuk esnatu ziren eta Spark ere erabili nahi zuten, baina dena okupatuta zegoen han, eta pozik zeuden. Uler daitezke. Dokumentazioa aztertzen hasi ginen. Prozesuan eragiteko erabil daitezkeen beste parametro batzuk daudela ikusi zen. Esaterako, exekutatzailea standby moduan badago, zer denbora igaro ondoren atera daitezke baliabideak?
spark.dynamicAllocation.executorIdleTimeout=120sGure kasuan, zure exekutatzaileek bi minututan ezer egiten ez badute, mesedez itzul itzazu igerileku komunera. Baina parametro hau ez zen beti nahikoa izan. Argi zegoen pertsona horrek denbora luzez ez zuela ezer egiten, eta baliabideak ez zirela askatzen. Parametro berezi bat ere badagoela ikusi zen: cachean gordetako datuak dituzten exekutatzaileak zein denbora igaro ondoren hautatzeko. Lehenespenez, parametro hau infinitua zen! zuzendu dugu.
spark.dynamicAllocation.cachedExecutorIdleTimeout=600sHau da, zure exekutiboak 5 minutuz ezer egiten ez badute, eman igerileku komunari. Modu honetan, erabiltzaile kopuru handientzako baliabideak askatzeko eta igortzeko abiadura duina bihurtu da. Deskontentu kopurua gutxitu egin da. Baina harago joatea eta aplikazio bakoitzeko gehienezko exekutatzaile kopurua mugatzea erabaki genuen, funtsean, programako parte-hartzaile bakoitzeko.
spark.dynamicAllocation.maxExecutors=19Orain, noski, asegabe dauden pertsonak daude beste aldean - "klusterra alferrik dago, eta 19 ejekutore baino ez ditut", baina zer egin dezakezu? Balantze zuzen bat behar dugu. Ezin dituzu denak zoriontsu egin.
Eta gure kasuaren berezitasunekin lotutako istorio txiki bat gehiago. Nolabait, hainbat pertsona berandu iritsi ziren ikasgai praktiko batera, eta arrazoiren batengatik Spark ez zen haientzat hasi. Doako baliabideen kopurua aztertu dugu, badirudi hor dagoela. Spark hasi behar da. Zorionez, ordurako dokumentazioa jada nonbait azpikortexean gehituta zegoen, eta gogoratu genuen abiarazitakoan Spark-ek abiatzeko ataka bilatzen duela. Barrutiko lehen ataka okupatuta badago, hurrengora mugitzen da ordenan. Doakoa bada, harrapatzen du. Eta horretarako gehienezko saiakera kopurua adierazten duen parametro bat dago. Lehenetsia 16 da. Kopurua klasean gure taldeko pertsona kopurua baino txikiagoa da. Horren arabera, 16 saiakera egin ondoren, Sparkek amore eman eta ezin nuela hasi esan zuen. Ezarpen hau zuzendu dugu.
spark.port.maxRetries=50Jarraian, gure kasuaren berezitasunekin oso lotuta ez dauden ezarpen batzuen berri emango dizut.
Spark azkarrago abiarazteko, SPARK_HOME hasierako direktorioan dagoen jars karpeta artxibatzea eta HDFS-en jartzea gomendatzen da. Orduan ez du denbora galduko langileek jarnik hauek kargatzen.
spark.yarn.archive=hdfs:///tmp/spark-archive.zipEra berean, kryo serializatzaile gisa erabiltzea gomendatzen da azkarrago funtzionatzeko. Lehenetsitakoa baino optimizatuagoa da.
spark.serializer=org.apache.spark.serializer.KryoSerializerEta Spark-ekin aspaldiko arazo bat ere badago, askotan memoriatik huts egiten duela. Askotan, langileek dena kalkulatu eta emaitza gidariari bidaltzen duten momentuan gertatzen da. Parametro hau handiagoa egin dugu guretzat. Lehenespenez, 1 GB da, 3 egin dugu.
spark.driver.maxResultSize=3072Eta azkenik, postre moduan. Nola eguneratu Spark 2.1 bertsiora HortonWorks banaketan - HDP 2.5.3.0. HDP-ren bertsio honek aurrez instalatutako 2.0 bertsioa dauka, baina Spark nahiko aktiboki garatzen ari zela erabaki genuen behin, eta bertsio berri bakoitzak akats batzuk konpontzen ditu eta funtzio gehigarriak eskaintzen ditu, besteak beste, python APIrako, beraz, zer behar den erabaki genuen. eginda eguneratzea da.
Hadoop 2.7-ren webgune ofizialetik deskargatu da bertsioa. Deskonprimitu eta HDP karpetan sartu. Esteka sinbolikoak behar bezala instalatu ditugu. Abian jartzen dugu - ez da hasten. Errore oso argia idazten du.
java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfigGooglen ibili ondoren, jakin genuen Sparkek Hadoop jaio arte ez itxarotea erabaki zuela, eta elastiko bertsio berria erabiltzea erabaki zuela. Beraiek elkarrekin eztabaidatzen dute gai honen inguruan JIRAn. Irtenbidea deskargatzea izan zen . Jarri hau SPARK_HOME-ko jars karpetan, konprimitu berriro eta kargatu HDFSra.
Akats hau konpondu genuen, baina berri bat sortu zen eta nahiko erraztua.
org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch application masterAldi berean, 2.0 bertsioa exekutatzen saiatzen gara - dena ondo dago. Saiatu zer gertatzen ari den asmatzen. Aplikazio honen erregistroak aztertu eta honelako zerbait ikusi genuen:
/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jarOro har, arrazoiren batengatik hdp.version ez da konpondu. Googlen bilatu ondoren, irtenbide bat aurkitu dugu. Ambari-ko YARN ezarpenetara joan eta parametro bat gehitu behar duzu yarn-gune pertsonalizatuan:
hdp.version=2.5.3.0-37Magia horrek lagundu zuen, eta Spark-ek aireratu zuen. Gure Jupyter ordenagailu eramangarrietako hainbat probatu ditugu. Dena dabil. Larunbatean (bihar) lehen Spark ikasgairako prest gaude!
DUP. Ikasgaian zehar, beste arazo bat agertu zen. Noizbait, YARNek Spark-erako edukiontziak emateari utzi zion. YARN-en parametroa zuzendu behar zen, lehenespenez 0.2 zen:
yarn.scheduler.capacity.maximum-am-resource-percent=0.8
Hau da, baliabideen %20k baino ez zuen parte hartu baliabideen banaketan. Parametroak aldatu ondoren, YARN berriro kargatu dugu. Arazoa konpondu zen eta gainerako parte-hartzaileek ere txinparta testuingurua exekutatu ahal izan zuten.
Iturria: www.habr.com