سرور تجزیاتی نظام

یہ تجزیاتی نظام کے بارے میں مضامین کی سیریز کا دوسرا حصہ ہے (حصہ 1 کا لنک).

آج اس میں کوئی شک نہیں ہے کہ محتاط ڈیٹا پروسیسنگ اور نتائج کی تشریح تقریباً کسی بھی قسم کے کاروبار میں مدد کر سکتی ہے۔ اس سلسلے میں، تجزیاتی نظام تیزی سے پیرامیٹرز سے بھرے ہوتے جا رہے ہیں، اور ایپلی کیشنز میں محرکات اور صارف کے واقعات کی تعداد بڑھ رہی ہے۔
اس کی وجہ سے، کمپنیاں اپنے تجزیہ کاروں کو تجزیہ کرنے اور درست فیصلوں میں تبدیل کرنے کے لیے زیادہ سے زیادہ خام معلومات دے رہی ہیں۔ کسی کمپنی کے لیے تجزیاتی نظام کی اہمیت کو کم نہیں سمجھا جانا چاہیے، اور نظام خود قابل اعتماد اور مستحکم ہونا چاہیے۔

کلائنٹ تجزیہ کار

کسٹمر اینالیٹکس ایک ایسی سروس ہے جسے کمپنی اپنی ویب سائٹ یا ایپلیکیشن سے آفیشل SDK کے ذریعے جوڑتی ہے، اپنے کوڈ بیس میں ضم ہوتی ہے اور ایونٹ کے محرکات کو منتخب کرتی ہے۔ اس نقطہ نظر کا ایک واضح منفی پہلو ہے: آپ کی منتخب کردہ کسی بھی سروس کی حدود کی وجہ سے جمع کردہ تمام ڈیٹا پر بالکل اسی طرح کارروائی نہیں کی جا سکتی ہے جیسا کہ آپ چاہتے ہیں۔ مثال کے طور پر، ایک سسٹم پر MapReduce کاموں کو چلانا آسان نہیں ہوگا، دوسرے پر آپ اپنا ماڈل نہیں چلا سکیں گے۔ ایک اور نقصان خدمات کے لیے باقاعدہ (متاثر کن) بل ہو گا۔
مارکیٹ میں کسٹمر کے تجزیات کے بہت سے حل موجود ہیں، لیکن جلد یا بدیر تجزیہ کاروں کو اس حقیقت کا سامنا کرنا پڑتا ہے کہ ہر کام کے لیے موزوں کوئی بھی یونیورسل سروس نہیں ہے (جبکہ ان تمام خدمات کی قیمتیں ہر وقت بڑھ رہی ہیں)۔ ایسی صورت حال میں، کمپنیاں اکثر تمام ضروری حسب ضرورت ترتیبات اور صلاحیتوں کے ساتھ اپنا تجزیاتی نظام بنانے کا فیصلہ کرتی ہیں۔

سرور تجزیہ کار

سرور سائیڈ اینالیٹکس ایک ایسی سروس ہے جسے کمپنی کے اندر اس کے اپنے سرورز پر اور (عام طور پر) اپنی کوششوں سے تعینات کیا جا سکتا ہے۔ اس ماڈل میں، تمام یوزر ایونٹس کو اندرونی سرورز پر اسٹور کیا جاتا ہے، جس سے ڈویلپرز کو مختلف اسٹوریج ڈیٹا بیسز آزمانے اور سب سے آسان فن تعمیر کا انتخاب کرنے کی اجازت ملتی ہے۔ اور یہاں تک کہ اگر آپ اب بھی کچھ کاموں کے لیے تھرڈ پارٹی کلائنٹ اینالیٹکس استعمال کرنا چاہتے ہیں، تب بھی یہ ممکن ہوگا۔
سرور سائیڈ اینالیٹکس کو دو طریقوں سے تعینات کیا جا سکتا ہے۔ پہلے: کچھ اوپن سورس یوٹیلیٹیز کا انتخاب کریں، انہیں اپنی مشینوں پر لگائیں اور کاروباری منطق تیار کریں۔

