تقسیم شدہ کمپیوٹنگ اور بڑے ڈیٹا کے لیے مارکیٹ، کے مطابق ، ہر سال 18-19٪ کی شرح سے بڑھ رہا ہے۔ اس کا مطلب یہ ہے کہ ان مقاصد کے لیے سافٹ ویئر کے انتخاب کا مسئلہ متعلقہ رہتا ہے۔ اس پوسٹ میں، ہم اس بات سے شروع کریں گے کہ ہمیں تقسیم شدہ کمپیوٹنگ کی ضرورت کیوں ہے، ہم سافٹ ویئر کے انتخاب پر مزید تفصیل سے غور کریں گے، ہم ہڈوپ کو Cloudera کے ساتھ استعمال کرنے کے بارے میں بات کریں گے، اور آخر میں ہم ہارڈ ویئر کے انتخاب کے بارے میں بات کریں گے اور اس سے کارکردگی پر کیا اثر پڑتا ہے۔ مختلف طریقوں سے.
ہمیں عام کاروبار میں تقسیم شدہ کمپیوٹنگ کی ضرورت کیوں ہے؟ سب کچھ ایک ہی وقت میں سادہ اور پیچیدہ ہے۔ سادہ - کیونکہ زیادہ تر معاملات میں ہم معلومات کے فی یونٹ نسبتاً آسان حساب لگاتے ہیں۔ مشکل - کیونکہ ایسی بہت سی معلومات موجود ہیں۔ اتنے سارے. نتیجے کے طور پر، ایک کرنا پڑتا ہے . اس طرح، استعمال کے معاملات کافی آفاقی ہیں: حسابات کا اطلاق جہاں بھی ہوتا ہے وہاں اس سے بھی بڑے ڈیٹا سرے پر میٹرکس کی ایک بڑی تعداد کو مدنظر رکھنا ضروری ہوتا ہے۔
ایک حالیہ مثال: ڈوڈو پیزا کسٹمر آرڈر بیس کے تجزیے کی بنیاد پر، کہ صوابدیدی ٹاپنگز کے ساتھ پیزا کا انتخاب کرتے وقت، صارفین عام طور پر اجزاء کے صرف چھ بنیادی سیٹوں کے علاوہ کچھ بے ترتیب کے ساتھ کام کرتے ہیں۔ اس کے مطابق، پزیریا ایڈجسٹ خریداری. اس کے علاوہ، یہ صارفین کو آرڈر کے مرحلے پر پیش کی جانے والی اضافی مصنوعات کی بہتر طریقے سے سفارش کرنے میں کامیاب رہا، جس سے منافع میں اضافہ ہوا۔
ایک اور مثال: تجارتی سامان نے H&M کو فروخت کی سطح کو برقرار رکھتے ہوئے انفرادی اسٹورز میں درجہ بندی کو 40% تک کم کرنے کی اجازت دی۔ یہ خراب فروخت کی پوزیشنوں کو چھوڑ کر حاصل کیا گیا تھا، اور حسابات میں موسمی کیفیت کو مدنظر رکھا گیا تھا۔
آلہ کا انتخاب
اس قسم کی کمپیوٹنگ کے لیے انڈسٹری کا معیار Hadoop ہے۔ کیوں؟ کیونکہ ہڈوپ ایک بہترین، اچھی طرح سے دستاویزی فریم ورک ہے (اسی ہیبر اس موضوع پر بہت سے تفصیلی مضامین دیتا ہے)، جس کے ساتھ افادیت اور لائبریریوں کا ایک پورا مجموعہ ہے۔ آپ ان پٹ کے طور پر سٹرکچرڈ اور غیر ساختہ ڈیٹا دونوں کے بڑے سیٹ جمع کر سکتے ہیں، اور سسٹم خود انہیں کمپیوٹنگ پاور کے درمیان تقسیم کر دے گا۔ مزید یہ کہ، ان ہی صلاحیتوں کو کسی بھی وقت بڑھایا یا غیر فعال کیا جا سکتا ہے - وہی افقی اسکیل ایبلٹی عمل میں ہے۔
2017 میں، بااثر مشاورتی کمپنی گارٹنر کہ ہڈوپ جلد ہی متروک ہو جائے گا۔ وجہ کافی معمولی ہے: تجزیہ کاروں کا خیال ہے کہ کمپنیاں بڑے پیمانے پر کلاؤڈ کی طرف ہجرت کریں گی، کیونکہ وہاں وہ کمپیوٹنگ پاور کے استعمال کی بنیاد پر ادائیگی کر سکیں گی۔ ہڈوپ کو "دفن" کرنے کے قابل سمجھا جانے والا دوسرا اہم عنصر کام کی رفتار ہے۔ کیونکہ Apache Spark یا Google Cloud DataFlow جیسے اختیارات MapReduce بنیادی Hadoop سے تیز ہیں۔
ہڈوپ کئی ستونوں پر ٹکی ہوئی ہے، جن میں سب سے زیادہ قابل ذکر MapReduce ٹیکنالوجیز (سروروں کے درمیان حسابات کے لیے ڈیٹا تقسیم کرنے کا نظام) اور HDFS فائل سسٹم ہیں۔ مؤخر الذکر کو خاص طور پر کلسٹر نوڈس کے درمیان تقسیم کی گئی معلومات کو ذخیرہ کرنے کے لیے ڈیزائن کیا گیا ہے: ایک مقررہ سائز کے ہر بلاک کو کئی نوڈس پر رکھا جا سکتا ہے، اور نقل کی بدولت، نظام انفرادی نوڈس کی ناکامیوں کے خلاف مزاحم ہے۔ فائل ٹیبل کے بجائے، NameNode نامی ایک خاص سرور استعمال کیا جاتا ہے۔
نیچے دی گئی مثال سے پتہ چلتا ہے کہ MapReduce کیسے کام کرتا ہے۔ پہلے مرحلے میں ڈیٹا کو ایک خاص وصف کے مطابق تقسیم کیا جاتا ہے، دوسرے مرحلے پر اسے کمپیوٹنگ پاور کے ذریعے تقسیم کیا جاتا ہے، تیسرے مرحلے پر حساب کتاب ہوتا ہے۔
MapReduce کو اصل میں گوگل نے اپنی تلاش کی ضروریات کے لیے بنایا تھا۔ پھر MapReduce مفت کوڈ میں چلا گیا، اور اپاچی نے اس منصوبے کو سنبھال لیا۔ ٹھیک ہے، گوگل آہستہ آہستہ دوسرے حلوں کی طرف ہجرت کر گیا۔ ایک دلچسپ بات: اس وقت، گوگل کے پاس گوگل کلاؤڈ ڈیٹا فلو کے نام سے ایک پروجیکٹ ہے، جو ہڈوپ کے بعد اگلے مرحلے کے طور پر اس کے فوری متبادل کے طور پر رکھا گیا ہے۔
قریب سے دیکھنے سے پتہ چلتا ہے کہ گوگل کلاؤڈ ڈیٹا فلو اپاچی بیم کے تغیر پر مبنی ہے، جبکہ اپاچی بیم میں اچھی طرح سے دستاویزی اپاچی اسپارک فریم ورک شامل ہے، جو ہمیں حل پر عمل درآمد کی تقریباً اسی رفتار کے بارے میں بات کرنے کی اجازت دیتا ہے۔ ٹھیک ہے، Apache Spark HDFS فائل سسٹم پر ٹھیک کام کرتا ہے، جو آپ کو اسے Hadoop سرورز پر تعینات کرنے کی اجازت دیتا ہے۔
گوگل کلاؤڈ ڈیٹا فلو کے خلاف ہڈوپ اور اسپارک کے لیے دستاویزات کا حجم اور تیار حل یہاں شامل کریں، اور ٹول کا انتخاب واضح ہو جاتا ہے۔ مزید یہ کہ انجینئرز خود فیصلہ کر سکتے ہیں کہ کون سا کوڈ - ہڈوپ یا اسپارک کے تحت - وہ کام، تجربے اور قابلیت پر توجہ مرکوز کرتے ہوئے اس پر عمل درآمد کریں گے۔
کلاؤڈ یا مقامی سرور
کلاؤڈ میں عام منتقلی کی طرف رجحان نے یہاں تک کہ ایک ایسی دلچسپ اصطلاح کو جنم دیا ہے جیسے Hadoop-as-a-service۔ ایسے میں کنیکٹڈ سرورز کی انتظامیہ بہت ضروری ہو گئی ہے۔ کیونکہ، افسوس، اس کی مقبولیت کے باوجود، خالص ہڈوپ کو ترتیب دینا ایک مشکل ٹول ہے، کیونکہ آپ کو ہاتھ سے بہت کچھ کرنا پڑتا ہے۔ مثال کے طور پر، آپ سرورز کو انفرادی طور پر ترتیب دے سکتے ہیں، ان کی کارکردگی کی نگرانی کر سکتے ہیں، اور بہت سے پیرامیٹرز کو ٹھیک کر سکتے ہیں۔ عام طور پر، ایک شوقیہ کے لیے کام کرتے ہیں اور کسی جگہ خراب ہونے یا کسی چیز کو کھونے کا ایک بڑا موقع ہوتا ہے۔
لہذا، مختلف تقسیم بہت مقبول ہو گئی ہیں، جو ابتدائی طور پر آسان تعیناتی اور انتظامی آلات سے لیس ہیں۔ ایک مقبول تقسیم جو اسپارک کو سپورٹ کرتی ہے اور چیزوں کو آسان بناتی ہے وہ ہے Cloudera۔ اس کے ادا شدہ اور مفت ورژن دونوں ہیں - اور بعد میں، تمام اہم فعالیت دستیاب ہے، اور نوڈس کی تعداد کو محدود کیے بغیر۔
سیٹ اپ کے دوران، Cloudera مینیجر SSH کے ذریعے آپ کے سرورز سے جڑ جائے گا۔ ایک دلچسپ نقطہ: انسٹال کرتے وقت، یہ بتانا بہتر ہے کہ اسے نام نہاد کے ذریعہ انجام دیا جائے۔ پارسل: خصوصی پیکجز، جن میں سے ہر ایک میں ایک دوسرے کے ساتھ کام کرنے کے لیے تشکیل کردہ تمام ضروری اجزاء شامل ہیں۔ درحقیقت، یہ پیکیج مینیجر کا ایسا بہتر ورژن ہے۔
تنصیب کے بعد، ہمیں ایک کلسٹر مینجمنٹ کنسول ملتا ہے، جہاں آپ کلسٹرز، انسٹال کردہ خدمات کے لیے ٹیلی میٹری دیکھ سکتے ہیں، اس کے علاوہ آپ وسائل کو شامل/ ہٹا سکتے ہیں اور کلسٹر کنفیگریشن میں ترمیم کر سکتے ہیں۔
نتیجے کے طور پر، اس راکٹ کی کٹنگ آپ کے سامنے آتی ہے، جو آپ کو بگ ڈیٹا کے روشن مستقبل کی طرف لے جائے گی۔ لیکن اس سے پہلے کہ ہم "چلیں" کہیں، آئیے تیزی سے آگے بڑھیں۔
ہارڈ ویئر کی ضروریات
ان کی ویب سائٹ پر، Cloudera مختلف ممکنہ کنفیگریشنز کا ذکر کرتا ہے۔ عام اصول جن کے ذریعہ وہ بنائے گئے ہیں مثال میں دکھائے گئے ہیں:
MapReduce اس پر امید تصویر کو دھندلا کر سکتا ہے۔ پچھلے حصے میں دیے گئے خاکے کو دوبارہ دیکھیں تو یہ واضح ہو جاتا ہے کہ تقریباً تمام معاملات میں، ڈسک یا نیٹ ورک سے ڈیٹا پڑھتے وقت MapReduce جاب ایک رکاوٹ کا شکار ہو سکتا ہے۔ یہ Cloudera بلاگ پر بھی نوٹ کیا گیا ہے۔ نتیجے کے طور پر، کسی بھی تیز رفتار حسابات کے لیے، بشمول اسپارک کے ذریعے، جو اکثر ریئل ٹائم کیلکولیشن کے لیے استعمال ہوتا ہے، I/O رفتار بہت اہم ہے۔ اس لیے، ہڈوپ کا استعمال کرتے وقت، یہ بہت ضروری ہے کہ متوازن اور تیز مشینیں کلسٹر میں داخل ہوں، جسے ہلکے سے کہیں، کلاؤڈ انفراسٹرکچر میں ہمیشہ فراہم نہیں کیا جاتا ہے۔
لوڈ ڈسٹری بیوشن میں توازن طاقتور ملٹی کور CPUs والے سرورز پر اوپن اسٹیک ورچوئلائزیشن کے استعمال سے حاصل کیا جاتا ہے۔ ڈیٹا نوڈس کو ان کے اپنے پروسیسر کے وسائل اور مخصوص ڈسکیں مختص کی جاتی ہیں۔ ہمارے حل میں Atos Codex ڈیٹا لیک انجن وسیع ورچوئلائزیشن حاصل کی جاتی ہے، یہی وجہ ہے کہ ہم کارکردگی کے لحاظ سے (نیٹ ورک کے بنیادی ڈھانچے کا اثر کم سے کم کیا جاتا ہے) اور TCO (اضافی جسمانی سرورز کو ختم کر دیا جاتا ہے) دونوں میں جیت جاتے ہیں۔
BullSequana S200 سرورز استعمال کرنے کی صورت میں، ہمیں ایک بہت ہی یکساں بوجھ ملتا ہے، جو کچھ رکاوٹوں سے خالی ہے۔ کم از کم کنفیگریشن میں 3 BullSequana S200 سرورز شامل ہیں، ہر ایک میں دو JBODs کے ساتھ ساتھ اضافی S200s جن میں چار ڈیٹا نوڈز اختیاری طور پر منسلک ہیں۔ TeraGen ٹیسٹ میں لوڈ کی ایک مثال یہ ہے:
مختلف اعداد و شمار کے حجم اور نقل کی قدروں کے ساتھ ٹیسٹ کلسٹر نوڈس میں لوڈ کی تقسیم کے لحاظ سے ایک جیسے نتائج دکھاتے ہیں۔ ذیل میں کارکردگی ٹیسٹ کے ذریعے ڈسک تک رسائی کی تقسیم کا گراف ہے۔
حسابات 3 BullSequana S200 سرورز کی کم از کم ترتیب پر مبنی ہیں۔ اس میں 9 ڈیٹا نوڈس اور 3 ماسٹر نوڈس کے ساتھ ساتھ OpenStack ورچوئلائزیشن کی بنیاد پر تحفظ کی تعیناتی کی صورت میں محفوظ ورچوئل مشینیں شامل ہیں۔ ٹیراسورٹ ٹیسٹ کا نتیجہ: انکرپشن کے ساتھ تین کے ریپلیکشن فیکٹر کا 512 MB بلاک سائز 23,1 منٹ ہے۔
نظام کو کیسے بڑھایا جا سکتا ہے؟ ڈیٹا لیک انجن کے لیے مختلف قسم کے ایکسٹینشن دستیاب ہیں:
- ڈیٹا نوڈس: ہر 40 TB قابل استعمال جگہ کے لیے
- GPU انسٹال کرنے کی صلاحیت کے ساتھ تجزیاتی نوڈس
- کاروباری ضروریات پر منحصر دیگر اختیارات (مثال کے طور پر، اگر آپ کو کافکا اور اس طرح کی ضرورت ہو)
Atos Codex Data Lake Engine کمپلیکس میں خود سرور اور پہلے سے نصب سافٹ ویئر دونوں شامل ہیں، بشمول ایک لائسنس کے ساتھ Cloudera کٹ؛ ہڈوپ بذات خود، RedHat Enterprise Linux کرنل پر مبنی ورچوئل مشینوں کے ساتھ OpenStack، ڈیٹا کی نقل اور بیک اپ سسٹم (بشمول بیک اپ نوڈ اور Cloudera BDR - بیک اپ اور ڈیزاسٹر ریکوری کا استعمال)۔ Atos Codex Data Lake Engine تصدیق شدہ پہلا ورچوئلائزیشن حل ہے۔ .
اگر آپ تفصیلات میں دلچسپی رکھتے ہیں، تو ہمیں تبصرے میں اپنے سوالات کے جوابات دینے میں خوشی ہوگی۔
ماخذ: www.habr.com