کتاب "کافکا اسٹریمز ان ایکشن۔ ریئل ٹائم کام کے لیے ایپلی کیشنز اور مائیکرو سروسز"

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

اقتباس۔ 5.3 ایگریگیشن اور ونڈونگ آپریشنز

اس سیکشن میں، ہم کافکا اسٹریمز کے سب سے امید افزا حصوں کو دریافت کرنے کے لیے آگے بڑھیں گے۔ اب تک ہم نے کافکا اسٹریمز کے درج ذیل پہلوؤں کا احاطہ کیا ہے۔

• پروسیسنگ ٹوپولوجی بنانا؛
• اسٹریمنگ ایپلی کیشنز میں ریاست کا استعمال؛
• ڈیٹا سٹریم کنکشن کی کارکردگی؛
• ایونٹ اسٹریمز (KStream) اور اپ ڈیٹ اسٹریمز (KTable) کے درمیان فرق۔

درج ذیل مثالوں میں ہم ان تمام عناصر کو اکٹھا کریں گے۔ آپ ونڈونگ کے بارے میں بھی جانیں گے، اسٹریمنگ ایپلی کیشنز کی ایک اور بڑی خصوصیت۔ ہماری پہلی مثال ایک سادہ جمع ہوگی۔

5.3.1 صنعت کے شعبے کے ذریعہ اسٹاک کی فروخت کا مجموعہ

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

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

ڈیٹا کو مطلوبہ شکل میں ترجمہ کرنے کے لیے اس طرح کے جمع کرنے کے لیے درج ذیل کئی مراحل کی ضرورت ہوگی (عام اصطلاحات میں بات کریں)۔

1. ایک موضوع پر مبنی ذریعہ بنائیں جو خام اسٹاک ٹریڈنگ کی معلومات شائع کرتا ہے۔ ہمیں اسٹاک ٹرانزیکشن کی قسم کی شئیر والیوم کی کسی چیز کا نقشہ بنانا ہوگا۔ بات یہ ہے کہ اسٹاک ٹرانزیکشن آبجیکٹ سیلز میٹا ڈیٹا پر مشتمل ہے، لیکن ہمیں صرف فروخت کیے جانے والے حصص کی تعداد کے بارے میں ڈیٹا کی ضرورت ہے۔
2. اسٹاک کی علامت کے ذریعہ شیئر والیوم ڈیٹا کو گروپ کریں۔ علامت کے لحاظ سے گروپ کرنے کے بعد، آپ اس ڈیٹا کو اسٹاک سیلز والیوم کے ذیلی ٹوٹل میں سمیٹ سکتے ہیں۔ یہ بات قابل غور ہے کہ KStream.groupBy طریقہ KGroupedStream قسم کی ایک مثال واپس کرتا ہے۔ اور آپ KGroupedStream.reduce طریقہ کو مزید کال کرکے KTable مثال حاصل کرسکتے ہیں۔

KGroupedStream انٹرفیس کیا ہے؟

KStream.groupBy اور KStream.groupByKey طریقے KGroupedStream کی مثال واپس کرتے ہیں۔ KGroupedStream کلیدوں کے ذریعے گروپ بندی کے بعد واقعات کے سلسلے کی درمیانی نمائندگی ہے۔ اس کے ساتھ براہ راست کام کرنے کا مقصد بالکل نہیں ہے۔ اس کے بجائے، KGroupedStream کو جمع کرنے کی کارروائیوں کے لیے استعمال کیا جاتا ہے، جس کے نتیجے میں ہمیشہ KTable بنتا ہے۔ اور چونکہ ایگریگیشن آپریشنز کا نتیجہ KTable ہے اور وہ ایک اسٹیٹ اسٹور استعمال کرتے ہیں، اس لیے یہ ممکن ہے کہ اس کے نتیجے میں تمام اپ ڈیٹس مزید پائپ لائن کے نیچے نہ بھیجی جائیں۔