پیشہ
Cons

آپ اپنی مرضی کے مطابق کچھ بھی کر سکتے ہیں۔
یہ اکثر بہت مشکل ہوتا ہے اور اس کے لیے علیحدہ ڈویلپرز کی ضرورت ہوتی ہے۔

دوسرا: SaaS سروسز (Amazon, Google, Azure) کو خود تعینات کرنے کے بجائے لیں۔ ہم تیسرے حصے میں مزید تفصیل سے ساس کے بارے میں بات کریں گے۔

پیشہ
Cons

یہ درمیانے حجم میں سستا ہو سکتا ہے، لیکن بڑی ترقی کے ساتھ یہ اب بھی بہت مہنگا ہو جائے گا۔
تمام پیرامیٹرز کو کنٹرول کرنا ممکن نہیں ہوگا۔

انتظامیہ مکمل طور پر سروس فراہم کرنے والے کے کندھوں پر منتقل ہوتی ہے۔
یہ ہمیشہ معلوم نہیں ہوتا ہے کہ سروس کے اندر کیا ہے (ہو سکتا ہے اس کی ضرورت نہ ہو)

سرور کے تجزیات کو کیسے جمع کریں۔

اگر ہم کلائنٹ کے تجزیات کو استعمال کرنے سے دور رہنا چاہتے ہیں اور اپنا بنانا چاہتے ہیں، تو سب سے پہلے ہمیں نئے نظام کے فن تعمیر کے ذریعے سوچنے کی ضرورت ہے۔ ذیل میں میں آپ کو مرحلہ وار بتاؤں گا کہ آپ کو کن چیزوں پر غور کرنے کی ضرورت ہے، ہر قدم کی ضرورت کیوں ہے اور آپ کون سے ٹولز استعمال کر سکتے ہیں۔

1. ڈیٹا وصول کرنا

بالکل اسی طرح جیسے گاہک کے تجزیات کے معاملے میں، سب سے پہلے، کمپنی کے تجزیہ کار واقعات کی ان اقسام کا انتخاب کرتے ہیں جن کا وہ مستقبل میں مطالعہ کرنا چاہتے ہیں اور انہیں ایک فہرست میں جمع کرتے ہیں۔ عام طور پر، یہ واقعات ایک مخصوص ترتیب میں ہوتے ہیں، جسے "ایونٹ پیٹرن" کہا جاتا ہے۔
اگلا، تصور کریں کہ ایک موبائل ایپلیکیشن (ویب سائٹ) کے باقاعدہ صارفین (آلات) اور بہت سے سرورز ہیں۔ واقعات کو آلات سے سرور پر محفوظ طریقے سے منتقل کرنے کے لیے، ایک درمیانی پرت کی ضرورت ہے۔ فن تعمیر پر منحصر ہے، ایونٹ کی کئی مختلف قطاریں ہو سکتی ہیں۔
اپاچی کافکا ہے - پب/سب قطار، جو واقعات کو جمع کرنے کے لیے ایک قطار کے طور پر استعمال ہوتا ہے۔

کے مطابق Quora پر پوسٹ کریں۔ 2014 میں، اپاچی کافکا کے تخلیق کار نے سافٹ ویئر کا نام فرانز کافکا کے نام پر رکھنے کا فیصلہ کیا کیونکہ "یہ ایک ایسا نظام ہے جو لکھنے کے لیے موزوں ہے" اور اس لیے کہ وہ کافکا کے کاموں سے محبت کرتے تھے۔ - وکیپیڈیا

