7.6 ریئل ٹائم اور اسٹریمنگ ڈیٹا

جائزہ اور محرکات

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

بڑی ٹیموں کے لیے اسٹریمنگ تب سامنے آتی ہے جب تاخیر کاروبار کے لیے اہم ہونے لگے۔ ایک گھنٹہ دیر سے آنے والا فراڈ کا فیصلہ بیکار ہے۔ کل پہنچنے والا ذاتی بندی کا اشارہ کچھ ذاتی نہیں بناتا۔ آپریشنل ڈیش بورڈ جو حقیقت سے ایک شفٹ پیچھے رہے اسے دیکھنے والوں کو گمراہ کرتا ہے۔ باب 7.2 (ڈیٹا انجینئرنگ) دلیل دیتا ہے کہ آپ ڈیفالٹ سے batch چنیں اور اسٹریمنگ صرف وہاں لیں جہاں تاخیر واقعی ادا کرے، اور یہ باب آپ کو باقی راستے لے جاتا ہے: ریئل ٹائم اپنی لاگت کب کماتا ہے، اور اسے اپنے آپریشنز کے بجٹ کو آگ لگائے بغیر کیسے بنایا جائے۔ اسٹریمنگ باب 3.12 (event-driven فن تعمیر اور پیغام رسانی) کے event-driven پیغام رسانی کے نمونوں، باب 3.4 (ڈیٹا فن تعمیر اور ذخیرہ) کے ذخیرے کے انتخابات، اور باب 9.2 (مشاہدہ اور telemetry) کے telemetry کے عمل کے قریب بیٹھتی ہے۔

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

بنیادی اصول

• اسٹریمنگ صرف تب لیں جب تاخیر کی واضح کاروباری قدر ہو؛ batch سستا اور سادہ ہے۔
• محدود (متناہی) ڈیٹا کو لامحدود (کبھی ختم نہ ہونے والے) ڈیٹا سے ممتاز کریں، اور اس کے مطابق ڈیزائن کریں۔
• واقعے کے وقت کو، پہنچنے کے وقت کو نہیں، سچ کا ماخذ سمجھیں، اور دیر سے اور ترتیب سے باہر ڈیٹا کی منصوبہ بندی کریں۔
• windows اور watermarks وہ طریقہ ہیں جن سے آپ لامتناہی streams سے متناہی جوابات پاتے ہیں۔
• نازک exactly-once وعدوں پر idempotent sinks کے ذریعے effectively-once نتائج کو ترجیح دیں۔
• حالت والی پروسیسنگ کو checkpointing چاہیے تاکہ وہ کھوئے یا دوگنی گنے بغیر بحال ہو سکے۔
• پہلے دن سے backpressure اور دوبارہ پروسیسنگ کے لیے ڈیزائن کریں، بعد کے خیال کے طور پر نہیں۔
• اسٹریمنگ کی منطق قابل مشاہدہ اور قابل آڈٹ رکھیں؛ خاموش stream ناکام batch سے بدتر ہے۔

سفارشات

بنانے سے پہلے ریئل ٹائم کا جواز دیں

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

processing کے وقت کی بجائے event کے وقت کے گرد ڈیزائن کریں

اسٹریمنگ میں سب سے مشکل خیال یہ ہے کہ واقعات ایک لمحے ہوتے ہیں اور دوسرے لمحے پروسیس ہوتے ہیں۔ Event time وہ ہے جب چیز واقعی ہوئی، مثلاً جب مسافر نے کارڈ tap کیا۔ Processing time وہ ہے جب آپ کا نظام اسے سنبھالنے تک پہنچا۔ یہ مسلسل الگ ہوتے رہتے ہیں: فون سرنگ میں سگنل کھوتا ہے اور تین منٹ کے taps ایک ساتھ اپ لوڈ کرتا ہے، نیٹ ورک کی ہچکی پیغامات کی ترتیب بدلتی ہے، partition پیچھے رہ جاتا ہے۔ اگر آپ processing time پر حساب کریں تو آپ کے اعداد دنیا کی عکاسی کی بجائے آپ کے انفراسٹرکچر کے ساتھ ڈگمگاتے ہیں۔ یہ دیر سے اور ترتیب سے باہر کا مسئلہ اس نظم و ضبط کا دل ہے، اور یہ event-driven فن تعمیر کی event ماڈلنگ سے براہ راست جڑتا ہے۔ ہر event پر ماخذ پر اس کا event time ٹھپہ لگائیں، وہ timestamp پوری پائپ لائن میں ساتھ لے جائیں، اور اپنے نتائج اسی کے مقابل شمار کریں۔

متناہی جوابات پانے کو windows اور watermarks استعمال کریں

لامحدود stream کبھی ختم نہیں ہوتی، اس لیے “events گنیں” کا کوئی جواب نہیں جب تک آپ اسے محدود نہ کریں۔ Windows وہ حد بندی کرتے ہیں۔ Tumbling windows وقت کو مقررہ، غیر اوور لیپ ہونے والے ڈبوں میں کاٹتے ہیں، مثلاً ہر منٹ۔ Sliding windows اوور لیپ کرتے ہیں، تاکہ پانچ منٹ کی کھڑکی جو ہر منٹ آگے بڑھے ہموار متحرک عدد دے۔ Session windows سرگرمی کے دھماکوں کو غیر فعالیت کے وقفوں سے الگ گروپ کرتے ہیں، جو صارف کے سیشنز کو اچھی طرح موزوں ہے۔ جب آپ کے پاس windows ہوں تو آپ کو طے کرنا ہے کہ کھڑکی کب مکمل ہے، کیونکہ دیر سے ڈیٹا اب بھی آ سکتا ہے۔ Watermark نظام کا اندازہ ہے کہ اس نے غالباً دیے گئے event time تک کے تمام events دیکھ لیے ہیں۔ جب watermark کھڑکی کے اختتام سے گزرے تو آپ نتیجہ جاری کرتے ہیں۔ ٹیون کریں کہ آپ کتنا انتظار کرتے ہیں: کھڑکیاں زیادہ دیر کھلی رکھیں تو آپ تاخیر اور میموری کی قیمت پر زیادہ دیر برداشت کرتے ہیں، جلد بند کریں تو پیچھے رہ جانے والوں کو گرانے کا خطرہ ہے۔ واضح طور پر طے کریں کہ کھڑکی بند ہونے کے بعد آنے والے ڈیٹا کا کیا ہوتا ہے، آیا آپ اسے گراتے ہیں، لاگ کرتے ہیں، یا اصلاح جاری کرتے ہیں۔

