Batch vs Stream Processing
- ●Batch processing বড় data একসাথে প্রক্রিয়া করে—high latency কিন্তু high throughput।
- ●Stream processing data আসামাত্র event-by-event প্রক্রিয়া করে—low latency real-time ফল দেয়।
- ●Lambda architecture দুটো একসাথে চালায়, Kappa শুধু stream দিয়ে সব করে।
সমস্যাটা কী?
ভাবো তোমার একটা অ্যাপে প্রতিদিন কোটি কোটি event আসে—ক্লিক, পেমেন্ট, লগইন। এই data থেকে দুই ধরনের প্রশ্নের উত্তর দরকার।
প্রথম ধরন: "গতকাল মোট কত বিক্রি হলো, কোন product বেশি চলল?"—এটা রাতে একবার চালালেই হয়, কিন্তু বিশাল data নিয়ে কাজ।
দ্বিতীয় ধরন: "এই মুহূর্তে কেউ fraud করছে কিনা ধরো", বা "live dashboard-এ এখনকার active user দেখাও"—এটা সেকেন্ডের মধ্যে দরকার, পরের দিন হলে কোনো মূল্য নেই।
এই দুই ধরনের চাহিদা সামলাতে দুটো ভিন্ন approach: batch processing আর stream processing। কোনটা কখন—সেটাই আজকের বিষয়।
মূল ধারণা
Batch processing হলো বিপুল পরিমাণ data একত্রে জমিয়ে নির্দিষ্ট সময়ে একসাথে প্রক্রিয়া করা। Stream processing হলো data যেমন যেমন আসছে (event by event), তেমন তেমন তখনই প্রক্রিয়া করা।
মূল ব্যবসায়িক trade-off হলো latency vs throughput:
- Batch: latency বেশি (ফল পেতে অপেক্ষা), কিন্তু throughput বিশাল (একবারে প্রচুর data)।
- Stream: latency কম (প্রায় তৎক্ষণাৎ ফল), কিন্তু প্রতিটা event আলাদা সামলায় বলে design জটিল।
কীভাবে কাজ করে
Batch Processing
Data একটা storage-এ (যেমন data lake, HDFS) জমা হয়। নির্দিষ্ট সময়ে (যেমন প্রতি রাত ২টায়) একটা job পুরো dataset নিয়ে প্রক্রিয়া করে ফল লিখে রাখে। ক্লাসিক model হলো MapReduce, আধুনিক engine হলো Apache Spark।
বৈশিষ্ট্য—bounded data (নির্দিষ্ট শুরু-শেষ আছে), high throughput, কিন্তু ফল পেতে minutes থেকে hours লাগে।
Stream Processing
Data একটা stream (যেমন Kafka topic) দিয়ে অবিরাম আসে। processing engine (যেমন Apache Flink, Kafka Streams) প্রতিটা event আসামাত্র প্রক্রিয়া করে এবং তৎক্ষণাৎ ফল আপডেট করে।
বৈশিষ্ট্য—unbounded data (কখনো শেষ হয় না), low latency (মিলিসেকেন্ড থেকে সেকেন্ড)। কিন্তু সামলাতে হয় কঠিন বিষয়—out-of-order event, windowing (সময়ের জানালা ধরে গণনা), state management।
তুলনামূলক টেবিল
| বৈশিষ্ট্য | Batch | Stream |
|---|---|---|
| Data | bounded (সীমিত) | unbounded (অবিরাম) |
| Latency | high (মিনিট-ঘণ্টা) | low (মিলিসেকেন্ড-সেকেন্ড) |
| Throughput | খুব বেশি | মাঝারি-বেশি |
| জটিলতা | কম | বেশি |
| ফল | নির্ভুল, complete | আনুমানিক, incremental |
| Engine | Spark, MapReduce | Flink, Kafka Streams |
এক নজরে
ভাবো একটা লন্ড্রি দোকান। Batch processing হলো—সারাদিনের সব কাপড় জমিয়ে রাতে একসাথে বড় মেশিনে ধোয়া। একবারে অনেক কাপড় ধোয়া যায় (high throughput), কিন্তু সকালে কাপড় দিলে সেটা পরদিন পাবে (high latency)।
Stream processing হলো—একটা ইস্ত্রি (iron) করার লোক, যার সামনে যে কাপড় আসছে সে তখনই ইস্ত্রি করে দিচ্ছে। প্রতিটা কাপড় সাথে সাথে রেডি (low latency), কিন্তু একসাথে হাজার কাপড় সামলাতে পারে না, আর ব্যবস্থাপনা মনোযোগ চায়।
কৌশল: Lambda vs Kappa Architecture
বাস্তবে অনেক system-এ batch আর stream দুটোই দরকার। দুটো জনপ্রিয় architecture:
Lambda Architecture
দুটো আলাদা pipeline একসাথে চলে:
- Batch layer: সব historical data নিয়ে নির্ভুল, complete ফল দেয় (ধীর কিন্তু সঠিক)।
- Speed layer: stream দিয়ে রিয়েল-টাইম আনুমানিক ফল দেয় (দ্রুত কিন্তু কম নিখুঁত)।
- Serving layer: দুটোর ফল মিলিয়ে দেখায়।
সুবিধা—real-time + accuracy দুটোই। অসুবিধা—একই logic দুই জায়গায় (batch ও stream code) maintain করতে হয়, যা ঝামেলা ও bug-প্রবণ।
Kappa Architecture
Lambda-র দ্বৈত-pipeline সমস্যার সমাধান—সব কিছু একটাই stream pipeline দিয়ে করা। historical data দরকার হলে stream (যেমন Kafka log) আবার শুরু থেকে replay করা হয়। ফলে এক জায়গায় code, কম জটিলতা। এটা সম্ভব হয়েছে Kafka ও Flink-এর মতো tool data retain ও replay করতে পারায়।
কখন ব্যবহার করবে / করবে না
- Batch: দৈনিক/সাপ্তাহিক রিপোর্ট, billing, ML model training, ETL job—যেখানে সময় গুরুত্বপূর্ণ নয় কিন্তু নির্ভুলতা ও বড় data জরুরি।
- Stream: fraud detection, real-time dashboard, alerting, recommendation update, live monitoring—যেখানে দেরি মানে মূল্য হারানো।
শুধু "real-time cool শোনায়" বলে সব কিছু stream-এ নিও না। Stream processing-এ state management, exactly-once semantics, out-of-order event, late data—এসব সামলানো অনেক জটিল ও ব্যয়বহুল। যদি ব্যবসার ফল কয়েক মিনিট দেরিতে পেলেই চলে, batch অনেক সহজ, সস্তা ও নির্ভরযোগ্য। জটিলতা শুধু তখনই নাও যখন low latency সত্যিই দরকার।
বাস্তব উদাহরণ
একটা ফিনটেক কোম্পানি দুটোই ব্যবহার করে। Stream (Kafka + Flink) দিয়ে প্রতিটা transaction আসামাত্র fraud check করে—সন্দেহজনক হলে সাথে সাথে block, কারণ এক মিনিট দেরি মানে টাকা চলে যাওয়া। আবার batch (Spark) দিয়ে প্রতি রাতে পুরো দিনের transaction নিয়ে নিখুঁত financial reconciliation ও regulatory report বানায়, যেখানে নির্ভুলতা সবচেয়ে জরুরি, গতি নয়। তারা ধীরে ধীরে Kappa-র দিকে যাচ্ছে যাতে একই Flink pipeline দুটো কাজই করতে পারে।
ইন্টারভিউতে batch না stream জিজ্ঞেস করলে প্রশ্ন করো: "ফল কত দ্রুত দরকার?" উত্তর "সেকেন্ড" হলে stream, "ঘণ্টা/দিন" হলে batch। আর Lambda vs Kappa-তে এক লাইনে বলো: "Lambda batch+stream দুই pipeline, Kappa সব stream দিয়ে replay করে—কম code, কম জটিলতা।"
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Stream processing-এর প্রধান সুবিধা কী?
2. Batch processing কখন উপযুক্ত?
3. Kappa architecture-এ Lambda-র তুলনায় পার্থক্য কী?