ہماری مثال میں، بہت سے ڈیٹا پروڈیوسر اور ڈیٹا صارفین (آلات اور سرورز) ہیں، اور کافکا انہیں ایک دوسرے سے مربوط کرنے میں مدد کرتا ہے۔ مندرجہ ذیل مراحل میں صارفین کو مزید تفصیل سے بیان کیا جائے گا، جہاں وہ اہم موضوعات ہوں گے۔ اب ہم صرف ڈیٹا پروڈیوسر (واقعات) پر غور کریں گے۔
کافکا قطار اور تقسیم کے تصورات کو سمیٹتا ہے؛ اس کے بارے میں کہیں اور پڑھنا بہتر ہے (مثال کے طور پر، میں دستاویزات)۔ تفصیلات میں جانے کے بغیر، آئیے تصور کریں کہ دو مختلف OS کے لیے ایک موبائل ایپلیکیشن لانچ کی گئی ہے۔ پھر ہر ورژن اپنا الگ ایونٹ اسٹریم بناتا ہے۔ پروڈیوسر کافکا کو واقعات بھیجتے ہیں، انہیں ایک مناسب قطار میں ریکارڈ کیا جاتا ہے۔

(تصویر اس وجہ سے)

ایک ہی وقت میں، کافکا آپ کو ٹکڑوں میں پڑھنے اور واقعات کے سلسلے کو منی بیچوں میں پروسیس کرنے کی اجازت دیتا ہے۔ کافکا ایک بہت ہی آسان ٹول ہے جو بڑھتی ہوئی ضروریات (مثال کے طور پر واقعات کے جغرافیائی محل وقوع کے لحاظ سے) کے ساتھ اچھی طرح پیمانہ کرتا ہے۔
عام طور پر ایک شارڈ کافی ہوتا ہے، لیکن اسکیلنگ کرتے وقت چیزیں زیادہ پیچیدہ ہوجاتی ہیں (جیسا کہ وہ ہمیشہ کرتے ہیں)۔ شاید کوئی بھی پیداوار میں صرف ایک جسمانی شارڈ استعمال نہیں کرنا چاہے گا، کیونکہ فن تعمیر کو غلطی برداشت کرنا چاہیے۔ کافکا کے علاوہ، ایک اور معروف حل ہے - RabbitMQ۔ ہم نے اسے پروڈکشن میں ایونٹ کے تجزیات کے لیے قطار کے طور پر استعمال نہیں کیا (اگر آپ کو ایسا تجربہ ہے تو ہمیں اس کے بارے میں تبصرے میں بتائیں!)۔ تاہم، ہم نے AWS Kinesis استعمال کیا۔

اگلے مرحلے پر جانے سے پہلے، ہمیں سسٹم کی ایک اور اضافی پرت کا ذکر کرنا ہوگا - خام لاگ اسٹوریج۔ یہ ایک مطلوبہ پرت نہیں ہے، لیکن اگر کچھ غلط ہو جائے اور کافکا میں ایونٹ کی قطاریں دوبارہ ترتیب دی جائیں تو یہ مفید ہو گا۔ خام نوشتہ جات کو ذخیرہ کرنے کے لیے کسی پیچیدہ اور مہنگے حل کی ضرورت نہیں ہوتی؛ آپ انہیں آسانی سے کہیں صحیح ترتیب میں لکھ سکتے ہیں (یہاں تک کہ ہارڈ ڈرائیو پر بھی)۔

2. پروسیسنگ ایونٹ اسٹریمز

