سلام، سلام! پرون
یو کوچنی پیژندنه چې موږ څنګه سپارک کاروو. موږ درې میاشتنی پروګرام لرو
زموږ د کارونې ځانګړتیا دا ده چې د هغو خلکو شمیر چې په ورته وخت کې په سپارک کار کوي د ټولې ډلې سره مساوي وي. د مثال په توګه، په یوه سیمینار کې، کله چې هرڅوک په ورته وخت کې یو څه هڅه کوي او زموږ د ښوونکي وروسته تکراروي. او دا ډیر ندی - ځینې وختونه تر 40 پورې خلک. شاید په نړۍ کې ډیری شرکتونه شتون نلري چې د ورته کارونې قضیې سره مخ وي.
بل ، زه به تاسو ته ووایم چې څنګه او ولې موږ ځانګړي ترتیب پیرامیټرې غوره کړې.
راځئ چې له پیل څخه پیل وکړو. سپارک په کلستر کې د چلولو لپاره 3 اختیارونه لري: سټایلون، د میسوس کارول، او د YARN کارول. موږ پریکړه وکړه چې دریم انتخاب غوره کړو ځکه چې دا زموږ لپاره معنی لري. موږ دمخه د هاډوپ کلستر لرو. زموږ ګډونوال لا دمخه د دې جوړښت سره ښه آشنا دي. راځی چی یارن وکاروو.
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 نسخه ته د تازه کولو څرنګوالی. د HDP دا نسخه د مخکې نصب شوي نسخه 2.0 لري، مګر موږ یوځل د ځان لپاره پریکړه وکړه چې سپارک په فعاله توګه وده کوي، او هره نوې نسخه ځینې بګونه حل کوي او اضافي ځانګړتیاوې وړاندې کوي، په شمول د python API لپاره، نو موږ پریکړه وکړه، څه ته اړتیا لري. ترسره شي یو تازه دی.
د هډوپ 2.7 لپاره د رسمي ویب پا fromې څخه نسخه ډاونلوډ کړئ. دا خلاص کړئ او د HDP فولډر کې یې واچوئ. موږ د اړتیا سره سم سم لینکونه نصب کړل. موږ یې پیل کوو - دا نه پیل کیږي. ډېره عجیبه تېروتنه لیکي.
java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfig
د ګوګل کولو وروسته، موږ وموندله چې سپارک پریکړه وکړه چې د هډوپ زیږیدلو پورې انتظار ونه کړي، او پریکړه یې وکړه چې د جرسي نوې نسخه وکاروي. دوی پخپله په جرګه کې د دې موضوع په اړه یو بل سره بحث کوي. حل دا و چې ډاونلوډ کړئ
موږ د دې تېروتنې په شاوخوا کې ترلاسه کړل، مګر یو نوی او پرځای یې منظم شوی.
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
دې جادو مرسته وکړه، او سپارک یې واخیست. موږ خپل څو جوپېټر لپټاپونه ازمویل. هر څه کار کوي. موږ د شنبې په ورځ (سبا) د لومړي سپارک درس لپاره چمتو یو!
DUP. د درس په جریان کې، یوه بله ستونزه روښانه شوه. په یو وخت کې، YARN د سپارک لپاره د کانتینرونو چمتو کول بند کړل. په YARN کې دا اړینه وه چې پیرامیټر سم کړئ، کوم چې په ډیفالټ کې 0.2 و:
yarn.scheduler.capacity.maximum-am-resource-percent=0.8
يعنې د منابعو په ويش کې يوازې شل سلنه برخه اخيستې وه. د پیرامیټونو بدلولو وروسته، موږ یارن بیا پورته کړ. ستونزه هواره شوه او پاتې ګډونوال هم په دې وتوانېدل چې د سپیڅلي سیاق په لور روان شي.
سرچینه: www.habr.com