Habr, kumusta! Kahapon sa , mula sa mga lalaki mula sa Rambler&Co, napakaraming tanong mula sa mga kalahok na may kaugnayan sa pag-configure ng tool na ito. Nagpasya kaming sumunod sa kanyang mga yapak at ibahagi ang aming karanasan. Ang paksa ay hindi madali - kaya inaanyayahan ka naming ibahagi ang iyong karanasan sa mga komento, marahil naiintindihan din namin at gumamit ng mali.
Isang maliit na panimula sa kung paano namin ginagamit ang Spark. Mayroon kaming tatlong buwang programa , at sa buong ikalawang modyul ang aming mga kalahok ay gumagawa sa instrumentong ito. Alinsunod dito, ang aming gawain, bilang mga tagapag-ayos, ay ihanda ang kumpol para magamit sa loob ng naturang kaso.
Ang kakaiba ng aming paggamit ay ang bilang ng mga taong sabay-sabay na nagtatrabaho sa Spark ay maaaring katumbas ng buong grupo. Halimbawa, sa isang seminar, kapag ang lahat ay sumubok ng isang bagay sa parehong oras at umuulit pagkatapos ng aming guro. At hindi ito marami - minsan hanggang 40 tao. Marahil ay hindi maraming kumpanya sa mundo ang nahaharap sa ganitong kaso ng paggamit.
Susunod, sasabihin ko sa iyo kung paano at bakit pinili namin ang ilang mga parameter ng config.
Magsimula tayo sa simula pa lang. May 3 opsyon ang Spark para tumakbo sa isang cluster: standalone, gamit ang Mesos, at gamit ang YARN. Nagpasya kaming piliin ang pangatlong opsyon dahil may katuturan ito sa amin. Mayroon na tayong hadoop cluster. Ang aming mga kalahok ay pamilyar na sa arkitektura nito. Gamitin natin YARN.
spark.master=yarnHigit pang mas kawili-wili. Ang bawat isa sa 3 opsyon sa pag-deploy na ito ay may 2 opsyon sa pag-deploy: client at cluster. Batay at iba't ibang mga link sa Internet, maaari nating tapusin na ang kliyente ay angkop para sa interactive na trabaho - halimbawa, sa pamamagitan ng jupyter notebook, at ang cluster ay mas angkop para sa mga solusyon sa produksyon. Sa aming kaso, interesado kami sa interactive na gawain, samakatuwid:
spark.deploy-mode=clientSa pangkalahatan, mula ngayon ay gagana ang Spark sa YARN, ngunit hindi ito sapat para sa amin. Dahil mayroon kaming isang programa tungkol sa malaking data, kung minsan ang mga kalahok ay hindi sapat sa kung ano ang nakuha sa loob ng balangkas ng isang pantay na paghiwa ng mga mapagkukunan. At pagkatapos ay nakakita kami ng isang kawili-wiling bagay - dynamic na paglalaan ng mapagkukunan. Sa madaling salita, ang punto ay ito: kung mayroon kang isang mahirap na gawain at ang kumpol ay libre (halimbawa, sa umaga), kung gayon ang paggamit ng pagpipiliang ito ay maaaring magbigay sa iyo ng karagdagang mapagkukunan. Ang pangangailangan ay kinakalkula doon ayon sa isang tusong formula. Hindi na kami magdedetalye - gumagana ito nang maayos.
spark.dynamicAllocation.enabled=trueItinakda namin ang parameter na ito, at sa pagsisimula ay nag-crash ang Spark at hindi nagsimula. Tama, dahil kailangan kong basahin ito mas maingat. Nakasaad dito na para maging ok ang lahat, kailangan mo ring paganahin ang karagdagang parameter.
spark.shuffle.service.enabled=trueBakit kailangan ito? Kapag ang aming trabaho ay hindi na nangangailangan ng napakaraming mapagkukunan, dapat ibalik ng Spark ang mga ito sa karaniwang pool. Ang pinaka-nakakaubos ng oras na yugto sa halos anumang gawain sa MapReduce ay ang yugto ng Shuffle. Binibigyang-daan ka ng parameter na ito na i-save ang data na nabuo sa yugtong ito at ilabas ang mga tagapagpatupad nang naaayon. At ang tagapagpatupad ay ang proseso na kinakalkula ang lahat ng bagay sa manggagawa. Mayroon itong tiyak na bilang ng mga core ng processor at isang tiyak na halaga ng memorya.
Ang parameter na ito ay naidagdag. Parang gumana ang lahat. Ito ay naging kapansin-pansin na ang mga kalahok ay talagang binibigyan ng mas maraming mapagkukunan kapag kailangan nila ang mga ito. Ngunit ang isa pang problema ay lumitaw - sa ilang mga punto ang ibang mga kalahok ay nagising at nais ding gumamit ng Spark, ngunit ang lahat ay abala doon, at sila ay hindi nasisiyahan. Maiintindihan sila. Sinimulan naming tingnan ang dokumentasyon. Ito ay lumabas na mayroon pa ring isang bilang ng mga parameter kung saan maaari mong maimpluwensyahan ang proseso. Halimbawa, kung ang tagapagpatupad ay nasa standby mode, pagkaraan ng anong oras maaaring kunin ang mga mapagkukunan mula dito?
spark.dynamicAllocation.executorIdleTimeout=120sSa aming kaso, kung walang gagawin ang iyong mga tagapagpatupad sa loob ng dalawang minuto, mangyaring ibalik sila sa karaniwang pool. Ngunit ang parameter na ito ay hindi palaging sapat. Malinaw na ang tao ay matagal nang walang ginagawa, at ang mga mapagkukunan ay hindi nalilibre. Ito ay naka-out na mayroon ding isang espesyal na parameter - pagkatapos ng anong oras upang piliin ang mga executors na naglalaman ng naka-cache na data. Bilang default, ang parameter na ito ay infinity! Itinama namin ito.
spark.dynamicAllocation.cachedExecutorIdleTimeout=600sIyon ay, kung ang iyong mga tagapagpatupad ay walang ginagawa sa loob ng 5 minuto, ibigay sila sa karaniwang pool. Sa mode na ito, ang bilis ng pagpapalabas at pag-isyu ng mga mapagkukunan para sa isang malaking bilang ng mga gumagamit ay naging disente. Ang dami ng kawalang-kasiyahan ay nabawasan. Ngunit nagpasya kaming magpatuloy at limitahan ang maximum na bilang ng mga tagapagpatupad sa bawat aplikasyon - mahalagang bawat kalahok ng programa.
spark.dynamicAllocation.maxExecutors=19Ngayon, siyempre, may mga hindi nasisiyahang tao sa kabilang panig - "ang kumpol ay walang ginagawa, at mayroon lang akong 19 na tagapagpatupad," ngunit ano ang magagawa mo? Kailangan namin ng ilang uri ng tamang balanse. Hindi mo mapasaya ang lahat.
At isa pang maliit na kuwento na may kaugnayan sa mga detalye ng aming kaso. Kahit papaano, ilang tao ang nahuli sa isang praktikal na aralin, at sa ilang kadahilanan ay hindi nagsimula ang Spark para sa kanila. Tiningnan namin ang dami ng libreng resources - parang nandoon. Dapat magsimula ang spark. Sa kabutihang palad, sa oras na iyon ang dokumentasyon ay naidagdag na sa subcortex sa isang lugar, at naalala namin na kapag sinimulan ang Spark, naghahanap ito ng port kung saan magsisimula. Kung abala ang unang port sa hanay, lilipat ito sa susunod sa pagkakasunud-sunod. Kung ito ay libre, ito ay kumukuha. At mayroong isang parameter na nagpapahiwatig ng maximum na bilang ng mga pagtatangka para dito. Ang default ay 16. Ang bilang ay mas mababa sa bilang ng mga tao sa aming grupo sa klase. Alinsunod dito, pagkatapos ng 16 na pagtatangka, sumuko si Spark at sinabing hindi ako makapagsimula. Naitama na namin ang setting na ito.
spark.port.maxRetries=50Susunod, sasabihin ko sa iyo ang tungkol sa ilang mga setting na hindi masyadong nauugnay sa mga detalye ng aming kaso.
Upang simulan ang Spark nang mas mabilis, inirerekumenda na i-archive ang jars folder na matatagpuan sa SPARK_HOME home directory at ilagay ito sa HDFS. Pagkatapos ay hindi siya mag-aaksaya ng oras sa pagkarga ng mga jarnik na ito ng mga manggagawa.
spark.yarn.archive=hdfs:///tmp/spark-archive.zipInirerekomenda din na gamitin ang kryo bilang serializer para sa mas mabilis na operasyon. Ito ay mas na-optimize kaysa sa default.
spark.serializer=org.apache.spark.serializer.KryoSerializerAt mayroon ding matagal nang problema sa Spark na madalas itong nag-crash mula sa memorya. Kadalasan nangyayari ito sa sandaling nakalkula ng mga manggagawa ang lahat at ipinadala ang resulta sa driver. Ginawa naming mas malaki ang parameter na ito para sa aming sarili. Bilang default, ito ay 1GB, ginawa namin itong 3.
spark.driver.maxResultSize=3072At panghuli, bilang panghimagas. Paano i-update ang Spark sa bersyon 2.1 sa pamamahagi ng HortonWorks - HDP 2.5.3.0. Ang bersyon na ito ng HDP ay naglalaman ng isang paunang naka-install na bersyon 2.0, ngunit minsan naming napagpasyahan para sa aming sarili na ang Spark ay aktibong umuunlad, at ang bawat bagong bersyon ay nag-aayos ng ilang mga bug at nagbibigay ng karagdagang mga tampok, kabilang ang para sa python API, kaya nagpasya kami, kung ano ang kailangang ang gagawin ay isang update.
Na-download ang bersyon mula sa opisyal na website para sa Hadoop 2.7. I-unzip ito at ilagay sa HDP folder. Nag-install kami ng mga symlink kung kinakailangan. Inilunsad namin ito - hindi ito nagsisimula. Sumulat ng isang hindi malinaw na error.
java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfigPagkatapos ng googling, nalaman namin na nagpasya si Spark na huwag maghintay hanggang sa ipanganak si Hadoop, at nagpasya na gamitin ang bagong bersyon ng jersey. Sila mismo ang nagtatalo sa isa't isa tungkol sa paksang ito sa JIRA. Ang solusyon ay ang pag-download . Ilagay ito sa folder ng jars sa SPARK_HOME, i-zip itong muli at i-upload ito sa HDFS.
Nalampasan namin ang error na ito, ngunit lumitaw ang isang bago at medyo naka-streamline.
org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch application masterKasabay nito, sinusubukan naming patakbuhin ang bersyon 2.0 - lahat ay ok. Subukang hulaan kung ano ang nangyayari. Tiningnan namin ang mga log ng application na ito at may nakita kaming ganito:
/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jarSa pangkalahatan, sa ilang kadahilanan ay hindi nalutas ang hdp.version. Pagkatapos mag-googling, nakakita kami ng solusyon. Kailangan mong pumunta sa mga setting ng YARN sa Ambari at magdagdag ng parameter doon sa custom na yarn-site:
hdp.version=2.5.3.0-37Nakatulong ang magic na ito, at nag-take off si Spark. Sinubukan namin ang ilan sa aming mga jupyter na laptop. Lahat ay gumagana. Handa na kami para sa unang Spark lesson sa Sabado (bukas)!
DUP. Sa panahon ng aralin, isa pang problema ang dumating sa liwanag. Sa ilang mga punto, ang YARN ay huminto sa pagbibigay ng mga lalagyan para sa Spark. Sa YARN kinakailangan na iwasto ang parameter, na bilang default ay 0.2:
yarn.scheduler.capacity.maximum-am-resource-percent=0.8 Iyon ay, 20% lamang ng mga mapagkukunan ang lumahok sa pamamahagi ng mga mapagkukunan. Matapos baguhin ang mga parameter, ni-reload namin ang YARN. Nalutas ang problema at ang iba pang kalahok ay nakapagpatakbo rin ng konteksto ng spark.
Pinagmulan: www.habr.com
