ہم ایک حیرت انگیز وقت میں رہتے ہیں جب آپ بہت سے ریڈی میڈ اوپن سورس ٹولز کو تیزی سے اور آسانی سے جوڑ سکتے ہیں، انہیں اسٹیک اوور فلو کے مشورے کے مطابق اپنے "شعور کو بند" کے ساتھ ترتیب دے سکتے ہیں، بغیر "متعدد خطوط" میں تلاش کیے، اور لانچ کر سکتے ہیں۔ انہیں تجارتی آپریشن میں. اور جب آپ کو اپ ڈیٹ/توسیع کرنے کی ضرورت ہوتی ہے یا کوئی غلطی سے دو مشینوں کو دوبارہ شروع کر دیتا ہے - آپ کو احساس ہوتا ہے کہ کسی قسم کا جنونی برا خواب شروع ہو گیا ہے، سب کچھ ڈرامائی طور پر پہچان سے باہر ہو گیا ہے، پیچھے ہٹنے کی کوئی ضرورت نہیں ہے، مستقبل مبہم اور محفوظ ہے، پروگرامنگ کے بجائے شہد کی مکھیاں پالیں اور پنیر بنائیں۔
یہ کچھ بھی نہیں ہے کہ زیادہ تجربہ کار ساتھی، جن کے سر کیڑوں سے بھرے ہوئے ہیں اور اس وجہ سے وہ پہلے سے ہی سرمئی ہیں، "فیشنی زبانوں" میں درجنوں سرورز پر "کیوبز" میں "کنٹینرز" کے پیک کی ناقابل یقین حد تک تیزی سے تعیناتی کے بارے میں سوچ رہے ہیں۔ متضاد غیر مسدود I/O، معمولی مسکراہٹ اور وہ خاموشی سے "man ps" کو دوبارہ پڑھنا جاری رکھتے ہیں، "nginx" سورس کوڈ کو تلاش کرتے ہیں جب تک کہ ان کی آنکھوں سے خون بہہ نہ جائے، اور یونٹ ٹیسٹ لکھیں، لکھیں، لکھیں۔ ساتھیوں کو معلوم ہے کہ سب سے زیادہ دلچسپ چیز تب آئے گی جب نئے سال کے موقع پر ایک دن "یہ سب" رات کو داؤ پر لگا دیا جائے گا۔ اور ان کی مدد صرف یونکس کی نوعیت، حفظ شدہ TCP/IP اسٹیٹ ٹیبل اور بنیادی چھانٹی-تلاش الگورتھم کے بارے میں گہری سمجھ سے ہو گی۔ نظام کو دوبارہ زندہ کرنے کے لیے جیسے ہی chimes ہڑتال ہوتی ہے۔
اوہ ہاں، میں تھوڑا سا مشغول ہو گیا، لیکن مجھے امید ہے کہ میں توقع کی حالت کو پہنچانے میں کامیاب ہو گیا ہوں۔
آج میں DataLake کے لیے ایک آسان اور سستے اسٹیک کی تعیناتی میں اپنے تجربے کا اشتراک کرنا چاہتا ہوں، جو کمپنی میں مکمل طور پر مختلف ساختی تقسیم کے لیے تجزیاتی کاموں کی اکثریت کو حل کرتا ہے۔
کچھ عرصہ پہلے، ہم سمجھ گئے تھے کہ کمپنیوں کو مصنوعات اور تکنیکی تجزیات دونوں کے پھلوں کی ضرورت ہے (مشین لرننگ کی صورت میں کیک پر آئسنگ کا ذکر نہ کریں) اور رجحانات اور خطرات کو سمجھنے کے لیے - ہمیں جمع کرنے اور تجزیہ کرنے کی ضرورت ہے۔ زیادہ سے زیادہ میٹرکس.
Bitrix24 میں بنیادی تکنیکی تجزیات
کئی سال پہلے، Bitrix24 سروس کے آغاز کے ساتھ ساتھ، ہم نے ایک سادہ اور قابل اعتماد تجزیاتی پلیٹ فارم بنانے میں فعال طور پر وقت اور وسائل کی سرمایہ کاری کی جس سے بنیادی ڈھانچے میں مسائل کو فوری طور پر دیکھنے اور اگلے مرحلے کی منصوبہ بندی کرنے میں مدد ملے گی۔ بلاشبہ، یہ مشورہ دیا گیا تھا کہ تیار کردہ اوزار لے جائیں جو ممکن حد تک آسان اور قابل فہم ہوں۔ نتیجے کے طور پر، ناگیوس کو نگرانی کے لیے اور منین کو تجزیات اور تصور کے لیے چنا گیا۔ اب ہمارے پاس ناگیوس میں ہزاروں چیک، منین میں سیکڑوں چارٹ ہیں، اور ہمارے ساتھی انہیں ہر روز کامیابی کے ساتھ استعمال کرتے ہیں۔ میٹرکس واضح ہیں، گراف واضح ہیں، سسٹم کئی سالوں سے قابل اعتماد طریقے سے کام کر رہا ہے اور اس میں باقاعدگی سے نئے ٹیسٹ اور گراف شامل کیے جاتے ہیں: جب ہم ایک نئی سروس کو کام میں لاتے ہیں، تو ہم کئی ٹیسٹ اور گراف شامل کرتے ہیں۔ اچھی قسمت.
نبض پر انگلی - اعلی درجے کی تکنیکی تجزیات
"جلد سے جلد" مسائل کے بارے میں معلومات حاصل کرنے کی خواہش نے ہمیں سادہ اور قابل فہم ٹولز - pinba اور xhprof کے ساتھ فعال تجربات کی طرف راغب کیا۔
پنبا نے ہمیں پی ایچ پی میں ویب صفحات کے حصوں کے کام کرنے کی رفتار کے بارے میں UDP پیکٹ میں اعدادوشمار بھیجے، اور ہم MySQL اسٹوریج میں آن لائن دیکھ سکتے ہیں (Pinba تیز ایونٹ اینالیٹکس کے لیے اپنے MySQL انجن کے ساتھ آتا ہے) مسائل کی ایک مختصر فہرست اور جوابات۔ انہیں اور xhprof نے خود بخود ہمیں کلائنٹس سے سست ترین پی ایچ پی صفحات کے عمل کے گراف جمع کرنے اور تجزیہ کرنے کی اجازت دی کہ اس کی وجہ کیا ہو سکتی ہے - سکون سے، چائے ڈالتے ہوئے یا کچھ مضبوط۔
کچھ عرصہ قبل، ٹول کٹ کو ریورس انڈیکسنگ الگورتھم کی بنیاد پر ایک اور کافی آسان اور قابل فہم انجن سے بھر دیا گیا تھا، جو کہ افسانوی لوسین لائبریری - لچکدار/کیبانا میں مکمل طور پر لاگو کیا گیا تھا۔ نوشتہ جات میں ہونے والے واقعات پر مبنی الٹا لوسین انڈیکس میں دستاویزات کی ملٹی تھریڈڈ ریکارڈنگ کا سادہ خیال اور پہلوؤں کی تقسیم کا استعمال کرتے ہوئے ان کے ذریعے فوری تلاش کرنا واقعی مفید ثابت ہوا۔
کیبانا میں تصورات کی تکنیکی شکل کے باوجود کم درجے کے تصورات جیسے "بالٹی" "اوپر کی طرف بہنا" اور ابھی تک مکمل طور پر فراموش نہ کیے گئے رشتہ دار الجبرا کی نئی ایجاد کردہ زبان، اس آلے نے درج ذیل کاموں میں ہماری مدد کرنا شروع کی:
- Bitrix24 کلائنٹ نے پچھلے گھنٹے میں p1 پورٹل پر کتنی PHP غلطیاں کیں اور کون سی؟ سمجھیں، معاف کریں اور جلدی درست کریں۔
- جرمنی کے پورٹلز پر پچھلے 24 گھنٹوں میں کتنی ویڈیو کالز کی گئیں، کس کوالٹی کے ساتھ اور کیا چینل/نیٹ ورک میں کوئی دشواری تھی؟
- سسٹم کی فعالیت (پی ایچ پی کے لیے ہماری سی ایکسٹینشن)، تازہ ترین سروس اپ ڈیٹ میں ماخذ سے مرتب کی گئی اور کلائنٹس کے لیے کتنی اچھی طرح سے کام کرتی ہے؟ کیا سیگ فالٹس ہیں؟
- کیا کسٹمر کا ڈیٹا پی ایچ پی میموری میں فٹ ہے؟ کیا پروسیس کے لیے مختص میموری سے تجاوز کرنے کے بارے میں کوئی خرابی ہے: "میموری سے باہر"؟ تلاش کریں اور غیر جانبدار کریں۔
یہاں ایک ٹھوس مثال ہے۔ مکمل اور ملٹی لیول ٹیسٹنگ کے باوجود، کلائنٹ، ایک انتہائی غیر معیاری کیس اور خراب ان پٹ ڈیٹا کے ساتھ، ایک پریشان کن اور غیر متوقع غلطی موصول ہوئی، ایک سائرن بج گیا اور اسے فوری طور پر ٹھیک کرنے کا عمل شروع ہوا:
مزید برآں، کیبانا آپ کو مخصوص واقعات کے لیے اطلاعات کو منظم کرنے کی اجازت دیتا ہے، اور کچھ ہی عرصے میں کمپنی میں ٹول کو مختلف محکموں کے درجنوں ملازمین - تکنیکی مدد اور ترقی سے لے کر QA تک استعمال کرنے لگے۔
کمپنی کے اندر کسی بھی شعبے کی سرگرمی کو ٹریک کرنے اور پیمائش کرنے کے لیے آسان ہو گیا ہے - سرورز پر لاگز کا دستی طور پر تجزیہ کرنے کے بجائے، آپ کو صرف ایک بار پارسنگ لاگز ترتیب دینے ہوں گے اور لطف اندوز ہونے کے لیے انہیں لچکدار کلسٹر میں بھیجنا ہوگا، مثال کے طور پر، کبانہ میں غور کرنا۔ ڈیش بورڈ پر پچھلے قمری مہینے کے لیے 3-D پرنٹر پر پرنٹ کیے گئے دو سروں والے بلی کے بچوں کی تعداد۔
بنیادی کاروباری تجزیات
ہر کوئی جانتا ہے کہ کمپنیوں میں کاروباری تجزیات اکثر، جی ہاں، ایکسل کے انتہائی فعال استعمال سے شروع ہوتے ہیں۔ لیکن اہم بات یہ ہے کہ یہ وہاں ختم نہیں ہوتا ہے۔ کلاؤڈ پر مبنی Google Analytics بھی آگ میں ایندھن ڈالتا ہے - آپ جلدی سے اچھی چیزوں کے عادی ہونے لگتے ہیں۔
ہماری ہم آہنگی سے ترقی کرنے والی کمپنی میں، بڑے ڈیٹا کے ساتھ زیادہ گہرے کام کے یہاں اور وہاں "پیغمبر" ظاہر ہونے لگے۔ مزید گہرائی اور ہمہ جہتی رپورٹس کی ضرورت باقاعدگی سے ظاہر ہونے لگی اور مختلف شعبہ جات کے حضرات کی کوششوں سے کچھ عرصہ قبل ایک سادہ اور عملی حل کا اہتمام کیا گیا - کلک ہاؤس اور پاور بی آئی کا مجموعہ۔
کافی عرصے تک اس لچکدار حل نے بہت مدد کی لیکن آہستہ آہستہ یہ سمجھ آنے لگی کہ کلک ہاؤس ربڑ نہیں ہے اور اس کا اس طرح مذاق نہیں اڑایا جا سکتا۔
یہاں یہ اچھی طرح سمجھنا ضروری ہے کہ کلک ہاؤس، ڈروڈ کی طرح، ورٹیکا کی طرح، ایمیزون ریڈ شفٹ (جو پوسٹگریس پر مبنی ہے)، ایسے تجزیاتی انجن ہیں جو کافی آسان تجزیات کے لیے موزوں ہیں (رقم، جمع، کالم کے لحاظ سے کم از کم-زیادہ سے زیادہ اور چند ممکنہ شمولیت )، کیونکہ مائی ایس کیو ایل اور دیگر (قطار پر مبنی) ڈیٹا بیس کے برعکس جو ہم سے واقف ہیں، رشتہ دار جدولوں کے کالموں کے موثر اسٹوریج کے لیے منظم کیا گیا ہے۔
جوہر میں، ClickHouse صرف ایک زیادہ گنجائش والا "ڈیٹا بیس" ہے، جس میں پوائنٹ بہ پوائنٹ اندراج بہت آسان نہیں ہے (اس طرح اس کا مقصد ہے، سب کچھ ٹھیک ہے)، لیکن خوشگوار تجزیات اور ڈیٹا کے ساتھ کام کرنے کے لیے دلچسپ طاقتور فنکشنز کا ایک سیٹ۔ ہاں، آپ ایک جھرمٹ بھی بنا سکتے ہیں - لیکن آپ سمجھتے ہیں کہ خوردبین سے کیلوں کو ہتھوڑا لگانا بالکل درست نہیں ہے اور ہم نے دوسرے حل تلاش کرنا شروع کر دیے۔
ازگر اور تجزیہ نگاروں کا مطالبہ
ہماری کمپنی میں بہت سے ڈویلپرز ہیں جو PHP، JavaScript، C#، C/C++، Java, Go, Rust, Python, Bash میں تقریباً ہر روز 10-20 سال تک کوڈ لکھتے ہیں۔ ایسے بہت سے تجربہ کار سسٹم ایڈمنسٹریٹرز بھی ہیں جنہوں نے ایک سے زیادہ بالکل ناقابل یقین آفت کا تجربہ کیا ہے جو شماریات کے قوانین میں فٹ نہیں بیٹھتے ہیں (مثال کے طور پر، جب RAID-10 میں زیادہ تر ڈسک آسمانی بجلی گرنے سے تباہ ہو جاتی ہیں)۔ ایسے حالات میں، ایک طویل عرصے سے یہ واضح نہیں تھا کہ "ازگر تجزیہ کار" کیا ہے. ازگر پی ایچ پی کی طرح ہے، صرف نام تھوڑا لمبا ہے اور مترجم کے سورس کوڈ میں دماغ کو تبدیل کرنے والے مادوں کے کچھ کم نشانات ہیں۔ تاہم، جیسے جیسے زیادہ سے زیادہ تجزیاتی رپورٹیں بنتی گئیں، تجربہ کار ڈویلپرز نے numpy، pandas، matplotlib، seaborn جیسے اوزاروں میں تنگ مہارت کی اہمیت کو تیزی سے سمجھنا شروع کیا۔
فیصلہ کن کردار، غالباً، الفاظ "لاجسٹک ریگریشن" کے امتزاج سے ملازمین کے اچانک بے ہوش ہو جانا اور ہاں، ہاں، پائسپارک کا استعمال کرتے ہوئے بڑے ڈیٹا پر موثر رپورٹنگ کے مظاہرے نے ادا کیا تھا۔
Apache Spark، اس کا عملی نمونہ جس پر متعلقہ الجبرا بالکل فٹ بیٹھتا ہے، اور اس کی صلاحیتوں نے MySQL کے عادی ڈویلپرز پر ایسا تاثر دیا کہ تجربہ کار تجزیہ کاروں کے ساتھ صفوں کو مضبوط کرنے کی ضرورت روز بروز واضح ہوتی گئی۔
اپاچی اسپارک/ہڈوپ کی مزید کوششیں اور جو اسکرپٹ کے مطابق نہیں ہوئی
تاہم، یہ جلد ہی واضح ہو گیا کہ Spark کے ساتھ کچھ نظامی طور پر بالکل ٹھیک نہیں تھا، یا صرف اپنے ہاتھوں کو بہتر طریقے سے دھونا ضروری تھا۔ اگر Hadoop/MapReduce/Lucene اسٹیک کافی تجربہ کار پروگرامرز کے ذریعہ بنایا گیا تھا، جو ظاہر ہے کہ اگر آپ جاوا میں سورس کوڈ یا لوسین میں ڈوگ کٹنگ کے آئیڈیاز کو قریب سے دیکھیں، تو Spark، اچانک، غیر ملکی زبان Scala میں لکھا جاتا ہے، جو کہ ہے۔ عملییت کے نقطہ نظر سے بہت متنازعہ ہے اور فی الحال ترقی نہیں کر رہا ہے۔ اور کم آپریشنز کے لیے میموری مختص کرنے کے ساتھ غیر منطقی اور انتہائی شفاف کام کی وجہ سے اسپارک کلسٹر پر حسابات میں باقاعدگی سے کمی (بہت سی چابیاں ایک ساتھ آتی ہیں) نے اس کے گرد ایک ہالہ بنا دیا ہے جس میں بڑھنے کی گنجائش ہے۔ مزید برآں، بڑی تعداد میں عجیب و غریب کھلی بندرگاہوں، ناقابل فہم جگہوں پر عارضی فائلوں کے بڑھنے اور جار پر انحصار کی وجہ سے صورتحال مزید گھمبیر ہوگئی - جس کی وجہ سے سسٹم کے منتظمین کو ایک ایسا احساس پیدا ہوا جو بچپن سے مشہور تھا: شدید نفرت (یا شاید۔ انہیں اپنے ہاتھ صابن سے دھونے کی ضرورت تھی)۔
نتیجے کے طور پر، ہم نے کئی داخلی تجزیاتی منصوبے "بچ گئے" ہیں جو فعال طور پر اپاچی اسپارک (بشمول اسپارک اسٹریمنگ، اسپارک ایس کیو ایل) اور ہڈوپ ایکو سسٹم (اور اسی طرح) کا استعمال کرتے ہیں۔ اس حقیقت کے باوجود کہ وقت گزرنے کے ساتھ ساتھ ہم نے "اس" کو اچھی طرح سے تیار کرنا اور مانیٹر کرنا سیکھ لیا، اور ڈیٹا کی نوعیت میں تبدیلی اور یکساں RDD ہیشنگ کے عدم توازن کی وجہ سے "یہ" عملی طور پر اچانک کریش ہونا بند ہو گیا، کچھ لینے کی خواہش پہلے سے ہی تیار ہو گئی۔ , اپ ڈیٹ اور بادل میں کہیں زیر انتظام مضبوط اور مضبوط اضافہ ہوا. یہ وہ وقت تھا جب ہم نے ایمیزون ویب سروسز کی ریڈی میڈ کلاؤڈ اسمبلی کو استعمال کرنے کی کوشش کی۔ اور، بعد میں، اس کا استعمال کرتے ہوئے مسائل کو حل کرنے کی کوشش کی۔ EMR Apache Spark ہے جسے Amazon نے ماحولیاتی نظام کے اضافی سافٹ ویئر کے ساتھ تیار کیا ہے، جیسا کہ Cloudera/Hortonworks بناتا ہے۔
تجزیات کے لیے ربڑ فائل اسٹوریج کی فوری ضرورت ہے۔
جسم کے مختلف حصوں کو جلانے کے ساتھ ہڈوپ/چنگاری کو "کھانا پکانے" کا تجربہ بیکار نہیں تھا۔ ایک واحد، سستا اور قابل اعتماد فائل اسٹوریج بنانے کی ضرورت جو ہارڈ ویئر کی ناکامیوں کے خلاف مزاحم ہو اور جس میں فائلوں کو مختلف سسٹمز سے مختلف فارمیٹس میں اسٹور کرنا ممکن ہو اور اس ڈیٹا سے رپورٹس کے لیے موثر اور وقت کی بچت کے نمونے بنائے جائیں۔ صاف
میں یہ بھی چاہتا تھا کہ اس پلیٹ فارم کے سافٹ ویئر کو اپ ڈیٹ کرنا 20 صفحات پر مشتمل جاوا کے نشانات کو پڑھنے اور اسپارک ہسٹری سرور اور بیک لِٹ میگنفائنگ گلاس کا استعمال کرتے ہوئے کلسٹر کے کلومیٹر طویل تفصیلی لاگز کا تجزیہ کرنے کے ساتھ نئے سال کے ڈراؤنے خواب میں تبدیل نہ ہو۔ میں ایک سادہ اور شفاف ٹول حاصل کرنا چاہتا تھا جس کے لیے ہڈ کے نیچے باقاعدگی سے غوطہ خوری کی ضرورت نہ ہو اگر ڈیولپر کی معیاری MapReduce درخواست پر عمل درآمد بند ہو جائے جب ڈیٹا ورکر کی میموری سے محروم ہو جائے تو بہت اچھی طرح سے منتخب کردہ سورس ڈیٹا پارٹیشننگ الگورتھم کی وجہ سے۔
کیا ایمیزون S3 ڈیٹا لیک کا امیدوار ہے؟
Hadoop/MapReduce کے تجربے نے ہمیں سکھایا کہ ہمیں ایک قابل توسیع، قابل بھروسہ فائل سسٹم اور اس کے اوپر اسکیل ایبل ورکرز کی ضرورت ہے، ڈیٹا کے قریب "آنا" تاکہ ڈیٹا کو نیٹ ورک پر منتقل نہ کیا جا سکے۔ کارکنوں کو مختلف فارمیٹس میں ڈیٹا پڑھنے کے قابل ہونا چاہیے، لیکن ترجیحی طور پر غیر ضروری معلومات کو نہ پڑھیں اور کارکنوں کے لیے آسان فارمیٹس میں ڈیٹا کو پہلے سے ذخیرہ کرنے کے قابل ہوں۔
ایک بار پھر، بنیادی خیال. کسی ایک کلسٹر تجزیاتی انجن میں بڑے ڈیٹا کو "ڈالنے" کی کوئی خواہش نہیں ہے، جو جلد یا بدیر دم گھٹ جائے گا اور آپ کو اسے بدصورت بنانا پڑے گا۔ میں فائلوں کو، صرف فائلوں کو، ایک قابل فہم شکل میں ذخیرہ کرنا چاہتا ہوں اور مختلف لیکن قابل فہم ٹولز کا استعمال کرتے ہوئے ان پر موثر تجزیاتی سوالات کرنا چاہتا ہوں۔ اور مختلف فارمیٹس میں زیادہ سے زیادہ فائلیں ہوں گی۔ اور انجن کو نہیں بلکہ سورس ڈیٹا کو شارڈ کرنا بہتر ہے۔ ہمیں ایک قابل توسیع اور عالمگیر ڈیٹا لیک کی ضرورت ہے، ہم نے فیصلہ کیا...
کیا ہوگا اگر آپ ہڈوپ سے اپنی چپس تیار کیے بغیر، واقف اور معروف اسکیل ایبل کلاؤڈ اسٹوریج Amazon S3 میں فائلیں اسٹور کرتے ہیں؟
یہ واضح ہے کہ ذاتی ڈیٹا "کم" ہے، لیکن دوسرے ڈیٹا کا کیا ہوگا اگر ہم اسے وہاں سے باہر لے جائیں اور "اسے مؤثر طریقے سے چلائیں"؟
ایمیزون ویب سروسز کا کلسٹر-بگ ڈیٹا اینالیٹکس ایکو سسٹم - بہت آسان الفاظ میں
AWS کے ساتھ ہمارے تجربے کو دیکھتے ہوئے، Apache Hadoop/MapReduce وہاں ایک طویل عرصے سے مختلف ساسز کے تحت فعال طور پر استعمال ہوتا رہا ہے، مثال کے طور پر ڈیٹا پائپ لائن سروس میں (میں اپنے ساتھیوں سے حسد کرتا ہوں، انہوں نے اسے صحیح طریقے سے تیار کرنا سیکھ لیا)۔ یہاں ہم DynamoDB ٹیبلز سے مختلف سروسز سے بیک اپ سیٹ کرتے ہیں۔
اور وہ کئی سالوں سے ایمبیڈڈ Hadoop/MapReduce کلسٹرز جیسے کلاک ورک پر باقاعدگی سے چل رہے ہیں۔ "اسے سیٹ کریں اور بھول جائیں":
آپ تجزیہ کاروں کے لیے کلاؤڈ میں مشتری لیپ ٹاپ ترتیب دے کر اور AI ماڈلز کو جنگ میں تربیت اور تعینات کرنے کے لیے AWS SageMaker سروس کا استعمال کر کے ڈیٹا شیطانیت میں مؤثر طریقے سے مشغول ہو سکتے ہیں۔ یہ ہمارے لیے کیسا لگتا ہے:
اور ہاں، آپ اپنے لیے یا کلاؤڈ میں کسی تجزیہ کار کے لیے ایک لیپ ٹاپ اٹھا سکتے ہیں اور اسے ہڈوپ/اسپارک کلسٹر سے منسلک کر سکتے ہیں، حساب کتاب کر سکتے ہیں اور پھر سب کچھ ٹھیک کر سکتے ہیں:
انفرادی تجزیاتی منصوبوں کے لیے واقعی آسان ہے اور کچھ کے لیے ہم نے بڑے پیمانے پر حساب اور تجزیات کے لیے کامیابی کے ساتھ EMR سروس کا استعمال کیا ہے۔ ڈیٹا لیک کے سسٹم حل کے بارے میں کیا ہے، کیا یہ کام کرے گا؟ اس وقت ہم امید اور مایوسی کے دہانے پر تھے اور تلاش جاری رکھی۔
AWS Glue - سٹیرائڈز پر صفائی سے پیک کیا ہوا اپاچی اسپارک
یہ پتہ چلا کہ AWS کے پاس "Hive/Pig/Spark" اسٹیک کا اپنا ورژن ہے۔ Hive کا کردار، یعنی ڈیٹا لیک میں فائلوں اور ان کی اقسام کا کیٹلاگ "ڈیٹا کیٹلاگ" سروس کے ذریعہ انجام دیا جاتا ہے، جو اپاچی ہائیو فارمیٹ کے ساتھ اس کی مطابقت کو نہیں چھپاتا ہے۔ آپ کو اس سروس میں معلومات شامل کرنے کی ضرورت ہے کہ آپ کی فائلیں کہاں واقع ہیں اور وہ کس فارمیٹ میں ہیں۔ ڈیٹا نہ صرف s3 میں ہو سکتا ہے، بلکہ ڈیٹا بیس میں بھی ہو سکتا ہے، لیکن یہ اس پوسٹ کا موضوع نہیں ہے۔ یہ ہے کہ ہماری ڈیٹا لیک ڈیٹا ڈائرکٹری کو کس طرح منظم کیا گیا ہے:
فائلیں رجسٹرڈ ہیں، بہت اچھا۔ اگر فائلوں کو اپ ڈیٹ کر دیا گیا ہے، تو ہم کرالرز کو یا تو دستی طور پر یا شیڈول کے مطابق لانچ کرتے ہیں، جو جھیل سے ان کے بارے میں معلومات کو اپ ڈیٹ کرے گا اور انہیں محفوظ کرے گا۔ اس کے بعد جھیل سے ڈیٹا پر کارروائی کی جا سکتی ہے اور نتائج کو کہیں اپ لوڈ کیا جا سکتا ہے۔ آسان ترین صورت میں، ہم s3 پر بھی اپ لوڈ کرتے ہیں۔ ڈیٹا پروسیسنگ کہیں بھی کی جا سکتی ہے، لیکن یہ تجویز کیا جاتا ہے کہ آپ AWS Glue API کے ذریعے جدید صلاحیتوں کا استعمال کرتے ہوئے Apache Spark کلسٹر پر پروسیسنگ کو ترتیب دیں۔ درحقیقت، آپ pyspark لائبریری کا استعمال کرتے ہوئے اچھے پرانے اور مانوس ازگر کا کوڈ لے سکتے ہیں اور ہڈوپ کی ہمت میں کھودنے اور ڈوکر-موکر کنٹینرز کو گھسیٹنے اور انحصار کے تنازعات کو ختم کیے بغیر، نگرانی کے ساتھ کچھ صلاحیت کے کلسٹر کے N نوڈس پر اس کے عمل کو ترتیب دے سکتے ہیں۔ .
ایک بار پھر، ایک سادہ خیال. اپاچی اسپارک کو کنفیگر کرنے کی ضرورت نہیں ہے، آپ کو صرف پائتھن کوڈ لکھنے کی ضرورت ہے، اسے اپنے ڈیسک ٹاپ پر مقامی طور پر ٹیسٹ کریں اور پھر اسے کلاؤڈ میں ایک بڑے کلسٹر پر چلائیں، یہ بتاتے ہوئے کہ سورس ڈیٹا کہاں ہے اور نتیجہ کہاں ڈالنا ہے۔ بعض اوقات یہ ضروری اور مفید ہوتا ہے، اور ہم اسے کیسے ترتیب دیتے ہیں:
اس طرح، اگر آپ کو s3 میں ڈیٹا کا استعمال کرتے ہوئے اسپارک کلسٹر پر کسی چیز کا حساب لگانے کی ضرورت ہے، تو ہم python/pyspark میں کوڈ لکھتے ہیں، اس کی جانچ کرتے ہیں، اور کلاؤڈ کے لیے اچھی قسمت۔
آرکیسٹریشن کے بارے میں کیا خیال ہے؟ اگر کام گر گیا اور غائب ہو گیا تو کیا ہوگا؟ ہاں، اپاچی پگ کے انداز میں ایک خوبصورت پائپ لائن بنانے کی تجویز ہے اور ہم نے انہیں آزمایا بھی، لیکن ابھی کے لیے ہم نے پی ایچ پی اور جاوا اسکرپٹ میں اپنی گہری حسب ضرورت آرکیسٹریشن کو استعمال کرنے کا فیصلہ کیا ہے (میں سمجھتا ہوں، علمی اختلاف ہے، لیکن یہ کام کرتا ہے، سال اور غلطیوں کے بغیر)۔
جھیل میں محفوظ فائلوں کی شکل کارکردگی کی کلید ہے۔
دو اور اہم نکات کو سمجھنا بہت ضروری ہے۔ جھیل میں فائل ڈیٹا سے متعلق استفسارات کو جلد از جلد مکمل کرنے اور نئی معلومات شامل کرنے پر کارکردگی خراب نہ ہونے کے لیے، آپ کو یہ کرنے کی ضرورت ہے:
- فائلوں کے کالموں کو الگ سے اسٹور کریں (تاکہ آپ کو کالموں میں کیا ہے یہ سمجھنے کے لیے تمام لائنوں کو پڑھنے کی ضرورت نہ پڑے)۔ اس کے لیے ہم نے کمپریشن کے ساتھ پارکیٹ فارمیٹ لیا۔
- فائلوں کو فولڈرز میں شارڈ کرنا بہت ضروری ہے جیسے: زبان، سال، مہینہ، دن، ہفتہ۔ انجن جو اس قسم کی شارڈنگ کو سمجھتے ہیں وہ تمام ڈیٹا کو لگاتار چھاننے کے بغیر صرف ضروری فولڈرز کو دیکھیں گے۔
بنیادی طور پر، اس طرح، آپ سب سے اوپر لٹکائے ہوئے تجزیاتی انجنوں کے لیے ماخذ ڈیٹا کو انتہائی موثر شکل میں ترتیب دیتے ہیں، جو کہ شارڈ فولڈرز میں بھی منتخب طور پر فائلوں سے صرف ضروری کالم داخل اور پڑھ سکتے ہیں۔ آپ کو کہیں بھی ڈیٹا کو "پُر" کرنے کی ضرورت نہیں ہے (اسٹوریج آسانی سے پھٹ جائے گا) - بس فوراً سمجھداری سے اسے درست فارمیٹ میں فائل سسٹم میں ڈال دیں۔ بلاشبہ، یہاں یہ واضح رہے کہ ڈیٹا لیک میں ایک بہت بڑی csv فائل کو ذخیرہ کرنا، جسے کالم نکالنے کے لیے سب سے پہلے کلسٹر کے ذریعے لائن بہ لائن پڑھنا ضروری ہے، زیادہ مناسب نہیں ہے۔ مندرجہ بالا دو نکات پر دوبارہ غور کریں اگر یہ ابھی تک واضح نہیں ہے کہ یہ سب کیوں ہو رہا ہے۔
AWS Athena - جیک ان دی باکس
اور پھر، ایک جھیل بناتے ہوئے، ہم کسی نہ کسی طرح حادثاتی طور پر ایمیزون ایتھینا کے پاس آ گئے۔ اچانک معلوم ہوا کہ ہماری بڑی لاگ فائلوں کو فولڈر کے شارڈز میں درست (پارکیٹ) کالم فارمیٹ میں احتیاط سے ترتیب دے کر، آپ ان سے بہت جلد انتہائی معلوماتی انتخاب کر سکتے ہیں اور اپاچی اسپارک/گلو کلسٹر کے بغیر رپورٹس بنا سکتے ہیں۔
s3 میں ڈیٹا سے چلنے والا ایتھینا انجن افسانوی پر مبنی ہے۔ - MPP (بڑے پیمانے پر متوازی پروسیسنگ) ڈیٹا پروسیسنگ کے نقطہ نظر کے خاندان کا ایک نمائندہ، ڈیٹا کو لے کر جہاں یہ ہے، S3 اور Hadoop سے Cassandra اور عام ٹیکسٹ فائلوں تک۔ آپ کو صرف ایتھینا سے SQL استفسار پر عمل کرنے کے لیے کہنے کی ضرورت ہے، اور پھر سب کچھ "جلد اور خود بخود کام کرتا ہے۔" یہ نوٹ کرنا ضروری ہے کہ ایتھینا "سمارٹ" ہے، یہ صرف ضروری شارڈ فولڈرز تک جاتی ہے اور درخواست میں درکار کالم ہی پڑھتی ہے۔
ایتھینا کی درخواستوں کی قیمت بھی دلچسپ ہے۔ ہم ادائیگی کرتے ہیں۔ . وہ. کلسٹر میں فی منٹ مشینوں کی تعداد کے لیے نہیں، بلکہ... اصل میں 100-500 مشینوں پر اسکین کیے گئے ڈیٹا کے لیے، صرف درخواست کو مکمل کرنے کے لیے ضروری ڈیٹا۔
اور درست طریقے سے شارڈ فولڈرز سے صرف ضروری کالموں کی درخواست کرنے سے، یہ پتہ چلا کہ ایتھینا سروس ہمیں ایک ماہ میں دسیوں ڈالر خرچ کرتی ہے۔ ٹھیک ہے، بہت اچھا، تقریباً مفت، کلسٹرز پر تجزیات کے مقابلے میں!
ویسے، یہ ہے کہ ہم اپنے ڈیٹا کو s3 میں کس طرح شیئر کرتے ہیں:
نتیجتاً، تھوڑے ہی عرصے میں، کمپنی کے مکمل طور پر مختلف محکموں نے، انفارمیشن سیکیورٹی سے لے کر تجزیات تک، ایتھینا کو فعال طور پر درخواستیں کرنا شروع کر دیں اور تیزی سے، سیکنڈوں میں، کافی طویل عرصے میں "بڑے" ڈیٹا سے مفید جوابات حاصل کر لیے: مہینوں، آدھا سال، وغیرہ
لیکن ہم مزید آگے بڑھے اور جوابات کے لیے بادل کے پاس جانے لگے : ایک تجزیہ کار ایک مانوس کنسول میں SQL استفسار لکھتا ہے، جو 100-500 مشینوں پر "پینی کے لیے" ڈیٹا کو s3 پر بھیجتا ہے اور عام طور پر چند سیکنڈ میں جواب دیتا ہے۔ آرام دہ۔ اور تیز۔ میں اب بھی اس پر یقین نہیں کر سکتا۔
نتیجے کے طور پر، ڈیٹا کو s3 میں محفوظ کرنے کا فیصلہ کرنے کے بعد، ایک موثر کالمی فارمیٹ میں اور ڈیٹا کو فولڈرز میں مناسب شارڈنگ کے ساتھ... ہمیں ڈیٹا لیک اور ایک تیز اور سستا تجزیاتی انجن موصول ہوا - مفت میں۔ اور وہ کمپنی میں بہت مقبول ہو گیا، کیونکہ... ایس کیو ایل کو سمجھتا ہے اور کلسٹرز کو شروع کرنے/روکنے/سیٹنے کے مقابلے میں زیادہ تیزی سے کام کرتا ہے۔ "اور اگر نتیجہ ایک ہی ہے تو زیادہ ادائیگی کیوں؟"
ایتھینا سے ایک درخواست کچھ اس طرح نظر آتی ہے۔ اگر آپ چاہیں تو یقیناً آپ کافی تشکیل دے سکتے ہیں۔ لیکن ہم خود کو سادہ گروپ بندی تک محدود رکھیں گے۔ آئیے دیکھتے ہیں کہ کلائنٹ کے پاس کچھ ہفتے پہلے ویب سرور لاگز میں کون سے رسپانس کوڈ تھے اور اس بات کو یقینی بنائیں کہ کوئی خرابی نہیں ہے:
نتائج
ایک طویل، لیکن تکلیف دہ راستے سے گزرنے کے بعد، خطرات اور پیچیدگی کی سطح اور معاونت کی لاگت کا مسلسل مناسب اندازہ لگاتے ہوئے، ہم نے ڈیٹا لیک اور تجزیات کے لیے ایک ایسا حل تلاش کیا جو ملکیت کی رفتار اور قیمت دونوں سے ہمیں خوش کرنے سے کبھی باز نہیں آتا۔
اس سے معلوم ہوا کہ کمپنی کے بالکل مختلف محکموں کی ضروریات کے لیے ڈیٹا لیک کو چلانے کے لیے ایک موثر، تیز اور سستا بنانا مکمل طور پر ان تجربہ کار ڈویلپرز کی صلاحیتوں کے اندر ہے جنہوں نے کبھی معمار کے طور پر کام نہیں کیا اور یہ نہیں جانتے کہ چوکوں پر چوکوں کو کس طرح کھینچنا ہے۔ ہڈوپ ماحولیاتی نظام سے تیر اور 50 اصطلاحات جانیں۔
سفر کے آغاز میں، میرا سر کھلے اور بند سافٹ ویئر کے بہت سے جنگلی چڑیا گھر سے پھٹ رہا تھا اور اولاد کو ذمہ داری کے بوجھ کی سمجھ تھی۔ بس اپنے ڈیٹا لیک کو آسان ٹولز سے بنانا شروع کریں: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3...، فیڈ بیک جمع کرنا اور ہونے والے عمل کی فزکس کو گہرائی سے سمجھنا۔ ہر چیز پیچیدہ اور گندی ہے - اسے دشمنوں اور حریفوں کو دیں۔
اگر آپ کلاؤڈ پر نہیں جانا چاہتے اور اوپن سورس پروجیکٹس کو سپورٹ، اپ ڈیٹ اور پیچ کرنا چاہتے ہیں، تو آپ مقامی طور پر ہماری طرح کی ایک اسکیم بنا سکتے ہیں، جس میں سب سے اوپر Hadoop اور Presto والی سستی آفس مشینیں ہیں۔ اہم بات یہ ہے کہ رکنا اور آگے بڑھنا نہیں ہے، شمار کریں، آسان اور واضح حل تلاش کریں، اور سب کچھ یقینی طور پر کام کرے گا! سب کے لیے گڈ لک اور دوبارہ ملتے ہیں!
ماخذ: www.habr.com