7.6 রিয়েল-টাইম ও স্ট্রিমিং ডেটা

পরিচিতি ও প্রেরণা

ডেটা পাইপলাইন সম্পর্কে আপনি যা জানেন তার বেশিরভাগই ধরে নেয় ডেটা স্থির থাকে। আপনি একদিনের রেকর্ড জমান, রাতারাতি একটি কাজ চালান এবং সকালে ফল পড়েন। রিয়েল-টাইম ও স্ট্রিমিং ডেটা সেই ধারণা উল্টে দেয়। সম্পূর্ণ হয়ে যাওয়া ডেটার স্তূপ প্রক্রিয়া করার বদলে আপনি আসতে থাকা ইভেন্টের অফুরন্ত প্রবাহ প্রক্রিয়া করেন এবং নিরন্তর উত্তর তৈরি করেন। এটাই ব্যাচ প্রক্রিয়াকরণ, যা সীমাবদ্ধ, সম্পূর্ণ ডেটাসেটের ওপর কাজ করে, এবং স্ট্রিম প্রক্রিয়াকরণ, যা অসীম, কখনো-শেষ-না-হওয়া প্রবাহের ওপর কাজ করে, এই দুইয়ের পার্থক্য।

বড় দলের জন্য স্ট্রিমিং দেখা দেয় যে মুহূর্তে বিলম্ব ব্যবসার কাছে গুরুত্বপূর্ণ হতে শুরু করে। এক ঘণ্টা দেরিতে আসা প্রতারণা সিদ্ধান্ত মূল্যহীন। আগামীকাল পৌঁছানো ব্যক্তিগতকরণ সংকেত কিছুই ব্যক্তিগত করে না। এক শিফট পিছিয়ে থাকা পরিচালনগত ড্যাশবোর্ড যারা দেখছে তাদের বিভ্রান্ত করে। অধ্যায় 7.2 (ডেটা প্রকৌশল) যুক্তি দেয় ডিফল্টে ব্যাচ বাছুন এবং বিলম্ব সত্যিই মূল্য দেয় কেবল সেখানেই স্ট্রিমিংয়ের দিকে হাত বাড়ান, এবং এই অধ্যায় আপনাকে বাকি পথ নিয়ে যায়: কখন রিয়েল-টাইম তার খরচ অর্জন করে, এবং পরিচালনা বাজেটে আগুন না ধরিয়ে কীভাবে তা গড়বেন। স্ট্রিমিং অধ্যায় 3.12 (ইভেন্ট-চালিত স্থাপত্য ও মেসেজিং)-এর ইভেন্ট-চালিত মেসেজিং প্যাটার্ন, অধ্যায় 3.4 (ডেটা স্থাপত্য ও সংরক্ষণ)-এর সংরক্ষণ পছন্দ এবং অধ্যায় 9.2 (পর্যবেক্ষণযোগ্যতা ও টেলিমেট্রি)-র টেলিমেট্রি চর্চার কাছাকাছি বসে।

এন্টারপ্রাইজ ও সরকারি পরিবেশ ঝুঁকি বাড়ায়। একটি ব্যাংক কার্ড রিডারের পলক ফেলার সময়ে লেনদেনের প্রতারণা স্কোর করে। একটি পরিবহন সংস্থা লক্ষ লক্ষ যাত্রীর জন্য যান ট্র্যাক করে ও পৌঁছানোর সময় পূর্বাভাস দেয়। একটি সুবিধা সংস্থা প্রতিটি সিদ্ধান্তের নিরীক্ষণযোগ্য রেকর্ড রেখে দাবির অসঙ্গতির দিকে নজর রাখে। এই সবকিছুতে মূল্য আসে ডেটা তাজা থাকতে তার ওপর কাজ করা থেকে, এবং ঝুঁকি আসে ভুল, অসম্পূর্ণ বা পরে পুনর্গঠন অসম্ভব ডেটার ওপর কাজ করা থেকে। এই অধ্যায় দুটি নিয়েই স্পষ্টমত।

মূল নীতিসমূহ

• কেবল যখন বিলম্বের স্পষ্ট ব্যবসায়িক মূল্য আছে তখনই স্ট্রিমিংয়ের দিকে হাত বাড়ান; ব্যাচ সস্তা ও সরলতর।
• সীমাবদ্ধ (সসীম) ডেটা ও অসীম (কখনো-শেষ-না-হওয়া) ডেটা আলাদা করুন, এবং সেভাবে নকশা করুন।
• আগমন সময় নয়, ইভেন্ট সময়কে সত্যের উৎস গণ্য করুন, এবং দেরিতে আসা ও ক্রমহীন ডেটার পরিকল্পনা করুন।
• অসীম প্রবাহ থেকে সসীম উত্তর পাওয়ার উপায় উইন্ডো ও ওয়াটারমার্ক।
• ভঙ্গুর ঠিক-একবার প্রতিশ্রুতির বদলে অভিন্ন সিঙ্কের মাধ্যমে কার্যত-একবার ফল পছন্দ করুন।
• অবস্থাবান প্রক্রিয়াকরণে চেকপয়েন্টিং লাগে যাতে তা হারানো বা দ্বিগুণ গণনা ছাড়াই পুনরুদ্ধার করতে পারে।
• ব্যাকপ্রেশার ও পুনঃপ্রক্রিয়ার জন্য প্রথম দিন থেকে নকশা করুন, পরে ভাবনা হিসেবে নয়।
• স্ট্রিমিং যুক্তি পর্যবেক্ষণযোগ্য ও নিরীক্ষণযোগ্য রাখুন; একটি নীরব স্ট্রিম একটি ব্যর্থ ব্যাচের চেয়ে খারাপ।

সুপারিশ

গড়ার আগে রিয়েল-টাইম যথার্থ করুন

সবচেয়ে গুরুত্বপূর্ণ স্ট্রিমিং সিদ্ধান্ত হলো স্ট্রিম করবেন কি না। রিয়েল-টাইম আপনার পরিচালনগত জটিলতা ও খরচ প্রায় দ্বিগুণ করে, কারণ আপনি চলে-থামে এমন একটি কাজ বদলে এমন একটি সিস্টেম নেন যা প্রতি সেকেন্ডে সুস্থ থাকতে হবে। প্রতিশ্রুতির আগে নাম দিন তাজা ডেটা কোন সিদ্ধান্ত সম্ভব করে এবং সেই সিদ্ধান্ত দেরিতে এলে খরচ কত। প্রতারণা স্কোরিং, পরিচালনগত সতর্কতা এবং জীবন্ত ব্যক্তিগতকরণ সাধারণত মান পেরোয়। যে ড্যাশবোর্ড একজন মানুষ দিনে দুবার দেখে তা প্রায় কখনো পেরোয় না, পরিকল্পনা বৈঠকে “রিয়েল-টাইম” শুনতে যতই তৃপ্তিদায়ক লাগুক। বিলম্ব প্রয়োজন সংখ্যা হিসেবে লিখে রাখুন, সেকেন্ড বা মিনিটে, এবং বাস্তবের সঙ্গে মেলান। মানুষ যাকে রিয়েল-টাইম বলে তার বেশিরভাগ কয়েক মিনিট পরপর চলা মাইক্রো-ব্যাচ দিয়ে খরচের ভগ্নাংশে ভালোভাবে মেটে।

প্রক্রিয়াকরণ সময় নয়, ইভেন্ট সময় ঘিরে নকশা করুন