تمام واقعات کو تیار کرنے اور انہیں مناسب قطاروں میں رکھنے کے بعد، ہم پروسیسنگ کے مرحلے کی طرف بڑھتے ہیں۔ یہاں میں آپ کو پروسیسنگ کے دو سب سے عام اختیارات کے بارے میں بتاؤں گا۔
پہلا آپشن اپاچی سسٹم میں اسپارک اسٹریمنگ کو فعال کرنا ہے۔ اپاچی کے تمام پروڈکٹس HDFS پر رہتے ہیں، فائل کی نقل کے ساتھ ایک محفوظ فائل سسٹم۔ اسپارک اسٹریمنگ ایک استعمال میں آسان ٹول ہے جو اسٹریمنگ ڈیٹا اور اسکیل کو اچھی طرح سے ہینڈل کرتا ہے۔ تاہم، اسے برقرار رکھنا مشکل ہوسکتا ہے۔
دوسرا آپشن یہ ہے کہ آپ اپنا ایونٹ ہینڈلر بنائیں۔ ایسا کرنے کے لیے، آپ کو، مثال کے طور پر، ایک Python ایپلیکیشن لکھنے کے لیے، اسے Docker میں بنانا اور کافکا کی قطار میں سبسکرائب کرنے کی ضرورت ہے۔ جب محرکات ڈاکر ہینڈلرز پر پہنچیں گے، پروسیسنگ شروع ہو جائے گی۔ اس طریقہ کے ساتھ، آپ کو ایپلی کیشنز کو ہر وقت چلاتے رہنے کی ضرورت ہے۔
آئیے مان لیتے ہیں کہ ہم نے اوپر بیان کردہ آپشنز میں سے ایک کا انتخاب کیا ہے اور خود پروسیسنگ کی طرف بڑھتے ہیں۔ پروسیسرز کو ڈیٹا کی درستگی کی جانچ پڑتال، ردی کی ٹوکری اور "ٹوٹے" واقعات کو فلٹر کرکے شروع کرنا چاہئے۔ توثیق کے لیے ہم عام طور پر استعمال کرتے ہیں۔ سربرس. اس کے بعد، آپ ڈیٹا میپنگ کر سکتے ہیں: مشترکہ ٹیبل میں شامل کرنے کے لیے مختلف ذرائع سے ڈیٹا کو نارمل اور معیاری بنایا جاتا ہے۔

3. ڈیٹا بیس

تیسرا مرحلہ معمول کے واقعات کو برقرار رکھنا ہے۔ تیار شدہ تجزیاتی نظام کے ساتھ کام کرتے وقت، ہمیں اکثر ان تک رسائی حاصل کرنی پڑے گی، اس لیے ایک آسان ڈیٹا بیس کا انتخاب کرنا ضروری ہے۔
اگر ڈیٹا ایک مقررہ اسکیم میں اچھی طرح فٹ بیٹھتا ہے، تو آپ انتخاب کرسکتے ہیں۔ کلک ہاؤس یا کوئی اور کالمی ڈیٹا بیس۔ اس طرح مجموعے بہت تیزی سے کام کریں گے۔ منفی پہلو یہ ہے کہ اسکیم کو سختی سے طے کیا گیا ہے اور اس لیے بغیر کسی ترمیم کے صوابدیدی اشیاء کو شامل کرنا ممکن نہیں ہوگا (مثال کے طور پر، جب کوئی غیر معیاری واقعہ پیش آتا ہے)۔ لیکن آپ واقعی بہت جلد گن سکتے ہیں۔
غیر ساختہ ڈیٹا کے لیے، آپ NoSQL لے سکتے ہیں، مثال کے طور پر، اپاچی Cassandra. یہ HDFS پر چلتا ہے، اچھی طرح سے نقل کرتا ہے، آپ بہت سی مثالیں پیش کر سکتے ہیں، اور غلطی برداشت کرنے والا ہے۔
آپ کچھ آسان بھی اٹھا سکتے ہیں، مثال کے طور پر، منگو ڈی بی. یہ کافی سست اور چھوٹے حجم کے لیے ہے۔ لیکن پلس یہ ہے کہ یہ بہت آسان ہے اور اس لیے شروع کرنے کے لیے موزوں ہے۔

4. جمع کرنا

