آپ کی ڈیٹا پائپ لائن ایک گڑبڑ ہے — لاکھوں کو ضائع کرنے سے ڈپلیکیٹ ڈیٹا کو کیسے روکا جائے یہ ہے۔

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

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

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

آئیے سٹریمنگ ڈیٹا پائپ لائنز میں ڈپلیکیشن کے لیے تین بنیادی طریقوں کو چیک کریں:

Pub/Sub Message انتساب کا استعمال کرتے ہوئے ڈپلیکیشن

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

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

آئیے تکنیکی اصطلاحات میں بات کرتے ہیں، گوگل کلاؤڈ Pub/Sub فراہم کرتا ہے جو ایک غیر مطابقت پذیر اور توسیع پذیر پیغام رسانی کی خدمت ہے جو ان پیغامات پر کارروائی کرنے والی خدمات سے پیغامات تیار کرنے والی خدمات کو ڈیکپل کرتی ہے۔ اعداد و شمار کو لوڈ اور تقسیم کرنے کے لیے اسٹریمنگ اینالیٹکس اور ڈیٹا انٹیگریشن پائپ لائنز کے لیے بہت زیادہ استعمال کیا جاتا ہے۔ یہ عام طور پر صارف کے تعامل کے واقعات، سرور کے واقعات، ریئل ٹائم ایونٹس، ڈیٹا بیس کے درمیان ڈیٹا کو نقل کرنے، پوری تنظیم میں کاروباری واقعات کا اشتراک کرنے کے لیے ایک انٹرپرائز ایونٹ بس کے طور پر کام کرتا ہے، اور ایپلی کیشنز سے ڈیٹا سٹریمنگ کے لیے استعمال کیا جاتا ہے جس میں سینسر اور ایپلیکیشن ایونٹس شامل ہیں ڈیٹا پائپ لائن کے ذریعے گوگل کلاؤڈ کی دیگر مصنوعات کے ساتھ۔

Pub/Sub اس کی خصوصیات کا استعمال کرتے ہوئے ڈپلیکیٹ ڈیٹا کو ہینڈل کرنے کے لیے ایک سادہ لیکن طاقتور طریقہ پیش کرتا ہے۔ پب/سب ٹاپک کے ہر پیغام میں میٹا ڈیٹا میں کلیدی قدر کے جوڑے شامل ہو سکتے ہیں۔ اس ڈیٹا کو ڈپلیکیٹ ایونٹس کی شناخت کرنے اور ڈیٹا پروسیسنگ سروسز پر بوجھ ڈالے بغیر ڈیٹا پائپ لائن میں ڈپلیکیشن کو فعال کرنے کے لیے استعمال کیا جا سکتا ہے جس میں عام طور پر وسائل کی لاگت زیادہ ہوتی ہے اور ڈیٹا پائپ لائن کو بہت سست کر دیتی ہے۔

ان پیغامات کے لیے جن میں ایک منفرد فیلڈ جیسے transaction_id ، پیغامات شائع کرتے وقت اس قدر کو ایک انتساب کے طور پر سیٹ کیا جا سکتا ہے۔ ڈیٹا فلو میں پب/سب سے پیغامات پڑھتے وقت، آپ اس انتساب کا استعمال کرتے ہوئے پائپ لائن کو ڈپلیکیٹ کرنے کے لیے کنفیگر کر سکتے ہیں۔

یہ حل اس وقت موثر ہوتا ہے جب ڈپلیکیٹس سورس ایپلیکیشن یا ڈیوائس سے پب/سب ٹاپک کے اندر منفرد شناخت کنندہ کا استعمال کرتے ہوئے اسٹریم کر رہے ہوں۔ اس حل کی حد یہ ہے کہ یہ صرف ایک دوسرے کے 10 منٹ کی ونڈو کے اندر شائع ہونے والے ڈپلیکیٹ پیغامات کے لیے اچھا کام کرتا ہے۔ اگرچہ اسے لاگو کرنا آسان ہے لیکن Pub/Sub میں ٹائم ونڈو کی حد کے مطابق اسکیل ایبلٹی کا فقدان ہے۔ یہ ایسی صورتوں میں بہت کارآمد ہے جیسے، تیز رفتار کیمرہ یا سینسر ڈیوائسز ہر پیغام کی 10 منٹ کی ونڈو کے اندر ڈپلیکیٹ ایونٹس تیار کرتے ہیں، یہ بہت اچھا کام کرتا ہے۔