স্ট্রিমিংয়ের সবচেয়ে কঠিন একক ধারণা হলো ইভেন্ট একটি মুহূর্তে ঘটে আর প্রক্রিয়া হয় অন্য মুহূর্তে। ইভেন্ট সময় হলো যখন জিনিসটি আসলে ঘটেছিল, উদাহরণস্বরূপ একজন যাত্রী যখন কার্ড ট্যাপ করেছিলেন। প্রক্রিয়াকরণ সময় হলো যখন আপনার সিস্টেম তা সামলাতে পৌঁছেছিল। এরা ক্রমাগত আলাদা হয়ে যায়: একটি ফোন সুড়ঙ্গে সংকেত হারায় এবং তিন মিনিটের ট্যাপ একসঙ্গে আপলোড করে, একটি নেটওয়ার্ক বিঘ্ন বার্তা ক্রম বদলায়, একটি পার্টিশন পিছিয়ে পড়ে। আপনি প্রক্রিয়াকরণ সময়ে গণনা করলে আপনার সংখ্যা বিশ্বকে প্রতিফলিত করার বদলে আপনার অবকাঠামোর সঙ্গে দোলে। এই দেরিতে আসা ও ক্রমহীন সমস্যা শৃঙ্খলার হৃদয়, এবং এটি ইভেন্ট-চালিত স্থাপত্য-এর ইভেন্ট মডেলিংয়ের সঙ্গে সরাসরি যুক্ত। উৎসে প্রতিটি ইভেন্টে তার ইভেন্ট সময় ছাপ দিন, সেই টাইমস্ট্যাম্প পুরো পাইপলাইন জুড়ে বহন করুন, এবং তার বিপরীতে আপনার ফল গণনা করুন।

সসীম উত্তর পেতে উইন্ডো ও ওয়াটারমার্ক ব্যবহার করুন

একটি অসীম স্ট্রিম কখনো শেষ হয় না, তাই “ইভেন্ট গোনো”-র কোনো উত্তর নেই যতক্ষণ না আপনি তা সীমাবদ্ধ করেন। উইন্ডো সেই সীমাবদ্ধকরণ করে। টাম্বলিং উইন্ডো সময়কে নির্দিষ্ট, অ-অধিক্রমী বালতিতে কাটে, যেমন প্রতি মিনিটে। স্লাইডিং উইন্ডো অধিক্রমী, তাই প্রতি মিনিটে এগোনো পাঁচ-মিনিটের উইন্ডো আপনাকে একটি মসৃণ চলমান সংখ্যা দেয়। সেশন উইন্ডো নিষ্ক্রিয়তার ফাঁক দ্বারা আলাদা কার্যকলাপের ঝাঁক জড়ো করে, যা ব্যবহারকারী সেশনে ভালো মানায়। উইন্ডো পেয়ে গেলে আপনাকে ঠিক করতে হবে একটি উইন্ডো কখন শেষ, কারণ দেরিতে ডেটা এখনো আসতে পারে। ওয়াটারমার্ক হলো সিস্টেমের অনুমান যে সে সম্ভবত একটি নির্দিষ্ট ইভেন্ট সময় পর্যন্ত সব ইভেন্ট দেখেছে। ওয়াটারমার্ক একটি উইন্ডোর শেষ ছাড়ালে আপনি ফল নির্গত করেন। কতক্ষণ অপেক্ষা করবেন তা বাঁধুন: উইন্ডো বেশি সময় খোলা রাখলে আপনি বিলম্ব ও মেমরির খরচে বেশি দেরি সহ্য করেন, দ্রুত বন্ধ করলে পিছিয়ে থাকাদের হারানোর ঝুঁকি। উইন্ডো বন্ধ হওয়ার পরে আসা ডেটার কী হবে তা স্পষ্টভাবে ঠিক করুন, ফেলে দেবেন, লগ করবেন, নাকি একটি সংশোধন নির্গত করবেন।

সিঙ্ক অভিন্ন করুন এবং কার্যত-একবার পছন্দ করুন

ডেলিভারি গ্যারান্টি সরল শোনায় এবং তা নয়। অন্তত-একবার ডেলিভারি মানে প্রতিটি ইভেন্ট প্রক্রিয়া হয়, কিন্তু কিছু পুনঃচেষ্টার পরে একাধিকবার প্রক্রিয়া হতে পারে, তাই গণনা ফুলতে পারে। ঠিক-একবার আদর্শ শোনায় কিন্তু ব্যয়বহুল এবং আক্ষরিকভাবে যেকোনো বাহ্যিক সিস্টেম জুড়ে প্রায়ই অসম্ভব। বাস্তব লক্ষ্য কার্যত-একবার: পর্যবেক্ষণযোগ্য ফল যেন প্রতিটি ইভেন্ট একবার প্রক্রিয়া হয়েছে, নিচে যন্ত্র পুনঃচেষ্টা করলেও। আপনি সেখানে পৌঁছান আপনার অভিন্ন সিঙ্ক বারবার লিখতে নিরাপদ করে, নির্ধারণবাদী কী ও আপসার্ট ব্যবহার করে যাতে একটি পুনঃচালিত ইভেন্ট নকল করার বদলে ওভাররাইট করে। অন্তত-একবার ডেলিভারি অভিন্ন লেখার সঙ্গে মেলান এবং আপনি সর্বত্র ভারী লেনদেনমূলক সমন্বয়ের দাম না দিয়ে সঠিক ফল পান। প্রকৃত ঠিক-একবার যন্ত্র সংরক্ষণ করুন সেই সংকীর্ণ জায়গার জন্য যেখানে সত্যিই দরকার।

অবস্থাবান প্রক্রিয়াকরণ চেকপয়েন্ট করুন যাতে পুনরুদ্ধার করা যায়

অনেক দরকারি স্ট্রিমিং গণনা অবস্থাবান: চলমান গণনা, স্ট্রিম জুড়ে জোড়া, ডিডুপ্লিকেশন, সাম্প্রতিক আচরণ মনে রাখা প্রতারণা মডেল। সেই অবস্থা মেমরিতে থাকে এবং একটি প্রক্রিয়া পুনরায় শুরু হলে উধাও হবে। চেকপয়েন্টিং পর্যায়ক্রমে অবস্থা ও স্ট্রিম অবস্থান একসঙ্গে স্ন্যাপশট নেয়, যাতে ক্র্যাশের পরে সিস্টেম সবকিছু পুনরায় চালানো বা স্মৃতি হারানোর বদলে একটি সামঞ্জস্যপূর্ণ বিন্দু থেকে পুনরায় শুরু করে। আপনার অবস্থা সুচিন্তিতভাবে আকার দিন, কারণ সীমাহীন অবস্থা প্রোডাকশনে একটি স্ট্রিমিং কাজকে মেমরি-শেষ করার সাধারণ উপায়। আর দরকার নেই এমন অবস্থায় মেয়াদোত্তীর্ণ ও টাইম-টু-লিভ ব্যবহার করুন, এবং অবস্থা আকার প্রথম-শ্রেণির মেট্রিক হিসেবে পর্যবেক্ষণ করুন। ব্যর্থতার পরে পুনরুদ্ধার সময় একটি প্রকৃত সেবা-স্তরের উদ্বেগ, তাই আপনার ব্যবহারকারীরা করার আগে তা পরীক্ষা করুন।

চেঞ্জ ডেটা ক্যাপচারে পরিচালনগত ডেটাবেস থেকে স্ট্রিম করুন

