यार्नवर स्पार्क कॉन्फिगर करत आहे

हॅबर, हॅलो! काल दि अपाचे स्पार्कला समर्पित भेट, Rambler&Co मधील मुलांकडून, हे साधन कॉन्फिगर करण्याशी संबंधित सहभागींकडून बरेच प्रश्न होते. आम्ही त्याच्या पावलावर पाऊल ठेवून आमचे अनुभव सांगायचे ठरवले. विषय सोपा नाही - म्हणून आम्ही तुम्हाला तुमचा अनुभव टिप्पण्यांमध्ये सामायिक करण्यासाठी आमंत्रित करतो, कदाचित आम्ही काहीतरी चुकीचे समजू आणि वापरतो.

आपण स्पार्क कसा वापरतो याचा थोडा परिचय. आमचा तीन महिन्यांचा कार्यक्रम आहे "बिग डेटा स्पेशलिस्ट", आणि संपूर्ण दुसऱ्या मॉड्यूलमध्ये आमचे सहभागी या इन्स्ट्रुमेंटवर कार्य करतात. त्यानुसार, आमचे कार्य, आयोजक म्हणून, अशा परिस्थितीत वापरासाठी क्लस्टर तयार करणे आहे.

आमच्या वापराचे वैशिष्ठ्य म्हणजे स्पार्कवर एकाच वेळी काम करणार्‍या लोकांची संख्या संपूर्ण गटाच्या समान असू शकते. उदाहरणार्थ, सेमिनारमध्ये, जेव्हा प्रत्येकजण एकाच वेळी काहीतरी प्रयत्न करतो आणि आमच्या शिक्षकानंतर पुनरावृत्ती करतो. आणि हे खूप नाही - कधीकधी 40 लोकांपर्यंत. अशा वापराच्या प्रकरणाचा सामना करणार्‍या जगात कदाचित फारशा कंपन्या नाहीत.

पुढे, मी तुम्हाला काही कॉन्फिगरेशन पॅरामीटर्स कसे आणि का निवडले ते सांगेन.

चला अगदी सुरुवातीपासून सुरुवात करूया. स्पार्ककडे क्लस्टरवर चालण्यासाठी 3 पर्याय आहेत: स्टँडअलोन, मेसोस वापरणे आणि यार्न वापरणे. आम्ही तिसरा पर्याय निवडण्याचे ठरवले कारण ते आम्हाला समजले. आमच्याकडे आधीच हॅडूप क्लस्टर आहे. आमचे सहभागी आधीच त्याच्या आर्किटेक्चरशी चांगले परिचित आहेत. चला सूत वापरू.

spark.master=yarn

पुढे अधिक मनोरंजक. या 3 उपयोजन पर्यायांपैकी प्रत्येकामध्ये 2 उपयोजन पर्याय आहेत: क्लायंट आणि क्लस्टर. आधारित दस्तऐवजीकरण आणि इंटरनेटवरील विविध दुवे, आम्ही असा निष्कर्ष काढू शकतो की क्लायंट परस्पर कार्यासाठी योग्य आहे - उदाहरणार्थ, ज्युपीटर नोटबुकद्वारे, आणि क्लस्टर उत्पादन समाधानासाठी अधिक योग्य आहे. आमच्या बाबतीत, आम्हाला परस्परसंवादी कार्यात रस होता, म्हणून:

spark.deploy-mode=client

सर्वसाधारणपणे, आतापासून स्पार्क कसा तरी यार्नवर कार्य करेल, परंतु हे आमच्यासाठी पुरेसे नव्हते. आमच्याकडे मोठ्या डेटाबद्दल एक कार्यक्रम असल्याने, काहीवेळा सहभागींकडे संसाधनांच्या समान कापणीच्या चौकटीत जे काही प्राप्त झाले होते ते पुरेसे नसते. आणि मग आम्हाला एक मनोरंजक गोष्ट सापडली - डायनॅमिक संसाधन वाटप. थोडक्यात, मुद्दा हा आहे: जर तुमच्याकडे एखादे अवघड काम असेल आणि क्लस्टर विनामूल्य असेल (उदाहरणार्थ, सकाळी), तर स्पार्क हा पर्याय वापरल्याने तुम्हाला अतिरिक्त संसाधने मिळू शकतात. गरजेची गणना तेथे धूर्त सूत्रानुसार केली जाते. आम्ही तपशीलात जाणार नाही - ते चांगले कार्य करते.

