Spark-ის კონფიგურაცია YARN-ზე

ჰაბრ, გამარჯობა! გუშინ Apache Spark-ისადმი მიძღვნილი შეხვედრა, Rambler&Co-ს ბიჭებისგან, საკმაოდ ბევრი კითხვა იყო მონაწილეებისგან ამ ხელსაწყოს კონფიგურაციასთან დაკავშირებით. გადავწყვიტეთ მის კვალს გავყოლოდით და გამოცდილება გაგვეზიარებინა. თემა ადვილი არ არის - ამიტომ გეპატიჟებით კომენტარებში გაგვიზიარეთ თქვენი გამოცდილება, იქნებ ჩვენც გავიგოთ და გამოვიყენოთ რაიმე არასწორად.

მცირე შესავალი იმის შესახებ, თუ როგორ ვიყენებთ Spark-ს. გვაქვს სამთვიანი პროგრამა "დიდი მონაცემთა სპეციალისტი"და მეორე მოდულის განმავლობაში ჩვენი მონაწილეები მუშაობენ ამ ინსტრუმენტზე. შესაბამისად, ჩვენი, როგორც ორგანიზატორების, ამოცანაა მოვამზადოთ კლასტერი ასეთ შემთხვევაში გამოსაყენებლად.

ჩვენი გამოყენების თავისებურება ის არის, რომ Spark-ზე ერთდროულად მომუშავე ადამიანების რაოდენობა შეიძლება იყოს მთელი ჯგუფის ტოლი. მაგალითად, სემინარზე, როდესაც ყველა ერთდროულად ცდის რაღაცას და იმეორებს ჩვენი მასწავლებლის შემდეგ. და ეს არ არის ბევრი - ზოგჯერ 40-მდე ადამიანი. მსოფლიოში, ალბათ, არც თუ ისე ბევრი კომპანიაა, რომლებსაც ასეთი გამოყენების შემთხვევა ემუქრებათ.

შემდეგი, მე გეტყვით, როგორ და რატომ შევარჩიეთ გარკვეული კონფიგურაციის პარამეტრები.

დავიწყოთ თავიდანვე. Spark-ს აქვს კლასტერზე მუშაობის 3 ვარიანტი: დამოუკიდებელი, Mesos-ის გამოყენებით და YARN-ის გამოყენებით. მესამე ვარიანტის არჩევა გადავწყვიტეთ, რადგან ეს ჩვენთვის აზრიანი იყო. ჩვენ უკვე გვაქვს ჰადოპ კლასტერი. ჩვენი მონაწილეები უკვე კარგად იცნობენ მის არქიტექტურას. მოდით გამოვიყენოთ YARN.

spark.master=yarn

უფრო საინტერესო. ამ 3 განლაგების ვარიანტებიდან თითოეულს აქვს განლაგების 2 ვარიანტი: კლიენტი და კლასტერი. დაფუძნებული დოკუმენტაცია და ინტერნეტის სხვადასხვა ბმულზე, შეგვიძლია დავასკვნათ, რომ კლიენტი შესაფერისია ინტერაქტიული მუშაობისთვის - მაგალითად, იუპიტერის ნოუთბუქის საშუალებით, ხოლო კლასტერი უფრო შესაფერისია საწარმოო გადაწყვეტილებებისთვის. ჩვენს შემთხვევაში, ჩვენ დაინტერესებული ვიყავით ინტერაქტიული მუშაობით, ამიტომ:

spark.deploy-mode=client

ზოგადად, ამიერიდან Spark როგორმე იმუშავებს YARN-ზე, მაგრამ ეს ჩვენთვის საკმარისი არ იყო. ვინაიდან ჩვენ გვაქვს პროგრამა დიდი მონაცემების შესახებ, ზოგჯერ მონაწილეებს არ ჰქონდათ საკმარისი ის, რაც მოპოვებული იყო რესურსების თანაბარი დაჭრის ფარგლებში. და შემდეგ ჩვენ აღმოვაჩინეთ საინტერესო რამ - დინამიური რესურსების განაწილება. მოკლედ, საქმე ასეთია: თუ თქვენ გაქვთ რთული დავალება და კლასტერი თავისუფალია (მაგალითად, დილით), მაშინ ამ ოფციის გამოყენებით Spark მოგცემთ დამატებით რესურსებს. აუცილებლობა იქ გამოითვლება ეშმაკური ფორმულის მიხედვით. ჩვენ არ შევალთ დეტალებში - ის კარგად მუშაობს.

spark.dynamicAllocation.enabled=true

ჩვენ დავაყენეთ ეს პარამეტრი და გაშვებისთანავე Spark გაფუჭდა და არ დაიწყო. ასეა, რადგან უნდა წავიკითხო დოკუმენტაცია უფრო ფრთხილად. მასში ნათქვამია, რომ იმისათვის, რომ ყველაფერი კარგად იყოს, თქვენ ასევე უნდა ჩართოთ დამატებითი პარამეტრი.