আপনি প্রায়ই এমন একটি ডেটাবেসের পরিবর্তনে প্রতিক্রিয়া দেখাতে চান যা ইভেন্ট নির্গত করার জন্য নকশা করা হয়নি। চেঞ্জ ডেটা ক্যাপচার (CDC) এটি সমাধান করে ডেটাবেসের লেনদেন লগ পড়ে এবং প্রতিটি সন্নিবেশ, হালনাগাদ ও মুছে ফেলাকে পরিবর্তন ইভেন্টের স্ট্রিমে পরিণত করে। এটি একটি টাইমারে টেবিল পোল করার চেয়ে অনেক ভালো, যা ধীর, মাঝের অবস্থা মিস করে এবং উৎসকে পেটায়। CDC আপনাকে একটি সার্চ ইনডেক্স, একটি ক্যাশ, একটি বিশ্লেষণ স্টোর বা একটি নিম্নধারা সেবা নিরন্তর রেকর্ড-সিস্টেমের সঙ্গে সিঙ্কে রাখতে দেয়, এবং অ্যাপ্লিকেশনে আক্রমণাত্মক পরিবর্তন ছাড়াই তা করে। পরিবর্তন স্ট্রিমকে প্রথম-শ্রেণির ডেটা পণ্য গণ্য করুন: এর স্কিমা সংস্করণ করুন, অর্থ নথিবদ্ধ করুন, এবং এর বিলম্ব নজরে রাখুন, কারণ নিম্নধারা সবকিছু সেই বিলম্ব উত্তরাধিকার পায়।

দুটি কোডবেস রক্ষণাবেক্ষণের বদলে স্ট্রিমিং-প্রথম স্থাপত্য পছন্দ করুন

ক্লাসিক ল্যাম্বডা স্থাপত্য নির্ভুল, সম্পূর্ণ ইতিহাসের জন্য একটি ব্যাচ স্তর তাজা, আনুমানিক ফলের জন্য একটি স্পিড স্তরের পাশাপাশি চালায়, তারপর দুটি মেলায়। এটি কাজ করে, কিন্তু এটি আপনাকে একই ব্যবসায়িক যুক্তি দুটি সিস্টেমে দুবার লিখতে ও রক্ষণাবেক্ষণ করতে এবং চিরকাল পার্থক্য মেলাতে বাধ্য করে। কাপ্পা স্থাপত্য এটি ভেঙে দেয়: ইভেন্টের একটি টেকসই, পুনঃচালনযোগ্য লগ রাখুন এবং সব প্রক্রিয়াকরণ স্ট্রিম প্রক্রিয়াকরণ হিসেবে চালান, যুক্তি বদলালে লগ পুনরায় চালিয়ে ইতিহাস পুনঃপ্রক্রিয়া করে। শিল্প এই স্ট্রিমিং-প্রথম আকারের দিকে সরেছে কারণ একটি একক কোডবেস রক্ষণাবেক্ষণ ও যুক্তি করা নাটকীয়ভাবে সস্তা। আপনি যদি আপনার ব্যাচ প্রয়োজন একটি ধরে-রাখা ইভেন্ট লগের ওপর পুনঃচালনা হিসেবে প্রকাশ করতে পারেন, আপনি দুই-কোডবেস কর সম্পূর্ণ এড়ান। ইতিহাস ধরে রাখা লগ-ভিত্তিক ব্রোকার ব্যবহার করুন যাতে পুনঃপ্রক্রিয়া পুনর্নির্মাণ নয়, রিওয়াইন্ডের বিষয়।

স্ট্রিমকে SQL, ম্যাটেরিয়ালাইজড ভিউ ও রিয়েল-টাইম OLAP হিসেবে উন্মুক্ত করুন

স্ট্রিমিং দরকার এমন প্রত্যেককে নিম্ন-স্তরের স্ট্রিম প্রক্রিয়াকরণ কোড লিখতে হওয়া উচিত নয়। স্ট্রিমিং SQL বিশ্লেষক ও ইঞ্জিনিয়ারদের তাদের ইতিমধ্যে জানা ভাষায় উইন্ডো, জোড়া ও সমষ্টি প্রকাশ করতে দেয়, এবং ফল ম্যাটেরিয়ালাইজড ভিউ হিসেবে নিরন্তর হালনাগাদ রাখে। তাজা ডেটার ওপর কম-বিলম্ব বিশ্লেষণাত্মক কোয়েরির জন্য একটি রিয়েল-টাইম অনলাইন বিশ্লেষণাত্মক প্রক্রিয়াকরণ (OLAP) স্টোর স্ট্রিম গ্রহণ করে এবং মিলিসেকেন্ডে স্লাইস-অ্যান্ড-ডাইস কোয়েরির উত্তর দেয়, যা একটি সত্যিকারের জীবন্ত পরিচালনগত ড্যাশবোর্ডকে শক্তি দেয়। লক্ষ্য যখন ফিচার ও পরীক্ষায় দ্রুত প্রতিক্রিয়া, এগুলো অধ্যায় 7.4 (পণ্য বিশ্লেষণ ও পরীক্ষা)-র পণ্য বিশ্লেষণ চর্চার সঙ্গে জুড়ুন। যেখানে এই উচ্চতর-স্তরের টুল মানায় সেখানে ব্যবহার করুন, এবং হাতে-লেখা স্ট্রিম প্রসেসর সংরক্ষণ করুন সেই যুক্তির জন্য যা তারা প্রকাশ করতে পারে না।

প্রথম থেকে ব্যাকপ্রেশার ও পুনঃপ্রক্রিয়ার পরিকল্পনা করুন

একটি স্ট্রিম আপনার প্রক্রিয়া করার চেয়ে দ্রুত আসতে পারে। ব্যাকপ্রেশার হলো সেই যন্ত্র যা একটি ধীর ভোক্তাকে ভেঙে পড়া বা নীরবে ডেটা ফেলার বদলে উজানকে ধীর হতে সংকেত দিতে দেয়। নিশ্চিত করুন আপনার পাইপলাইনের প্রতিটি ধাপ তা মানে, এবং ভোক্তা বিলম্ব শিরোনাম মেট্রিক হিসেবে পর্যবেক্ষণ করুন, কারণ বাড়তে থাকা বিলম্ব আপনি দৌড়ে হারছেন তার প্রথম সতর্কতা। পুনঃপ্রক্রিয়া অন্য সামর্থ্য যা মানুষ গাঁথা থাকলে ভালো হতো বলে ভাবে। যখন আপনি একটি বাগ পান বা একটি নিয়ম বদলান, আপনি সংশোধিত যুক্তির মধ্য দিয়ে ইতিহাস পুনরায় চালাতে চান। এটি সম্ভব কেবল যদি আপনার ইভেন্ট লগ যথেষ্ট ইতিহাস ধরে রাখে এবং আপনার সিঙ্ক পুনঃচালনা শুষে নেওয়ার মতো যথেষ্ট অভিন্ন হয়। দুটোই প্রথম দিন থেকে নকশায় গাঁথুন; ঘটনার চাপের মধ্যে সংযোজন করা দুর্বিষহ।

ট্রেড-অফ: সুবিধা ও অসুবিধা