spark.dynamicAllocation.enabled=true

आम्ही हे पॅरामीटर सेट केले आणि स्टार्टअप झाल्यावर स्पार्क क्रॅश झाला आणि सुरू झाला नाही. ते बरोबर आहे, कारण मला ते वाचावे लागले दस्तऐवजीकरण जास्त काळजीपूर्वक. हे नमूद करते की सर्वकाही ठीक होण्यासाठी, तुम्हाला अतिरिक्त पॅरामीटर देखील सक्षम करणे आवश्यक आहे.

spark.shuffle.service.enabled=true

त्याची गरज का आहे? जेव्हा आमच्या कामाला इतक्या संसाधनांची आवश्यकता नसते, तेव्हा स्पार्कने त्यांना सामान्य पूलमध्ये परत केले पाहिजे. जवळजवळ कोणत्याही MapReduce कार्यामध्ये सर्वात जास्त वेळ घेणारा टप्पा म्हणजे शफल स्टेज. हे पॅरामीटर तुम्हाला या टप्प्यावर व्युत्पन्न झालेला डेटा जतन करण्याची आणि त्यानुसार निष्पादकांना सोडण्याची परवानगी देते. आणि एक्झिक्युटर ही अशी प्रक्रिया आहे जी कामगारावरील प्रत्येक गोष्टीची गणना करते. त्यात विशिष्ट संख्येत प्रोसेसर कोर आणि विशिष्ट प्रमाणात मेमरी असते.

हे पॅरामीटर जोडले गेले आहे. सर्व काही कामी आल्यासारखे वाटले. हे लक्षात येण्याजोगे झाले की सहभागींना जेव्हा त्यांची गरज असते तेव्हा त्यांना अधिक संसाधने दिली जातात. परंतु आणखी एक समस्या उद्भवली - काही क्षणी इतर सहभागी जागे झाले आणि त्यांना स्पार्क वापरायचा होता, परंतु तेथे सर्व काही व्यस्त होते आणि ते नाखूष होते. ते समजू शकतात. आम्ही कागदपत्रे पाहू लागलो. असे दिसून आले की प्रक्रियेवर प्रभाव टाकण्यासाठी इतर अनेक पॅरामीटर्स वापरल्या जाऊ शकतात. उदाहरणार्थ, एक्झिक्युटर स्टँडबाय मोडमध्ये असल्यास, किती वेळानंतर त्यातून संसाधने घेतली जाऊ शकतात?

spark.dynamicAllocation.executorIdleTimeout=120s

आमच्या बाबतीत, जर तुमचे एक्झिक्युटर दोन मिनिटांसाठी काहीही करत नसतील, तर कृपया त्यांना सामान्य पूलमध्ये परत करा. परंतु हे पॅरामीटर नेहमीच पुरेसे नव्हते. हे स्पष्ट होते की ती व्यक्ती बर्याच काळापासून काहीही करत नव्हती आणि संसाधने मुक्त केली जात नव्हती. असे दिसून आले की एक विशेष पॅरामीटर देखील आहे - कॅशे केलेला डेटा असलेल्या एक्झिक्युटर्सची निवड कोणत्या वेळेनंतर करावी. डीफॉल्टनुसार, हे पॅरामीटर अनंत होते! आम्ही ते दुरुस्त केले.

spark.dynamicAllocation.cachedExecutorIdleTimeout=600s

