ہیلو، ہیلو! کل پر ، Rambler&Co کے لڑکوں کی طرف سے، اس ٹول کو ترتیب دینے سے متعلق شرکاء کی طرف سے کافی سوالات تھے۔ ہم نے اس کے نقش قدم پر چلنے اور اپنے تجربے کا اشتراک کرنے کا فیصلہ کیا۔ موضوع آسان نہیں ہے - اس لیے ہم آپ کو دعوت دیتے ہیں کہ آپ تبصروں میں اپنا تجربہ شیئر کریں، ہوسکتا ہے کہ ہم بھی کچھ غلط سمجھیں اور استعمال کریں۔
اسپارک کو ہم کس طرح استعمال کرتے ہیں اس کا ایک چھوٹا سا تعارف۔ ہمارا تین ماہ کا پروگرام ہے۔ ، اور دوسرے ماڈیول میں ہمارے شرکاء اس آلے پر کام کرتے ہیں۔ اس کے مطابق، ہمارا کام، منتظمین کے طور پر، ایسی صورت میں استعمال کے لیے کلسٹر کو تیار کرنا ہے۔
ہمارے استعمال کی خاصیت یہ ہے کہ Spark پر بیک وقت کام کرنے والے لوگوں کی تعداد پورے گروپ کے برابر ہو سکتی ہے۔ مثال کے طور پر، ایک سیمینار میں، جب سب ایک ہی وقت میں کچھ کرنے کی کوشش کرتے ہیں اور ہمارے استاد کے بعد دہراتے ہیں۔ اور یہ بہت زیادہ نہیں ہے - کبھی کبھی 40 افراد تک۔ دنیا میں شاید ایسی بہت سی کمپنیاں نہیں ہیں جنہیں اس طرح کے استعمال کے کیس کا سامنا کرنا پڑتا ہے۔
اگلا، میں آپ کو بتاؤں گا کہ ہم نے کچھ کنفیگریشن پیرامیٹرز کو کیسے اور کیوں منتخب کیا۔
آئیے شروع سے شروع کرتے ہیں۔ اسپارک کے پاس کلسٹر پر چلانے کے لیے 3 اختیارات ہیں: اسٹینڈ لون، میسوس کا استعمال، اور یارن کا استعمال۔ ہم نے تیسرا آپشن منتخب کرنے کا فیصلہ کیا کیونکہ یہ ہمارے لیے معنی خیز تھا۔ ہمارے پاس پہلے سے ہی ایک ہڈوپ کلسٹر ہے۔ ہمارے شرکاء پہلے ہی اس کے فن تعمیر سے اچھی طرح واقف ہیں۔ آئیے یارن کا استعمال کریں۔
spark.master=yarnمزید دلچسپ۔ ان 3 تعیناتی اختیارات میں سے ہر ایک میں 2 تعیناتی کے اختیارات ہیں: کلائنٹ اور کلسٹر۔ پر مبنی اور انٹرنیٹ پر مختلف لنکس، ہم یہ نتیجہ اخذ کر سکتے ہیں کہ کلائنٹ انٹرایکٹو کام کے لیے موزوں ہے - مثال کے طور پر، jupyter نوٹ بک کے ذریعے، اور کلسٹر پیداوار کے حل کے لیے زیادہ موزوں ہے۔ ہمارے معاملے میں، ہم انٹرایکٹو کام میں دلچسپی رکھتے تھے، لہذا:
spark.deploy-mode=clientعام طور پر، اب سے Spark کسی نہ کسی طرح یارن پر کام کرے گا، لیکن یہ ہمارے لیے کافی نہیں تھا۔ چونکہ ہمارے پاس بڑے اعداد و شمار کے بارے میں ایک پروگرام ہے، بعض اوقات شرکاء کے پاس اتنا نہیں ہوتا تھا کہ وسائل کے یکساں ٹکڑے کرنے کے فریم ورک کے اندر حاصل کیا گیا تھا۔ اور پھر ہمیں ایک دلچسپ چیز ملی - متحرک وسائل کی تقسیم۔ مختصراً، نکتہ یہ ہے: اگر آپ کے پاس کوئی مشکل کام ہے اور کلسٹر مفت ہے (مثال کے طور پر، صبح)، تو اس آپشن کو استعمال کرنے سے Spark آپ کو اضافی وسائل فراہم کر سکتا ہے۔ ضرورت کا حساب وہاں ایک چالاک فارمولے کے مطابق کیا جاتا ہے۔ ہم تفصیلات میں نہیں جائیں گے - یہ اچھی طرح سے کام کرتا ہے۔
spark.dynamicAllocation.enabled=trueہم نے یہ پیرامیٹر سیٹ کیا، اور شروع ہونے پر Spark کریش ہو گیا اور شروع نہیں ہوا۔ یہ ٹھیک ہے، کیونکہ مجھے اسے پڑھنا پڑا زیادہ احتیاط سے. یہ بتاتا ہے کہ سب کچھ ٹھیک ہونے کے لیے، آپ کو ایک اضافی پیرامیٹر کو بھی فعال کرنے کی ضرورت ہے۔
spark.shuffle.service.enabled=trueاس کی ضرورت کیوں ہے؟ جب ہمارے کام کو اب اتنے وسائل کی ضرورت نہیں ہے، تو اسپارک کو انہیں عام تالاب میں واپس کر دینا چاہیے۔ تقریباً کسی بھی MapReduce کام میں سب سے زیادہ وقت لینے والا مرحلہ شفل مرحلہ ہے۔ یہ پیرامیٹر آپ کو اس مرحلے پر پیدا ہونے والے ڈیٹا کو محفوظ کرنے اور اس کے مطابق عمل کرنے والوں کو جاری کرنے کی اجازت دیتا ہے۔ اور ایگزیکیوٹر وہ عمل ہے جو کارکن پر ہر چیز کا حساب لگاتا ہے۔ اس میں پروسیسر کور کی ایک خاص تعداد اور میموری کی ایک خاص مقدار ہے۔
یہ پیرامیٹر شامل کر دیا گیا ہے۔ سب کچھ کام کرتا دکھائی دے رہا تھا۔ یہ قابل توجہ بن گیا کہ شرکاء کو درحقیقت اس وقت زیادہ وسائل دیئے گئے جب انہیں ان کی ضرورت تھی۔ لیکن ایک اور مسئلہ پیدا ہوا - کسی وقت دوسرے شرکاء جاگ اٹھے اور وہ بھی سپارک استعمال کرنا چاہتے تھے، لیکن وہاں سب کچھ مصروف تھا، اور وہ ناخوش تھے۔ انہیں سمجھا جا سکتا ہے۔ ہم نے دستاویزات کو دیکھنا شروع کیا۔ یہ پتہ چلا کہ بہت سے دوسرے پیرامیٹرز ہیں جو عمل کو متاثر کرنے کے لئے استعمال کیے جا سکتے ہیں. مثال کے طور پر، اگر ایگزیکیوٹر اسٹینڈ بائی موڈ میں ہے تو اس سے کتنے وقت کے بعد وسائل لیے جا سکتے ہیں؟
spark.dynamicAllocation.executorIdleTimeout=120sہمارے معاملے میں، اگر آپ کے عملدار دو منٹ تک کچھ نہیں کرتے ہیں، تو براہ کرم انہیں عام تالاب میں واپس کر دیں۔ لیکن یہ پیرامیٹر ہمیشہ کافی نہیں تھا۔ یہ واضح تھا کہ وہ شخص طویل عرصے سے کچھ نہیں کر رہا تھا، اور وسائل کو آزاد نہیں کیا جا رہا تھا. یہ پتہ چلا کہ ایک خاص پیرامیٹر بھی ہے - کتنے وقت کے بعد کیش شدہ ڈیٹا پر مشتمل ایگزیکیوٹرز کو منتخب کریں۔ پہلے سے طے شدہ طور پر، یہ پیرامیٹر انفینٹی تھا! ہم نے اسے درست کیا۔
spark.dynamicAllocation.cachedExecutorIdleTimeout=600sیعنی، اگر آپ کے عملدار 5 منٹ تک کچھ نہیں کرتے ہیں، تو انہیں عام پول میں دیں۔ اس موڈ میں، صارفین کی ایک بڑی تعداد کے لیے وسائل کو جاری کرنے اور جاری کرنے کی رفتار مہذب ہو گئی ہے۔ عدم اطمینان کی مقدار میں کمی آئی ہے۔ لیکن ہم نے مزید آگے جانے اور فی درخواست پر عملدرآمد کرنے والوں کی زیادہ سے زیادہ تعداد کو محدود کرنے کا فیصلہ کیا - بنیادی طور پر فی پروگرام شریک۔
spark.dynamicAllocation.maxExecutors=19اب، بلاشبہ، دوسری طرف غیر مطمئن لوگ ہیں - "کلسٹر بیکار ہے، اور میرے پاس صرف 19 ایگزیکیوٹرز ہیں،" لیکن آپ کیا کر سکتے ہیں؟ ہمیں کسی قسم کے درست توازن کی ضرورت ہے۔ آپ سب کو خوش نہیں کر سکتے۔
اور ہمارے کیس کی تفصیلات سے متعلق ایک اور چھوٹی کہانی۔ کسی نہ کسی طرح، کئی لوگوں کو عملی سبق کے لیے دیر ہوئی، اور کسی وجہ سے ان کے لیے Spark شروع نہیں ہوا۔ ہم نے مفت وسائل کی مقدار کو دیکھا - ایسا لگتا ہے کہ وہاں موجود ہے۔ چنگاری شروع ہونی چاہیے۔ خوش قسمتی سے، اس وقت تک سب کورٹیکس میں دستاویزات پہلے ہی کہیں شامل کر دی گئی تھیں، اور ہمیں یاد آیا کہ جب لانچ کیا گیا تو، اسپارک ایک بندرگاہ کی تلاش کرتا ہے جس پر شروع کیا جائے۔ اگر رینج میں پہلی بندرگاہ مصروف ہے، تو یہ ترتیب سے اگلی بندرگاہ پر چلی جاتی ہے۔ اگر یہ مفت ہے، تو یہ قبضہ کر لیتا ہے۔ اور ایک پیرامیٹر ہے جو اس کے لیے کوششوں کی زیادہ سے زیادہ تعداد کی نشاندہی کرتا ہے۔ پہلے سے طے شدہ 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اور آخر میں، ایک میٹھی کے طور پر. HortonWorks ڈسٹری بیوشن - HDP 2.1 پر Spark کو ورژن 2.5.3.0 میں اپ ڈیٹ کرنے کا طریقہ۔ HDP کا یہ ورژن پہلے سے انسٹال شدہ ورژن 2.0 پر مشتمل ہے، لیکن ہم نے ایک بار خود فیصلہ کیا کہ Spark کافی فعال طور پر ترقی کر رہا ہے، اور ہر نیا ورژن کچھ کیڑے ٹھیک کرتا ہے اور اضافی خصوصیات فراہم کرتا ہے، بشمول python API کے لیے، لہذا ہم نے فیصلہ کیا، کیا ضرورت ہے کیا جائے ایک اپ ڈیٹ ہے.
ہڈوپ 2.7 کے لیے آفیشل ویب سائٹ سے ورژن ڈاؤن لوڈ کیا۔ اسے ان زپ کریں اور اسے HDP فولڈر میں ڈالیں۔ ہم نے ضرورت کے مطابق سملنک انسٹال کیا۔ ہم اسے شروع کرتے ہیں - یہ شروع نہیں ہوتا ہے۔ بہت عجیب غلطی لکھتے ہیں۔
java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfigگوگل کرنے کے بعد، ہمیں پتہ چلا کہ اسپارک نے ہڈوپ کے پیدا ہونے تک انتظار نہ کرنے کا فیصلہ کیا، اور جرسی کا نیا ورژن استعمال کرنے کا فیصلہ کیا۔ وہ خود اس موضوع پر ایک دوسرے سے JIRA میں بحث کرتے ہیں۔ اس کا حل ڈاؤن لوڈ کرنا تھا۔ . اسے 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 حل نہیں ہوا۔ گوگل کرنے کے بعد، ہم نے ایک حل تلاش کیا. آپ کو Ambari میں YARN کی ترتیبات پر جانے کی ضرورت ہے اور اپنی مرضی کے مطابق یارن سائٹ میں ایک پیرامیٹر شامل کرنا ہوگا:
hdp.version=2.5.3.0-37اس جادو نے مدد کی، اور چنگاری شروع ہوگئی۔ ہم نے اپنے کئی jupyter لیپ ٹاپ کا تجربہ کیا۔ سب کچھ کام کر رہا ہے۔ ہم ہفتہ (کل) کو پہلے سپارک سبق کے لیے تیار ہیں!
یو پی ڈی. درس کے دوران ایک اور مسئلہ سامنے آیا۔ کسی وقت، یارن نے اسپارک کے لیے کنٹینرز فراہم کرنا بند کر دیا۔ یارن میں پیرامیٹر کو درست کرنا ضروری تھا، جو پہلے سے طے شدہ طور پر 0.2 تھا:
yarn.scheduler.capacity.maximum-am-resource-percent=0.8
یعنی وسائل کی تقسیم میں صرف 20% وسائل نے حصہ لیا۔ پیرامیٹرز کو تبدیل کرنے کے بعد، ہم نے یارن کو دوبارہ لوڈ کیا۔ مسئلہ حل ہو گیا تھا اور باقی شرکاء بھی چنگاری سیاق و سباق کو چلانے کے قابل تھے۔
ماخذ: www.habr.com