পছন্দ	সুবিধা	অসুবিধা	সবচেয়ে ভালো মানায়
ব্যাচ	সরল, সস্তা, পরীক্ষা ও ব্যাকফিল সহজ	উচ্চ বিলম্ব, চালনার মাঝে বাসি	প্রতিবেদন, বেশিরভাগ বিশ্লেষণ
মাইক্রো-ব্যাচ (মিনিট)	প্রায়-রিয়েল-টাইম, স্ট্রিমিংয়ের চেয়ে অনেক সরল	সত্যিই তাৎক্ষণিক নয়	“রিয়েল-টাইম” ড্যাশবোর্ড
প্রকৃত স্ট্রিমিং (সাব-সেকেন্ড)	তাৎক্ষণিক প্রতিক্রিয়া, নিরন্তর ফল	জটিল, ব্যয়বহুল, পরীক্ষা কঠিন	প্রতারণা, সতর্কতা, জীবন্ত ব্যক্তিগতকরণ
অন্তত-একবার + অভিন্ন সিঙ্ক	সঠিক ফল, সাশ্রয়ী, স্থিতিস্থাপক	শৃঙ্খলাবদ্ধ কী নকশা লাগে	বেশিরভাগ স্ট্রিমিং পাইপলাইন
ঠিক-একবার যন্ত্র	শুরু-থেকে-শেষ শক্তিশালী গ্যারান্টি	ব্যয়বহুল, সিস্টেম জুড়ে সীমিত	সংকীর্ণ উচ্চ-ঝুঁকির পথ
ল্যাম্বডা (ব্যাচ + স্পিড)	নির্ভুল ইতিহাস ও তাজা দৃশ্য	রক্ষণাবেক্ষণের দুটি কোডবেস	লেগেসি মাইগ্রেশন
কাপ্পা (স্ট্রিমিং-প্রথম)	একটি কোডবেস, পুনঃচালনযোগ্য	ধরে-রাখা, টেকসই লগ লাগে	নতুন স্ট্রিমিং প্ল্যাটফর্ম

কেন্দ্রীয় টানাপোড়েন বিলম্ব বনাম জটিলতা। রিয়েল-টাইমের দিকে প্রতিটি পদক্ষেপ আপনার পরিচালনগত বোঝা, পরীক্ষা কঠিনতা ও অর্থে খরচ করে, এবং প্রতিদান রৈখিক নয়: দৈনিক থেকে প্রতি-কয়েক-মিনিটে যাওয়া সস্তা এবং প্রায়ই যথেষ্ট, যখন মিনিট থেকে সাব-সেকেন্ডে যাওয়ায় খরচ কেন্দ্রীভূত হয়। প্রযুক্তির নয়, সিদ্ধান্তের দাম কষে টানাপোড়েন সমাধান করুন। জিজ্ঞেস করুন তাজা ডেটা কোন কাজ সম্ভব করে এবং দেরির খরচ কত, তারপর সেই কাজ যতটা বিলম্ব হ্রাস যথার্থ করে ততটাই কিনুন। যখন স্ট্রিমিং দরকার, অভিন্ন সিঙ্ক ও স্ট্রিমিং-প্রথম লগসহ অন্তত-একবার ডেলিভারির ওপর ঝুঁকুন, কারণ সেই সংমিশ্রণ আপনাকে সবচেয়ে ভারী গ্যারান্টি ছাড়াই সঠিকতা ও পুনঃচালনযোগ্যতা দেয়।

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

1. রিয়েল-টাইম ডেটা আমাদের জন্য আসলে কোন সিদ্ধান্ত সম্ভব করে, এবং সেই ডেটা তাৎক্ষণিকভাবে নয়, এক মিনিট দেরিতে এলে খরচ কত? এটি সেই প্রশ্ন যা প্রতিটি স্ট্রিমিং প্রকল্পের গেট হওয়া উচিত, কারণ স্ট্রিমিং ব্যাচের তুলনায় আপনার পরিচালনগত খরচ ও জটিলতা প্রায় দ্বিগুণ করে। একটি বড় দল ত্রৈমাসিকের পর ত্রৈমাসিক এমন রিয়েল-টাইম প্ল্যাটফর্ম গড়ে পুড়িয়ে দিতে পারে যা এমন ড্যাশবোর্ড সেবা দেয় যা মানুষ দিনে দুবার দেখে, যা আগুনে ছুঁড়ে দেওয়া অর্থ। ডেটা যে সুনির্দিষ্ট কাজ চালায় তা আনুন, সেটি একটি প্রতারণামূলক লেনদেন আটকানো, একজন অপারেটরকে পেজ করা, বা একজন ব্যবহারকারী কী দেখে তা বদলানো যা-ই হোক, এবং প্রতিটির জন্য বিলম্বের খরচের একটি সংখ্যা বসান। সৎ উত্তর যদি হয় পাঁচ-মিনিটের মাইক্রো-ব্যাচ প্রয়োজন মেটাত, সেটি উদযাপনের যোগ্য আবিষ্কার, লুকানোর নয়। উত্তর সরাসরি বদলে দেবে আপনি প্রকৃত স্ট্রিমিং গড়বেন, মাইক্রো-ব্যাচে থামবেন, নাকি ব্যাচে থাকবেন।

2. আমরা দেরিতে ও ক্রমহীন ইভেন্ট কীভাবে সামলাই, এবং একটি উইন্ডো বন্ধ হওয়ার পরে আসা ডেটার কী হয়? দেরিতে ও ক্রমহীন ডেটা স্ট্রিমিংয়ের কঠিন অংশ, এবং যে দল এই প্রশ্ন এড়ায় তারা প্রোডাকশনে তা আবিষ্কার করে যখন তাদের সংখ্যা মিলতে অস্বীকার করে। প্রতিদ্বন্দ্বী চাপ বিলম্ব ও সঠিকতা: পিছিয়ে থাকাদের ধরতে উইন্ডো বেশি সময় খোলা রাখলে আপনি প্রতিটি ফল দেরি করান ও বেশি মেমরি খরচ করেন, দ্রুত বন্ধ করলে নীরবে প্রকৃত ডেটা ফেলে দেন। আপনার ডেটা আসলে কত দেরিতে আসে তার প্রমাণ আনুন, আপনার উৎস জুড়ে ইভেন্ট সময় ও প্রক্রিয়াকরণ সময়ের ফাঁক হিসেবে মাপা, কারণ সুড়ঙ্গে থাকা একটি মোবাইল উৎস একটি সার্ভার-পাশের ইভেন্ট থেকে খুব আলাদা আচরণ করে। সুস্পষ্টভাবে ঠিক করুন দেরিতে ডেটা ফেলা হবে, লগ করা হবে, নাকি একটি সংশোধন ট্রিগার করবে, এবং নিশ্চিত করুন নিম্নধারায় সবাই জানে কোনটি। একটি সরকারি প্রেক্ষাপটে যেখানে সংখ্যা রক্ষণযোগ্য হতে হবে, নীরবে দেরিতে ইভেন্ট ফেলা একটি সম্মতি সমস্যা হতে পারে, তাই নীতি হতে হবে সুচিন্তিত ও নথিবদ্ধ।

3. আমাদের সিঙ্ক কি ইতিহাস নিরাপদে পুনরায় চালানোর মতো যথেষ্ট অভিন্ন, এবং আমাদের ইভেন্ট লগ কি পুনঃচালনা সম্ভব করার মতো যথেষ্ট ধরে রাখে? পুনঃপ্রক্রিয়া সেই সামর্থ্য যা দল সবচেয়ে বেশি চেয়েছে গাঁথা থাকলে ভালো হতো এবং সবচেয়ে বেশি গাঁথেনি, এবং তা একসঙ্গে কাজ করা দুটি জিনিসের ওপর নির্ভর করে: নকল না করে পুনঃচালিত ইভেন্ট শুষে নেওয়া অভিন্ন সিঙ্ক, এবং পুনঃচালনার জন্য যথেষ্ট ইতিহাস ধরে রাখা একটি টেকসই লগ। দুটি ছাড়া একটি যুক্তি বাগ সারানো মানে আপনি আক্রান্ত সময়কাল পরিষ্কারভাবে পুনঃগণনা করতে পারেন না, এবং চাপের মধ্যে হাতে সংখ্যা তালি দিতে আটকে থাকেন। আপনার বর্তমান ধারণ জানালা এবং একটি সুনির্দিষ্ট পরীক্ষা আনুন: গত ত্রৈমাসিকের একটি প্রকৃত বাগ বাছুন এবং জিজ্ঞেস করুন আক্রান্ত ডেটার ওপর সংশোধিত যুক্তি পুনরায় চালানো যেত কি না। এর বিপরীতে টান খরচ, কারণ ইতিহাস ধরে রাখা এবং অভিন্ন লেখা নকশা করা অগ্রিম সংরক্ষণ ও শৃঙ্খলা লাগে। কিন্তু বিকল্পটি সবচেয়ে খারাপ মুহূর্তে, একটি ঘটনার সময়, উঠে আসে, তাই উত্তর আকার দেয় আপনার দরকার হওয়ার আগে পুনঃচালনযোগ্যতায় কতটা বিনিয়োগ করবেন।