KTable.groupBy طریقہ اسی طرح کے KGroupedTable کو لوٹاتا ہے - اپ ڈیٹس کے سلسلے کی ایک درمیانی نمائندگی، کلید کے ذریعے دوبارہ گروپ۔

آئیے ایک مختصر وقفہ لیں اور تصویر کو دیکھیں۔ 5.9، جو ظاہر کرتا ہے کہ ہم نے کیا حاصل کیا ہے۔ یہ ٹوپولوجی آپ کو پہلے سے ہی بہت واقف ہونا چاہئے۔

آئیے اب اس ٹوپولوجی کے کوڈ کو دیکھتے ہیں (اسے src/main/java/bbejeck/chapter_5/AggregationsAndReducingExample.java فائل میں مل سکتا ہے) (فہرست 5.2)۔

دیئے گئے کوڈ کو اس کے اختصار اور کئی سطروں میں کئے گئے اعمال کی بڑی مقدار سے پہچانا جاتا ہے۔ آپ builder.stream طریقہ کار کے پہلے پیرامیٹر میں کچھ نیا دیکھ سکتے ہیں: Enum قسم AutoOffsetReset.EARLIEST کی ایک قدر (ایک تازہ ترین بھی ہے)، Consumed.withOffsetResetPolicy طریقہ استعمال کرکے سیٹ کریں۔ اس گنتی کی قسم کو ہر KStream یا KTable کے لیے آفسیٹ ری سیٹ کی حکمت عملی بتانے کے لیے استعمال کیا جا سکتا ہے اور کنفیگریشن سے آفسیٹ ری سیٹ آپشن پر فوقیت لیتا ہے۔

GroupByKey اور GroupBy

KStream انٹرفیس میں ریکارڈز کو گروپ کرنے کے دو طریقے ہیں: GroupByKey اور GroupBy۔ دونوں ایک KGrouped Table واپس کرتے ہیں، تو آپ سوچ رہے ہوں گے کہ ان میں کیا فرق ہے اور کون سا کب استعمال کرنا ہے؟

GroupByKey طریقہ استعمال کیا جاتا ہے جب KStream میں کلیدیں پہلے سے خالی نہ ہوں۔ اور سب سے اہم بات، "دوبارہ تقسیم کی ضرورت ہے" کا جھنڈا کبھی سیٹ نہیں کیا گیا۔

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

یہ واضح ہے کہ mapValues ​​اور groupBy طریقے کیا کرتے ہیں، تو آئیے sum() طریقہ (src/main/java/bbejeck/model/ShareVolume.java میں پایا جاتا ہے) پر ایک نظر ڈالیں (فہرست 5.3)۔

ShareVolume.sum کا طریقہ اسٹاک سیلز والیوم کا چل رہا کل واپس کرتا ہے، اور حساب کے پورے سلسلے کا نتیجہ KTable آبجیکٹ ہے۔ . اب آپ سمجھ گئے ہیں کہ KTable کیا کردار ادا کرتا ہے۔ جب ShareVolume آبجیکٹ آتے ہیں تو متعلقہ KTable آبجیکٹ تازہ ترین تازہ کاری کو اسٹور کرتا ہے۔ یہ یاد رکھنا ضروری ہے کہ تمام اپ ڈیٹس پچھلے شیئر والیوم کے ٹیبل میں جھلکتی ہیں، لیکن سبھی کو آگے نہیں بھیجا جاتا ہے۔

اس کے بعد ہم اس KTable کو جمع کرنے کے لیے استعمال کرتے ہیں (تجارت کیے گئے حصص کی تعداد کے حساب سے) پانچ کمپنیوں تک پہنچنے کے لیے جن کے حصص کی ہر صنعت میں تجارت کی جاتی ہے۔ اس معاملے میں ہمارے اعمال پہلے جمع کرنے والوں کی طرح ہوں گے۔

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