sinks کو idempotent بنائیں اور effectively-once کو ترجیح دیں

ترسیل کی ضمانتیں سادہ لگتی ہیں اور ہیں نہیں۔ At-least-once ترسیل کا مطلب ہے کہ ہر event پروسیس ہوتا ہے، مگر کچھ دوبارہ کوشش کے بعد ایک سے زیادہ بار پروسیس ہو سکتے ہیں، اس لیے گنتیاں پھول سکتی ہیں۔ Exactly-once مثالی لگتا ہے مگر مہنگا ہے اور، من مانے بیرونی نظاموں میں لفظی طور پر لیا جائے تو، اکثر ناممکن۔ عملی ہدف effectively-once ہے: قابل مشاہدہ نتیجہ ایسا ہے گویا ہر event ایک بار پروسیس ہوا، چاہے مشینری نے نیچے دوبارہ کوشش کی ہو۔ آپ وہاں اپنے idempotent sinks کو بار بار لکھنے کے لیے محفوظ بنا کر پہنچتے ہیں، قطعی چابیاں اور upserts استعمال کر کے تاکہ دوبارہ چلایا event نقل کرنے کی بجائے اوور رائٹ کرے۔ At-least-once ترسیل کو idempotent تحریروں سے ملائیں اور آپ ہر جگہ بھاری transactional ہم آہنگی کی ادائیگی کیے بغیر درست نتائج پاتے ہیں۔ حقیقی exactly-once مشینری ان تنگ جگہوں کے لیے رکھیں جنہیں واقعی چاہیے۔

حالت والی پروسیسنگ کو checkpoint کریں تاکہ وہ بحال ہو سکے

بہت سی مفید اسٹریمنگ کی گنتیاں حالت والی ہیں: چلتی گنتیاں، streams کے پار joins، تکرار ہٹانا، فراڈ کے ماڈل جو حالیہ برتاؤ یاد رکھتے ہیں۔ وہ حالت میموری میں رہتی ہے اور عمل ری سٹارٹ ہونے پر غائب ہو جاتی۔ Checkpointing وقتاً فوقتاً حالت اور stream کی پوزیشن کا ساتھ snapshot لیتی ہے، تاکہ crash کے بعد نظام سب کچھ دوبارہ چلانے یا اپنی یادداشت کھونے کی بجائے مستقل نقطے سے دوبارہ شروع ہو۔ اپنی حالت کا سائز دانستہ طے کریں، کیونکہ لامحدود حالت پروڈکشن میں اسٹریمنگ job کی میموری ختم کرنے کا عام طریقہ ہے۔ جس حالت کی اب ضرورت نہیں اس پر expiry اور time-to-live استعمال کریں، اور حالت کے سائز کو اولین درجے کی میٹرک کے طور پر مانیٹر کریں۔ ناکامی کے بعد بحالی کا وقت حقیقی service-level کی تشویش ہے، اس لیے اسے اپنے صارفین کے آزمانے سے پہلے ٹیسٹ کریں۔

change data capture سے آپریشنل ڈیٹا بیس سے اسٹریم کریں

آپ اکثر ایسے ڈیٹا بیس میں تبدیلیوں پر ردعمل چاہتے ہیں جو کبھی events نکالنے کے لیے ڈیزائن نہیں ہوا۔ Change data capture (CDC) ڈیٹا بیس کا transaction log پڑھ کر اور ہر insert، update، اور delete کو تبدیلی کے events کی stream میں بدل کر اسے حل کرتی ہے۔ یہ ٹیبل کو ٹائمر پر poll کرنے سے کہیں بہتر ہے، جو سست ہے، درمیانی حالتیں چوک جاتی ہے، اور ماخذ کو ہتھوڑے مارتی ہے۔ CDC آپ کو تلاش کا index، cache، تجزیات کا ذخیرہ، یا نیچے کی سروس ریکارڈ کے نظام کے ساتھ مسلسل ہم آہنگ رکھنے دیتی ہے، اور یہ ایپلیکیشن میں دخل اندازی والی تبدیلیوں کے بغیر کرتی ہے۔ تبدیلی کی stream کو اولین درجے کی ڈیٹا پروڈکٹ سمجھیں: اس کے schema کو ورژن کریں، اس کے معنی دستاویزی کریں، اور اس کی تاخیر دیکھیں، کیونکہ نیچے کا سب کچھ وہ تاخیر وراثت میں پاتا ہے۔

دو کوڈ بیس برقرار رکھنے کی بجائے streaming-first فن تعمیر کو ترجیح دیں