4. একটি স্ট্রিমিং কাজ ক্র্যাশ করলে কত দ্রুত পুনরুদ্ধার করতে হবে, কতটা অবস্থা ধরে রাখার অনুমতি আছে, এবং আমরা কি প্রোডাকশন লোডে আসলে একটি পুনরুদ্ধার সময় মেপেছি? একটি ব্যাচ কাজ মরলে আগামীকাল পুনরায় চালানো যায়, কিন্তু একটি সর্বদা-চালু স্ট্রিম মরলে তা চলমান বিভ্রাট, এবং চলমান গণনা, জোড়া বা প্রতারণা মডেল ধরে রাখা অবস্থাবান কাজ পুনরায় চালুর পরে মিনিটের স্মৃতি হারাতে পারে বা অবস্থা পুনরায় লোড করতে দীর্ঘ সময় নিতে পারে। একটি বড় দলের জন্য এটি সেই অগ্লামারাস খুঁটিনাটি যা নীরবে আপনার প্রকৃত প্রাপ্যতা ঠিক করে: সীমাহীন অবস্থা বাড়তে থাকে যতক্ষণ না একটি কাজ মেমরি শেষ করে, এবং ধীর চেকপয়েন্ট পুনরুদ্ধার দশ-সেকেন্ডের ঝলককে দশ-মিনিটের করে তোলে। প্রতিদ্বন্দ্বী চাপ সতেজতা বনাম নিরাপত্তা, কারণ আরও ঘন ঘন চেকপয়েন্ট পুনরুদ্ধার ছোট করে কিন্তু ওভারহেড যোগ করে, এবং উদার অবস্থা ধারণ নির্ভুলতা বাড়ায় কিন্তু মেমরি নিঃশেষের ঝুঁকি আনে। একটি সুনির্দিষ্ট পুনরুদ্ধার সময় উদ্দেশ্য, আপনার বর্তমান অবস্থা আকার ও তার বৃদ্ধি বক্ররেখা, আপনার চেকপয়েন্ট ব্যবধান এবং আশাবাদী অনুমানের বদলে একটি প্রকৃত ফেইলওভার ড্রিলের ফল আনুন। এন্টারপ্রাইজ ও সরকারি পরিবেশে যেখানে স্ট্রিম প্রতারণা স্কোরিং বা জননিরাপত্তা ফিডকে সমর্থন করে, একটি অপরীক্ষিত পুনরুদ্ধার পথ এমন পরিচালনগত ঝুঁকি যা আপনি না মেপে গ্রহণ করেছেন, তাই ড্রিলকে থাকলে-ভালো নয়, প্রয়োজন গণ্য করুন।

5. আমরা কি একটি স্ট্রিমিং-প্রথম কোডবেস চালাই নাকি আলাদা ব্যাচ স্তর ও স্পিড স্তর, এবং দুটি মেলানো রাখতে আমাদের আসলে কত খরচ হয়? সঠিক ইতিহাসের জন্য ব্যাচ স্তর ও তাজা ফলের জন্য স্পিড স্তরের ল্যাম্বডা প্যাটার্ন আপনাকে একই ব্যবসায়িক যুক্তি দুটি সিস্টেমে দুবার লিখতে এবং চিরকাল তাদের উত্তর মেলাতে বাধ্য করে, যেখানে একটি স্ট্রিমিং-প্রথম (কাপ্পা) আকার একটি টেকসই, পুনঃচালনযোগ্য লগ রাখে এবং সব প্রক্রিয়াকরণ স্ট্রিম প্রক্রিয়াকরণ হিসেবে চালায়। একটি বড় প্রতিষ্ঠানের জন্য নকল যুক্তি সেই জায়গা যেখানে ড্রিফট ও বিতর্কিত সংখ্যা জন্মায়, কারণ একটি নিয়ম এক স্তরে বদলায় আর অন্যটিতে নয়, এবং ইঞ্জিনিয়াররা দুটি কেন মেলে না তা ব্যাখ্যা করতে প্রকৃত সময় ব্যয় করে। দুটি রাখার দিকে টান জড়তা ও একটি প্রমাণিত ব্যাচ স্তরের আরাম, তাই সততার সঙ্গে রক্ষণাবেক্ষণ করের বিপরীতে তা ওজন করুন। আপনি বর্তমানে উভয় জায়গায় চালান এমন গণনার তালিকা, দুই স্তরের অমিলে সৃষ্ট ঘটনা, এবং আপনার ইভেন্ট লগ ব্যাচ প্রয়োজন পুনঃচালনা হিসেবে প্রকাশ করার মতো যথেষ্ট ইতিহাস ধরে রাখে কি না তার মূল্যায়ন আনুন। সরকারি ও নিরীক্ষিত এন্টারপ্রাইজ প্রেক্ষাপটে একই সময়কালের জন্য ভিন্ন সংখ্যা জানাতে পারে এমন দুটি স্তর নিজেই একটি সম্মতি দায়, কারণ আপনাকে বলতে পারতে হবে কোন সংখ্যা কর্তৃত্বপূর্ণ এবং কেন।

6. এই সর্বদা-চালু সিস্টেম রাত তিনটায় ভাঙলে কে তা পরিচালনা করে, এবং আমরা কি অন-কল বোঝা ও এর দাবি করা বিশেষজ্ঞ দক্ষতার বাজেট করেছি, নাকি ব্যাচ-আকারের কর্মী ধরে নিচ্ছি? স্ট্রিমিং খরচ গড়া থেকে চালানোর দিকে সরায়: সিস্টেম প্রতি সেকেন্ডে সুস্থ থাকতে হবে, যার মানে প্রকৃত অন-কল কভারেজ, ইভেন্ট সময়, ওয়াটারমার্ক, অবস্থা ও ডেলিভারি শব্দার্থিকতায় দক্ষ ইঞ্জিনিয়ার, এবং চলে-থামে এমন একটি কাজের চেয়ে কঠিনতর পরীক্ষা। দল নিয়মিত একটি স্ট্রিমিং প্ল্যাটফর্ম তার সামর্থ্যের জোরে অনুমোদন করে এবং যারা এটি বাঁচিয়ে রাখে তাদের অর্থায়ন করে না, তাই প্ল্যাটফর্ম ক্ষয়ে যায় ও আস্থা ক্ষীণ হয়। ট্রেড-অফ পরিসর বনাম টেকসইতা: প্রতিটি অতিরিক্ত রিয়েল-টাইম পাইপলাইন আরেকটি জিনিস যা কাউকে পেজ করতে পারে, তাই প্রশ্ন হলো সে যে বিলম্ব কেনে তা একটি স্থায়ী পরিচালনগত প্রতিশ্রুতি যথার্থ করে কি না। প্রোডাকশনে প্রতিটি স্ট্রিমের মালিক কে তার একটি সৎ তালিকা, আপনার বর্তমান অন-কল ঘূর্ণন ও তার হেডরুম, এবং ইভেন্ট-সময় দক্ষতা আসলে কোথায় আছে, নিয়োগ, অংশীদার বা ম্যানেজড সেবা যা-ই হোক, আনুন। একটি সরকারি সংস্থা বা বড় এন্টারপ্রাইজের জন্য ক্রয় ও নিয়োগ লিড টাইম এবং যেকোনো ম্যানেজড-সেবা বিকল্প যোগ করুন, কারণ একটি রিয়েল-টাইম প্ল্যাটফর্ম যা আপনি নিয়োগ বা ধরে রাখতে পারেন না এমন দুর্লভ প্রতিভার ওপর নির্ভর করে তা বিভ্রাট-প্রবণ সিস্টেম কর্মীসংকটে চালানোর পরিকল্পনা।