تصویر میں شکل 5.10 ڈیٹا فلو ٹوپولوجی گراف کو دکھاتا ہے۔ جیسا کہ آپ دیکھ سکتے ہیں، پروسیسنگ کا دوسرا دور بہت آسان ہے۔

اب جب کہ ہمیں پروسیسنگ کے اس دوسرے دور کی ساخت کی واضح سمجھ ہے، ہم اس کے سورس کوڈ کی طرف رجوع کر سکتے ہیں (آپ اسے فائل src/main/java/bbejeck/chapter_5/AggregationsAndReducingExample.java میں دیکھیں گے) (فہرست 5.4) .

یہ ابتدائی کنندہ ایک مقررہ قطار متغیر پر مشتمل ہے۔ یہ ایک حسب ضرورت آبجیکٹ ہے جو java.util.TreeSet کے لیے ایک اڈاپٹر ہے جو ٹریڈ کیے جانے والے حصص کی نزولی ترتیب میں ٹاپ N نتائج کو ٹریک کرنے کے لیے استعمال ہوتا ہے۔

آپ گروپ بی اور میپ ویلیوز کالز پہلے ہی دیکھ چکے ہیں، اس لیے ہم ان میں نہیں جائیں گے (ہم KTable.toStream طریقہ کو کال کر رہے ہیں کیونکہ KTable.print طریقہ فرسودہ ہے)۔ لیکن آپ نے ابھی تک aggregate() کا KTable ورژن نہیں دیکھا ہے، اس لیے ہم اس پر بات کرنے میں تھوڑا وقت گزاریں گے۔

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

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

ہم نے دو اہم کام کرنا سیکھا:

• ایک مشترکہ کلید کے ذریعے KTable میں گروپ ویلیوز؛
• ان گروپ شدہ اقدار پر رول اپ اور ایگریگیشن جیسی مفید کارروائیاں انجام دیں۔

کافکا اسٹریمز ایپلی کیشن کے ذریعے منتقل ہونے والے ڈیٹا کے معنی کو سمجھنے اور یہ سمجھنے کے لیے کہ ان کارروائیوں کو انجام دینے کا طریقہ جاننا ضروری ہے۔

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

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

اگلا، ہم ایک مخصوص مدت کے اندر جمع کرنے جیسے آپریشنز کو دیکھیں گے - نام نہاد ونڈونگ آپریشنز۔

5.3.2 ونڈو آپریشنز

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

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

خریدار کے ذریعہ تبادلے کے لین دین کی گنتی

اگلی مثال میں، ہم متعدد تاجروں کے درمیان اسٹاک کے لین دین کو ٹریک کریں گے—یا تو بڑی تنظیمیں یا ہوشیار انفرادی فنانسرز۔

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

اس طرح کی ٹریکنگ درج ذیل مراحل پر مشتمل ہے:

• اسٹاک ٹرانزیکشن کے موضوع سے پڑھنے کے لیے ایک سلسلہ بنانا؛
• خریدار کی شناخت اور اسٹاک کی علامت کے ذریعہ آنے والے ریکارڈوں کو گروپ کرنا۔ گروپ بائے میتھڈ کو کال کرنے سے KGroupedStream کلاس کی مثال ملتی ہے۔
• KGroupedStream.windowedBy طریقہ ٹائم ونڈو تک محدود ڈیٹا سٹریم لوٹاتا ہے، جو ونڈو جمع کرنے کی اجازت دیتا ہے۔ ونڈو کی قسم پر منحصر ہے، یا تو ایک TimeWindowedKStream یا ایک SessionWindowedKStream لوٹایا جاتا ہے۔
• جمع آپریشن کے لیے لین دین کی گنتی۔ ونڈو والے ڈیٹا کا بہاؤ اس بات کا تعین کرتا ہے کہ آیا اس شمار میں کسی خاص ریکارڈ کو مدنظر رکھا گیا ہے۔
• کسی عنوان پر نتائج لکھنا یا ترقی کے دوران کنسول میں آؤٹ پٹ کرنا۔