تمام واقعات کو احتیاط سے محفوظ کرنے کے بعد، ہم آنے والے بیچ سے تمام اہم معلومات اکٹھا کرنا اور ڈیٹا بیس کو اپ ڈیٹ کرنا چاہتے ہیں۔ عالمی سطح پر، ہم متعلقہ ڈیش بورڈز اور میٹرکس حاصل کرنا چاہتے ہیں۔ مثال کے طور پر، واقعات سے صارف کا پروفائل جمع کریں اور کسی نہ کسی طرح رویے کی پیمائش کریں۔ واقعات کو جمع کیا جاتا ہے، جمع کیا جاتا ہے، اور دوبارہ محفوظ کیا جاتا ہے (صارف کی میزوں میں)۔ ایک ہی وقت میں، آپ ایک ایسا نظام بنا سکتے ہیں تاکہ آپ ایک فلٹر کو ایگریگیٹر کوآرڈینیٹر سے بھی جوڑ سکیں: صرف ایک خاص قسم کے ایونٹ سے صارفین کو اکٹھا کریں۔
اس کے بعد، اگر ٹیم کے کسی فرد کو صرف اعلیٰ سطح کے تجزیات کی ضرورت ہو، تو بیرونی تجزیاتی نظام کو منسلک کیا جا سکتا ہے۔ آپ Mixpanel دوبارہ لے سکتے ہیں۔ لیکن چونکہ یہ کافی مہنگا ہے، اس لیے تمام یوزر ایونٹس وہاں نہیں بھیجے جاتے ہیں، بلکہ صرف وہی جو ضروری ہے۔ ایسا کرنے کے لیے، ہمیں ایک کوآرڈینیٹر بنانے کی ضرورت ہے جو کچھ خام واقعات یا کسی ایسی چیز کو منتقل کرے گا جسے ہم نے پہلے اکٹھا کیا تھا بیرونی سسٹمز، APIs یا اشتہاری پلیٹ فارمز پر۔

5. فرنٹ اینڈ

آپ کو فرنٹ اینڈ کو بنائے گئے سسٹم سے جوڑنے کی ضرورت ہے۔ ایک اچھی مثال خدمت ہے۔ سرخ کرنا، ایک ڈیٹا بیس GUI ہے جو ڈیش بورڈ بنانے میں مدد کرتا ہے۔ تعامل کیسے کام کرتا ہے:

1. صارف ایک SQL استفسار کرتا ہے۔
2. جواب میں اسے ایک نشان ملتا ہے۔
3. اس کے لیے ایک 'نیا تصور' بناتا ہے اور ایک خوبصورت گراف حاصل کرتا ہے جسے آپ اپنے لیے محفوظ کر سکتے ہیں۔

سروس میں تصورات خود کار طریقے سے اپ ڈیٹ ہو رہے ہیں، آپ اپنی نگرانی کو اپنی مرضی کے مطابق اور ٹریک کر سکتے ہیں۔ Redash مفت ہے اگر خود میزبان ہو، لیکن SaaS کے طور پر اس کی لاگت $50 فی مہینہ ہوگی۔

حاصل يہ ہوا

اوپر دیے گئے تمام مراحل کو مکمل کرنے کے بعد، آپ اپنا سرور اینالیٹکس بنائیں گے۔ براہ کرم نوٹ کریں کہ یہ اتنا آسان نہیں ہے جتنا کہ کسٹمر کے تجزیات کو جوڑنا، کیونکہ ہر چیز کو خود ترتیب دینے کی ضرورت ہے۔ اس لیے، اپنا نظام بنانے سے پہلے، ایک سنجیدہ تجزیاتی نظام کی ضرورت کا ان وسائل سے موازنہ کرنا قابل قدر ہے جو آپ اس کے لیے مختص کرنے کے لیے تیار ہیں۔
اگر آپ نے ریاضی کی ہے اور محسوس کیا ہے کہ اخراجات بہت زیادہ ہیں، تو اگلے حصے میں میں اس بارے میں بات کروں گا کہ سرور سائیڈ اینالیٹکس کا سستا ورژن کیسے بنایا جائے۔

پڑھنے کا شکریہ! مجھے تبصرے میں سوالات پوچھ کر خوشی ہوگی۔

ماخذ: www.habr.com