খাতভেদে দৃষ্টিভঙ্গি

স্টার্টআপ। স্ট্রিমিং কদাচিৎ আপনার প্রথম পদক্ষেপ, এবং একটি ভারী প্ল্যাটফর্ম দাঁড় করানো একটি ক্ষুদ্র দলকে ডোবাতে পারে। আপনার মূল মূল্য ছোঁয়া একটি সংকেত বাছুন, ইভেন্ট একটি একক ধরে-রাখা লগ-ভিত্তিক ব্রোকারে রাখুন, এবং কী-যুক্ত, অভিন্ন সিঙ্কসহ একটি হালকা প্রসেসর চালান যাতে একটি অন্তত-একবার পুনঃচেষ্টা কখনো দ্বিগুণ গণনা না করে। কয়েক দিনের ইতিহাস রাখুন যাতে সংশোধিত যুক্তির মধ্য দিয়ে পুনরায় চালাতে পারেন, এবং নিজের ক্লাস্টার চালানোর চেয়ে একটি ম্যানেজড স্ট্রিমিং সেবা পছন্দ করুন, কারণ আপনার দুর্লভতম সম্পদ প্রকৌশল মনোযোগ।

ছোট ব্যবসা। আপনার সম্ভবত কোনো স্ট্রিমিং বিশেষজ্ঞ নেই এবং সর্বদা-চালু অবকাঠামো চালানোর আগ্রহ নেই, তাই রিয়েল-টাইমকে আপনি কর্মী দিয়ে চালান এমন সিস্টেমের বদলে ইতিমধ্যে ব্যবহৃত টুলের ভেতরে কেনা জিনিস গণ্য করুন। প্রয়োজনকে একটি সংখ্যা সংযুক্ত বিলম্ব প্রশ্ন হিসেবে ফ্রেম করুন, এবং বেশিরভাগ ক্ষেত্রে প্রতি কয়েক মিনিটে রিফ্রেশ হওয়া একটি মাইক্রো-ব্যাচ খরচ ও ঝুঁকির ভগ্নাংশে তা মেটাবে। এমন বিক্রেতা বাছুন যাদের রিয়েল-টাইম ফিচার বিলম্ব নিয়ে স্বচ্ছ এবং পিছু হটা সহজ, এবং কাস্টম স্ট্রিমিং সংরক্ষণ করুন বিরল ক্ষেত্রের জন্য যেখানে তাজা ডেটা সরাসরি রাজস্ব বা নিরাপত্তা চালায়।

এন্টারপ্রাইজ। সমস্যা অনেক দল জুড়ে সামঞ্জস্য ও খরচ: একটি ভাগ করা লগ-ভিত্তিক প্ল্যাটফর্ম, একটি মানক ইভেন্ট-সময় ও দেরিতে-ডেটা নীতি, এবং অভিন্ন সিঙ্ক যাতে গোষ্ঠীগুলো ভঙ্গুর পাইপলাইন পুনরাবিষ্কার বন্ধ করে। সর্বদা-চালু পরিচালনা ও অন-কল বোঝা স্পষ্টভাবে বাজেট করুন, নকল ব্যাচ কোডবেস এড়াতে একটি স্ট্রিমিং-প্রথম লগে প্রমিত করুন, এবং স্ট্রিমকে বিশেষায়িত কাজের ছড়ানোর বদলে মালিক, স্কিমা সংস্করণ ও পর্যবেক্ষিত বিলম্বসহ শাসিত ডেটা পণ্য হিসেবে পরিচালনা করুন। পোর্টফোলিও মেট্রিক হিসেবে প্রতি স্ট্রিমে বিলম্ব, পুনরুদ্ধার সময় ও খরচ অনুসরণ করুন।

সরকার। নিরীক্ষণযোগ্যতা ও জনগণের কাছে জবাবদিহি প্রতিটি পছন্দ আকার দেয়। প্রতিটি প্রক্রিয়াকৃত ইভেন্ট একটি টেকসই লগে ধরে রাখুন যাতে তদারকি সংস্থাকে জানানো সংখ্যা, যাত্রী সংখ্যা, সুবিধার অসঙ্গতি, প্রতারণা সিদ্ধান্ত, ঠিক পুনর্গঠন করা যায়, এবং ইভেন্ট নীরবে ফেলার বদলে দেরিতে-ডেটা নীতি সুস্পষ্ট ও নথিবদ্ধ করুন। ক্রয়ে ডেটা বহনযোগ্যতা এবং একটি ম্যানেজড সেবার ডেলিভারি ও ধারণ গ্যারান্টির প্রকাশ দাবি করা উচিত, এবং একটি নিয়ম বদলের পরে যেকোনো পুনঃবিবৃতি কেউ ট্রেস করতে পারে না এমন ম্যানুয়াল তালি নয়, সংশোধিত যুক্তির মধ্য দিয়ে রক্ষণযোগ্য পুনঃচালনা হওয়া উচিত।

উদাহরণ

স্টার্টআপ। একটি ভোক্তা অ্যাপ ব্যবহারকারীদের একটি জীবন্ত কার্যকলাপ ফিড দেখাতে এবং সন্দেহজনক লগইন ঘটার সঙ্গে সঙ্গে চিহ্নিত করতে চায়। দলটি একটি ভারী স্ট্রিমিং প্ল্যাটফর্ম দাঁড় করানো প্রতিরোধ করে। তারা ইভেন্ট একটি একক ধরে-রাখা লগ-ভিত্তিক ব্রোকারে রাখে, লগইন-ঝুঁকি যুক্তির জন্য একটি হালকা স্ট্রিম প্রসেসর চালায়, এবং একটি রিয়েল-টাইম OLAP স্টোরে জোগান দেয় যা কার্যকলাপ ফিড চালায়। প্রতিটি সিঙ্ক কী-যুক্ত ও অভিন্ন, তাই একটি অন্তত-একবার পুনঃচেষ্টা কখনো দ্বিগুণ গণনা করে না। পরে ঝুঁকি নিয়মে একটি বাগ পেলে তারা কেবল সংশোধিত যুক্তির মধ্য দিয়ে রাতারাতি লগ পুনরায় চালায়, কারণ তারা এক সপ্তাহের ইতিহাস রেখেছিল এবং কখনো দ্বিতীয় ব্যাচ কোডবেস লাগেনি।

