YARN मा स्पार्क कन्फिगर गर्दै

Habr, नमस्कार! हिजो मा Apache Spark लाई समर्पित भेटघाट, Rambler&Co का केटाहरूबाट, यो उपकरण कन्फिगर गर्न सम्बन्धित सहभागीहरूबाट धेरै प्रश्नहरू थिए। हामीले उहाँको पाइला पछ्याउने र हाम्रो अनुभव साझा गर्ने निर्णय गर्यौं। विषय सजिलो छैन - त्यसैले हामी तपाइँलाई टिप्पणीहरूमा तपाइँको अनुभव साझा गर्न आमन्त्रित गर्दछौं, हुनसक्छ हामी पनि बुझ्छौं र केहि गलत प्रयोग गर्दछौं।

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

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

अर्को, म तपाईंलाई कसरी र किन हामीले निश्चित कन्फिगरेसन प्यारामिटरहरू चयन गर्यौं भनेर बताउनेछु।

सुरुदेखि नै सुरु गरौं। स्पार्कसँग क्लस्टरमा चलाउन ३ विकल्पहरू छन्: स्ट्यान्डअलोन, मेसोस प्रयोग गरेर, र यार्न प्रयोग गरेर। हामीले तेस्रो विकल्प रोज्ने निर्णय गर्यौं किनभने यसले हामीलाई अर्थपूर्ण बनायो। हामीसँग पहिले नै एक हडूप क्लस्टर छ। हाम्रा सहभागीहरू पहिले नै यसको वास्तुकलासँग राम्ररी परिचित छन्। यार्न प्रयोग गरौं।

spark.master=yarn

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

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 छिटो सुरु गर्न, SPARK_HOME गृह डाइरेक्टरीमा रहेको जार फोल्डरलाई संग्रह गरी HDFS मा राख्न सिफारिस गरिन्छ। त्यसोभए उसले कामदारहरूद्वारा यी जर्निकहरू लोड गर्न समय खेर फाल्ने छैन।

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

यो पनि छिटो सञ्चालनको लागि एक क्रमिक रूपमा kryo प्रयोग गर्न सिफारिस गरिएको छ। यो पूर्वनिर्धारित एक भन्दा बढी अनुकूलित छ।

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

र त्यहाँ स्पार्कसँग लामो समयदेखि चलिरहेको समस्या पनि छ कि यो अक्सर मेमोरीबाट क्र्यास हुन्छ। प्रायः यो क्षणमा हुन्छ जब कर्मचारीहरूले सबै कुरा गणना गरेका छन् र चालकलाई परिणाम पठाउँछन्। हामीले आफ्नो लागि यो प्यारामिटर ठूलो बनायौं। पूर्वनिर्धारित रूपमा, यो 1GB हो, हामीले यसलाई 3 बनायौं।

spark.driver.maxResultSize=3072

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

Hadoop 2.7 को लागि आधिकारिक वेबसाइटबाट संस्करण डाउनलोड। यसलाई अनजिप गर्नुहोस् र HDP फोल्डरमा राख्नुहोस्। हामीले आवश्यकता अनुसार सिमलिङ्कहरू स्थापना गर्यौं। हामी यसलाई सुरु गर्छौं - यो सुरु हुँदैन। धेरै अनौठो त्रुटि लेख्छ।

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

गुगलिङ पछि, हामीले पत्ता लगायौं कि स्पार्कले Hadoop को जन्म नभएसम्म पर्खन नदिने निर्णय गर्यो, र जर्सीको नयाँ संस्करण प्रयोग गर्ने निर्णय गर्यो। तिनीहरू आफैं यस विषयमा जिरामा एक अर्कासँग बहस गर्छन्। समाधान डाउनलोड गर्नु थियो जर्सी संस्करण १.१७.१। यसलाई 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 समाधान भएन। गुगलिङ पछि, हामीले समाधान फेला पार्यौं। तपाईंले अम्बारीको यार्न सेटिङहरूमा गएर आफू अनुकूल धागो साइटमा एउटा प्यारामिटर थप्नुपर्छ:

hdp.version=2.5.3.0-37

यो जादूले मद्दत गर्यो, र स्पार्क बन्द भयो। हामीले हाम्रा धेरै jupyter ल्यापटपहरू परीक्षण गर्‍यौं। सबै काम भइरहेको छ। हामी शनिबार (भोलि) मा पहिलो स्पार्क पाठको लागि तयार छौं!

DUP। पाठको क्रममा, अर्को समस्या प्रकाशमा आयो। केही बिन्दुमा, यार्नले स्पार्कका लागि कन्टेनरहरू उपलब्ध गराउन बन्द गर्यो। यार्न मा यो प्यारामिटर सही गर्न आवश्यक थियो, जुन पूर्वनिर्धारित रूपमा 0.2 थियो:

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

अर्थात् स्रोतको बाँडफाँडमा २० प्रतिशत मात्रै श्रोतले भाग लिएका छन् । प्यारामिटरहरू परिवर्तन गरेपछि, हामीले यार्न पुन: लोड गर्यौं। समस्या समाधान भयो र बाँकी सहभागीहरूले पनि स्पार्क सन्दर्भ चलाउन सक्षम भए।

स्रोत: www.habr.com