په YARN کې د سپارک تنظیم کول

سلام، سلام! پرون ملاقات اپاچی سپارک ته وقف شوی، د Rambler&Co د هلکانو څخه ، د دې وسیلې تنظیم کولو پورې اړوند برخه اخیستونکو څخه خورا ډیرې پوښتنې وې. موږ پریکړه وکړه چې د هغه په ​​پښو کې تعقیب کړو او خپلې تجربې شریکې کړو. موضوع اسانه نده - نو موږ تاسو ته بلنه درکوو چې خپلې تجربې په نظرونو کې شریکې کړئ، شاید موږ هم پوه شو او یو څه غلط کاروو.

یو کوچنی پیژندنه چې موږ څنګه سپارک کاروو. موږ درې میاشتنی پروګرام لرو "د لوی معلوماتو متخصص"، او د دویم ماډل په اوږدو کې زموږ برخه اخیستونکي په دې وسیله کار کوي. په دې اساس، زموږ دنده، د تنظیم کونکو په توګه، په داسې یوه قضیه کې د کارولو لپاره کلستر چمتو کول دي.

زموږ د کارونې ځانګړتیا دا ده چې د هغو خلکو شمیر چې په ورته وخت کې په سپارک کار کوي د ټولې ډلې سره مساوي وي. د مثال په توګه، په یوه سیمینار کې، کله چې هرڅوک په ورته وخت کې یو څه هڅه کوي او زموږ د ښوونکي وروسته تکراروي. او دا ډیر ندی - ځینې وختونه تر 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

د ګوګل کولو وروسته، موږ وموندله چې سپارک پریکړه وکړه چې د هډوپ زیږیدلو پورې انتظار ونه کړي، او پریکړه یې وکړه چې د جرسي نوې نسخه وکاروي. دوی پخپله په جرګه کې د دې موضوع په اړه یو بل سره بحث کوي. حل دا و چې ډاونلوډ کړئ د جرسي نسخه 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

دې جادو مرسته وکړه، او سپارک یې واخیست. موږ خپل څو جوپېټر لپټاپونه ازمویل. هر څه کار کوي. موږ د شنبې په ورځ (سبا) د لومړي سپارک درس لپاره چمتو یو!

DUP. د درس په جریان کې، یوه بله ستونزه روښانه شوه. په یو وخت کې، YARN د سپارک لپاره د کانتینرونو چمتو کول بند کړل. په YARN کې دا اړینه وه چې پیرامیټر سم کړئ، کوم چې په ډیفالټ کې 0.2 و:

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

يعنې د منابعو په ويش کې يوازې شل سلنه برخه اخيستې وه. د پیرامیټونو بدلولو وروسته، موږ یارن بیا پورته کړ. ستونزه هواره شوه او پاتې ګډونوال هم په دې وتوانېدل چې د سپیڅلي سیاق په لور روان شي.

سرچینه: www.habr.com

Add a comment