म्हणजेच, जर तुमचे एक्झिक्युटर 5 मिनिटांसाठी काहीही करत नसतील तर त्यांना सामान्य पूलमध्ये द्या. या मोडमध्ये, मोठ्या संख्येने वापरकर्त्यांसाठी संसाधने सोडण्याची आणि जारी करण्याची गती सभ्य बनली आहे. असंतोषाचे प्रमाण कमी झाले आहे. परंतु आम्ही आणखी पुढे जाण्याचा निर्णय घेतला आणि प्रत्येक अनुप्रयोगासाठी जास्तीत जास्त एक्झिक्युटर्सची संख्या मर्यादित करण्याचा निर्णय घेतला - मूलत: प्रति प्रोग्राम सहभागी.

spark.dynamicAllocation.maxExecutors=19

आता, अर्थातच, दुसरीकडे असमाधानी लोक आहेत - "क्लस्टर निष्क्रिय आहे, आणि माझ्याकडे फक्त 19 एक्झिक्युटर आहेत," पण तुम्ही काय करू शकता? आम्हाला काही प्रकारचे योग्य संतुलन हवे आहे. तुम्ही सगळ्यांना खुश करू शकत नाही.

आणि आमच्या केसच्या वैशिष्ट्यांशी संबंधित आणखी एक छोटी कथा. कसे तरी, अनेक लोकांना व्यावहारिक धड्यासाठी उशीर झाला आणि काही कारणास्तव स्पार्क त्यांच्यासाठी सुरू झाला नाही. आम्ही विनामूल्य संसाधनांचे प्रमाण पाहिले - ते तेथे असल्याचे दिसते. स्पार्क सुरू झाला पाहिजे. सुदैवाने, तोपर्यंत सबकॉर्टेक्समध्ये कुठेतरी दस्तऐवजीकरण आधीच जोडले गेले होते, आणि आम्हाला आठवले की लॉन्च केल्यावर, स्पार्क एक बंदर शोधत आहे ज्यावर सुरू होईल. श्रेणीतील पहिले पोर्ट व्यस्त असल्यास, ते क्रमाने पुढील पोर्टवर जाते. जर ते विनामूल्य असेल तर ते कॅप्चर करते. आणि एक पॅरामीटर आहे जो यासाठी जास्तीत जास्त प्रयत्न दर्शवितो. डीफॉल्ट 16 आहे. ही संख्या वर्गातील आमच्या गटातील लोकांच्या संख्येपेक्षा कमी आहे. त्यानुसार, 16 प्रयत्नांनंतर, स्पार्कने हार मानली आणि सांगितले की मी सुरू करू शकत नाही. आम्ही ही सेटिंग दुरुस्त केली आहे.

spark.port.maxRetries=50

पुढे मी तुम्हाला काही सेटिंग्जबद्दल सांगेन ज्या आमच्या केसच्या वैशिष्ट्यांशी फारशी संबंधित नाहीत.

स्पार्क जलद सुरू करण्यासाठी, SPARK_HOME होम डिरेक्टरीमध्ये असलेल्या जार फोल्डरचे संग्रहण करून ते HDFS वर ठेवण्याची शिफारस केली जाते. मग तो कामगारांकडून या जर्निक्स लोड करण्यात वेळ घालवणार नाही.

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

जलद ऑपरेशनसाठी क्रिओचा सीरियलायझर म्हणून वापर करण्याची देखील शिफारस केली जाते. हे डीफॉल्टपेक्षा अधिक ऑप्टिमाइझ केलेले आहे.

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

आणि स्पार्कमध्ये एक दीर्घकालीन समस्या देखील आहे की ती बर्याचदा मेमरीमधून क्रॅश होते. बर्याचदा हे त्या क्षणी घडते जेव्हा कामगारांनी सर्वकाही मोजले आणि ड्रायव्हरला निकाल पाठवला. आम्ही हे पॅरामीटर स्वतःसाठी मोठे केले. डीफॉल्टनुसार, ते 1GB आहे, आम्ही ते 3 केले.

