Inasanidi Spark kwenye UZI

Habr, habari! Jana tarehe Mkutano wa Apache Spark, kutoka kwa wavulana katika Rambler&Co, walipokea maswali machache kutoka kwa washiriki kuhusiana na kusanidi zana hii. Tuliamua kufuata nyayo na kubadilishana uzoefu wetu. Ni mada tata, kwa hivyo tunakuhimiza ushiriki uzoefu wako katika maoni; labda sisi pia, hatuelewi na kutumia kitu vibaya.

Utangulizi wa haraka wa jinsi tunavyotumia Spark. Tuna programu ya miezi mitatu. Mtaalamu Mkuu wa Takwimu, na washiriki wetu wanafanya kazi na zana hii katika moduli nzima ya pili. Kwa hivyo, kazi yetu kama waandaaji ni kuandaa nguzo kwa ajili ya matumizi katika utafiti huu wa kifani.

Kipengele cha kipekee cha kesi yetu ya utumiaji ni kwamba idadi ya watu wanaofanya kazi kwenye Spark wakati huo huo inaweza kuwa sawa na kikundi kizima. Kwa mfano, wakati wa semina, wakati kila mtu anajaribu kitu kwa wakati mmoja na kurudia kile mwalimu wetu anafanya. Na hiyo ni nyingi sana - wakati mwingine hadi watu 40. Labda hakuna kampuni nyingi ulimwenguni ambazo hukutana na kesi ya aina hii ya utumiaji.

Ifuatayo, nitakuambia jinsi na kwa nini tulichagua vigezo fulani vya usanidi.

Hebu tuanze tangu mwanzo. Spark ina chaguzi tatu za kukimbia kwenye nguzo: ili kujitegemea, kutumia Mesos, na kutumia YARN. Tuliamua kwenda na chaguo la tatu kwa sababu lilikuwa na maana kwetu. Tayari tunayo nguzo ya Hadoop, na washiriki wetu tayari wanafahamu usanifu wake. Wacha tutumie UZI.

spark.master=yarn

Sasa inakuwa ya kuvutia zaidi. Kila moja ya chaguo hizi 3 za uwekaji ina chaguo 2 za uwekaji: mteja na nguzo. Kulingana na nyaraka Kulingana na viungo mbalimbali mtandaoni, tunaweza kuhitimisha kuwa mteja anafaa kwa kazi wasilianifu—kwa mfano, kupitia daftari la Jupyter—wakati nguzo hiyo inafaa zaidi kwa suluhu za uzalishaji. Kwa upande wetu, tulipendezwa na kazi ya maingiliano, kwa hivyo:

spark.deploy-mode=client

Spark kwa ujumla atakuwa akifanya kazi kwenye UZI kuanzia sasa na kuendelea, lakini hiyo haikutosha kwetu. Kwa kuwa mpango wetu unahusu data kubwa, wakati mwingine washiriki waliona kuwa rasilimali zilizosambazwa kwa usawa hazikutosha. Na kisha tukagundua kitu cha kufurahisha: ugawaji wa rasilimali wenye nguvu. Kwa kifupi, inafanya kazi kama hii: ikiwa una kazi ngumu na nguzo ni bure (kwa mfano, asubuhi), Spark inaweza kutumia kipengele hiki kutenga rasilimali za ziada. Haja inahesabiwa kwa kutumia formula ya busara. Hatutaingia katika maelezo, lakini inafanya kazi vizuri.

spark.dynamicAllocation.enabled=true

Tuliweka kigezo hiki, na Spark ilianguka na haikuanza. Hiyo ni kweli, kwa sababu tulipaswa kusoma nyaraka Zingatia sana. Inasema kwamba kwa kila kitu kufanya kazi vizuri, unahitaji kuwezesha mpangilio wa ziada.

spark.shuffle.service.enabled=true