کلاسیکی Lambda فن تعمیر درست، مکمل تاریخ کے لیے batch کی تہہ کو تازہ، تخمینی نتائج کے لیے رفتار کی تہہ کے ساتھ چلاتا ہے، پھر انہیں ملاتا ہے۔ یہ کام کرتا ہے، مگر آپ کو وہی کاروباری منطق دو بار، دو نظاموں میں، لکھنے اور برقرار رکھنے اور فرق ہمیشہ کے لیے ہم آہنگ کرنے پر مجبور کرتا ہے۔ Kappa فن تعمیر اسے سمیٹتا ہے: events کا پائیدار، دوبارہ چلانے کے قابل log رکھیں اور تمام پروسیسنگ کو stream پروسیسنگ کے طور پر چلائیں، منطق بدلنے پر log دوبارہ چلا کر تاریخ دوبارہ پروسیس کریں۔ صنعت اس streaming-first شکل کی طرف بہی ہے کیونکہ واحد کوڈ بیس برقرار رکھنا اور اس پر استدلال کرنا ڈرامائی طور پر سستا ہے۔ اگر آپ اپنی batch ضروریات کو برقرار رکھے event log پر دوبارہ چلانے کے طور پر ظاہر کر سکیں تو آپ دو کوڈ بیس کا ٹیکس مکمل طور پر بچاتے ہیں۔ Log پر مبنی brokers استعمال کریں جو تاریخ برقرار رکھتے ہیں تاکہ دوبارہ پروسیسنگ دوبارہ بنانے کی بجائے ریوائنڈ کرنے کا معاملہ ہو۔

streams کو SQL، materialised views، اور ریئل ٹائم OLAP کے طور پر پیش کریں

ہر وہ شخص جسے اسٹریمنگ چاہیے اسے نچلی سطح کا stream پروسیسنگ کا کوڈ لکھنا نہیں پڑنا چاہیے۔ Streaming SQL تجزیہ کاروں اور انجینئروں کو windows، joins، اور aggregations اس زبان میں ظاہر کرنے دیتی ہے جو وہ پہلے سے جانتے ہیں، اور نتائج کو materialised views کے طور پر مسلسل موجودہ رکھتی ہے۔ تازہ ڈیٹا پر کم تاخیر کی تجزیاتی کوئریز کے لیے ریئل ٹائم online analytical processing (OLAP) ذخیرہ stream ingest کرتا اور slice-and-dice کوئریز کا جواب ملی سیکنڈ میں دیتا ہے، جو واقعی زندہ آپریشنل ڈیش بورڈ کو طاقت دیتا ہے۔ جب ہدف فیچرز اور تجربات پر تیز جواب ہو تو انہیں باب 7.4 (پروڈکٹ تجزیات اور تجربات) کے پروڈکٹ تجزیات کے عمل سے جوڑیں۔ یہ اعلیٰ سطح کے ٹولز وہاں چنیں جہاں وہ فٹ ہوں، اور ہاتھ سے لکھے stream processors اس منطق کے لیے رکھیں جو وہ ظاہر نہ کر سکیں۔

backpressure اور دوبارہ پروسیسنگ کی منصوبہ بندی شروع سے کریں

Stream اس سے تیز آ سکتی ہے جتنی آپ پروسیس کر سکیں۔ Backpressure وہ میکانزم ہے جو سست صارف کو اوپر سگنل دینے دیتا ہے کہ گرنے یا خاموشی سے ڈیٹا چھوڑنے کی بجائے سست ہو جائیں۔ یقینی بنائیں کہ آپ کی پائپ لائن کا ہر مرحلہ اس کا احترام کرتا ہے، اور صارف کی تاخیر کو سرخی کی میٹرک کے طور پر مانیٹر کریں، کیونکہ بڑھتی تاخیر اس کا اولین انتباہ ہے کہ آپ دوڑ ہار رہے ہیں۔ دوبارہ پروسیسنگ دوسری صلاحیت ہے جسے لوگ چاہتے ہیں کہ بنائی ہوتی۔ جب آپ بگ پائیں یا قاعدہ بدلیں تو آپ تاریخ کو درست منطق سے گزارنا چاہتے ہیں۔ یہ تبھی ممکن ہے جب آپ کا event log کافی تاریخ برقرار رکھے اور آپ کے sinks اتنے idempotent ہوں کہ دوبارہ چلانا جذب کر سکیں۔ دونوں کو پہلے دن سے ڈیزائن کریں؛ واقعے کے دباؤ میں انہیں بعد میں لگانا تکلیف دہ ہے۔

سمجھوتے: فوائد اور نقصانات

انتخاب	فوائد	نقصانات	بہترین موزونیت
Batch	سادہ، سستا، ٹیسٹ اور backfill میں آسان	زیادہ تاخیر، رنز کے درمیان باسی	رپورٹنگ، زیادہ تر تجزیات
Micro-batch (منٹ)	تقریباً ریئل ٹائم، اسٹریمنگ سے کہیں سادہ	واقعی فوری نہیں	“ریئل ٹائم” ڈیش بورڈز
حقیقی اسٹریمنگ (سب-سیکنڈ)	فوری ردعمل، مسلسل نتائج	پیچیدہ، مہنگی، ٹیسٹ مشکل	فراڈ، الرٹنگ، زندہ ذاتی بندی
At-least-once + idempotent sink	درست نتائج، سستا، لچکدار	چابی کا نظم و ضبط والا ڈیزائن چاہیے	زیادہ تر اسٹریمنگ پائپ لائنز
Exactly-once مشینری	سرے سے سرے تک مضبوط ضمانت	مہنگی، نظاموں کے پار محدود	تنگ زیادہ داؤ کے راستے
Lambda (batch + رفتار)	درست تاریخ جمع تازہ نظارہ	دو کوڈ بیس برقرار رکھنے ہیں	پرانی منتقلیاں
Kappa (streaming-first)	ایک کوڈ بیس، دوبارہ چلانے کے قابل	برقرار رکھا، پائیدار log چاہیے	نئے اسٹریمنگ پلیٹ فارمز