ایسی مثالیں ہو سکتی ہیں جب پبلیشر کے اندر ہی ڈپلیکیٹس تیار ہوئے ہوں جیسے Pub/Sub ڈاؤن اسٹریم کی طرف سے پیغامات کے استعمال میں تاخیر کی وجہ سے یا Pub/Sub کو کبھی بھی ڈیلیور کردہ پیغامات کے لیے کوئی اقرارنامہ موصول نہیں ہوا، Pub/Sub اسی کا استعمال کرتے ہوئے وہی پیغام بھیجنے کی دوبارہ کوشش کرتا ہے۔ Message_id، اس طرح ناشر میں ڈپلیکیٹ ایونٹس بناتا ہے۔ اس سے نمٹنے کے لیے، پب/سب کا استعمال کرتے ہوئے، ہم پے لوڈ کے پیغام_آئی ڈی کا تعین کر سکتے ہیں اور اسے شناخت کنندہ کے طور پر استعمال کر سکتے ہیں۔ Cloud DataFlow گوگل کلاؤڈ پلیٹ فارم (GCP) پر سٹریم پروسیسنگ ڈیٹا کے لیے ایک مکمل طور پر منظم سروس ہے، جو ہر ریکارڈ پر ایک بار پروسیسنگ فراہم کرتی ہے۔ ہمارے لیے اس کا کیا مطلب ہے؟ - یہ میسج_آئی ڈی کی بنیاد پر ڈپلیکیٹ ایونٹس کی نشاندہی کرتا ہے اور ڈیٹا پائپ لائنز میں کارروائی کرتے وقت انہیں ختم کر دیتا ہے لیکن غیر معمولی معاملات میں یہ ڈپلیکیٹ ایونٹس جب ڈیٹا فلو کے اندر مختلف ورکر نوڈس پر پروسیس ہوتے ہیں، تو وہ غیر موثر طریقے سے نیچے کی طرف پہنچ جاتے ہیں۔ آپ کو اب بھی اپنے ڈیٹا لیک میں ڈپلیکیٹس ملیں گے۔

ہم آخر تک اس مضمون میں اس طرح کے معاملات کو کیسے ہینڈل کرنے کے بارے میں مزید بات کریں گے۔ آئیے سٹریمنگ ڈیٹا کو ڈپلیکیٹ کرنے کے لیے باقی آپشنز پر فوکس کرتے ہیں۔

اپاچی بیم کے ڈی ڈپلیکیٹ پی ٹی ٹرانسفارم کا استعمال کرتے ہوئے ڈی ڈپلیکیشن

اب ہم جانتے ہیں کہ Pub/Sub ڈپلیکیٹ ایونٹس کو کیسے ہینڈل کرتا ہے، اس کے بعد کلاؤڈ ڈیٹا فلو کا استعمال کرتے ہوئے پب/سبسکرائبر کے ذریعہ ان پیغامات کی پروسیسنگ سورس ایپلیکیشن سے سٹریمنگ پیغامات پڑھتی ہے۔ ڈیٹا فلو ایک مکمل طور پر منظم سروس ہے جو اعلی درجے کی اسٹریمنگ صلاحیتوں کو فعال کرنے کے لیے اوپن سورس Apache Beam SDK کا استعمال کرتی ہے۔ ڈیٹا فلو کا پیمانہ 4000 ورکر نوڈس فی کام ہے اور بیچ اور اسٹریمنگ پائپ لائنز دونوں میں وسائل کے بہتر استعمال کے لیے آٹو اسکیلنگ خصوصیات کے ساتھ ڈیٹا کے پیٹا بائٹس پر کارروائی کر سکتا ہے۔

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