Kwa nini inahitajika? Wakati kazi yetu haihitaji tena kiasi kikubwa cha rasilimali, Spark inapaswa kuzirudisha kwenye bwawa la pamoja. Hatua inayohitaji nguvu kazi kubwa katika takriban kazi yoyote ya MapReduce ni hatua ya Changanya. Kigezo hiki huturuhusu kuhifadhi data iliyotolewa wakati wa hatua hii na, ipasavyo, kuwaweka huru watekelezaji. Mtekelezaji ni mchakato unaojumuisha kila kitu juu ya mfanyakazi. Ina idadi fulani ya cores processor na kiasi fulani cha kumbukumbu.

Tuliongeza parameter hii. Kila kitu kilionekana kufanya kazi. Ilibainika kuwa washiriki walikuwa wakipata rasilimali zaidi wakati walizihitaji. Lakini shida nyingine ilitokea: wakati fulani, washiriki wengine wangeamka na pia wanataka kutumia Spark, lakini kila kitu kilikuwa na kazi, na hawakuwa na furaha. Inaeleweka. Tulianza kuangalia nyaraka. Ilibainika kuwa kulikuwa na vigezo vingine kadhaa ambavyo vinaweza kutumika kushawishi mchakato. Kwa mfano, ikiwa mtekelezaji hafanyi kitu, ni baada ya muda gani rasilimali zinaweza kuchukuliwa kutoka kwake?

spark.dynamicAllocation.executorIdleTimeout=120s

Kwa upande wetu, ikiwa watekelezaji wako hawafanyi kitu kwa dakika mbili, tafadhali warudishe kwenye bwawa la pamoja. Lakini hata parameter hii haikuwa ya kutosha kila wakati. Ilikuwa wazi kuwa mtumiaji amekuwa bila kufanya kitu kwa muda mrefu, na rasilimali hazikuwa zikitolewa. Ilibainika kuwa kulikuwa na kigezo kingine maalum - wakati ambapo watekelezaji walio na data iliyohifadhiwa wanapaswa kutupwa. Kwa chaguo-msingi, kigezo hiki kiliwekwa kwa ukomo! Tuliirekebisha.

spark.dynamicAllocation.cachedExecutorIdleTimeout=600s

Kwa hivyo, ikiwa watekelezaji wako hawafanyi chochote kwa dakika 5, wape kwenye bwawa la pamoja. Katika hali hii, kasi ya kutolewa kwa rasilimali na ugawaji kwa idadi kubwa ya watumiaji ikawa nzuri. Idadi ya malalamiko ilipungua. Lakini tuliamua kwenda mbali zaidi na kudhibiti idadi ya juu zaidi ya watekelezaji kwa kila ombi—kimsingi kwa kila mshiriki wa programu.

spark.dynamicAllocation.maxExecutors=19

Sasa, bila shaka, kuna baadhi ya watu wasioridhika upande ule mwingine—“kundi halina kazi, na nina watekelezaji 19 pekee”—lakini unaweza kufanya nini? Aina fulani ya usawa inahitajika. Huwezi kumfurahisha kila mtu.

Hapa kuna hadithi nyingine fupi inayohusiana na maalum ya kesi yetu. Wakati mmoja, watu kadhaa walichelewa kwa somo la vitendo, na kwa sababu fulani, Spark hakutaka kuanza. Tulikagua idadi ya rasilimali zisizolipishwa—ilionekana kuwa na baadhi. Cheche inapaswa kuanza. Kwa bahati nzuri, kufikia hatua hiyo, hati zilikuwa tayari zimehifadhiwa mahali fulani nyuma ya akili zetu, na tukakumbuka kwamba Spark inapoanza, inatafuta bandari kuanza. Ikiwa lango la kwanza katika safu limekaliwa, linaendelea hadi lingine katika mlolongo. Ikiwa ni bure, huichukua. Kuna kigezo kinachobainisha idadi ya juu zaidi ya majaribio kwa hili. Kwa chaguo-msingi, ni 16. Nambari hii ni ndogo kuliko idadi ya watu katika kikundi chetu kwenye somo. Ipasavyo, baada ya majaribio 16, Spark alikata tamaa na kusema haiwezi kuanza. Tulirekebisha parameter hii.

