বিগ ডেটার আদি যুগে ইঞ্জিনিয়াররা ল্যাম্বডা আর্কিটেকচার (Lambda Architecture) ব্যবহার করতে বাধ্য হতেন—যেখানে দ্রুত ফলাফলের জন্য একটি আলাদা স্ট্রিমিং লেয়ার (Storm) এবং শতভাগ নিখুঁত ফলাফলের জন্য একটি ধীরগতির ব্যাচ লেয়ার (Hadoop) সমান্তরালে চালাতে হতো। ২০১৫ সালে গুগল প্রকাশ করে তাদের বৈপ্লবিক গবেষণাপত্র “দ্য ডেটাফ্লো মডেল (The Dataflow Model)”। ডেটাফ্লো মডেল প্রমাণ করে যে ব্যাচ এবং স্ট্রিমিং মূলত একই গাণিতিক মুদ্রার এপিঠ-ওপিঠ। অ্যাপাচি ফ্লিংক (Apache Flink) এবং অ্যাপাচি বিম (Apache Beam)-এর ভিত্তি স্থাপনকারী এই মডেল ইভেন্ট টাইম (Event Time), ওয়াটারমার্কস (Watermarks) এবং চ্যান্ডি-ল্যামপোর্ট স্টেট স্ন্যাপশটের মাধ্যমে অসীম ডেটা স্ট্রিমের ওপর গাণিতিকভাবে নির্ভুল গণনার যুগান্তকারী দ্বার উন্মোচন করে।
১. স্ট্রিমিংয়ের চারটি মৌলিক প্রশ্ন
টাইলার আকিয়াউ পুরো স্ট্রিম প্রসেসিংকে চারটি স্বাধীন প্রশ্নের মাধ্যমে কাঠামোবদ্ধ করেন:
- What (কী নির্ণয় করা হচ্ছে?): ট্রান্সফরমেশন বা হিসাব (যোগফল, গড়, ম্যাক্সিমাম)।
- Where (সময়ের কোন অংশে হিসাব হচ্ছে?): উইন্ডোয়িং (টাম্বলিং, স্লাইডিং, বা সেশন উইন্ডো)।
- When (কখন ফলাফল প্রকাশ করা হবে?): ওয়াটারমার্কস এবং ট্রিগার মেকানিজম।
- How (পূর্ববর্তী ফলাফলের সাথে নতুন ডেটা কীভাবে মিশবে?): একুমুলেশন ও রিট্র্যাকশন (পুরাতন মান সংশোধন)।
২. ইভেন্ট টাইম (Event Time) বনাম প্রসেসিং টাইম (Processing Time)
পূর্ববর্তী সিস্টেমগুলো কোনো ঘটনা সার্ভারে এসে পৌঁছানোর মুহূর্তকে (Processing Time) ভিত্তি করে কাজ করত। কিন্তু মোবাইলে নেটওয়ার্ক ড্রপ হলে বা সার্ভারে কিউ জ্যাম হলে একটি ঘটনা ঘটার কয়েক মিনিট বা ঘণ্টা পর সার্ভারে পৌঁছাতে পারে:
$$Delta(e) = t_{text{processing}} – t_{text{event}}$$
প্রসেসিং টাইমের ওপর নির্ভর করলে ব্যাংকিং ট্রানজ্যাকশন বা ডেটা অ্যানালিটিক্সে চরম ভুল ফলাফল আসে। ইভেন্ট টাইম (Event Time) হলো ঘটনাটি বাস্তব পৃথিবীতে ঘটার মুহূর্তে ডিভাইসে তৈরি হওয়া অপরিবর্তনীয় টাইমস্ট্যাম্প। একমাত্র ইভেন্ট টাইমের ওপর ভিত্তি করলেই চরম নেটওয়ার্ক বিশৃঙ্খলার মধ্যেও শতভাগ নির্ভুল ফলাফল অর্জন সম্ভব।
৩. ওয়াটারমার্কস (Watermarks): ডেটার সমাপ্তির বার্তা
যদি ডেটা এলোমেলো সময়ে পৌঁছায়, তবে একটি সিস্টেম কীভাবে বুঝবে যে ১২:০০ থেকে ১২:১০ পর্যন্ত সময়ের সব ডেটা এসে গেছে এবং এখন চূড়ান্ত যোগফল প্রকাশ করা নিরাপদ? এর সমাধান হলো ওয়াটারমার্ক (Watermark)।
ওয়াটারমার্ক $W(t)$ হলো ডেটা প্রবাহের মধ্য দিয়ে হেঁটে চলা একটি বিশেষ টাইমস্ট্যাম্প যা দৃঢ়ভাবে ঘোষণা করে:
$$forall e, quad t_{text{event}}(e) > W(t)$$
অর্থাৎ, $W(t)$-এর পরে আর এমন কোনো ডেটা আসবে না যার ইভেন্ট টাইম $W(t)$-এর চেয়ে ছোট। ফলে সিস্টেম নিশ্চিন্তে সেই উইন্ডোর হিসাব সম্পন্ন করে মেমোরি খালি করে দিতে পারে। কোনো ডেটা ওয়াটারমার্ক পার হওয়ার পর অত্যন্ত দেরিতে পৌঁছালে (Late Data) আধুনিক সিস্টেম তা ফেলে না দিয়ে সংশোধনী বা রিট্র্যাকশন (Retraction) পাঠায়।
৪. চ্যান্ডি-ল্যামপোর্ট ডিস্ট্রিবিউটেড স্টেট স্ন্যাপশট
স্ট্রিম প্রসেসিং চলাকালীন কোনো সার্ভার ক্র্যাশ করলে ডেটা যেন দ্বিগুণ হিসাব না হয় বা হারিয়ে না যায় (Exactly-Once Semantics), সে জন্য অ্যাপাচি ফ্লিংক ১৯৮৫ সালের বিখ্যাত চ্যান্ডি-ল্যামপোর্ট (Chandy-Lamport) অ্যালগরিদমের রূপান্তর ব্যবহার করে:
- কোঅর্ডিনেটর ডেটা প্রবাহের মধ্যে বিশেষ চেকপয়েন্ট ব্যারিয়ার (Checkpoint Barrier) ঢুকিয়ে দেয়।
- ব্যারিয়ারটি ডেটার পাশাপাশি কোনো প্রসেসিং না থামিয়েই সমান্তরালে এগিয়ে চলে।
- প্রতিটি প্রসেসর যখন সমস্ত ইনপুট থেকে ব্যারিয়ারটি গ্রহণ করে, তখন সে ব্যাকগ্রাউন্ডে নিজের বর্তমান স্টেটের একটি অ্যাসিঙ্ক স্ন্যাপশট ক্লাউড স্টোরেজে সেভ করে ফেলে।
- কোনো বিপর্যয় ঘটলে পুরো ক্লাস্টার শেষ সফল চেকপয়েন্টে ফিরে গিয়ে কাফকা থেকে পুনরায় অফসেট পড়ে নিখুঁত এক্স্যাক্টলি-ওয়ানস স্টেট পুনরুদ্ধার করে।