مرکزی کھنچاؤ تاخیر بمقابلہ پیچیدگی ہے۔ ریئل ٹائم کی طرف ہر قدم آپ کو آپریشنل بوجھ، ٹیسٹنگ کی مشکل، اور پیسے میں لاگت دیتا ہے، اور واپسیاں خطی نہیں: روزانہ سے ہر چند منٹ پر جانا سستا اور اکثر کافی ہے، جبکہ منٹوں سے سب-سیکنڈ پر جانا وہ جگہ ہے جہاں خرچ مرتکز ہوتا ہے۔ ٹیکنالوجی کی بجائے فیصلے کی قیمت لگا کر کھنچاؤ حل کریں۔ پوچھیں کہ تازگی کون سا عمل ممکن بناتی ہے اور دیر کی کیا لاگت ہے، پھر تاخیر کی اتنی کمی خریدیں جتنی وہ عمل جائز ٹھہرائے۔ جب آپ کو اسٹریمنگ چاہیے تو at-least-once ترسیل پر idempotent sinks اور streaming-first log پر ٹیک لگائیں، کیونکہ یہ امتزاج آپ کو بھاری ترین ضمانتوں کے بغیر درستی اور دوبارہ چلانے کی صلاحیت دیتا ہے۔

اپنی ٹیم کے ساتھ بحث کے سوالات

1. ریئل ٹائم ڈیٹا ہمارے لیے واقعی کون سا فیصلہ ممکن بناتا ہے، اور جب وہ ڈیٹا فوری کی بجائے ایک منٹ دیر سے آئے تو اس کی کیا لاگت ہے؟ یہ وہ سوال ہے جو ہر اسٹریمنگ منصوبے کو دروازہ دار کرے، کیونکہ اسٹریمنگ batch کے مقابل آپ کی آپریشنل لاگت اور پیچیدگی تقریباً دوگنی کرتی ہے۔ بڑی ٹیم ایسے ریئل ٹائم پلیٹ فارم بنانے میں سہ ماہیاں جلا سکتی ہے جو ایسے ڈیش بورڈز کی خدمت کرے جنہیں انسان دن میں دو بار چیک کرتا ہے، جو آگ لگائے ہوئے پیسے ہیں۔ وہ ٹھوس عمل لائیں جسے ڈیٹا چلاتا ہے، چاہے وہ فراڈ والا لین دین روکنا ہو، آپریٹر کو پیجر دینا ہو، یا صارف کے دیکھنے والی چیز بدلنا ہو، اور ہر ایک کے لیے تاخیر کی لاگت پر عدد لگائیں۔ اگر ایماندار جواب یہ ہے کہ پانچ منٹ کا micro-batch ضرورت پوری کرے گا تو یہ ایسی دریافت ہے جس کا جشن منانا چاہیے، چھپانا نہیں۔ جواب کو براہ راست بدلنا چاہیے کہ آیا آپ حقیقی اسٹریمنگ بناتے ہیں، micro-batches پر ٹھہرتے ہیں، یا batch میں رہتے ہیں۔

2. ہم دیر سے اور ترتیب سے باہر آنے والے events کو کیسے سنبھالتے ہیں، اور کھڑکی بند ہونے کے بعد آنے والے ڈیٹا کا کیا ہوتا ہے؟ دیر سے اور ترتیب سے باہر ڈیٹا اسٹریمنگ کا مشکل حصہ ہے، اور جو ٹیمیں یہ سوال چھوڑ دیتی ہیں وہ اسے پروڈکشن میں دریافت کرتی ہیں جب ان کے اعداد مصالحت سے انکار کرتے ہیں۔ متصادم دباؤ تاخیر اور درستی ہیں: پیچھے رہنے والوں کو پکڑنے کے لیے کھڑکیاں زیادہ دیر کھلی رکھیں تو آپ ہر نتیجہ موخر اور زیادہ میموری کھاتے ہیں، جلد بند کریں تو آپ خاموشی سے حقیقی ڈیٹا گراتے ہیں۔ شہادت لائیں کہ آپ کا ڈیٹا واقعی کتنا دیر سے آتا ہے، آپ کے ماخذوں میں event time اور processing time کے فرق سے ناپا ہوا، کیونکہ سرنگوں میں موبائل ماخذ سرور کی طرف کے event سے بہت مختلف برتاؤ کرتا ہے۔ واضح طور پر طے کریں کہ دیر سے ڈیٹا گرایا جاتا ہے، لاگ ہوتا ہے، یا اصلاح ٹرگر کرتا ہے، اور یقینی بنائیں کہ نیچے ہر کوئی جانتا ہے کون سا۔ سرکاری سیاق میں جہاں اعداد کو قابل دفاع ہونا ہے، دیر سے events کو خاموشی سے گرانا تعمیل کا مسئلہ ہو سکتا ہے، اس لیے پالیسی دانستہ اور دستاویزی ہونی چاہیے۔

3. کیا ہمارے sinks اتنے idempotent ہیں کہ ہم تاریخ محفوظ طور پر دوبارہ چلا سکیں، اور کیا ہمارا event log دوبارہ چلانا ممکن بنانے کو کافی برقرار رکھتا ہے؟ دوبارہ پروسیسنگ وہ صلاحیت ہے جسے ٹیمیں سب سے زیادہ چاہتی ہیں کہ بنائی ہوتی اور سب سے زیادہ نہیں بناتیں، اور یہ دو چیزوں کے ساتھ کام کرنے پر منحصر ہے: idempotent sinks جو دوبارہ چلائے events کو نقل کیے بغیر جذب کریں، اور پائیدار log جو دوبارہ چلانے کو کافی تاریخ برقرار رکھے۔ دونوں کے بغیر منطق کے بگ کو ٹھیک کرنے کا مطلب ہے کہ آپ متاثرہ مدت صفائی سے دوبارہ نہیں گن سکتے، اور دباؤ میں ہاتھ سے اعداد پیوند کرنے میں پھنس جاتے ہیں۔ اپنی موجودہ برقراری کی کھڑکی اور ٹھوس ٹیسٹ لائیں: پچھلی سہ ماہی کا حقیقی بگ چنیں اور پوچھیں کہ کیا آپ متاثرہ ڈیٹا پر درست منطق دوبارہ چلا سکتے تھے۔ اس کے خلاف کھنچاؤ لاگت ہے، کیونکہ تاریخ برقرار رکھنا اور idempotent تحریریں ڈیزائن کرنا پہلے ذخیرہ اور نظم و ضبط لیتا ہے۔ لیکن متبادل بدترین ممکنہ لمحے، واقعے کے دوران، سامنے آتا ہے، اس لیے جواب شکل دیتا ہے کہ آپ ضرورت سے پہلے دوبارہ چلانے کی صلاحیت میں کتنا سرمایہ لگاتے ہیں۔