اس ایپلی کیشن کی ٹوپولوجی سادہ ہے، لیکن اس کی واضح تصویر مددگار ثابت ہوگی۔ آئیے تصویر پر ایک نظر ڈالتے ہیں۔ 5.11۔

اگلا، ہم ونڈو آپریشنز کی فعالیت اور متعلقہ کوڈ کو دیکھیں گے۔

ونڈو کی اقسام

کافکا اسٹریمز میں تین قسم کی ونڈوز ہیں:

• سیشنل
• "ٹمبلنگ" (گرنا)؛
• سلائڈنگ / ہاپنگ.

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

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

سیشن ونڈوز

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

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

اسٹاک کے لین دین کو ٹریک کرنے کے لیے سیشن ونڈوز کا استعمال

آئیے تبادلے کے لین دین کے بارے میں معلومات حاصل کرنے کے لیے سیشن ونڈوز کا استعمال کریں۔ سیشن ونڈوز کا نفاذ لسٹنگ 5.5 میں دکھایا گیا ہے (جو src/main/java/bbejeck/chapter_5/CountingWindowingAndKTableJoinExample.java میں پایا جا سکتا ہے)۔

آپ پہلے ہی اس ٹوپولوجی میں زیادہ تر آپریشنز دیکھ چکے ہیں، لہذا انہیں یہاں دوبارہ دیکھنے کی ضرورت نہیں ہے۔ لیکن یہاں کئی نئے عناصر بھی ہیں، جن پر اب ہم بات کریں گے۔

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

لسٹنگ 5.5 کا کوڈ سیشن ونڈوز کے اندر لین دین کی تعداد کو شمار کرتا ہے۔ تصویر میں 5.13 ان اعمال کا مرحلہ وار تجزیہ کیا جاتا ہے۔

windowedBy(SessionWindows.with(twentySeconds).until(20Minutes)) کو کال کرکے ہم ایک سیشن ونڈو بناتے ہیں جس میں 15 سیکنڈ کے غیر فعال ہونے کے وقفے اور 20 منٹ کے مستقل وقفے کے ساتھ۔ 20 سیکنڈ کے وقفہ کا مطلب یہ ہے کہ ایپلی کیشن میں کوئی بھی اندراج شامل ہوگا جو موجودہ سیشن کے اختتام یا شروع ہونے کے XNUMX سیکنڈ کے اندر موجودہ (فعال) سیشن میں آتا ہے۔

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

آئیے گنتی کے طریقہ کار سے چند اندراجات کو دیکھیں کہ سیشن کیسے کام کرتے ہیں (ٹیبل 5.1)۔

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

1. ریکارڈ 1 پہلے آتا ہے، لہذا آغاز کا وقت اختتامی وقت کے برابر ہے اور 00:00:00 ہے۔

2. اگلا ریکارڈ 2 آتا ہے، اور ہم ایسے سیشنز تلاش کرتے ہیں جو 23:59:55 سے پہلے ختم نہ ہوں اور 00:00:35 کے بعد شروع نہ ہوں۔ ہم ریکارڈ 1 تلاش کرتے ہیں اور سیشن 1 اور 2 کو یکجا کرتے ہیں۔ ہم سیشن 1 کے آغاز کا وقت (پہلے) اور سیشن 2 کا اختتامی وقت (بعد میں) لیتے ہیں، تاکہ ہمارا نیا سیشن 00:00:00 پر شروع ہو اور 00 پر ختم ہو: 00:15

3. ریکارڈ 3 آتا ہے، ہم 00:00:30 اور 00:01:10 کے درمیان سیشن تلاش کرتے ہیں اور کوئی نہیں ملتا۔ کلید 123-345-654،FFBE کے لیے ایک دوسرا سیشن شامل کریں، جو 00:00:50 پر شروع اور ختم ہوتا ہے۔