spark.driver.maxResultSize=3072

आणि शेवटी, मिष्टान्न म्हणून. हॉर्टनवर्क्स वितरण - HDP 2.1 वर आवृत्ती 2.5.3.0 वर स्पार्क कसे अद्यतनित करावे. एचडीपीच्या या आवृत्तीमध्ये पूर्व-स्थापित आवृत्ती 2.0 आहे, परंतु आम्ही एकदा स्वत: साठी ठरवले की स्पार्क सक्रियपणे विकसित होत आहे आणि प्रत्येक नवीन आवृत्ती काही दोष दूर करते तसेच पायथन API साठी अतिरिक्त वैशिष्ट्ये प्रदान करते, म्हणून आम्ही ठरवले की, कशाची आवश्यकता आहे पूर्ण करणे हे एक अद्यतन आहे.

Hadoop 2.7 साठी अधिकृत वेबसाइटवरून आवृत्ती डाउनलोड केली. ते अनझिप करा आणि HDP फोल्डरमध्ये ठेवा. आम्ही आवश्यकतेनुसार सिमलिंक्स स्थापित केले. आम्ही ते लाँच करतो - ते सुरू होत नाही. खूप विचित्र त्रुटी लिहितात.

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

गुगलिंग केल्यानंतर, आम्हाला कळले की स्पार्कने हडूपचा जन्म होईपर्यंत प्रतीक्षा न करण्याचा निर्णय घेतला आणि जर्सीची नवीन आवृत्ती वापरण्याचा निर्णय घेतला. ते स्वत: जिरामध्ये या विषयावर एकमेकांशी वाद घालतात. त्यावर उपाय होता डाउनलोड जर्सी आवृत्ती 1.17.1. हे SPARK_HOME मधील jars फोल्डरमध्ये ठेवा, ते पुन्हा झिप करा आणि HDFS वर अपलोड करा.

आम्हाला ही त्रुटी आढळली, परंतु एक नवीन आणि त्याऐवजी सुव्यवस्थित एक उद्भवली.

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

त्याच वेळी, आम्ही आवृत्ती 2.0 चालवण्याचा प्रयत्न करतो - सर्वकाही ठीक आहे. काय चालले आहे याचा अंदाज लावण्याचा प्रयत्न करा. आम्ही या अनुप्रयोगाच्या लॉगमध्ये पाहिले आणि असे काहीतरी पाहिले:

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

सर्वसाधारणपणे, काही कारणास्तव hdp.version निराकरण झाले नाही. गुगलिंग केल्यानंतर, आम्हाला एक उपाय सापडला. तुम्हाला अंबारी मधील यार्न सेटिंग्जमध्ये जाण्याची आणि कस्टम यार्न-साइटमध्ये पॅरामीटर जोडण्याची आवश्यकता आहे:

hdp.version=2.5.3.0-37

या जादूने मदत केली आणि स्पार्कने सुरुवात केली. आम्ही आमच्या अनेक ज्युपीटर लॅपटॉपची चाचणी केली. सर्व काही कार्यरत आहे. आम्ही शनिवारी (उद्या) पहिल्या स्पार्क धड्यासाठी तयार आहोत!

DUP. धड्यादरम्यान, आणखी एक समस्या समोर आली. काही ठिकाणी यार्नने स्पार्कसाठी कंटेनर देणे बंद केले. यार्नमध्ये पॅरामीटर दुरुस्त करणे आवश्यक होते, जे डीफॉल्टनुसार 0.2 होते:

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

म्हणजेच, संसाधनांच्या वितरणात केवळ 20% संसाधने सहभागी झाली. पॅरामीटर्स बदलल्यानंतर, आम्ही यार्न रीलोड केले. समस्येचे निराकरण झाले आणि उर्वरित सहभागी देखील स्पार्क संदर्भ चालविण्यात सक्षम झाले.

स्त्रोत: www.habr.com