4. جب اسٹریمنگ job crash ہو تو اسے کتنی تیزی سے بحال ہونا ہے، اسے کتنی حالت رکھنے کی اجازت ہے، اور کیا ہم نے پروڈکشن لوڈ میں بحالی کا وقت واقعی ناپا ہے؟ Batch job جو مر جائے کل دوبارہ چلائی جا سکتی ہے، لیکن ہمیشہ چالو stream جو مر جائے جاری بندش ہے، اور حالت والی jobs جو چلتی گنتیاں، joins، یا فراڈ کے ماڈل رکھتی ہیں منٹوں کی یادداشت کھو سکتی یا ری سٹارٹ کے بعد حالت دوبارہ لوڈ کرنے میں لمبا وقت لے سکتی ہیں۔ بڑی ٹیم کے لیے یہ وہ جگہ ہے جہاں بے رونق تفصیل خاموشی سے آپ کی حقیقی دستیابی طے کرتی ہے: لامحدود حالت اس وقت تک بڑھتی ہے جب تک job کی میموری ختم نہ ہو، اور سست checkpoint کی بحالی دس سیکنڈ کی ہچکی کو دس منٹ کی بنا دیتی ہے۔ متصادم دباؤ تازگی بمقابلہ حفاظت ہیں، کیونکہ زیادہ بار checkpoints بحالی مختصر کرتے مگر اوور ہیڈ جوڑتے ہیں، اور فراخ حالت کی برقراری درستی بہتر کرتی مگر میموری ختم ہونے کا خطرہ رکھتی ہے۔ ٹھوس recovery time objective، اپنی موجودہ حالت کا سائز اور اس کا بڑھنے کا منحنی، اپنا checkpoint کا وقفہ، اور پرامید اندازے کی بجائے حقیقی failover مشق کے نتائج لائیں۔ انٹرپرائز اور سرکاری ترتیبوں میں جہاں stream فراڈ کی اسکورنگ یا عوامی تحفظ کی feed کی پشت پناہی کرتی ہے، غیر آزمایا بحالی کا راستہ ایسا آپریشنل خطرہ ہے جو آپ نے بغیر ناپے قبول کیا، اس لیے مشق کو تقاضا سمجھیں، سہولت نہیں۔

5. کیا ہم ایک streaming-first کوڈ بیس چلاتے ہیں یا الگ batch کی تہہ اور رفتار کی تہہ، اور انہیں ہم آہنگ رکھنے میں ہمیں واقعی کیا لاگت ہے؟ Lambda کا نمونہ، درست تاریخ کے لیے batch کی تہہ جمع تازہ نتائج کے لیے رفتار کی تہہ، آپ کو وہی کاروباری منطق دو بار، دو نظاموں میں، لکھنے اور ان کے جوابات ہمیشہ کے لیے ہم آہنگ کرنے پر مجبور کرتا ہے، جبکہ streaming-first (Kappa) شکل پائیدار، دوبارہ چلانے کے قابل log رکھتی اور تمام پروسیسنگ کو stream پروسیسنگ کے طور پر چلاتی ہے۔ بڑے ادارے کے لیے دہرائی منطق وہ جگہ ہے جہاں بھٹکاؤ اور متنازع اعداد پنپتے ہیں، کیونکہ قاعدہ ایک تہہ میں بدلتا اور دوسری میں نہیں، اور انجینئر حقیقی وقت یہ سمجھانے میں لگاتے ہیں کہ دونوں کیوں اختلاف کرتی ہیں۔ دونوں رکھنے کی کشش جڑتا اور ثابت شدہ batch کی تہہ کا آرام ہے، اس لیے اسے دیکھ بھال کے ٹیکس کے مقابل ایمانداری سے تولیں۔ وہ گنتیاں لائیں جو آپ اس وقت دونوں جگہ چلاتے ہیں، دو تہوں کے اختلاف سے پیدا ہوئے واقعات، اور اس کا اندازہ کہ آیا آپ کا event log batch کی ضروریات کو دوبارہ چلانے کے طور پر ظاہر کرنے کو کافی تاریخ برقرار رکھتا ہے۔ سرکاری اور آڈٹ شدہ انٹرپرائز سیاق میں دو تہیں جو ایک ہی مدت کے مختلف اعداد رپورٹ کر سکیں خود تعمیل کی ذمہ داری ہے، کیونکہ آپ کو بتا سکنا ہے کہ کون سا عدد مستند ہے اور کیوں۔

