Habr, sveiks! Vakar uz , no Rambler&Co puišiem, bija diezgan daudz jautājumu no dalībniekiem saistībā ar šī rīka konfigurēšanu. Mēs nolēmām sekot viņa pēdās un dalīties pieredzē. Tēma nav viegla - tāpēc aicinām komentāros dalīties pieredzē, varbūt arī mēs kaut ko saprotam un lietojam nepareizi.
Neliels ievads par to, kā mēs izmantojam Spark. Mums ir trīs mēnešu programma , un visā otrajā modulī mūsu dalībnieki strādā pie šī instrumenta. Attiecīgi mūsu kā organizatoru uzdevums ir sagatavot klasteru izmantošanai šāda gadījuma ietvaros.
Mūsu izmantošanas īpatnība ir tāda, ka cilvēku skaits, kas vienlaikus strādā Spark, var būt vienāds ar visu grupu. Piemēram, seminārā, kad visi kaut ko mēģina vienlaikus un atkārto pēc mūsu skolotāja. Un tas nav daudz - dažreiz līdz 40 cilvēkiem. Iespējams, ka pasaulē nav daudz uzņēmumu, kas saskaras ar šādu lietošanas gadījumu.
Tālāk es jums pastāstīšu, kā un kāpēc mēs izvēlējāmies noteiktus konfigurācijas parametrus.
Sāksim no paša sākuma. Spark ir 3 darbības iespējas klasterī: atsevišķa, izmantojot Mesos un izmantojot YARN. Mēs nolēmām izvēlēties trešo variantu, jo tas mums bija loģiski. Mums jau ir hadoop klasteris. Mūsu dalībnieki jau labi pārzina tās arhitektūru. Izmantosim DZIJU.
spark.master=yarnVēl interesantāk. Katrai no šīm 3 izvietošanas opcijām ir 2 izvietošanas opcijas: klients un klasteris. Pamatojoties un dažādas saites internetā, varam secināt, ka klients ir piemērots interaktīvam darbam - piemēram, caur jupyter notebook, un klasteris ir vairāk piemērots ražošanas risinājumiem. Mūsu gadījumā mūs interesēja interaktīvs darbs, tāpēc:
spark.deploy-mode=clientKopumā turpmāk Spark kaut kā strādās pie DZIJAS, bet ar to mums nepietika. Tā kā mums ir programma par lielajiem datiem, reizēm dalībniekiem nepietika ar to, kas tika iegūts vienmērīgas resursu sadalīšanas ietvaros. Un tad mēs atradām interesantu lietu - dinamisku resursu piešķiršanu. Īsāk sakot, būtība ir šāda: ja jums ir sarežģīts uzdevums un klasteris ir brīvs (piemēram, no rīta), tad, izmantojot šo opciju, Spark var sniegt papildu resursus. Tur pēc viltīgas formulas tiek aprēķināta nepieciešamība. Mēs neiedziļināsimies detaļās — tas darbojas labi.
spark.dynamicAllocation.enabled=trueMēs iestatījām šo parametru, un startēšanas laikā Spark avarēja un nesākas. Tieši tā, jo man tas bija jāizlasa rūpīgāk. Tajā teikts, ka, lai viss būtu kārtībā, ir jāiespējo arī papildu parametrs.
spark.shuffle.service.enabled=trueKāpēc tas ir vajadzīgs? Kad mūsu darbs vairs neprasa tik daudz resursu, Spark vajadzētu tos atgriezt kopējā baseinā. Vislaikietilpīgākais posms gandrīz jebkurā MapReduce uzdevumā ir jaukšanas posms. Šis parametrs ļauj saglabāt datus, kas tiek ģenerēti šajā posmā, un attiecīgi atbrīvot izpildītājus. Un izpildītājs ir process, kas visu aprēķina uz strādnieka. Tam ir noteikts procesora kodolu skaits un noteikts atmiņas apjoms.
Šis parametrs ir pievienots. Šķita, ka viss darbojas. Kļuva pamanāms, ka dalībniekiem faktiski tika piešķirti vairāk resursu, kad tie bija nepieciešami. Taču radās cita problēma – kādā brīdī pamodās citi dalībnieki un arī gribēja izmantot Spark, taču tur viss bija aizņemts, un viņi bija neapmierināti. Viņus var saprast. Sākām skatīt dokumentāciju. Izrādījās, ka ir virkne citu parametru, ar kuriem var ietekmēt procesu. Piemēram, ja izpildītājs ir gaidīšanas režīmā, pēc kāda laika no tā var izņemt resursus?
spark.dynamicAllocation.executorIdleTimeout=120sMūsu gadījumā, ja jūsu izpildītāji divas minūtes neko nedara, tad lūdzu atgrieziet tos kopējā baseinā. Bet ar šo parametru ne vienmēr bija pietiekami. Bija skaidrs, ka cilvēks jau ilgu laiku neko nav darījis, un resursi neatbrīvojas. Izrādījās, ka ir arī īpašs parametrs - pēc kura laika atlasīt izpildītājus, kas satur kešatmiņā saglabātos datus. Pēc noklusējuma šis parametrs bija bezgalība! Mēs to labojām.
spark.dynamicAllocation.cachedExecutorIdleTimeout=600sTas ir, ja jūsu izpildītāji neko nedara 5 minūtes, nododiet tos kopējam baseinam. Šajā režīmā lielam lietotāju skaitam resursu atbrīvošanas un izsniegšanas ātrums ir kļuvis pienācīgs. Neapmierinātības apjoms ir samazinājies. Bet mēs nolēmām iet tālāk un ierobežot maksimālo izpildītāju skaitu uz vienu pieteikumu – būtībā uz vienu programmas dalībnieku.
spark.dynamicAllocation.maxExecutors=19Tagad, protams, otrā pusē ir neapmierinātie - "klasteris ir dīkstāvē, un man ir tikai 19 izpildītāji", bet ko jūs varat darīt? Vajag kaut kādu pareizu līdzsvaru. Nevar visus iepriecināt.
Un vēl viens neliels stāsts, kas saistīts ar mūsu lietas specifiku. Kaut kā uz praktisko nodarbību aizkavējās vairāki cilvēki, kuriem nez kāpēc Spark nestartēja. Apskatījām brīvo resursu apjomu – šķiet, ka ir. Spark vajadzētu sākt. Par laimi, līdz tam laikam dokumentācija jau bija kaut kur pievienota subkorteksam, un mēs atcerējāmies, ka palaižot Spark meklē portu, no kura sākt. Ja diapazona pirmais ports ir aizņemts, tas secībā pāriet uz nākamo. Ja tas ir bezmaksas, tas tver. Un ir parametrs, kas norāda maksimālo mēģinājumu skaitu. Noklusējums ir 16. Skaits ir mazāks par cilvēku skaitu mūsu grupā klasē. Attiecīgi pēc 16 mēģinājumiem Spark padevās un teica, ka nevaru startēt. Mēs esam labojuši šo iestatījumu.
spark.port.maxRetries=50Tālāk es jums pastāstīšu par dažiem iestatījumiem, kas nav īpaši saistīti ar mūsu lietas specifiku.
Lai ātrāk palaistu Spark, ieteicams arhivēt mapi jars, kas atrodas SPARK_HOME mājas direktorijā, un ievietot to HDFS. Tad viņš netērēs laiku, iekraujot šos jarnikus strādniekiem.
spark.yarn.archive=hdfs:///tmp/spark-archive.zipIr arī ieteicams izmantot kryo kā serializatoru ātrākai darbībai. Tas ir vairāk optimizēts nekā noklusējuma.
spark.serializer=org.apache.spark.serializer.KryoSerializerUn ar Spark ir arī ilgstoša problēma, ka tā bieži avarē no atmiņas. Nereti tas notiek brīdī, kad strādnieki visu ir aprēķinājuši un rezultātu nosūta šoferim. Mēs paši sev palielinājām šo parametru. Pēc noklusējuma tas ir 1 GB, mēs to izveidojām par 3.
spark.driver.maxResultSize=3072Un visbeidzot, kā deserts. Kā atjaunināt Spark uz versiju 2.1 HortonWorks izplatīšanā — HDP 2.5.3.0. Šajā HDP versijā ir iepriekš instalēta versija 2.0, taču mēs paši nolēmām, ka Spark attīstās diezgan aktīvi, un katra jaunā versija izlabo dažas kļūdas, kā arī nodrošina papildu funkcijas, tostarp python API, tāpēc mēs nolēmām, kas ir nepieciešams jāpaveic, ir atjauninājums.
Lejupielādēta versija no oficiālās vietnes Hadoop 2.7. Izskrūvējiet to un ievietojiet HDP mapē. Mēs uzstādījām simboliskās saites pēc vajadzības. Mēs to palaižam — tas nesākas. Raksta ļoti neskaidru kļūdu.
java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfigPēc googlēšanas mēs noskaidrojām, ka Spark nolēma negaidīt, līdz piedzims Hadoop, un nolēma izmantot jauno krekla versiju. Viņi paši savā starpā strīdas par šo tēmu JIRA. Risinājums bija lejupielādēt . Ievietojiet to mapē SPARK_HOME burkas, saspiediet to vēlreiz un augšupielādējiet to HDFS.
Mēs apiejām šo kļūdu, taču radās jauna un diezgan racionalizēta kļūda.
org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch application masterTajā pašā laikā mēs cenšamies palaist versiju 2.0 - viss ir kārtībā. Mēģiniet uzminēt, kas notiek. Mēs izskatījām šīs lietojumprogrammas žurnālus un redzējām kaut ko līdzīgu:
/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jarVispār nez kāpēc hdp.version neatrisinājās. Pēc googlēšanas mēs atradām risinājumu. Jums ir jāatver Ambari YARN iestatījumi un jāpievieno parametrs pielāgotai dzijas vietnei:
hdp.version=2.5.3.0-37Šī maģija palīdzēja, un Spark pacēlās gaisā. Mēs pārbaudījām vairākus mūsu Jupyter klēpjdatorus. Viss darbojas. Esam gatavi pirmajai Spark nodarbībai sestdien (rīt)!
DUP. Nodarbības laikā atklājās vēl viena problēma. Kādā brīdī YARN pārtrauca nodrošināt Spark konteinerus. Programmā YARN bija jālabo parametrs, kas pēc noklusējuma bija 0.2:
yarn.scheduler.capacity.maximum-am-resource-percent=0.8
Tas ir, tikai 20% resursu piedalījās resursu sadalē. Pēc parametru maiņas pārlādējām DZIJU. Problēma tika atrisināta, un arī pārējie dalībnieki varēja palaist kontekstu ar dzirksti.
Avots: www.habr.com