এন্টারপ্রাইজ। একটি খুচরা ব্যাংক প্রতিটি কার্ড লেনদেন অনুমোদন জানালার মধ্যে প্রতারণার জন্য স্কোর করে, জীবন্ত লেনদেন স্ট্রিমকে সাম্প্রতিক অ্যাকাউন্ট আচরণের একটি অবস্থাবান মডেলের বিপরীতে জুড়ে। চেকপয়েন্টিং স্কোরিং সেবাকে শেষ কয়েক মিনিটের স্মৃতি না হারিয়ে সেকেন্ডে একটি নোড ব্যর্থতা থেকে পুনরুদ্ধার করতে দেয়। আলাদাভাবে, চেঞ্জ ডেটা ক্যাপচার মূল ব্যাংকিং ডেটাবেস থেকে হালনাগাদ একটি সার্চ ইনডেক্স ও একটি ব্যক্তিগতকরণ সেবায় স্ট্রিম করে, পোলিং ছাড়াই দুটিকে তাজা রাখে। পরিচালনগত ড্যাশবোর্ড একটি রিয়েল-টাইম OLAP স্টোর থেকে পড়ে যাতে ঝুঁকি ও পরিচালনা দল ব্যবসা সরার সঙ্গে সঙ্গে দেখে, এবং পুরো পাইপলাইন অধ্যায় 9.2-তে বর্ণিত বিলম্ব ও থ্রুপুট টেলিমেট্রি নির্গত করে।

সরকার। একটি মহানগর পরিবহন কর্তৃপক্ষ রিয়েল-টাইমে পৌঁছানো পূর্বাভাস ও ভিড় পর্যবেক্ষণ করতে যানের অবস্থান ও ভাড়া ট্যাপ গ্রহণ করে, জনসাধারণের অ্যাপ ও একটি পরিচালনা কেন্দ্র দুটিতেই জোগান দিয়ে। কারণ সুড়ঙ্গের যাত্রীরা বিলম্বিত ঝাঁকে ট্যাপ আপলোড করে, দলটি পর্যবেক্ষিত দেরির সঙ্গে সুর করা ওয়াটারমার্কসহ ইভেন্ট সময়ে যাত্রী সংখ্যা গণনা করে, এবং উইন্ডো বন্ধ হওয়ার পরে আসা যেকোনো ইভেন্ট নীরবে ফেলার বদলে লগ করে। প্রতিটি প্রক্রিয়াকৃত ইভেন্ট একটি নিরীক্ষণযোগ্য লগে ধরে রাখা হয় যাতে তদারকি সংস্থাকে জানানো যাত্রী সংখ্যা ঠিক পুনর্গঠন করা যায়। একটি ভাড়া নিয়ম বদলালে তারা আক্রান্ত সময়কাল সংশোধিত যুক্তির মধ্য দিয়ে পুনরায় চালায় এবং একটি রক্ষণযোগ্য পুনঃবিবৃতি তৈরি করে।

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

রিয়েল-টাইম ডেটার প্রতিদান আসে কাজ এখনো গুরুত্বপূর্ণ থাকতে তা করা থেকে। অনুমোদনের সময় ধরা প্রতারণা এমন ক্ষতি ঠেকায় যা রাতের ব্যাচ কেবল প্রতিবেদন করত। একটি সেশনের মধ্যে সাড়া দেওয়া ব্যক্তিগতকরণ এমনভাবে রূপান্তর বাড়ায় যা আগামীকালের সুপারিশ পারে না। বর্তমান প্রতিফলিত করা পরিচালনগত মনিটরিং একটি ছোট সমস্যা বিভ্রাট বা জনসাধারণের ঘটনা হওয়ার আগে হস্তক্ষেপ করতে দেয়। প্রতিটি ক্ষেত্রে মূল্য হলো এখন কাজ করা ও পরে কাজ করার মধ্যে ব্যবধান, এবং যুক্তি দেওয়ার সময় আপনার সেটিই পরিমাণ করা উচিত।

মালিকানার মোট খরচ ব্যাচের চেয়ে বেশি, এবং সে বিষয়ে সততা আপনার বিশ্বাসযোগ্যতা রক্ষা করে। আপনি সর্বদা-চালু অবকাঠামোর জন্য, ইভেন্ট সময়, ওয়াটারমার্ক, অবস্থা ও ডেলিভারি শব্দার্থিকতা বোঝা ইঞ্জিনিয়ারদের জন্য, এবং চলে-থামার বদলে নিরন্তর সুস্থ থাকতে হবে এমন সিস্টেমের কঠিনতর পরীক্ষা ও অন-কল বোঝার জন্য দেন। একটি ধরে-রাখা লগে স্ট্রিমিং-প্রথম স্থাপত্য আপনাকে নকল ব্যাচ কোডবেস থেকে রেহাই দিয়ে চলমান খরচ কমায়, এবং অভিন্ন সিঙ্কসহ অন্তত-একবার বাছা শুরু-থেকে-শেষ ঠিক-একবার যন্ত্রের ব্যয় এড়ায়। সবচেয়ে ব্যয়বহুল ভুল হলো যেখানে মাইক্রো-ব্যাচ বা ব্যাচ যথেষ্ট সেখানে রিয়েল-টাইম গড়া, তাই সবচেয়ে শক্ত খরচ যুক্তি প্রায়ই স্ট্রিম না করার সিদ্ধান্ত। নেতৃত্বের কাছে প্রস্তাব নির্দিষ্ট বিলম্ব-সংবেদনশীল সিদ্ধান্ত ও তাদের পরিমাপযোগ্য প্রতিদান ঘিরে ফ্রেম করুন, এবং ব্যাচে থাকা কোথায় মূল্য না হারিয়ে অর্থ বাঁচায় সে বিষয়েও সমান স্পষ্ট হোন।

অ্যান্টি-প্যাটার্ন ও ফাঁদ

• প্রতি কয়েক মিনিটের একটি মাইক্রো-ব্যাচ প্রয়োজন মেটাত তখন মর্যাদার জন্য স্ট্রিমিং গড়া।
• প্রক্রিয়াকরণ সময়ে গণনা করা, ফলে আপনার সংখ্যা বিশ্বের বদলে আপনার অবকাঠামোর সঙ্গে দোলে।
• প্রোডাকশনে মেলানো ব্যর্থ না হওয়া পর্যন্ত দেরিতে ও ক্রমহীন ডেটা উপেক্ষা করা।
• অভিন্ন সিঙ্কসহ অন্তত-একবারের বদলে সর্বত্র আক্ষরিক ঠিক-একবারের পিছনে ছোটা।
• মেয়াদোত্তীর্ণ ছাড়া সীমাহীন অবস্থা, নীরবে বাড়তে থাকে যতক্ষণ না একটি কাজ মেমরি শেষ করে।
• চেকপয়েন্টিং নেই, তাই পুনরায় চালু অবস্থা হারায় বা পূর্ণ পুনঃচালনা বাধ্য করে।
• চেঞ্জ ডেটা ক্যাপচারের বদলে একটি টাইমারে পরিচালনগত ডেটাবেস পোল করা।
• নকল, ড্রিফট করা যুক্তিসহ একটি ল্যাম্বডা ব্যাচ স্তর ও স্পিড স্তর রক্ষণাবেক্ষণ করা।
• বাগ পেলে ইতিহাস পুনঃচালনার জন্য খুব ছোট একটি ধারণ জানালা।
• বিলম্ব, থ্রুপুট বা সতেজতা মেট্রিক ছাড়া স্ট্রিম, নীরবে ব্যর্থ হয়।

পরিপক্বতা মডেল