6. جب یہ ہمیشہ چالو نظام صبح تین بجے ٹوٹے تو اسے چلاتا کون ہے، اور کیا ہم نے on-call کا بوجھ اور وہ ماہر مہارتیں بجٹ کی ہیں جو یہ مانگتا ہے، یا ہم batch کی شکل کا عملہ فرض کر رہے ہیں؟ اسٹریمنگ لاگت کو تعمیر سے چلانے کی طرف منتقل کرتی ہے: نظام کو ہر سیکنڈ صحت مند رہنا ہے، جس کا مطلب حقیقی on-call کوریج، event time، watermarks، حالت، اور ترسیل کی معنویات میں رواں انجینئر، اور چل کر رک جانے والے job سے مشکل ٹیسٹنگ ہے۔ ٹیمیں معمول سے اسٹریمنگ پلیٹ فارم کو اس کی صلاحیتوں کی بنیاد پر منظور کرتی ہیں اور اسے زندہ رکھنے والے لوگوں کو کبھی فنڈ نہیں کرتیں، اس لیے پلیٹ فارم بگڑتا اور اعتماد گھٹتا ہے۔ سمجھوتا دائرہ بمقابلہ پائیداری ہے: ہر اضافی ریئل ٹائم پائپ لائن ایک اور چیز ہے جو کسی کو پیجر دے سکتی ہے، اس لیے سوال یہ ہے کہ آیا جو تاخیر یہ خریدتی ہے وہ مستقل آپریشنل عہد کا جواز ہے۔ پروڈکشن میں ہر stream کے مالک کی ایماندار فہرست، اپنی موجودہ on-call کی باری اور اس کی گنجائش، اور event-time کی مہارت واقعی کہاں بیٹھی ہے، چاہے بھرتی ہو، شراکت دار، یا منظم سروس، لائیں۔ عوامی ادارے یا بڑے انٹرپرائز کے لیے خریداری اور بھرتی کے lead times اور کوئی منظم سروس کا اختیار جوڑیں، کیونکہ ریئل ٹائم پلیٹ فارم جو ایسے کم یاب ہنر پر منحصر ہو جسے آپ بھرتی یا برقرار نہ رکھ سکیں کم عملے کے ساتھ بندش کے شکار نظام کو چلانے کا منصوبہ ہے۔

شعبہ جاتی نقطۂ نظر

اسٹارٹ اپ۔ اسٹریمنگ شاذ آپ کا پہلا اقدام ہے، اور بھاری پلیٹ فارم کھڑا کرنا چھوٹی ٹیم کو ڈبو سکتا ہے۔ وہ ایک اشارہ چنیں جو آپ کی بنیادی قدر کو چھوتا ہے، events کو ایک برقرار رکھے log پر مبنی broker پر رکھیں، اور ہلکا processor چابی والے، idempotent sinks کے ساتھ چلائیں تاکہ at-least-once دوبارہ کوشش کبھی دوگنی نہ گنے۔ چند دن کی تاریخ رکھیں تاکہ آپ درست منطق سے دوبارہ چلا سکیں، اور اپنا cluster چلانے کی بجائے منظم اسٹریمنگ سروس کو ترجیح دیں، کیونکہ آپ کا سب سے کم یاب وسیلہ انجینئرنگ کی توجہ ہے۔

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

بڑا ادارہ۔ مسئلہ بہت سی ٹیموں میں مستقل مزاجی اور لاگت ہے: مشترک log پر مبنی پلیٹ فارم، معیاری event-time اور دیر سے ڈیٹا کی پالیسی، اور idempotent sinks تاکہ گروہ نازک پائپ لائنز دوبارہ ایجاد کرنا چھوڑ دیں۔ ہمیشہ چالو آپریشنز اور on-call کا بوجھ واضح بجٹ کریں، streaming-first log پر معیار بندی کریں تاکہ آپ دہرائے batch کوڈ بیس سے بچیں، اور streams کو مالکوں، schema ورژننگ، اور مانیٹر شدہ تاخیر والی منظم ڈیٹا پروڈکٹس کے طور پر منظم کریں بجائے مخصوص jobs کے پھیلاؤ کے۔ تاخیر، بحالی کا وقت، اور فی stream لاگت کو پورٹ فولیو کی میٹرکس کے طور پر ٹریک کریں۔

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

مثالیں

اسٹارٹ اپ۔ صارف کی ایپ صارفین کو زندہ سرگرمی کی feed دکھانا اور مشکوک لاگ اِن ہوتے ہی نشان زد کرنا چاہتی ہے۔ ٹیم بھاری اسٹریمنگ پلیٹ فارم کھڑا کرنے کی مزاحمت کرتی ہے۔ وہ events کو ایک برقرار رکھے log پر مبنی broker پر رکھتے ہیں، لاگ اِن کے خطرے کی منطق کے لیے ہلکا stream processor چلاتے ہیں، اور ریئل ٹائم OLAP ذخیرہ کھلاتے ہیں جو سرگرمی کی feed کو طاقت دیتا ہے۔ ہر sink چابی والا اور idempotent ہے، اس لیے at-least-once دوبارہ کوشش کبھی دوگنی نہیں گنتی۔ جب انہیں بعد میں خطرے کے قاعدے میں بگ ملتا ہے تو وہ بس رات بھر log کو درست منطق سے دوبارہ چلاتے ہیں، کیونکہ انہوں نے ہفتے بھر کی تاریخ رکھی اور انہیں دوسرے batch کوڈ بیس کی کبھی ضرورت نہ پڑی۔

بڑا ادارہ۔ خوردہ بینک ہر کارڈ لین دین کو اجازت کی کھڑکی کے اندر فراڈ کے لیے score کرتا ہے، زندہ لین دین کی stream کو حالیہ کھاتے کے برتاؤ کے حالت والے ماڈل کے مقابل join کر کے۔ Checkpointing اسکورنگ کی سروس کو node کی ناکامی سے سیکنڈوں میں آخری چند منٹ کی یادداشت کھوئے بغیر بحال ہونے دیتی ہے۔ الگ سے، change data capture بنیادی بینکنگ ڈیٹا بیس سے اپ ڈیٹس کو تلاش کے index اور ذاتی بندی کی سروس میں stream کرتی ہے، دونوں کو poll کیے بغیر تازہ رکھتے ہوئے۔ آپریشنل ڈیش بورڈز ریئل ٹائم OLAP ذخیرے سے پڑھتے ہیں تاکہ خطرے اور آپریشنز کی ٹیمیں کاروبار کو حرکت کرتا دیکھیں، اور پوری پائپ لائن وہ تاخیر اور throughput کی telemetry خارج کرتی ہے جو باب 9.2 میں بیان ہے۔