4. ریکارڈ 4 آتا ہے اور ہم 23:59:45 اور 00:00:25 کے درمیان سیشنز تلاش کر رہے ہیں۔ اس بار دونوں سیشن 1 اور 2 ملے ہیں۔ تینوں سیشن ایک میں مل گئے ہیں، شروع کا وقت 00:00:00 اور اختتامی وقت 00:00:15 کے ساتھ۔

اس سیکشن میں جو کچھ بیان کیا گیا ہے اس سے، یہ مندرجہ ذیل اہم باریکیوں کو یاد رکھنے کے قابل ہے:

• سیشن فکسڈ سائز کی ونڈوز نہیں ہیں۔ سیشن کی مدت کا تعین ایک مقررہ مدت میں ہونے والی سرگرمی سے کیا جاتا ہے۔
• ڈیٹا میں موجود تاریخ/وقت کے ڈاک ٹکٹ اس بات کا تعین کرتے ہیں کہ آیا واقعہ کسی موجودہ سیشن کے اندر آتا ہے یا کسی بیکار مدت کے دوران۔

اس کے بعد ہم اگلی قسم کی ونڈو - "ٹمبلنگ" ونڈوز پر بات کریں گے۔

"ٹمبلنگ" ونڈوز

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

جیسا کہ آپ دیکھ سکتے ہیں، پچھلے 20 سیکنڈ میں موصول ہونے والے تمام واقعات ونڈو میں شامل ہیں۔ اس مدت کے اختتام پر، ایک نئی ونڈو بنائی جاتی ہے۔

فہرست 5.6 کوڈ دکھاتا ہے جو ہر 20 سیکنڈ میں اسٹاک ٹرانزیکشنز کیپچر کرنے کے لیے ٹمبلنگ ونڈوز کے استعمال کو ظاہر کرتا ہے (src/main/java/bbejeck/chapter_5/CountingWindowingAndKtableJoinExample.java میں پایا جاتا ہے)۔

TimeWindows.of میتھڈ کال میں اس چھوٹی تبدیلی کے ساتھ، آپ ٹمبلنگ ونڈو استعمال کر سکتے ہیں۔ یہ مثال till() طریقہ کو کال نہیں کرتی ہے، لہذا 24 گھنٹے کا ڈیفالٹ برقراری وقفہ استعمال کیا جائے گا۔

آخر میں، ونڈو کے آخری اختیارات - "ہاپنگ" ونڈوز پر جانے کا وقت آگیا ہے۔

سلائیڈنگ ("جمپنگ") ونڈوز

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

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

فہرست 5.7 سلائیڈنگ ونڈوز کی وضاحت کے لیے کوڈ کو ظاہر کرتی ہے (src/main/java/bbejeck/chapter_5/CountingWindowingAndKtableJoinExample.java میں پایا جاتا ہے)۔

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

آپ نے اس سیکشن میں دیکھا کہ جمع کے نتائج کو ٹائم ونڈوز تک کیسے محدود کیا جائے۔ خاص طور پر، میں چاہتا ہوں کہ آپ اس حصے سے درج ذیل تین چیزیں یاد رکھیں:

• سیشن ونڈوز کا سائز وقت کے لحاظ سے نہیں بلکہ صارف کی سرگرمی سے محدود ہے۔
• "ٹمبلنگ" ونڈوز ایک مقررہ مدت میں ہونے والے واقعات کا جائزہ فراہم کرتی ہیں۔
• جمپنگ ونڈو کا دورانیہ مقرر ہے، لیکن وہ کثرت سے اپ ڈیٹ ہوتے رہتے ہیں اور ان میں تمام ونڈوز میں اوور لیپنگ اندراجات شامل ہو سکتے ہیں۔

اگلا، ہم سیکھیں گے کہ کنکشن کے لیے KTable کو واپس KStream میں کیسے تبدیل کیا جائے۔

