Agordante Spark sur YARN

Habr, saluton! Hieraŭ plu renkontiĝo dediĉita al Apache Spark, de la uloj de Rambler&Co, estis sufiĉe multaj demandoj de partoprenantoj rilate al agordo de ĉi tiu ilo. Ni decidis sekvi liajn paŝojn kaj dividi nian sperton. La temo ne estas facila - do ni invitas vin konigi vian sperton en la komentoj, eble ni ankaŭ komprenas kaj uzas ion malĝustan.

Eta enkonduko al kiel ni uzas Spark. Ni havas trimonatan programon "Specialisto pri Grandaj Datumoj", kaj dum la dua modulo niaj partoprenantoj laboras pri tiu ĉi instrumento. Sekve, nia tasko, kiel organizantoj, estas prepari la areton por uzo ene de tia kazo.

La propreco de nia uzo estas, ke la nombro da homoj samtempe laborantaj sur Spark povas esti egala al la tuta grupo. Ekzemple, en seminario, kiam ĉiuj provas ion samtempe kaj ripetas post nia instruisto. Kaj ĉi tio ne estas multe - foje ĝis 40 homoj. Verŝajne ne estas multaj kompanioj en la mondo, kiuj alfrontas tian uzon.

Poste, mi rakontos al vi kiel kaj kial ni elektis iujn agordajn parametrojn.

Ni komencu de la komenco mem. Spark havas 3 eblojn por funkcii en areto: memstara, uzante Mesos kaj uzante YARN. Ni decidis elekti la trian opcion ĉar ĝi havis sencon por ni. Ni jam havas hadoop-grupon. Niaj partoprenantoj jam bone konas ĝian arkitekturon. Ni uzu YARN.

spark.master=yarn

Plue pli interesa. Ĉiu el ĉi tiuj 3 disfaldaj opcioj havas 2 disfaldajn opciojn: kliento kaj areto. Bazita dokumentado kaj diversaj ligiloj en Interreto, ni povas konkludi, ke kliento taŭgas por interaga laboro - ekzemple per jupyter kajero, kaj cluster pli taŭgas por produktadsolvoj. En nia kazo, ni interesiĝis pri interaga laboro, do:

spark.deploy-mode=client

Ĝenerale, de nun Spark iel funkcios pri YARN, sed ĉi tio ne sufiĉis por ni. Ĉar ni havas programon pri grandaj datumoj, foje la partoprenantoj ne havis sufiĉe da tio, kio estis akirita kadre de eĉ tranĉaĵo de rimedoj. Kaj tiam ni trovis interesan aferon - dinamika resursa asignado. Resume, la afero estas jena: se vi havas malfacilan taskon kaj la areto estas senpaga (ekzemple, matene), tiam uzi ĉi tiun opcion Spark povas doni al vi pliajn rimedojn. Neceso estas kalkulita tie laŭ ruza formulo. Ni ne eniros detalojn - ĝi funkcias bone.

spark.dynamicAllocation.enabled=true

Ni starigis ĉi tiun parametron, kaj post ekfunkciigo Spark kraŝis kaj ne ekis. Ĝuste, ĉar mi devis legi ĝin dokumentado pli zorge. Ĝi deklaras, ke por ke ĉio estu en ordo, vi ankaŭ devas ebligi plian parametron.

spark.shuffle.service.enabled=true

Kial ĝi estas bezonata? Kiam nia laboro ne plu postulas tiom da rimedoj, Spark devus resendi ilin al la komuna naĝejo. La plej tempopostula etapo en preskaŭ ajna MapReduce-tasko estas la Ŝtufa stadio. Ĉi tiu parametro permesas konservi la datumojn, kiuj estas generitaj en ĉi tiu etapo, kaj liberigi la ekzekutistojn laŭe. Kaj la ekzekutisto estas la procezo, kiu kalkulas ĉion sur la laboristo. Ĝi havas certan nombron da procesoraj kernoj kaj certan kvanton da memoro.

Ĉi tiu parametro estis aldonita. Ĉio ŝajnis funkcii. Evidentiĝis, ke partoprenantoj efektive ricevis pli da rimedoj kiam ili bezonis ilin. Sed aperis alia problemo – iam aliaj partoprenantoj vekiĝis kaj ankaŭ volis uzi Spark, sed ĉio estis okupata tie, kaj ili estis malfeliĉaj. Ili povas esti komprenataj. Ni komencis rigardi la dokumentadon. Evidentiĝis, ke ekzistas kelkaj aliaj parametroj, kiuj povas esti uzataj por influi la procezon. Ekzemple, se la ekzekutisto estas en standby, post kioma tempo oni povas preni rimedojn de ĝi?

spark.dynamicAllocation.executorIdleTimeout=120s

En nia kazo, se viaj ekzekutistoj faras nenion dum du minutoj, tiam bonvolu resendi ilin al la komuna naĝejo. Sed ĉi tiu parametro ne ĉiam sufiĉis. Estis klare, ke la persono delonge nenion faris, kaj rimedoj ne estis liberigitaj. Montriĝis, ke ankaŭ ekzistas speciala parametro - post kioma tempo elekti ekzekutistojn, kiuj enhavas konservitajn datumojn. Defaŭlte, ĉi tiu parametro estis senfineco! Ni korektis ĝin.

spark.dynamicAllocation.cachedExecutorIdleTimeout=600s