حکومت۔ میٹروپولیٹن ٹرانزٹ اتھارٹی گاڑیوں کی پوزیشنیں اور کرایے کے taps ingest کرتی ہے تاکہ حقیقی وقت میں آمد کی پیش گوئی اور ہجوم کی نگرانی کرے، عوامی ایپس اور آپریشنز سینٹر دونوں کو کھلاتے ہوئے۔ چونکہ سرنگوں میں مسافر taps کو تاخیر والے دھماکوں میں اپ لوڈ کرتے ہیں، ٹیم مسافروں کی تعداد event time پر watermarks کے ساتھ شمار کرتی ہے جو مشاہدہ شدہ دیر کے مطابق ٹیون ہیں، اور کھڑکی بند ہونے کے بعد آنے والے کسی بھی event کو خاموشی سے گرانے کی بجائے لاگ کرتی ہے۔ ہر پروسیس شدہ event قابل آڈٹ log میں برقرار رکھا جاتا ہے تاکہ نگرانی کے اداروں کو رپورٹ شدہ مسافروں کے اعداد بالکل دوبارہ تشکیل دیے جا سکیں۔ جب کرایے کا قاعدہ بدلتا ہے تو وہ متاثرہ مدت کو درست منطق سے دوبارہ چلاتے اور قابل دفاع دوبارہ بیان پیدا کرتے ہیں۔

کاروباری جواز: محرکات، ROI اور TCO

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

ملکیت کی کل لاگت batch سے زیادہ ہے، اور اس کے بارے میں ایماندار رہنا آپ کی ساکھ کی حفاظت کرتا ہے۔ آپ ہمیشہ چالو انفراسٹرکچر، event time، watermarks، حالت، اور ترسیل کی معنویات کو سمجھنے والے انجینئروں، اور ایسے نظام کی مشکل ٹیسٹنگ اور on-call کے بوجھ کی ادائیگی کرتے ہیں جسے چل کر رکنے کی بجائے مسلسل صحت مند رہنا ہے۔ برقرار رکھے log پر streaming-first فن تعمیر آپ کو دہرائے batch کوڈ بیس سے بچا کر جاری لاگت گھٹاتا ہے، اور idempotent sinks کے ساتھ at-least-once چننا سرے سے سرے تک exactly-once مشینری کے خرچ سے بچاتا ہے۔ سب سے مہنگی غلطی وہاں ریئل ٹائم بنانا ہے جہاں micro-batch یا batch کافی ہوتی، اس لیے لاگت کی مضبوط ترین دلیل اکثر اسٹریم نہ کرنے کا فیصلہ ہے۔ قیادت کے سامنے مخصوص تاخیر کے حساس فیصلوں اور ان کے قابل پیمائش فائدے کے گرد دلیل رکھیں، اور اتنی ہی واضح رہیں کہ batch میں رہنا کہاں بغیر قدر کھوئے پیسہ بچاتا ہے۔

ضد نمونے اور خامیاں

• وقار کے لیے اسٹریمنگ بنانا جب ہر چند منٹ کا micro-batch ضرورت پوری کر دیتا۔
• processing time پر حساب کرنا، اس لیے آپ کے اعداد دنیا کی بجائے آپ کے انفراسٹرکچر کے ساتھ ڈگمگاتے ہیں۔
• دیر سے اور ترتیب سے باہر ڈیٹا کو نظر انداز کرنا جب تک پروڈکشن میں مصالحت ناکام نہ ہو۔
• ہر جگہ لفظی exactly-once کا پیچھا کرنا بجائے idempotent sinks کے ساتھ at-least-once کے۔
• بغیر expiry کی لامحدود حالت، خاموشی سے بڑھتی یہاں تک کہ job کی میموری ختم ہو۔
• checkpointing نہیں، اس لیے ری سٹارٹ حالت کھوتا یا مکمل replay مجبور کرتا ہے۔
• change data capture کی بجائے آپریشنل ڈیٹا بیس کو ٹائمر پر poll کرنا۔
• دہرائی، بھٹکتی منطق کے ساتھ Lambda batch کی تہہ اور رفتار کی تہہ برقرار رکھنا۔
• برقراری کی کھڑکی بہت مختصر کہ بگ ملنے پر تاریخ دوبارہ نہ چلائی جا سکے۔
• ایسی streams جن کی تاخیر، throughput، یا تازگی کی میٹرکس نہیں، خاموشی سے ناکام ہوتی ہیں۔

پختگی کا ماڈل