5.3.3 KStream اور KTable اشیاء کو جوڑ رہا ہے۔

باب 4 میں، ہم نے دو KStream اشیاء کو جوڑنے پر تبادلہ خیال کیا۔ اب ہمیں KTable اور KStream کو جوڑنے کا طریقہ سیکھنا ہے۔ اس کی ضرورت درج ذیل سادہ وجہ سے ہو سکتی ہے۔ KStream ریکارڈز کا ایک سلسلہ ہے، اور KTable ریکارڈ کی تازہ کاریوں کا سلسلہ ہے، لیکن بعض اوقات آپ KTable سے اپ ڈیٹس کا استعمال کرتے ہوئے ریکارڈ کے سلسلے میں اضافی سیاق و سباق شامل کرنا چاہتے ہیں۔

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

1. اسٹاک ٹرانزیکشنز کی تعداد کے اعداد و شمار کے ساتھ KTable آبجیکٹ کو KStream میں تبدیل کریں، اس کے بعد کلید کو کلید کے ساتھ تبدیل کریں جو اس اسٹاک کی علامت کے مطابق صنعتی شعبے کی نشاندہی کرتی ہے۔
2. ایک KTable آبجیکٹ بنائیں جو اسٹاک ایکسچینج کی خبروں کے ساتھ کسی موضوع سے ڈیٹا پڑھے۔ یہ نئی KTable صنعت کے شعبے کے لحاظ سے درجہ بندی کی جائے گی۔
3. صنعت کے شعبے کے ذریعہ اسٹاک ایکسچینج کے لین دین کی تعداد کے بارے میں معلومات کے ساتھ خبروں کی تازہ کاریوں کو مربوط کریں۔

اب دیکھتے ہیں کہ اس ایکشن پلان کو کیسے عملی جامہ پہنایا جائے۔

KTable کو KStream میں تبدیل کریں۔

KTable کو KStream میں تبدیل کرنے کے لیے آپ کو درج ذیل کام کرنے ہوں گے۔

1. KTable.toStream() طریقہ کو کال کریں۔
2. KStream.map طریقہ کو کال کرکے، کلید کو انڈسٹری کے نام سے تبدیل کریں، اور پھر Windowed مثال سے TransactionSummary آبجیکٹ کو بازیافت کریں۔

ہم ان کارروائیوں کو مندرجہ ذیل کے طور پر ایک ساتھ ترتیب دیں گے (کوڈ فائل src/main/java/bbejeck/chapter_5/CountingWindowingAndKtableJoinExample.java) میں پایا جا سکتا ہے (فہرست 5.8)۔

چونکہ ہم KStream.map آپریشن کر رہے ہیں، اس لیے واپس کی گئی KStream مثال خود بخود دوبارہ تقسیم ہو جاتی ہے جب اسے کسی کنکشن میں استعمال کیا جاتا ہے۔

ہم نے تبدیلی کا عمل مکمل کر لیا ہے، اس کے بعد ہمیں اسٹاک نیوز پڑھنے کے لیے KTable آبجیکٹ بنانے کی ضرورت ہے۔

اسٹاک نیوز کے لیے KTable کی تخلیق

خوش قسمتی سے، KTable آبجیکٹ بنانے میں کوڈ کی صرف ایک لائن لگتی ہے (کوڈ src/main/java/bbejeck/chapter_5/CountingWindowingAndKtableJoinExample.java میں پایا جا سکتا ہے) (فہرست 5.9)۔

یہ بات قابل غور ہے کہ کسی بھی Serde آبجیکٹ کو متعین کرنے کی ضرورت نہیں ہے، کیونکہ سٹرنگ Serdes سیٹنگز میں استعمال ہوتی ہے۔ اس کے علاوہ، ابتدائی گنتی کا استعمال کرتے ہوئے، میز بالکل شروع میں ریکارڈ سے بھرا ہوا ہے۔