spark.shuffle.service.enabled=true

რატომ არის საჭირო? როდესაც ჩვენი სამუშაო აღარ მოითხოვს ამდენ რესურსს, Spark-მა ისინი საერთო აუზში უნდა დააბრუნოს. ყველაზე შრომატევადი ეტაპი თითქმის ნებისმიერ MapReduce ამოცანაში არის Shuffle ეტაპი. ეს პარამეტრი საშუალებას გაძლევთ შეინახოთ მონაცემები, რომლებიც წარმოიქმნება ამ ეტაპზე და გაათავისუფლოთ შემსრულებლები შესაბამისად. და შემსრულებელი არის პროცესი, რომელიც ითვლის ყველაფერს მუშაზე. მას აქვს გარკვეული რაოდენობის პროცესორის ბირთვი და გარკვეული რაოდენობის მეხსიერება.

ეს პარამეტრი დამატებულია. თითქოს ყველაფერი მუშაობდა. შესამჩნევი გახდა, რომ მონაწილეებს რეალურად ეძლეოდათ მეტი რესურსი, როცა ეს სჭირდებოდათ. მაგრამ სხვა პრობლემა გაჩნდა - რაღაც მომენტში სხვა მონაწილეებმა გაიღვიძეს და ასევე სურდათ Spark-ის გამოყენება, მაგრამ იქ ყველაფერი დაკავებული იყო და ისინი უკმაყოფილო იყვნენ. მათი გაგება შეიძლება. დავიწყეთ დოკუმენტაციის შესწავლა. აღმოჩნდა, რომ არსებობს მთელი რიგი სხვა პარამეტრები, რომლებიც შეიძლება გამოყენებულ იქნას პროცესზე ზემოქმედებისთვის. მაგალითად, თუ შემსრულებელი იმყოფება ლოდინის რეჟიმში, რა დროის შემდეგ შეიძლება მისგან რესურსების აღება?

spark.dynamicAllocation.executorIdleTimeout=120s

ჩვენს შემთხვევაში, თუ თქვენი შემსრულებლები არაფერს აკეთებენ ორი წუთის განმავლობაში, გთხოვთ, დააბრუნოთ ისინი საერთო აუზში. მაგრამ ეს პარამეტრი ყოველთვის არ იყო საკმარისი. აშკარა იყო, რომ ადამიანი დიდი ხნის განმავლობაში არაფერს აკეთებდა და რესურსები არ იხსნებოდა. აღმოჩნდა, რომ ასევე არსებობს სპეციალური პარამეტრი - რა დროის შემდეგ უნდა აირჩიოთ შემსრულებლები, რომლებიც შეიცავს ქეშ მონაცემებს. ნაგულისხმევად, ეს პარამეტრი იყო უსასრულობა! ჩვენ გავასწორეთ.

spark.dynamicAllocation.cachedExecutorIdleTimeout=600s

ანუ, თუ თქვენი შემსრულებლები არაფერს აკეთებენ 5 წუთის განმავლობაში, მიეცით ისინი საერთო აუზს. ამ რეჟიმში, მომხმარებელთა დიდი რაოდენობით რესურსების გამოშვებისა და გაცემის სიჩქარე გახდა ღირსეული. შემცირდა უკმაყოფილების რაოდენობა. მაგრამ ჩვენ გადავწყვიტეთ უფრო შორს წავსულიყავით და შევზღუდოთ შემსრულებლების მაქსიმალური რაოდენობა თითო აპლიკაციაზე - ძირითადად პროგრამის მონაწილეზე.

spark.dynamicAllocation.maxExecutors=19

ახლა, რა თქმა უნდა, მეორე მხარეს არიან უკმაყოფილოები - „კლასტერი უსაქმურია, მე კი მხოლოდ 19 შემსრულებელი მყავს“, მაგრამ რა ქნა, რაღაც სწორი ბალანსი გვჭირდება. ყველას ვერ გააბედნიერებ.