• سطح 1، آغاز: سب کچھ batch ہے، یا چند ہاتھ سے بنی اسٹریمنگ jobs نگرانی کے بغیر ردعملی طور پر چلتی ہیں۔ اعداد processing time پر شمار ہوتے ہیں، دیر سے ڈیٹا نظر انداز ہوتا ہے، اور ری سٹارٹ حالت کھوتا ہے۔ کوئی بگ ٹھیک کرنے کو تاریخ دوبارہ نہیں چلا سکتا، اور مسائل تب دریافت ہوتے ہیں جب نیچے کے اعداد مصالحت سے انکار کرتے ہیں۔
• سطح 2، ترقی: کچھ ٹیمیں checkpointing کے ساتھ log پر مبنی broker پر بنیادی اسٹریمنگ پائپ لائنز چلاتی ہیں، اور event time کو processing time سے ممتاز کرتیں اور بنیادی windows استعمال کرتی ہیں۔ عمل ٹیم سے ٹیم غیر مستقل ہے: ترسیل at-least-once ہے مگر سب sinks idempotent نہیں، دیر سے ڈیٹا کی ہینڈلنگ فی البدیہہ ہے، اور تاخیر الرٹ ہونے کی بجائے غیر رسمی دیکھی جاتی ہے۔
• سطح 3، معیار بندی: Event time، watermarks، اور واضح دیر سے ڈیٹا کی پالیسی دستاویزی اور ادارے بھر میں لاگو ہیں۔ Sinks effectively-once نتائج کے لیے idempotent ہیں، حالت پر expiry ہے، اور change data capture روایت سے نیچے کے نظاموں کو کھلاتی ہے۔ برقرار رکھا log دوبارہ چلانے کی معاونت کرتا ہے، اور تاخیر، throughput، اور تازگی ہر ٹیم کی عادت کی بجائے ادارے بھر کے معیار کے طور پر الرٹس کے ساتھ مانیٹر ہوتی ہیں۔
• سطح 4، انتظام: اسٹریمنگ کی ملکیت بنیادی خطوط کے مقابل ناپی اور کنٹرول کی جاتی ہے۔ ہر پائپ لائن سرے سے سرے تک تاخیر، صارف کی تاخیر، بحالی کا وقت، event-time کا skew، دیر سے events کی شرح، حالت کا سائز، اور فی دس لاکھ events لاگت کے service-level کے اہداف رکھتی ہے، سب متفقہ اہداف کے مقابل ٹریک اور regression پر الرٹ کرتے ہیں۔ بحالی کی مشق اور وقت ناپا جاتا ہے، فرض نہیں کیا جاتا، backpressure کی گنجائش اور حالت کی بڑھوتری کو گنجائش کے اشارے کے طور پر دیکھا جاتا ہے، اور نئی stream کو پروڈکشن جانے سے پہلے یہ میٹرکس پار کرنی ہوتی ہیں۔
• سطح 5، ہم آہنگی: Streaming-first فن تعمیر ایک دوبارہ چلانے کے قابل log سے تازہ اور تاریخی دونوں ضروریات پوری کرتا ہے، اور streaming SQL، materialised views، اور ریئل ٹائم OLAP تازہ ڈیٹا کو وسیع طور پر قابل رسائی بناتے ہیں۔ دوبارہ پروسیسنگ معمول اور ٹیسٹ شدہ ہے، پلیٹ فارم ناپے لوڈ اور لاگت کے مقابل autoscale اور دوبارہ متوازن ہوتا ہے، اور streams شہادت پر ریٹائر، دوبارہ دائرہ بند، یا تبدیل ہوتی ہیں۔ اسٹریمنگ کاروبار اور خطرے کی منصوبہ بندی سے مربوط ہے، اور ہر stream لوڈ اور لاگت کی تصویر بدلنے پر سرے سے سرے تک قابل مشاہدہ اور قابل آڈٹ ہے۔

بحث کے لیے خیالات

1. آپ کے اسٹیک میں “ریئل ٹائم” اپنی لاگت واقعی کہاں کماتا ہے، اور کہاں یہ بغیر جانچ کی خواہش ہے؟
2. آپ کے ماخذوں میں event time اور processing time کے درمیان خلا کتنا بڑا ہے، اور کیا آپ اسے ناپتے ہیں؟
3. کیا آپ Lambda batch-اور-رفتار کے سیٹ اپ کو واحد streaming-first کوڈ بیس میں سمیٹ سکتے ہیں، اور اس میں کیا رکاوٹ بنے گا؟
4. آپ کے کون سے sinks واقعی idempotent ہیں، اور کیا آپ آج پچھلی سہ ماہی کا ڈیٹا درست منطق سے محفوظ طور پر دوبارہ چلا سکتے ہیں؟
5. کھڑکی بند ہونے کے بعد آنے والے ڈیٹا کی آپ کی پالیسی کیا ہے، اور کیا نیچے ہر کوئی اسے جانتا ہے؟
6. change data capture اس طرح کو کیسے بدلے گی جس سے آپ تلاش، caches، اور تجزیات کو ہم آہنگ رکھتے ہیں؟

اہم نکات

• اسٹریمنگ صرف تب لیں جب تاخیر کے حساس فیصلے کی ادائیگی ہو؛ batch اور micro-batch سستے ڈیفالٹ ہیں۔
• event time پر حساب کریں، اور دیر سے اور ترتیب سے باہر ڈیٹا کو بنیادی مسئلہ سمجھیں، windows اور watermarks سے سنبھالا ہوا۔
• ہر جگہ لفظی exactly-once کی بجائے effectively-once نتائج کے لیے idempotent sinks کے ساتھ at-least-once ترسیل کو ترجیح دیں۔
• حالت والی پروسیسنگ کو checkpoint کریں، اپنی حالت کو محدود رکھیں، اور صارف کی تاخیر کو سرخی کی میٹرک کے طور پر مانیٹر کریں۔
• poll کرنے کی بجائے آپریشنل ڈیٹا بیس سے اسٹریم کرنے کو change data capture استعمال کریں۔
• دو کوڈ بیس برقرار رکھنے پر برقرار رکھے، دوبارہ چلانے کے قابل log پر streaming-first فن تعمیر کو ترجیح دیں۔
• streams کو streaming SQL، materialised views، اور ریئل ٹائم OLAP سے پیش کریں، اور ہر stream کو قابل مشاہدہ اور قابل آڈٹ رکھیں۔

حوالہ جات اور مزید مطالعہ

• Tyler Akidau, Slava Chernyak, and Reuven Lax, “Streaming Systems.”
• Martin Kleppmann, “Designing Data-Intensive Applications.”
• Nathan Marz and James Warren, “Big Data” (Lambda architecture).
• Jay Kreps, “Questioning the Lambda Architecture” (O’Reilly Radar).
• Fabian Hueske and Vasiliki Kalavri, “Stream Processing with Apache Flink.”
• Ben Stopford, “Designing Event-Driven Systems.”
• Tyler Akidau and colleagues, “The Dataflow Model” (VLDB paper on windowing and watermarks).