اب ہم آخری مرحلے پر جا سکتے ہیں - کنکشن۔

لین دین کی گنتی کے ڈیٹا کے ساتھ خبروں کی تازہ کاریوں کو مربوط کرنا

کنکشن بنانا مشکل نہیں ہے۔ متعلقہ صنعت کے لیے اسٹاک کی کوئی خبر نہ ہونے کی صورت میں ہم بائیں جوائن کا استعمال کریں گے (ضروری کوڈ فائل src/main/java/bbejeck/chapter_5/CountingWindowingAndKtableJoinExample.java) میں پایا جا سکتا ہے (فہرست 5.10)۔

یہ لیفٹ جوائن آپریٹر کافی آسان ہے۔ باب 4 میں جوائنز کے برعکس، JoinWindow طریقہ استعمال نہیں کیا جاتا ہے کیونکہ KStream-KTable جوائن کرتے وقت، KTable میں ہر کلید کے لیے صرف ایک اندراج ہوتا ہے۔ اس طرح کا رابطہ وقت میں محدود نہیں ہے: ریکارڈ یا تو کے ٹیبل میں ہے یا غائب ہے۔ اہم نتیجہ: KTable اشیاء کا استعمال کرتے ہوئے آپ KStream کو کم کثرت سے اپ ڈیٹ شدہ حوالہ ڈیٹا کے ساتھ افزودہ کر سکتے ہیں۔

اب ہم KStream سے واقعات کو تقویت دینے کا ایک زیادہ موثر طریقہ دیکھیں گے۔

5.3.4 گلوبل کے ٹیبل آبجیکٹ

جیسا کہ آپ دیکھ سکتے ہیں، ایونٹ کے سلسلے کو تقویت دینے یا ان میں سیاق و سباق شامل کرنے کی ضرورت ہے۔ باب 4 میں آپ نے دو KStream اشیاء کے درمیان تعلق دیکھا، اور پچھلے حصے میں آپ نے KStream اور KTable کے درمیان تعلق دیکھا۔ ان تمام صورتوں میں، ڈیٹا سٹریم کو دوبارہ تقسیم کرنے کے لیے ضروری ہے جب کسی نئی قسم یا قدر میں کلیدوں کا نقشہ بنایا جائے۔ کبھی کبھی دوبارہ تقسیم واضح طور پر کی جاتی ہے، اور کبھی کبھی کافکا اسٹریمز خود بخود کرتا ہے۔ دوبارہ تقسیم ضروری ہے کیونکہ چابیاں تبدیل ہو چکی ہیں اور ریکارڈز کو نئے حصوں میں ختم ہونا چاہیے، بصورت دیگر کنکشن ناممکن ہو جائے گا (اس پر باب 4، ذیلی سیکشن 4.2.4 کے سیکشن "ڈیٹا کی دوبارہ تقسیم" میں بحث کی گئی ہے)۔

دوبارہ تقسیم کرنے کی ایک قیمت ہے۔

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

چھوٹے ڈیٹاسیٹس سے منسلک ہو رہا ہے۔

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

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

کے اسٹریم آبجیکٹ کو گلوبل کے ٹیبل آبجیکٹ سے جوڑنا

ذیلی سیکشن 5.3.2 میں، ہم نے خریداروں کے ذریعے تبادلے کے لین دین کی ونڈو جمع کی۔ اس جمع کے نتائج کچھ اس طرح نظر آئے:

{customerId='074-09-3705', stockTicker='GUTM'}, 17
{customerId='037-34-5184', stockTicker='CORK'}, 16

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

ایسا کرنے کے لیے، ہم فہرست 5.11 سے کاؤنٹ اسٹریم آبجیکٹ استعمال کریں گے (متعلقہ کوڈ src/main/java/bbejeck/chapter_5/GlobalKTableExample.java میں پایا جا سکتا ہے) اور اسے دو GlobalKTable آبجیکٹ سے جوڑیں گے۔