Tio estas, se viaj ekzekutistoj faras nenion dum 5 minutoj, donu ilin al la komuna naĝejo. En ĉi tiu reĝimo, la rapideco liberigi kaj elsendi rimedojn por granda nombro da uzantoj fariĝis deca. La kvanto de malkontento malpliiĝis. Sed ni decidis iri plu kaj limigi la maksimuman nombron da ekzekutistoj por aplikaĵo - esence por programpartoprenanto.

spark.dynamicAllocation.maxExecutors=19

Nun, kompreneble, estas malkontentaj homoj aliflanke - "la areto estas neaktiva, kaj mi havas nur 19 ekzekutistoj", sed kion vi povas fari? Ni bezonas ian ĝustan ekvilibron. Vi ne povas feliĉigi ĉiujn.

Kaj unu pli malgranda rakonto rilata al la specifaĵoj de nia kazo. Iel, pluraj homoj malfruis por praktika leciono, kaj ial Spark ne ekiris por ili. Ni rigardis la kvanton de senpagaj rimedoj - ŝajnas esti tie. Spark devus komenciĝi. Feliĉe, tiam la dokumentaro jam estis aldonita al la subkortekso ie, kaj ni memoris, ke kiam lanĉite, Spark serĉas havenon por komenci. Se la unua haveno en la gamo estas okupata, ĝi moviĝas al la sekva en ordo. Se ĝi estas senpaga, ĝi kaptas. Kaj estas parametro, kiu indikas la maksimuman nombron da provoj por ĉi tio. La defaŭlta estas 16. La nombro estas malpli granda ol la nombro da homoj en nia grupo en la klaso. Sekve, post 16 provoj, Spark rezignis kaj diris, ke mi ne povas komenci. Ni korektis ĉi tiun agordon.

spark.port.maxRetries=50

Poste mi rakontos al vi pri iuj agordoj, kiuj ne tre rilatas al la specifaĵoj de nia kazo.

Por lanĉi Spark pli rapide, oni rekomendas arkivi la jardosierujon situantan en la hejma dosierujo SPARK_HOME kaj meti ĝin sur HDFS. Tiam li ne perdos tempon ŝarĝante ĉi tiujn jarnikojn de laboristoj.

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

Oni rekomendas ankaŭ uzi krion kiel seriigilon por pli rapida operacio. Ĝi estas pli optimumigita ol la defaŭlta.

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

Kaj ankaŭ ekzistas delonga problemo kun Spark, ke ĝi ofte kraŝas de memoro. Ofte tio okazas en la momento, kiam la laboristoj kalkulis ĉion kaj sendas la rezulton al la ŝoforo. Ni faris ĉi tiun parametron pli granda por ni mem. Defaŭlte, ĝi estas 1GB, ni faris ĝin 3.

spark.driver.maxResultSize=3072

Kaj laste, kiel deserto. Kiel ĝisdatigi Spark al versio 2.1 ĉe HortonWorks-distribuo - HDP 2.5.3.0. Ĉi tiu versio de HDP enhavas antaŭinstalitan version 2.0, sed ni iam decidis por ni mem, ke Spark evoluas sufiĉe aktive, kaj ĉiu nova versio korektas iujn cimojn kaj plie provizas pliajn funkciojn, inkluzive por la python API, do ni decidis, kio bezonas. esti farita estas ĝisdatigo.

Elŝutis la version de la oficiala retejo por Hadoop 2.7. Malfermu ĝin kaj metu ĝin en la HDP-dosierujon. Ni instalis la simbolligojn laŭbezone. Ni lanĉas ĝin - ĝi ne komenciĝas. Skribas tre neklaran eraron.

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

Post guglo, ni eksciis, ke Spark decidis ne atendi ĝis la naskiĝo de Hadoop, kaj decidis uzi la novan version de ĵerzo. Ili mem kverelas unu kun la alia pri tiu ĉi temo en JIRA. La solvo estis elŝuti ĵerza versio 1.17.1. Metu ĉi tion en la dosierujon de vazoj en SPARK_HOME, zipu ĝin denove kaj alŝutu ĝin al HDFS.

Ni ĉirkaŭiris ĉi tiun eraron, sed nova kaj sufiĉe flulinia aperis.

org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch application master

Samtempe ni provas ruli version 2.0 - ĉio estas en ordo. Provu diveni, kio okazas. Ni rigardis en la protokolojn de ĉi tiu aplikaĵo kaj vidis ion tian:

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

Ĝenerale, ial hdp.version ne solviĝis. Post guglo, ni trovis solvon. Vi devas iri al la agordoj de YARN en Ambari kaj aldoni parametron tie al kutima yarn-ejo:

hdp.version=2.5.3.0-37

Ĉi tiu magio helpis, kaj Fajrero ekflugis. Ni testis plurajn el niaj jupyter-tekkomputiloj. Ĉio funkcias. Ni estas pretaj por la unua Spark-leciono sabate (morgaŭ)!

DUP. Dum la leciono, alia problemo aperis. Iam, YARN ĉesis provizi ujojn por Spark. En YARN necesis korekti la parametron, kiu defaŭlte estis 0.2:

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

Tio estas, nur 20% de rimedoj partoprenis en la distribuado de rimedoj. Post ŝanĝi la parametrojn, ni reŝargis YARN. La problemo estis solvita kaj la ceteraj partoprenantoj ankaŭ povis ruli fajreran kuntekston.

fonto: www.habr.com