• স্তর 1, সূচনা: সবকিছু ব্যাচ, অথবা কয়েকটি হাতে-গড়া স্ট্রিমিং কাজ মনিটরিং ছাড়া প্রতিক্রিয়াশীলভাবে চলে। সংখ্যা প্রক্রিয়াকরণ সময়ে গণনা হয়, দেরিতে ডেটা উপেক্ষিত, এবং পুনরায় চালু অবস্থা হারায়। কেউ একটি বাগ সারাতে ইতিহাস পুনরায় চালাতে পারে না, এবং সমস্যা আবিষ্কৃত হয় যখন নিম্নধারা সংখ্যা মিলতে অস্বীকার করে।
• স্তর 2, বিকাশ: কিছু দল একটি লগ-ভিত্তিক ব্রোকারে চেকপয়েন্টিংসহ মূল স্ট্রিমিং পাইপলাইন চালায়, এবং ইভেন্ট সময় ও প্রক্রিয়াকরণ সময় আলাদা করে ও মৌলিক উইন্ডো ব্যবহার করে। চর্চা দল-ধরে-দল অসঙ্গত: ডেলিভারি অন্তত-একবার কিন্তু সব সিঙ্ক অভিন্ন নয়, দেরিতে-ডেটা সামলানো তাৎক্ষণিক, এবং বিলম্ব সতর্কতার বদলে অনানুষ্ঠানিকভাবে দেখা হয়।
• স্তর 3, মানসম্মতকরণ: ইভেন্ট সময়, ওয়াটারমার্ক এবং একটি সুস্পষ্ট দেরিতে-ডেটা নীতি নথিবদ্ধ ও প্রতিষ্ঠান জুড়ে প্রয়োগ করা। কার্যত-একবার ফলের জন্য সিঙ্ক অভিন্ন, অবস্থার মেয়াদোত্তীর্ণ আছে, এবং চেঞ্জ ডেটা ক্যাপচার রীতিতে নিম্নধারা সিস্টেমে জোগান দেয়। একটি ধরে-রাখা লগ পুনঃচালনা সমর্থন করে, এবং বিলম্ব, থ্রুপুট ও সতেজতা প্রতি-দলের অভ্যাসের বদলে প্রতিষ্ঠান-ব্যাপী মান হিসেবে সতর্কতাসহ পর্যবেক্ষিত।
• স্তর 4, ব্যবস্থাপনা: স্ট্রিমিং সম্পত্তি ভিত্তিরেখার বিপরীতে মাপা ও নিয়ন্ত্রিত। প্রতিটি পাইপলাইন শুরু-থেকে-শেষ বিলম্ব, ভোক্তা বিলম্ব, পুনরুদ্ধার সময়, ইভেন্ট-সময় তির্যকতা, দেরিতে-ইভেন্ট হার, অবস্থা আকার এবং প্রতি মিলিয়ন ইভেন্টে খরচের সেবা-স্তরের উদ্দেশ্য বহন করে, সবই সম্মত লক্ষ্যের বিপরীতে অনুসরণ করা এবং রিগ্রেশনে সতর্ক করা। পুনরুদ্ধার ধরে না নিয়ে ড্রিল ও সময় মাপা হয়, ব্যাকপ্রেশার হেডরুম ও অবস্থা বৃদ্ধি ক্ষমতা সংকেত হিসেবে নজরে রাখা হয়, এবং একটি নতুন স্ট্রিমকে প্রোডাকশনে যাওয়ার আগে এই মেট্রিক পেরোতে হয়।
• স্তর 5, সমন্বয়: একটি স্ট্রিমিং-প্রথম স্থাপত্য একটি পুনঃচালনযোগ্য লগ থেকে তাজা ও ঐতিহাসিক দুটি প্রয়োজনই মেটায়, এবং স্ট্রিমিং SQL, ম্যাটেরিয়ালাইজড ভিউ ও রিয়েল-টাইম OLAP তাজা ডেটা ব্যাপকভাবে প্রবেশগম্য করে। পুনঃপ্রক্রিয়া রুটিন ও পরীক্ষিত, প্ল্যাটফর্ম মাপা লোড ও খরচের বিপরীতে অটোস্কেল ও পুনঃভারসাম্য করে, এবং স্ট্রিম প্রমাণের ভিত্তিতে অবসর, পুনঃপরিসরিত বা প্রতিস্থাপিত হয়। স্ট্রিমিং ব্যবসা ও ঝুঁকি পরিকল্পনার সঙ্গে একীভূত, এবং লোড ও খরচ চিত্র সরলে প্রতিটি স্ট্রিম শুরু-থেকে-শেষ পর্যবেক্ষণযোগ্য ও নিরীক্ষণযোগ্য।

আলোচনার ভাবনা

1. আপনার স্ট্যাকের কোথায় “রিয়েল-টাইম” সত্যিই তার খরচ অর্জন করে, এবং কোথায় এটি একটি অপরীক্ষিত ইচ্ছা?
2. আপনার উৎস জুড়ে ইভেন্ট সময় ও প্রক্রিয়াকরণ সময়ের ফাঁক কত বড়, এবং আপনি কি তা মাপেন?
3. আপনি কি একটি ল্যাম্বডা ব্যাচ-ও-স্পিড সেটআপ একটি একক স্ট্রিমিং-প্রথম কোডবেসে ভাঙতে পারেন, এবং কী তা আটকাত?
4. আপনার কোন সিঙ্ক সত্যিই অভিন্ন, এবং আপনি কি আজ গত ত্রৈমাসিকের ডেটা সংশোধিত যুক্তির মধ্য দিয়ে নিরাপদে পুনরায় চালাতে পারেন?
5. একটি উইন্ডো বন্ধ হওয়ার পরে আসা ডেটার জন্য আপনার নীতি কী, এবং নিম্নধারায় সবাই কি তা জানে?
6. চেঞ্জ ডেটা ক্যাপচার কীভাবে সার্চ, ক্যাশ ও বিশ্লেষণ সিঙ্কে রাখার আপনার উপায় বদলাবে?

প্রধান শিক্ষা

• কেবল যখন একটি বিলম্ব-সংবেদনশীল সিদ্ধান্ত মূল্য দেয় তখন স্ট্রিমিংয়ের দিকে হাত বাড়ান; ব্যাচ ও মাইক্রো-ব্যাচ সস্তা ডিফল্ট।
• ইভেন্ট সময়ে গণনা করুন, এবং দেরিতে ও ক্রমহীন ডেটাকে মূল সমস্যা গণ্য করুন, উইন্ডো ও ওয়াটারমার্ক দিয়ে সামলানো।
• সর্বত্র আক্ষরিক ঠিক-একবারের বদলে কার্যত-একবার ফলের জন্য অভিন্ন সিঙ্কসহ অন্তত-একবার ডেলিভারি পছন্দ করুন।
• অবস্থাবান প্রক্রিয়াকরণ চেকপয়েন্ট করুন, আপনার অবস্থা সীমাবদ্ধ করুন, এবং ভোক্তা বিলম্ব শিরোনাম মেট্রিক হিসেবে পর্যবেক্ষণ করুন।
• পোলিংয়ের বদলে পরিচালনগত ডেটাবেস থেকে স্ট্রিম করতে চেঞ্জ ডেটা ক্যাপচার ব্যবহার করুন।
• দুটি কোডবেস রক্ষণাবেক্ষণের বদলে একটি ধরে-রাখা, পুনঃচালনযোগ্য লগে স্ট্রিমিং-প্রথম স্থাপত্য পছন্দ করুন।
• স্ট্রিমিং SQL, ম্যাটেরিয়ালাইজড ভিউ ও রিয়েল-টাইম OLAP-এর মাধ্যমে স্ট্রিম উন্মুক্ত করুন, এবং প্রতিটি স্ট্রিম পর্যবেক্ষণযোগ্য ও নিরীক্ষণযোগ্য রাখুন।

তথ্যসূত্র ও আরও পড়ার জন্য

• Tyler Akidau, Slava Chernyak ও Reuven Lax, “Streaming Systems.”
• Martin Kleppmann, “Designing Data-Intensive Applications.”
• Nathan Marz ও James Warren, “Big Data” (Lambda architecture).
• Jay Kreps, “Questioning the Lambda Architecture” (O’Reilly Radar).
• Fabian Hueske ও 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).