دسمبر کے آغاز میں، میں نے ایک مہلک غلطی کی اور ایک ڈویلپر کے طور پر اپنی زندگی میں ایک اہم موڑ بنایا اور کمپنی کے اندر ڈیٹا انجینئرنگ (DE) ٹیم میں چلا گیا۔ اس مضمون میں میں کچھ مشاہدات کا اشتراک کروں گا جو میں نے ڈی ای ٹیم میں کام کرنے کے دو ماہ کے دوران کیے تھے۔
ڈیٹا انجینئرنگ کیوں؟
میرا ڈی ای کا سفر 2019 کے موسم گرما میں شروع ہوا، جب ہم چلو چلتے ہیں ، اور وہاں میں نے روشن خیالی حاصل کی۔ میں نے موضوع میں دلچسپی لینا شروع کی، الگورتھم کا مطالعہ کیا اور یہاں تک کہ ان کے بارے میں ، اور پھر درخواست کے دائرہ کار کے بارے میں سوچا اور فوری طور پر پتہ چلا کہ ہماری کمپنی میں عملی ایپلی کیشن ڈیٹا بیس کی تقسیم ہے۔
ہماری ٹیم بالکل کیا کرتی ہے؟ ہم، تمام فیشن ایبل لڑکوں اور لڑکیوں کی طرح، ڈیٹا پر مبنی کمپنی بننا چاہتے ہیں۔ اور یہ ممکن ہونے کے لیے، ہمیں کم از کم ایک قابل اعتماد سٹوریج کی سہولت بنانے کی ضرورت ہے، جس کا استعمال کمپنی کو درکار رپورٹس بنانے کے لیے کیا جا سکتا ہے۔ لیکن سب سے اہم بات یہ ہے کہ اس اسٹوریج میں موجود ڈیٹا پر بھروسہ ہونا چاہیے۔ مزید یہ کہ، ان ڈیٹا کا استعمال کرتے ہوئے، آپ کو وقت پر سسٹم کی حالت کو بحال کرنے کے قابل ہونے کی ضرورت ہے۔ یہ سب اس حقیقت سے پیچیدہ ہے کہ ہم مائیکرو سروسز کی ایک بہادر نئی دنیا میں رہتے ہیں، اور یہ نظریہ یہ ظاہر کرتا ہے کہ ہر سروس اپنی چھوٹی فعالیت کو نافذ کرتی ہے، اس کا ڈیٹا بیس اس کا اپنا کاروبار ہے، اور وہ اسے کم از کم ہر روز حذف کر سکتا ہے، لیکن اسی وقت ہمیں سروس کی حالت وصول کرنے اور اس پر کارروائی کرنے کے قابل ہونا چاہیے۔
اگر آپ ڈیٹا سے چلنے والے بننا چاہتے ہیں تو پہلے ایونٹ سے چلنے والے بنیں۔
اتنا سادہ نہیں۔ ایونٹس مختلف ہیں، اور ڈویلپر اور ڈیٹا انجینئر انہیں مختلف انداز سے دیکھتے ہیں۔ واقعات کے بارے میں بات کرنا ایک الگ مضمون کا موضوع ہے، اس لیے میں یہاں اس میں نہیں جاؤں گا۔ اس کے علاوہ، اس طرح کا ایک مضمون پہلے سے ہی ہے ایک خاص مارٹن فولر، میں اس کے اعزاز کو نہیں چھینوں گا، اسے بھی مشہور ہونے دو۔
عام طور پر سوچنے کے لیے بہت کچھ ہے اور اسی لیے یہ علاقہ پرکشش ہے۔ ایسا ہی ہوتا ہے کہ ہماری کمپنی میں، ڈیٹا انجینئر صرف ایک ایسے شخص کے مقابلے میں ذمہ داری کا ایک بہت وسیع علاقہ ہے جو ETL/ELT پائپ لائنز لکھتا ہے (اگر آپ نہیں جانتے کہ ان مخففات کا کیا مطلب ہے، تو آئیں . سیاق و سباق کی تشہیر کے طور پر).
ہم اسٹوریج کے فن تعمیر، ڈیٹا ماڈلنگ، ڈیٹا سیکیورٹی سے متعلق مسائل، اور خود پائپ لائنوں سے نمٹتے ہیں۔ ہمیں یہ بھی یقینی بنانا ہوگا کہ ایک طرف، ہماری موجودگی پروڈکٹ ڈویلپرز کے لیے بہت زیادہ بوجھل نہیں ہے اور انہیں سسٹم میں نئی خصوصیات کاٹتے وقت ہماری ضروریات سے کم سے کم توجہ ہٹانی ہوگی، اور دوسری طرف، ہم تجزیہ کاروں اور BI ٹیم کے لیے اسٹوریج ڈیٹا میں انہیں آسانی سے فراہم کرنے کی ضرورت ہے۔ اسی طرح ہم جیتے ہیں۔
ترقی سے منتقلی کے دوران مشکلات
اپنے کام کے پہلے دن، مجھے بہت سی مشکلات کا سامنا کرنا پڑا جو میں آپ کے ساتھ شیئر کرنا چاہتا ہوں۔
1. پہلی چیز جو میں نے دیکھی وہ ٹیولنگ اور کچھ طریقوں کی عدم موجودگی تھی۔ مثال کے طور پر، ٹیسٹوں کے ساتھ کوڈ کی کوریج لیں۔ ہمارے پاس ترقی میں سینکڑوں ٹیسٹنگ فریم ورک ہیں۔ ڈیٹا کے ساتھ کام کرتے وقت، سب کچھ زیادہ پیچیدہ ہوتا ہے۔ جی ہاں، ہم ٹیسٹ ڈیٹا پر ETL پائپ لائنوں کی جانچ کر سکتے ہیں، لیکن ہمیں یہ سب کچھ دستی طور پر کرنا ہوگا اور ہر مخصوص کیس کے لیے حل تلاش کرنا ہوں گے۔ نتیجے کے طور پر، ٹیسٹ کی کوریج بہت خراب ہے. خوش قسمتی سے، نگرانی اور نوشتہ جات کی شکل میں رائے کی ایک اور پرت ہے، لیکن اس کے لیے ہم سے پہلے سے ہی اس بات کی ضرورت ہے کہ ہم فعال طور پر بجائے رد عمل کا اظہار کریں، جو کہ مشتعل اور پریشان کن ہے۔
2. ڈی ای کے نقطہ نظر سے دنیا بالکل بھی ایسی نہیں ہے جو ایک عام پروڈکٹ ڈویلپر کو لگتا ہے (ٹھیک ہے، یقینا، پڑھنے والا ایسا نہیں ہے، اور وہ پہلے سے ہی سب کچھ جانتا ہے، لیکن میں نہیں جانتا تھا اور اب میں ہوں اسے خراب کرنا)۔ ایک ڈویلپر کے طور پر، میں اپنی مائیکرو سروس بناتا ہوں، ڈیٹا کو [آپ کی پسند کے ڈیٹا بیس] میں رکھتا ہوں، وہاں اپنی ریاست محفوظ کرتا ہوں، ID کے ذریعے کچھ حاصل کرتا ہوں اور یہ ٹھیک ہے۔ سروس سست ہے، آرڈرز مبہم ہیں، بس۔ وہ مجھ سے اپنی ریاست کو کسی اور سروس میں تلاش کرنے کو کہتے ہیں، اس لیے میں کچھ RabbitMQ میں ایک ایونٹ ڈالوں گا اور بس۔ اور یہاں ہم پھر سے اوپر بیان کردہ واقعات کی طرف لوٹ آئے۔
آپریشنل کام کے لیے سروس کو جس چیز کی ضرورت ہے وہ تاریخی ڈیٹا کے لیے ہمارے موافق نہیں ہے، اس لیے سروس کے معاہدوں پر دوبارہ کام کرنے اور ترقیاتی ٹیموں کے ساتھ قریبی کام کا سوال شروع ہوتا ہے۔ آپ سوچ بھی نہیں سکتے کہ ہمیں اتفاق کرنے میں کتنے گھنٹے لگے: وہ ہماری کمپنی میں کس قسم کے ایونٹ سے منسلک ہے۔
3. آپ کو اپنے سر سے سوچنے کی ضرورت ہے۔ نہیں، میرا مطلب یہ نہیں ہے کہ ڈویلپرز یہ نہیں سوچتے ہیں (حالانکہ میں سب کے لیے بات کرنے والا کون ہوں)، یہ صرف اتنا ہے کہ پروڈکٹ ڈویلپمنٹ میں اکثر آپ کے پاس پہلے سے ہی کسی نہ کسی قسم کا فن تعمیر ہوتا ہے، اور آپ بیک لاگ سے مختلف شفلز کو کاٹ دیتے ہیں۔ بلاشبہ، اس کے لیے منصوبہ بندی اور سوچ کی ضرورت ہے، لیکن یہ سٹریم ورک ہے، جہاں بنیادی مسئلہ صرف اسے اچھی اور مؤثر طریقے سے کرنا ہے۔
ہمارے لیے یہ اتنا آسان نہیں ہے کیونکہ نظام کے مختلف اجزاء کو گرم اور آرام دہ یک سنگی سے جنگلی مائیکرو سرویس جنگل کی دنیا میں منتقل کرنا اتنا آسان نہیں ہے۔ جب سروس واقعات کو پھیلانا شروع کر دیتی ہے، تو آپ کو سٹوریج کو بھرنے کی منطق پر نظر ثانی کرنے کی ضرورت ہے، کیونکہ ڈیٹا اب مختلف نظر آتا ہے۔ یہ وہ جگہ ہے جہاں آپ کو بہت اور اچھی طرح سے سوچنے کی ضرورت ہے، اب ایک ڈویلپر کے طور پر نہیں، بلکہ ایک ڈیٹا انجینئر کے طور پر۔ جب آپ نوٹ بک اور قلم کے ساتھ یا بورڈ پر مارکر کے ساتھ دن گزارتے ہیں تو یہ ایک عام کہانی ہے۔ یہ بہت مشکل ہے، میں سوچنا پسند نہیں کرتا، مجھے پروڈکشن بھی پسند ہے۔
4. شاید سب سے اہم چیز معلومات ہے۔ جب ہمارے پاس علم کی کمی ہے تو ہم کیا کریں؟ اسٹیک اوور فلو کس نے کہا؟ اس شخص کو کمرے سے باہر لے جاؤ۔ ہم موضوع پر دستاویزات، کتابیں پڑھتے ہیں، اور ایک کمیونٹی بھی ہے جو فورمز، میٹنگز اور کانفرنسوں کا اہتمام کرتی ہے۔ دستاویزات بہت اچھا ہے، لیکن بدقسمتی سے، یہ نامکمل ہو سکتا ہے. ہم متعدد منصوبوں میں Cosmos DB استعمال کرتے ہیں۔ اس پروڈکٹ کے لیے دستاویزات کو پڑھنے میں خوش قسمتی ہے۔ کتابیں ہی نجات ہیں؛ خوش قسمتی سے، وہ موجود ہیں اور مل سکتی ہیں، ان میں بہت سارے بنیادی علم ہیں اور آپ کو بہت کچھ پڑھنا پڑتا ہے۔ لیکن مسئلہ کمیونٹی کا ہے۔
اب ہمارے علاقے میں کم از کم ایک مناسب کانفرنس یا میٹنگ ملنا مشکل ہے۔ نہیں، یقیناً، لفظ ڈیٹا کے ساتھ بہت سارے ملتے ہیں، لیکن اس لفظ کے آگے عموماً عجیب مخففات ہوتے ہیں جیسے ML یا AI۔ تو، یہ ہمارے لیے نہیں ہے، ہم اس بات پر بات کر رہے ہیں کہ ذخیرہ کرنے کی سہولیات کیسے بنائیں، اور یہ نہیں کہ اپنے آپ کو نیوران سے کیسے سمیر کریں۔ ان ہپسٹرز نے سب کچھ سنبھال لیا ہے۔ نتیجے کے طور پر، ہم ایک کمیونٹی کے بغیر ہیں. ویسے اگر آپ ڈیٹا انجینئر ہیں اور اچھی کمیونٹیز کو جانتے ہیں تو کمنٹس میں لکھیں۔
میٹنگ کے نتائج اور اعلان
ہم کیا ختم کرتے ہیں؟ میرا پہلا تجربہ مجھے بتاتا ہے کہ ڈیٹا انجینئر کے جوتے میں محسوس کرنا ہر ڈویلپر کے لیے مفید ہوگا۔ یہ ہمیں چیزوں کو مختلف طریقے سے دیکھنے کی اجازت دیتا ہے اور جب ہم دیکھتے ہیں کہ ڈویلپرز اپنے ڈیٹا کے ساتھ کیسا سلوک کرتے ہیں تو ہماری آنکھوں میں خون آجاتا ہے۔ لہذا، اگر آپ کی کمپنی میں کوئی ڈی ای ہے، تو صرف ان لڑکوں سے بات کریں، آپ بہت سی نئی چیزیں سیکھیں گے (اپنے بارے میں)۔
اور آخر میں، اعلان. چونکہ دن کے دوران اپنے موضوع پر میٹنگز تلاش کرنا مشکل ہے، اس لیے ہم نے خود اپنا بنانے کا فیصلہ کیا۔ ہم بدتر کیوں ہیں؟ خوش قسمتی سے ہمارے پاس ایک حیرت انگیز ہے۔ اور ہمارے دوستوں سے ، جو، ہماری طرح، محسوس کرتے ہیں کہ ڈیٹا انجینئر غیر منصفانہ طور پر توجہ سے محروم ہیں۔
اس موقع سے فائدہ اٹھاتے ہوئے، میں ہر اس شخص کو دعوت دیتا ہوں جو ہماری پہلی کمیونٹی میٹنگ میں آنے کا خیال رکھتا ہے جس کا امید افزا عنوان "DE یا DIE" ہے، جو 27.02.2020 فروری XNUMX کو ڈوڈو پیزا آفس میں ہوگا۔ تفصیلات پر .
اگر کچھ ہوتا ہے تو میں وہاں ہوں گا، آپ مجھے ذاتی طور پر اپنے چہرے پر بتا سکتے ہیں کہ میں ڈویلپرز کے بارے میں کتنا غلط ہوں۔
ماخذ: www.habr.com