اس فعالیت کو آزمانے کے لیے GitHub سے میرا نمونہ ڈیٹا پائپ لائن کوڈ چیک کریں۔

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

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

سنک میں نقل

اب تک، ہم نے دیکھا ہے کہ پبلیشر جیسے پب/سب اور انٹیگریشن سروسز کلاؤڈ ڈیٹا فلو ریئل ٹائم میں ڈپلیکیٹس کو کیسے ہینڈل کرتا ہے۔ میرے خیال میں یہ حل 100% موثر نہیں ہیں جب پروسیسنگ اوور ہیڈ اور حجم کے مسائل کی وجہ سے ونڈونگ کی بات آتی ہے، ایسے منظرناموں میں، کنارے کے معاملات کو ہینڈل کرنے کے لیے، بشمول جہاں ڈپلیکیٹ پیغام دیر سے پہنچنا ہے اور ڈیٹا فلو کے خیال میں یہ ایک منفرد ریکارڈ ہے کیونکہ یہ ایسا نہیں کرتا ہے۔ پیغامات کی انفرادیت کی جانچ پڑتال کرنے کے لیے ریکارڈ کی شناخت نہ رکھیں اور ایک اور منظر نامے میں، ڈیٹا فلو ان پیغامات کو مختلف ورکر نوڈس پر نیٹ ورک کی ناکامی اور/یا کارکن کی وجہ سے ہینڈل کرتا ہے۔ نوڈ کی ناکامی سے یہ سوچنے کا سبب بنتا ہے کہ یہ ڈیٹا فلو میں پروسیسنگ کے دوران ایک منفرد ریکارڈ ہے اور گوگل کلاؤڈ بگ کوری ٹیبل جیسے ڈاؤن اسٹریم سسٹمز میں داخل ہو جاتا ہے۔

ایسی مثالوں کو کم کرنے کے لیے اور ڈپلیکیشن کی حتمی جانچ کے طور پر سنک لیول پر ہو سکتا ہے، جیسے BigQuery یا دیگر ڈیٹا گوداموں میں۔ یہ نقطہ نظر اکثر اس وقت مفید ہوتا ہے جب ریئل ٹائم ڈپلیکیشن اہم نہ ہو، اور وقتاً فوقتاً ڈپلیکیشن کافی ہوتی ہے۔ یہ اعلی درجے کی SQL سوالات کا استعمال کرتے ہوئے تمام ڈپلیکیٹ پیغامات کو مؤثر طریقے سے فلٹر اور ختم کر دے گا۔

استعمال کے معاملے کی بنیاد پر، ڈپلیکیٹس کو ٹھیک کرنے کے لیے دو قسم کے حل دستیاب ہیں۔

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

دوسرا، ہم یا تو حقیقی وقت کا ڈیٹا حاصل کرنے کے لیے ایک مادّی نظریہ استعمال کر سکتے ہیں جو اسے تیزی سے کاروباری بصیرت حاصل کرنے کے لیے ایک مثالی حل بنا سکتا ہے۔

Bigquery SQL استفسار میرے Github dedup_sql لنک پر پیش کیا گیا ہے۔

