পাঠ্যক্রম খুলুন

মধ্যবর্তী পর্যায়

Stream বনাম Batch Processing: চলমান ও জমা ডেটা

Stream vs. Batch Processing

এই পাঠের কুইজ ↓৫ মিনিট পড়াPHP 8.3+ · Laravel 12

আগে পড়ে নিনKafka: partition, offset ও consumer group ↗

এই পাঠের সূচিপত্র

এই পাঠে যা শিখবেন

Streaming ও batch pipeline তুলনা করুন
Event time processing time আলাদা করুন
Late event-এর correction policy দিন

সমস্যা দিয়ে শুরু

দৈনিক sales report রাত বারোটায় তৈরি হয়, কিন্তু offline POS-এর কিছু বিক্রি ভোরে sync হয়। Report ভুল। Fraud team আবার রাত পর্যন্ত অপেক্ষা করতে পারে না। একই data থেকে low-latency alert ও পরে সংশোধিত report দুটো চাই।

সহজ করে বুঝি

Batch bounded dataset একসঙ্গে process করে; stream চলমান record incrementally process করে। Event time হলো বাস্তব ঘটনা ঘটার সময়, processing time হলো pipeline দেখার সময়। Window data-কে interval-এ ভাগ করে। Watermark late data সম্পর্কে estimate, সব future event নিশ্চিতভাবে শেষ হয়েছে এমন দৈবজ্ঞান নয়।

পরিচিত একটি উপমা

দিন শেষে পুরো দোকানের receipt গোনা batch। প্রতিটি receipt আসামাত্র counter বাড়ানো stream। বাইরে থাকা sales representative-এর receipt পরে এলে দিনের মোট সংশোধন করতে হয়। Receipt জমার সময় আর বিক্রির সময় এক না।

নকশাটি দেখুন

Diagram লোড হচ্ছে…

Streaming ও batch pipeline তুলনা করুন

Diagram-এর text flow দেখুন

flowchart LR
 P[Sales Events] --> S[Streaming Alerts]
 P --> L[(Durable Event Log)]
 L --> B[Nightly Batch]
 B --> R[Corrected Daily Report]
 S --> A[Fraud Review]

একই event source দ্রুত alert pipeline ও durable archive-এ যায়। Alert provisional হতে পারে। Batch সম্পূর্ণ interval পুনরায় গণনা করে late event যোগ করে report সংশোধন করে। দুই পথের semantics না মেলালে dashboard ও final report ভিন্ন অর্থ বহন করবে।

PHP ও Laravel-এ প্রয়োগ

Laravel scheduled reporting job-এর fragment। sales table-এ occurred_at UTC event time আছে, tenant authorized, এবং report date timezone policy আগেই নির্ধারিত। updateOrInsert report rerun-কে safe করে; production-এ unique tenant_id,report_date constraint লাগবে।

use Illuminate\Support\Facades\DB;

$total = DB::table('sales')
    ->where('tenant_id', $tenantId)
    ->where('occurred_at', '>=', $startUtc)
    ->where('occurred_at', '<', $endUtc)
    ->sum('amount_minor');

DB::table('daily_reports')->updateOrInsert(
    ['tenant_id' => $tenantId, 'report_date' => $reportDate],
    ['total_minor' => $total, 'computed_at' => now()],
);
// Rerun recent windows to incorporate late-arriving sales.
// A unique index and per-window serialization protect concurrent reruns.

এটি PHP 8.3+ ও Laravel 12-এর শিক্ষামূলক fragment; সম্পূর্ণ application নয়। সংশ্লিষ্ট route-এ authentication ও resource authorization প্রয়োগ করতে হবে। নিচের অনুশীলনে failure ইচ্ছা করে তৈরি করুন; শুধু সফল response দেখে correctness ধরে নেবেন না।

সুবিধা, সীমাবদ্ধতা ও trade-off

Stream দ্রুত feedback দেয়, কিন্তু state, late data ও replay কঠিন। Batch সাধারণত সহজে recompute করা যায়, তবে result অপেক্ষা করতে হয়। সব dashboard real-time করা খরচ বাড়ায়; business কত পুরোনো ফল সহ্য করবে সেটিই সিদ্ধান্ত।

সাধারণ ভুল

Arrival date অনুযায়ী offline sale ভুল দিনের report-এ রাখা।
Watermark পার হয়েছে বলে late record নীরবে ফেলে দেওয়া।
Streaming total ও batch total-এর filter আলাদা রাখা।

আরও একটু গভীরে

Window aggregation-এ exactly-once state update এবং external sink update ভিন্ন boundary হতে পারে। Session window, tumbling window ও sliding window আলাদা প্রশ্নের উত্তর দেয়। Timezone এবং daylight-saving policy data contract-এর অংশ।

এক দিনের sale পরের দিন ingest করুন। প্রথম provisional report এবং rerun-এর corrected report তুলনা করুন। UI-তে report generation time ও finality status দেখান। Audit-এর জন্য correction amount আলাদা রাখলে হিসাব কেন বদলেছে বোঝা সহজ হয়।

মনে রাখুন

দ্রুত ফল ও final ফল আলাদা হতে পারে।
Event time বেছে স্পষ্ট contract দিন।
Late data-এর correction পরিকল্পনা করুন।

নিজে চেষ্টা করুন

পাঁচ মিনিটের fraud window ও daily revenue report-এর জন্য window, lateness tolerance এবং correction policy লিখুন।

নিজের বোঝা যাচাই করুন

1. Stream মানে zero delay?

না। Ingestion, batching, state update এবং downstream latency থাকে।

2. Event time কেন?

ঘটনার business interval ঠিক রাখতে; delayed delivery যেন বিক্রির দিন বদলে না দেয়।

3. Batch কি পুরোনো?

না। Reliable recomputation ও bounded analytics-এ এখনও কার্যকর এবং সহজ।

4. Late event কী করব?

Drop, correction অথবা side output—policy স্পষ্ট এবং observable হতে হবে।

5. একই data দুই ফল কেন?

একটি provisional ও অন্যটি corrected হতে পারে; filter ও semantics mismatch থাকলেও তফাৎ হয়, পরীক্ষা করুন।

এই পাঠের কুইজ

এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।

এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।

জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।

সব বিষয় মিলিয়ে অনুশীলন করুন →

অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।