spark.port.maxRetries=50

Ifuatayo, nitazungumza juu ya mipangilio mingine ambayo haihusiani sana na maalum ya kesi yetu.

Ili kuharakisha uanzishaji wa Spark, inashauriwa kuweka folda ya mitungi kwenye kumbukumbu kwenye saraka yako ya SPARK_HOME na kuiweka kwenye HDFS. Kwa njia hii, Spark haitapoteza muda kupakua mitungi hii kwa kila mfanyakazi.

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

Kwa utendakazi wa haraka, pia inashauriwa kutumia kryo kama kiboreshaji. Imeboreshwa zaidi kuliko ile chaguo-msingi.

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

Spark pia ina tatizo la muda mrefu: mara nyingi huanguka kwenye kumbukumbu. Hii mara nyingi hutokea wakati wafanyakazi wamekamilisha mahesabu yao na kutuma matokeo kwa dereva. Tumeongeza kigezo hiki. Kwa chaguo-msingi, ni 1GB, lakini tumeiongeza hadi 3GB.

spark.driver.maxResultSize=3072

Na hatimaye, kama dokezo la mwisho, jinsi ya kuboresha Spark hadi toleo la 2.1 kwenye usambazaji wa HortonWorks—HDP 2.5.3.0. Toleo hili la HDP linakuja likiwa limesakinishwa awali na toleo la 2.0, lakini tuliamua kwamba Spark inaendelezwa kikamilifu, na kila toleo jipya hurekebisha baadhi ya hitilafu na kuongeza vipengele vya ziada, ikiwa ni pamoja na API ya Python, kwa hivyo tuliamua kwamba sasisho lilikuwa sawa.

Tulipakua toleo la Hadoop 2.7 kutoka kwa tovuti rasmi. Tuliifungua na kuiweka kwenye folda ya HDP. Tunaweka symlink kwa usahihi. Tulijaribu kuiendesha, lakini haikuanza. Ilirudisha kosa la kutatanisha sana.

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

Baada ya kuvinjari, tuligundua kwamba Spark alikuwa ameamua kutongoja Hadoop kuwa tayari na alikuwa ameamua kutumia toleo jipya la Jersey. Walikuwa wakibishana wao kwa wao kuhusu hilo huko JIRA. Suluhisho lilikuwa kuipakua. Toleo la Jersey 1.17.1. Weka hii kwenye folda ya mitungi katika SPARK_HOME, ifunge tena, na kuiweka kwenye HDFS.

Tulipata hitilafu hii, lakini mpya na ya kukwepa iliibuka.

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

Tulijaribu kuendesha toleo la 2.0, na kila kitu kilikuwa sawa. Nadhani nini kinaendelea. Tuliangalia kumbukumbu za programu na tukaona kitu kama hiki:

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

Kwa hivyo, kwa sababu fulani, hdp.version haikutatuliwa. Baada ya googling, tulipata suluhisho. Nenda kwa mipangilio ya UZI katika Ambari na uongeze kigezo kifuatacho kwenye tovuti maalum ya uzi:

hdp.version=2.5.3.0-37

Uchawi huu ulifanya kazi, na Spark akaondoka. Tulijaribu daftari zetu kadhaa za Jupyter. Kila kitu hufanya kazi. Tuko tayari kwa somo la kwanza la Spark Jumamosi (kesho)!

DUPSuala jingine liliibuka wakati wa darasa. Wakati fulani, YARN iliacha kupeana vyombo vya Spark. Kigezo katika UZI, ambacho kiliwekwa kuwa 0.2 kwa chaguo-msingi, kilihitaji kurekebishwa:

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

Hiyo ni, ni 20% tu ya rasilimali zilikuwa zinashiriki katika usambazaji wa rasilimali. Baada ya kubadilisha vigezo, tulianza tena YARN. Suala hilo lilitatuliwa, na washiriki waliobaki waliweza kuzindua muktadha wa cheche.

Chanzo: mapenzi.com