და კიდევ ერთი პატარა ამბავი, რომელიც დაკავშირებულია ჩვენი საქმის სპეციფიკასთან. რატომღაც რამდენიმე ადამიანმა დააგვიანა პრაქტიკულ გაკვეთილზე და რატომღაც სპარკმა არ დაიწყო მათთვის. ჩვენ გადავხედეთ უფასო რესურსების რაოდენობას - როგორც ჩანს, ეს არის. ნაპერწკალი უნდა დაიწყოს. საბედნიეროდ, იმ დროისთვის დოკუმენტაცია სადღაც უკვე დაემატა ქვეკორტექსს და ჩვენ გვახსოვდა, რომ გაშვებისას Spark ეძებს პორტს, საიდანაც უნდა დაიწყოს. თუ დიაპაზონის პირველი პორტი დაკავებულია, ის გადადის შემდეგზე თანმიმდევრობით. თუ უფასოა, ის იჭერს. და არის პარამეტრი, რომელიც მიუთითებს ამისთვის მცდელობების მაქსიმალურ რაოდენობაზე. ნაგულისხმევი არის 16. რიცხვი კლასში ჩვენი ჯგუფის ხალხის რაოდენობაზე ნაკლებია. შესაბამისად, 16 მცდელობის შემდეგ სპარკმა დანებდა და თქვა, რომ ვერ დავიწყე. ჩვენ შევასწორეთ ეს პარამეტრი.

spark.port.maxRetries=50

შემდეგ მე გეტყვით რამდენიმე პარამეტრზე, რომლებიც არ არის დაკავშირებული ჩვენი საქმის სპეციფიკასთან.

Spark-ის უფრო სწრაფად დასაწყებად, რეკომენდირებულია დაარქივოთ jars საქაღალდე, რომელიც მდებარეობს SPARK_HOME მთავარ დირექტორიაში და განათავსოთ იგი HDFS-ზე. მაშინ ის არ დაკარგავს დროს მუშების მიერ ამ ჯარნიკების ჩატვირთვაზე.

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

ასევე რეკომენდირებულია კრიოს გამოყენება როგორც სერიალიზატორი უფრო სწრაფი მუშაობისთვის. ის უფრო ოპტიმიზებულია, ვიდრე ნაგულისხმევი.

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

და ასევე არის დიდი ხნის პრობლემა Spark-თან, რომ ის ხშირად იშლება მეხსიერებიდან. ხშირად ეს ხდება იმ მომენტში, როდესაც მუშებმა ყველაფერი გამოთვალეს და შედეგს მძღოლს უგზავნიან. ეს პარამეტრი ჩვენთვის უფრო დიდი გავხადეთ. ნაგულისხმევად არის 1 GB, ჩვენ გავაკეთეთ 3.

spark.driver.maxResultSize=3072

და ბოლოს, როგორც დესერტი. როგორ განაახლოთ Spark 2.1 ვერსიაზე HortonWorks დისტრიბუციაზე - HDP 2.5.3.0. HDP-ის ეს ვერსია შეიცავს წინასწარ დაინსტალირებულ ვერსიას 2.0, მაგრამ ჩვენ ერთხელ გადავწყვიტეთ, რომ Spark საკმაოდ აქტიურად ვითარდება და ყოველი ახალი ვერსია აფიქსირებს შეცდომებს და დამატებით ფუნქციებს უზრუნველყოფს, მათ შორის პითონის API-სთვის, ამიტომ გადავწყვიტეთ, რა უნდა უნდა გაკეთდეს განახლება.

ჩამოტვირთეთ ვერსია Hadoop 2.7-ის ოფიციალური ვებსაიტიდან. გახსენით იგი და ჩადეთ HDP საქაღალდეში. ჩვენ დავაყენეთ სიმლინკები საჭიროებისამებრ. ჩვენ ვიწყებთ მას - ის არ იწყება. ძალიან უცნაურ შეცდომას წერს.

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

გუგლის შემდეგ გავიგეთ, რომ სპარკმა გადაწყვიტა არ დაელოდებინა ჰადოპის დაბადებამდე და გადაწყვიტა გამოეყენებინა მაისურის ახალი ვერსია. ამ თემაზე ჯირაში თავად კამათობენ ერთმანეთს. გამოსავალი იყო ჩამოტვირთვა მაისურის ვერსია 1.17.1. მოათავსეთ ეს jars საქაღალდეში 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

ეს მაგია დაეხმარა და სპარკი აფრინდა. ჩვენ გამოვცადეთ რამდენიმე ჩვენი იუპიტერის ლეპტოპი. ყველაფერი მუშაობს. ჩვენ მზად ვართ პირველი Spark გაკვეთილისთვის შაბათს (ხვალ)!

DUP. გაკვეთილზე კიდევ ერთი პრობლემა გამოიკვეთა. რაღაც მომენტში, YARN-მა შეწყვიტა Spark-ისთვის კონტეინერების მიწოდება. YARN-ში საჭირო იყო პარამეტრის გამოსწორება, რომელიც ნაგულისხმევად იყო 0.2:

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

ანუ რესურსების განაწილებაში მონაწილეობდა რესურსების მხოლოდ 20%. პარამეტრების შეცვლის შემდეგ, ჩვენ ხელახლა ჩავტვირთეთ YARN. პრობლემა მოგვარდა და დანარჩენმა მონაწილეებმა ასევე შეძლეს ნაპერწკლის კონტექსტის გაშვება.

წყარო: www.habr.com