YARN पर स्पार्क को कॉन्फ़िगर करना

हबर, नमस्ते! कल पर अपाचे स्पार्क को समर्पित मीटअपरैम्बलर एंड कंपनी के लोगों से, प्रतिभागियों से इस टूल को कॉन्फ़िगर करने से संबंधित बहुत सारे प्रश्न थे। हमने उनके नक्शेकदम पर चलने और अपना अनुभव साझा करने का फैसला किया। विषय आसान नहीं है - इसलिए हम आपको टिप्पणियों में अपना अनुभव साझा करने के लिए आमंत्रित करते हैं, हो सकता है कि हम भी कुछ गलत समझें और उपयोग करें।

हम स्पार्क का उपयोग कैसे करते हैं इसका एक छोटा सा परिचय। हमारा तीन महीने का कार्यक्रम है "बड़े डेटा विशेषज्ञ", और दूसरे मॉड्यूल के दौरान हमारे प्रतिभागी इस उपकरण पर काम करते हैं। तदनुसार, आयोजकों के रूप में हमारा कार्य, ऐसे मामले में उपयोग के लिए क्लस्टर तैयार करना है।

हमारे उपयोग की ख़ासियत यह है कि स्पार्क पर एक साथ काम करने वाले लोगों की संख्या पूरे समूह के बराबर हो सकती है। उदाहरण के लिए, एक सेमिनार में, जब हर कोई एक ही समय में कुछ करने की कोशिश करता है और हमारे शिक्षक के बाद दोहराता है। और यह बहुत अधिक नहीं है - कभी-कभी 40 लोगों तक। दुनिया में शायद ऐसी बहुत सी कंपनियाँ नहीं हैं जो इस तरह के उपयोग के मामले का सामना करती हों।

आगे, मैं आपको बताऊंगा कि हमने कुछ कॉन्फ़िगरेशन पैरामीटर कैसे और क्यों चुने।

आइए बिल्कुल शुरुआत से शुरू करें। स्पार्क के पास क्लस्टर पर चलने के लिए 3 विकल्प हैं: स्टैंडअलोन, मेसोस का उपयोग करना, और YARN का उपयोग करना। हमने तीसरा विकल्प चुनने का फैसला किया क्योंकि यह हमें समझ में आया। हमारे पास पहले से ही एक हडूप क्लस्टर है। हमारे प्रतिभागी पहले से ही इसकी वास्तुकला से अच्छी तरह परिचित हैं। आइए यार्न का उपयोग करें।

spark.master=yarn

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

spark.deploy-mode=client

सामान्य तौर पर, अब से स्पार्क किसी तरह YARN पर काम करेगा, लेकिन यह हमारे लिए पर्याप्त नहीं था। चूँकि हमारे पास बड़े डेटा के बारे में एक कार्यक्रम है, कभी-कभी प्रतिभागियों के पास संसाधनों के एक समान टुकड़े के ढांचे के भीतर जो कुछ भी प्राप्त हुआ था वह पर्याप्त नहीं था। और फिर हमें एक दिलचस्प चीज़ मिली - गतिशील संसाधन आवंटन। संक्षेप में, मुद्दा यह है: यदि आपके पास एक कठिन कार्य है और क्लस्टर मुफ़्त है (उदाहरण के लिए, सुबह में), तो इस विकल्प का उपयोग करके स्पार्क आपको अतिरिक्त संसाधन दे सकता है। वहां आवश्यकता की गणना एक चतुराईपूर्ण फार्मूले के अनुसार की जाती है। हम विवरण में नहीं जाएंगे - यह अच्छी तरह से काम करता है।

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

और अंत में, मिठाई के रूप में। हॉर्टनवर्क्स वितरण पर स्पार्क को संस्करण 2.1 में कैसे अपडेट करें - एचडीपी 2.5.3.0। एचडीपी के इस संस्करण में एक पूर्व-स्थापित संस्करण 2.0 है, लेकिन हमने एक बार अपने लिए निर्णय लिया कि स्पार्क काफी सक्रिय रूप से विकसित हो रहा है, और प्रत्येक नया संस्करण कुछ बग्स को ठीक करता है और अतिरिक्त सुविधाएँ प्रदान करता है, जिसमें पायथन एपीआई भी शामिल है, इसलिए हमने निर्णय लिया कि क्या करने की आवश्यकता है किया जाना एक अद्यतन है.

Hadoop 2.7 के लिए आधिकारिक वेबसाइट से संस्करण डाउनलोड किया गया। इसे अनजिप करके एचडीपी फोल्डर में डाल दें। हमने आवश्यकतानुसार सिम्लिंक स्थापित किए। हम इसे लॉन्च करते हैं - यह प्रारंभ नहीं होता है। बहुत अस्पष्ट त्रुटि लिखता है.

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

गूगल करने के बाद, हमें पता चला कि स्पार्क ने Hadoop के जन्म तक इंतजार न करने का फैसला किया, और जर्सी के नए संस्करण का उपयोग करने का फैसला किया। वे स्वयं JIRA में इस विषय पर एक दूसरे से बहस करते हैं। समाधान डाउनलोड करना था जर्सी संस्करण 1.17.1. इसे SPARK_HOME में जार फ़ोल्डर में रखें, इसे फिर से ज़िप करें और 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 हल नहीं हुआ। गूगल पर खोजने के बाद हमें इसका समाधान मिल गया। आपको अंबारी में YARN सेटिंग्स में जाना होगा और वहां कस्टम यार्न-साइट पर एक पैरामीटर जोड़ना होगा:

hdp.version=2.5.3.0-37

इस जादू से मदद मिली और स्पार्क ने उड़ान भरी। हमने अपने कई ज्यूपिटर लैपटॉप का परीक्षण किया। सब कुछ काम कर रहा है. हम शनिवार (कल) को पहले स्पार्क पाठ के लिए तैयार हैं!

युपीडी. पाठ के दौरान एक और समस्या सामने आई। कुछ बिंदु पर, YARN ने स्पार्क के लिए कंटेनर उपलब्ध कराना बंद कर दिया। YARN में पैरामीटर को सही करना आवश्यक था, जो डिफ़ॉल्ट रूप से 0.2 था:

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

अर्थात्, संसाधनों के वितरण में केवल 20% संसाधनों ने भाग लिया। पैरामीटर बदलने के बाद, हमने YARN को पुनः लोड किया। समस्या हल हो गई और बाकी प्रतिभागी भी स्पार्क कॉन्टेक्स्ट चलाने में सक्षम हो गए।

स्रोत: www.habr.com