ذیل میں bigquery sql کوڈ دو اختیارات کی وضاحت کرتا ہے جن پر ہم نے تبادلہ خیال کیا ہے:

 -- Use below SQL queries to periodically deduplicate data in BigQuery tables. CREATE OR REPLACE TABLE Transactions AS SELECT DISTINCT * FROM raw_transactions; --OR use below incremental steps to drop the necessary partitions and re-insert the deduped data into the original table -- Step 1: Insert distinct records from the original table based on the max timestamp available CREATE OR REPLACE TABLE STAGE_TRANSACTIONS AS SELECT DISTINCT * FROM raw_transactions WHERE event_timestamp > ( SELECT MAX(event_timestamp) FROM raw_transactions ); -- Step 2: Drop the partition after deduplication DELETE FROM raw_transactions WHERE event_timestamp = > ( SELECT MAX(event_timestamp) FROM raw_transactions ); -- Step 3: Insert deduplicated data into the main table INSERT INTO raw_transactions SELECT DISTINCT * FROM STAGE_TRANSACTIONS; --OR Use below SQL query to Merge new data without duplicates the table MERGE INTO raw_transactions AS target USING ( SELECT * FROM STAGE_TRANSACTIONS ) AS source ON target.transaction_id = source.transaction_id AND target.event_timestamp <= source.event_timestamp WHEN MATCHED THEN UPDATE SET target.product = source.product, target.price = source.price, target.location = source.location, target.store = source.store, target.zipcode = source.zipcode, target.city = source.city, target.promotion = source.promotion, target.event_timestamp = source.event_timestamp WHEN NOT MATCHED THEN INSERT (transaction_id, product, price, location, store, zipcode, city, promotion, event_timestamp) VALUES (source.transaction_id, source.product, source.price, source.location, source.store, source.zipcode, source.city, source.promotion, source.event_timestamp); --OR to get the real-time data without duplicates, use following materialized view and a finest solution to retrieve dedup records quickly CREATE MATERIALIZED VIEW raw_transactions_mv AS SELECT transaction_id, product, price, location, store, zipcode, city, promotion, event_timestamp FROM ( SELECT transaction_id, product, price, location, store, zipcode, city, promotion, event_timestamp, ROW_NUMBER() OVER ( PARTITION BY transaction_id ORDER BY event_timestamp DESC ) AS row_num FROM raw_transactions ) WHERE row_num = 1;

ٹیکنیکل ٹریڈ آف

ہر ڈپلیکیشن کی حکمت عملی اپنے ٹریڈ آف کے سیٹ کے ساتھ آتی ہے۔ صحیح نقطہ نظر کا انتخاب کرنے میں آپ کی مدد کے لیے یہاں ایک خلاصہ ہے:

مختصراً

ڈپلیکیشن اسٹریمنگ پائپ لائنز میں موثر ڈیٹا پروسیسنگ کا سنگ بنیاد ہے۔ حکمت عملی کا انتخاب آپ کی پائپ لائن کی حقیقی وقت کی ضروریات، پیچیدگی، اور وسائل کی رکاوٹوں پر منحصر ہے۔ Pub/Sub انتساب، Apache Beam Deduplicate PTransform، یا سنک پر مبنی ڈیڈپلیکیشن کی طاقتوں کا فائدہ اٹھا کر، آپ ڈاؤن اسٹریم سسٹمز کے لیے صاف، قابل اعتماد ڈیٹا کو یقینی بنا سکتے ہیں۔ ان طریقوں کو دریافت کریں، فراہم کردہ مثالوں کو نافذ کریں، اور بہترین نتائج کے لیے انہیں اپنے استعمال کے معاملے میں ڈھال لیں۔

کیا آپ ڈیٹا اینالیٹکس اور مشین لرننگ کے بارے میں مزید گہرائی سے گائیڈز میں دلچسپی رکھتے ہیں؟ مجھے فالو کریں۔ درمیانہ یا LinkedIn تازہ ترین مضامین کے لیے، اور نیچے دیے گئے تبصروں میں اپنے خیالات یا سوالات کا اشتراک کرنے کے لیے آزاد محسوس کریں۔ اگر آپ کو یہ مضمون کارآمد لگتا ہے تو اسے اپنے نیٹ ورک کے ساتھ شیئر کریں اور ریٹیل میں حقیقی وقت کے تجزیات کے امکانات کو غیر مقفل کرنے میں دوسروں کی مدد کریں۔