ہم پہلے بھی اس پر بات کر چکے ہیں، اس لیے میں اسے نہیں دہراؤں گا۔ لیکن میں نوٹ کرتا ہوں کہ toStream(.map فنکشن میں کوڈ کو پڑھنے کی اہلیت کی خاطر ان لائن لیمبڈا اظہار کی بجائے فنکشن آبجیکٹ میں خلاصہ کیا گیا ہے۔

اگلا مرحلہ GlobalKTable کی دو مثالوں کا اعلان کرنا ہے (دکھایا گیا کوڈ فائل src/main/java/bbejeck/chapter_5/GlobalKTableExample.java) میں پایا جا سکتا ہے (فہرست 5.12)۔

براہ کرم نوٹ کریں کہ عنوان کے نام شمار شدہ اقسام کا استعمال کرتے ہوئے بیان کیے گئے ہیں۔

اب جب کہ ہمارے پاس تمام اجزاء تیار ہیں، جو کچھ باقی ہے وہ کنکشن کے لیے کوڈ لکھنا ہے (جو فائل src/main/java/bbejeck/chapter_5/GlobalKTableExample.java میں پایا جا سکتا ہے) (فہرست 5.13)۔

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

جب آپ مندرجہ بالا جوائن آپریشن چلاتے ہیں، تو آپ کو اس طرح کے نتائج ملیں گے:

{customer='Barney, Smith' company="Exxon", transactions= 17}

جوہر تبدیل نہیں ہوا ہے، لیکن یہ نتائج زیادہ واضح نظر آتے ہیں۔

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

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

اگلا ہم کافکا اسٹریمز کی خصوصیت دیکھیں گے، جس کی بدولت ہم کافکا کے موضوع سے ڈیٹا استعمال کیے بغیر ریاستی تبدیلیوں کا مشاہدہ کر سکتے ہیں۔

5.3.5 قابل استفسار حالت

ہم نے پہلے ہی کئی آپریشنز انجام دیے ہیں جن میں ریاست شامل ہے اور ہمیشہ نتائج کو کنسول میں آؤٹ پٹ کرتے ہیں (ترقیاتی مقاصد کے لیے) یا انہیں کسی موضوع پر لکھتے ہیں (پروڈکشن کے مقاصد کے لیے)۔ کسی موضوع پر نتائج لکھتے وقت، آپ کو انہیں دیکھنے کے لیے کافکا صارف استعمال کرنا پڑتا ہے۔

ان عنوانات سے ڈیٹا کو پڑھنا ایک قسم کے مادّی خیالات کے طور پر سمجھا جا سکتا ہے۔ اپنے مقاصد کے لیے، ہم ویکیپیڈیا سے ایک مادی نظریہ کی تعریف استعمال کر سکتے ہیں: "...ایک فزیکل ڈیٹا بیس آبجیکٹ جس میں استفسار کے نتائج ہوتے ہیں۔ مثال کے طور پر، یہ ریموٹ ڈیٹا کی مقامی کاپی، یا ٹیبل کی قطاروں اور/یا کالموں کا ذیلی سیٹ یا جوائن کے نتائج، یا جمع کے ذریعے حاصل کردہ خلاصہ ٹیبل ہو سکتا ہے" (https://en.wikipedia.org/wiki /Materialized_view)۔

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

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

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

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

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

خلاصہ

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

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

→ کتاب کے بارے میں مزید تفصیلات یہاں دیکھی جا سکتی ہیں۔ پبلشر کی ویب سائٹ

→ Habrozhiteli کے لیے کوپن کا استعمال کرتے ہوئے 25% ڈسکاؤنٹ - کافکا اسٹریمز

→ کتاب کے کاغذی ورژن کی ادائیگی پر، ایک الیکٹرانک کتاب بذریعہ ای میل بھیجی جائے گی۔

ماخذ: www.habr.com