डेटा इंजीनियरिंग इंटरव्यू: आपको बैच, माइक्रो-बैच या स्ट्रीम प्रोसेसिंग का उपयोग कब करना चाहिए?

समस्या और दायरा

एक ई-कॉमर्स प्लेटफ़ॉर्म ऑर्डर इवेंट्स को एक ड्यूरेबल रीप्ले करने योग्य लॉग में लिखता है और अपरिवर्तनीय (immutable) कच्चे डेटा को बनाए रखता है। स्थिर दर अनिर्दिष्ट है; पीक 20,000 इवेंट प्रति सेकंड है, जिसमें कुछ समय के प्रचार-संबंधी बर्स्ट उस दर से दस गुना तक हो सकते हैं। इन्वेंट्री विसंगतियों के लिए इवेंट निर्माण के 10 सेकंड के भीतर अलर्ट की आवश्यकता होती है। ऑपरेशंस डैशबोर्ड को 5 मिनट के भीतर अपडेट होना चाहिए। फाइनेंस टीम अगले दिन खातों को बंद करती है और उसी व्यावसायिक दिन को पुन: चलाने योग्य (rerunnable) और समाधान योग्य (reconcilable) होना आवश्यक है। लगभग 2% इवेंट 6 घंटे तक की देरी से आते हैं।

ये दरें, बर्स्ट मल्टीप्लायर, देरी का प्रतिशत और समय-सीमाएं समस्या से जुड़ी पूर्वधारणाएं (assumptions) हैं, किसी इंजन के बारे में परफ़ॉर्मेंस के दावे नहीं। मान लें कि प्रत्येक इवेंट में एक स्थिर event_id, order_id, event_time और स्कीमा संस्करण है। फाइनेंस एक स्पष्ट समय क्षेत्र (time zone) में व्यावसायिक दिन का उपयोग करता है। चार लोगों की डेटा टीम पहले से ही एक वेयरहाउस और शेड्यूलर को सुचारू रूप से संचालित करती है, लेकिन उसके पास स्टेटफुल स्ट्रीमिंग जॉब्स के लिए अभी परिपक्व ऑन-कॉल ऑपरेशंस नहीं हैं।

इस समस्या में तीनों उपभोक्ताओं के लिए एक ही प्रोसेसिंग मोड की आवश्यकता नहीं है। इसका लक्ष्य कार्रवाई की समय-सीमाओं, परिणाम की पूर्णता, रिकवरी और रखरखाव लागत से सबसे छोटा और पर्याप्त डिज़ाइन निकालना है। यह data के अंतर्गत आता है क्योंकि इसका मूल क्रॉस-डोमेन प्लेटफ़ॉर्म आर्किटेक्चर के बजाय प्रोसेसिंग सेमांटिक्स, फ्रेशनेस और डेटा-क्वालिटी के ट्रेड-ऑफ़ हैं।

साक्षात्कारकर्ता क्या मूल्यांकन करते हैं

पहला संकेत यह है कि क्या उम्मीदवार मैसेज कतार (message queue) देखकर सीधे स्ट्रीमिंग को डिफ़ॉल्ट मानने के बजाय अंतिम उपयोगी व्यावसायिक कार्रवाई से पीछे की ओर काम करता है। एक अनबाउंडेड (unbounded) स्रोत केवल यह बताता है कि डेटा लगातार आ रहा है। इसके लिए डाउनस्ट्रीम के प्रत्येक परिणाम को एक बार में एक रिकॉर्ड प्रोसेस करने की आवश्यकता नहीं होती है। अगले दिन का फाइनेंस उसी लॉग के एक बाउंडेड स्नैपशॉट को पढ़ सकता है और बैच प्रोसेसिंग से आसान पुनरुत्पादन क्षमता (reproducibility) प्राप्त कर सकता है।

दूसरा संकेत प्रोसेसिंग लेटेंसी को एक्शन लेटेंसी से अलग करना है। एक इंजन 500 मिलीसेकंड में गणना कर सकता है, लेकिन हर 5 मिनट में रीफ़्रेश होने वाला सिंक सेकंड-स्तरीय डैशबोर्ड को रोक देता है। एक मजबूत उत्तर इंजेक्शन (ingestion), कतार (queueing), गणना (computation), लेखन (writes), कैश रीफ़्रेश और अलर्ट डिलीवरी का अलग-अलग बजट बनाता है, फिर प्रत्येक खंड को मापता है।

तीसरा संकेत एक सटीक शुद्धता सीमा (correctness boundary) है। स्ट्रीमिंग इंजन में एक्जेक्टली-वन्स प्रोसेसिंग यह साबित नहीं करती है कि देर से आया डेटा पूर्ण है, और यह बाहरी दुष्प्रभावों (external side effects) को स्वचालित रूप से सुरक्षित नहीं करती है। पुन: चलाने योग्य (rerunnable) बैच जॉब भी स्वचालित रूप से सुरक्षित नहीं होते हैं। एक परिभाषित इनपुट रेंज, बिज़नेस की, स्नैपशॉट संस्करण और परमाणु प्रकाशन (atomic publication) के बिना, दोबारा चलाना परिभाषाओं को डुप्लिकेट या मिश्रित कर सकता है।

अंत में, साक्षात्कारकर्ता परिचालन निर्णय (operational judgment) का परीक्षण कर रहा है। निरंतर स्ट्रीमिंग के लिए निरंतर क्षमता, बैकलॉग रिकवरी, स्टेट, चेकपॉइंट, सुरक्षित परिनियोजन और ऑन-कॉल स्वामित्व की आवश्यकता होती है। यदि माइक्रो-बैच 5 मिनट की समय-सीमा को मज़बूती से पूरा करते हैं, तो रिकॉर्ड-दर-रिकॉर्ड स्टेट किसी निर्णय को बदले बिना विफलता के नए मोड जोड़ता है। इसके विपरीत, प्रति घंटे की बैच प्रोसेसिंग उस 10-सेकंड के अलर्ट के मूल्य को नष्ट कर देती है जो वास्तव में पुनःपूर्ति (replenishment) या बिक्री पर रोक लगाता है।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• समय-सीमा कहाँ से शुरू और समाप्त होती है? यहाँ यह तब शुरू होती है जब स्रोत प्रणाली इवेंट को कमिट करती है और तब समाप्त होती है जब अलर्ट आता है या क्वेरी परिणाम दिखाई देता है। वेयरहाउस इंजेक्शन पर समाप्त होने वाला वादा सिंक और कैश विलंब की अनदेखी करता है।
• क्या 10-सेकंड का अलर्ट एक स्वचालित कार्रवाई को ट्रिगर करता है? स्वचालित इन्वेंट्री परिवर्तन, बिक्री पर रोक या सूचनाओं के लिए डीडुप्लिकेशन, आइडमपोटेंसी (idempotency) और ऑडिट की आवश्यकता होती है। एक केवल-अवलोकन (observational) अलर्ट अधिक गलत सकारात्मक (false positives) या डुप्लिकेट को सहन कर सकता है।
• क्या 5-मिनट का डैशबोर्ड एक अनुमान है या पूर्ण संख्या? "as of" (उस समय तक के) समय के साथ संशोधन योग्य अनुमान के लिए माइक्रो-बैच पर्याप्त है। यदि प्रत्येक प्रदर्शन में 6 घंटे की देरी वाला पिछला डेटा (late tail) शामिल होना चाहिए, तो 5-मिनट की ताज़गी और पूर्णता की आवश्यकताएं आपस में टकराती हैं और उत्पाद अनुबंध को बदलना होगा।
• फाइनेंस क्लोज़ को कब फ़्रीज़ करता है, और क्या यह बाद में समायोजित (adjust) हो सकता है? अगले दिन एक ड्राफ़्ट तैयार करना और उसके बाद समायोजन प्रविष्टियाँ करना, फ़्रीज़ करने से पहले छह घंटे प्रतीक्षा करने से अलग है। यह उत्तर बैच कटऑफ़ और संशोधन प्रोटोकॉल निर्धारित करता है।
• क्या तीनों उपयोग एक कच्चे लेयर और ट्रांसफ़ॉर्मेशन परिभाषाओं को साझा कर सकते हैं? वे सामान्यीकृत (normalized) इवेंट्स, बिज़नेस की और परीक्षण फ़िक्स्चर साझा कर सकते हैं। फ़िल्टर, समय क्षेत्र और राशि के नियमों की स्वतंत्र रूप से नकल करने से अंततः बैच-स्ट्रीम के बीच अंतर (drift) पैदा होगा।
• क्या टीम 24 घंटे स्टेटफुल स्ट्रीम का संचालन कर सकती है? बैकलॉग अलर्ट, चेकपॉइंट रिकवरी ड्रिल और सुरक्षित परिनियोजन के बिना, निरंतर स्ट्रीमिंग को केवल उसी सबसे छोटे रास्ते तक सीमित रखा जाना चाहिए जिसे वास्तव में सेकंड-स्तरीय कार्रवाई की आवश्यकता है।

30-सेकंड का उत्तर

"मैं स्रोत पर एक ही मोड लागू करने के बजाय व्यावसायिक कार्रवाई की समय-सीमा के अनुसार उपभोक्ताओं को विभाजित करूँगा। 10-सेकंड का इन्वेंट्री विसंगति पथ निरंतर स्ट्रीमिंग का उपयोग करता है। 5-मिनट का ऑपरेशंस डैशबोर्ड एक या दो मिनट के माइक्रो-बैच का उपयोग करता है, जिससे लेखन और कैश रीफ़्रेश के लिए बजट बचता है। अगले दिन का फाइनेंस बैच में व्यावसायिक-दिन के स्नैपशॉट का उपयोग करता है और समाधान (reconciliation) का मुख्य स्रोत बना रहता है। तीनों अपरिवर्तनीय कच्चे इवेंट, सामान्यीकरण नियम और बिज़नेस की साझा करते हैं।

स्ट्रीमिंग परिणाम संशोधन योग्य दृश्य (views) हैं, यह दावा नहीं कि देर से आया डेटा पूर्ण है। बाहरी कार्रवाइयाँ इवेंट और नियम संस्करण के अनुसार आइडमपोटेंट होती हैं। कटओवर से पहले, मैं बैच, माइक्रो-बैच और स्ट्रीम पथों के माध्यम से समान इतिहास को रीप्ले करता हूँ, काउंट, राशियों और टेल लेटेंसी की शैडो तुलना करता हूँ, और केवल सेकंड-स्तरीय पथ के लिए कार्यों को सक्षम करता हूँ। नियम यह है कि सबसे सरल मोड चुना जाए जो एक्शन SLO को पूरा करता हो और जिसकी रिकवरी सुसंगत (converge) हो।"

चरण-दर-चरण गहन विश्लेषण

चरण 1: तीन परिणाम अनुबंध लिखें

Spark, Flink या किसी अन्य उत्पाद को चुनने से पहले प्रत्येक आउटपुट की कुंजी, समय-सीमा, पूर्णता और संशोधन व्यवहार को परिभाषित करें।

एक इवेंट तीन अलग-अलग अनुबंधों की पूर्ति कर सकता है। मैसेज कतार एक इनपुट ट्रांसपोर्ट है और तीनों पंक्तियों को एक ही निष्पादन मोड में बाध्य नहीं कर सकती है।

चरण 2: एंड-टू-एंड एक्शन बजट आवंटित करें

10-सेकंड के अलर्ट के लिए एक परीक्षण योग्य पहला बजट स्रोत कमिट और ट्रांसपोर्ट, कतारबद्ध करने, गणना, सिंक और नियम कार्रवाई, तथा अलर्ट डिलीवरी के लिए 2-2 सेकंड निर्दिष्ट कर सकता है। लोड परीक्षणों को उन अनंतिम आवंटनों को बदलना होगा, लेकिन उनका कुल योग व्यावसायिक समय-सीमा से अधिक नहीं हो सकता है। प्रत्येक खंड के लिए p95, p99 और अधिकतम बैकलॉग अवधि रिकॉर्ड करें। केवल ऑपरेटर का समय धीमे सिंक को छुपा देता है।

5-मिनट का डैशबोर्ड हर 1 या 2 मिनट में एक माइक्रो-बैच शुरू कर सकता है। 2-मिनट के स्लाइस के साथ, शेड्यूल प्रतीक्षा सबसे खराब स्थिति में लगभग 2 मिनट होती है, गणना और लेखन को 1-1 मिनट मिलता है, और कैश रीफ़्रेश को अंतिम मिनट मिलता है। यदि दस गुना बर्स्ट गणना को बजट से बाहर धकेलता है, तो पहले समानता (parallelism) बढ़ाएं, स्लाइस को छोटा करें, या कम मूल्य वाले आयामों को स्थगित करें। औसत रनटाइम टेल SLO को साबित नहीं करता है।

फाइनेंस न्यूनतम लेटेंसी के बजाय पुनरुत्पादन क्षमता और एक फ़्रीज़ की गई परिभाषा से बंधा है। बैच एक स्पष्ट स्नैपशॉट या ऑफ़सेट रेंज पढ़ता है, run_id के साथ लेबल किए गए स्टेजिंग क्षेत्र में परिणाम लिखता है, उन्हें मान्य करता है, और परमाणु रूप से प्रकाशित करता है। समान इनपुट और नियम संस्करण को दोहराने पर समान परिणाम मिलना चाहिए।

चरण 3: दोहरे कार्यान्वयन का तकनीकी ऋण बनाए बिना तथ्यों को साझा करें

कच्चे इवेंट पहले मूल पेलोड, स्कीमा संस्करण, इंजेक्शन समय और स्रोत स्थिति के साथ एक रीप्ले करने योग्य लॉग या ऑब्जेक्ट स्टोर में प्रवेश करते हैं। एक सामान्यीकरण लेयर स्कीमा विकास, समय क्षेत्र, राशि इकाइयों, रद्दीकरण स्थिति और बिज़नेस की को लगातार संभालती है। प्रत्येक निष्पादन मोड उस सीमा के बाद पढ़ता है।

साझा तथ्यों के लिए तीन इंजनों के बीच लाइन-दर-लाइन कोड साझा करने की आवश्यकता नहीं है। एक अधिक उपयोगी सीमा एक साझा डेटा अनुबंध, गोल्डन फ़िक्स्चर और नियतात्मक (deterministic) नियम हैं। यदि बैच और स्ट्रीम को विंडो लॉजिक को अलग से लागू करना है, तो समान फ़िक्स्चर पर समानता परीक्षण चलाएं। फाइनेंस एक स्वतंत्र मजबूत जांच बनाए रख सकता है; कोड के पुन: उपयोग से नियंत्रण समाप्त नहीं होना चाहिए।

चरण 4: डुप्लिकेट, देर से आने वाले डेटा और दुष्प्रभावों को अलग से डिज़ाइन करें

इन्वेंट्री स्ट्रीम event_id द्वारा डीडुप्लिकेट करती है, छोटी इवेंट-टाइम विंडो की गणना करती है, और नियम व परिणाम संस्करण उत्सर्जित करती है। बिक्री पर रोक, पुनःपूर्ति या सूचना एक स्थिर एक्शन आइडमपोटेंसी कुंजी का उपयोग करती है। एक सफल चेकपॉइंट यह साबित नहीं करता है कि एक बाहरी HTTP कॉल एक बार हुई थी, इसलिए पुन: प्रयासों (retries) को पहले से की गई कार्रवाई को पहचानना चाहिए।

ऑपरेशंस माइक्रो-बैच निश्चित हाफ़-ओपन स्रोत-ऑफ़सेट रेंज को पढ़ता है और दूसरा कुल जोड़ने के बजाय एक संस्करणित लक्ष्य विंडो को बदल देता है। देर से आने वाले इवेंट बाद के बैचों में प्रवेश करते हैं और परिणाम संस्करण को बढ़ाते हैं। डैशबोर्ड "as of" समय दिखाता है, जिससे यह स्पष्ट होता है कि 5-मिनट की ताज़गी का मतलब यह नहीं है कि 6-घंटे का टेल डेटा पूर्ण है।

फाइनेंस बैच सहमत कटऑफ़ के बाद फ़्रीज़ किए गए इनपुट को पढ़ता है। बाद के इवेंट एक समायोजन रन में प्रवेश करते हैं जो मूल रन, इनपुट रेंज, नियम संस्करण और विसंगति अनुमोदन को बनाए रखता है। एक्जेक्टली-वन्स स्ट्रीम प्रोसेसिंग कुछ सीमाओं में डुप्लिकेट स्थायी प्रोसेसिंग परिणामों को रोक सकती है, लेकिन यह देर से आने वाले डेटा की उपस्थिति में पूर्णता को साबित नहीं करती है या बाहरी दुष्प्रभावों पर स्वचालित रूप से लागू नहीं होती है।

चरण 5: क्षमता और लागत को पुनरुत्पादित करने योग्य बनाएं

कहा गया पीक 20,000 इवेंट प्रति सेकंड है, इसलिए दस गुना बर्स्ट 200,000 प्रति सेकंड है। यदि एक सामान्यीकृत इवेंट उदाहरण के तौर पर 1 KiB है, तो पीक इनग्रेस लगभग 195 MiB प्रति सेकंड है। यह केवल एक क्षमता अनुमान है; उत्पादन का आकार संपीड़ित और असंपीड़ित आकार वितरण से पुनर्गणना करके तय किया जाना चाहिए।

निरंतर स्ट्रीमिंग को पीक ट्रैफ़िक और बैकलॉग रिकवरी दोनों के लिए निरंतर क्षमता की आवश्यकता होती है। 20,000 इवेंट प्रति सेकंड पर दस मिनट की विफलता 12 मिलियन कतारबद्ध इवेंट बनाती है। यदि पुनर्प्राप्त क्षमता केवल वर्तमान इनपुट के बराबर है, तो बैकलॉग कभी साफ़ नहीं होता है। एक माइक्रो-बैच को अगला स्लाइस आने से पहले एक स्लाइस समाप्त करना होगा। बैच सस्ते समय में संसाधनों को केंद्रित कर सकता है, लेकिन बहुत छोटे लगातार बैच स्टार्टअप, कमिट और छोटी-फ़ाइल ओवरहेड को प्रमुख बना देते हैं।

तुलना में निरंतर कंप्यूट, स्टेट और चेकपॉइंट स्टोरेज, सिंक राइट्स, स्कैन, ऑन-कॉल कार्य और परिनियोजन जटिलता शामिल है। केवल क्लाउड शुल्क में चार लोगों की टीम द्वारा तीन समान कार्यान्वयनों को बनाए रखने की लागत छूट जाती है। अनुशंसित डिज़ाइन निरंतर स्ट्रीमिंग को इन्वेंट्री अलर्ट तक सीमित करता है, जिससे फाइनेंस और डैशबोर्ड के लिए चौबीसों घंटे स्टेट की आवश्यकता नहीं होती।

चरण 6: एक कटओवर के बजाय शैडो रीप्ले के साथ माइग्रेट करें

इतिहास के उस हिस्से को फ़्रीज़ करें जिसमें सामान्य ट्रैफ़िक, दस गुना बर्स्ट, डुप्लिकेट, अव्यवस्था और 6 घंटे का देर से आने वाला टेल डेटा शामिल हो। पुराने बैच परिणाम को आधार रेखा (baseline) के रूप में उपयोग करें जबकि नए माइक्रो-बैच और स्ट्रीम जॉब बिना इन्वेंट्री क्रियाओं को ट्रिगर किए शैडो मोड में चलते हैं। प्रत्येक बिज़नेस की के लिए काउंट, राशियों, संस्करणों और देर से संशोधन के इतिहास की तुलना करें, और प्रत्येक विसंगति को स्पष्ट करें।

चरणों में एक्सपोज़र बढ़ाएं: केवल शैडो टेबल लिखें, एक आंतरिक डैशबोर्ड खोलें, फिर स्ट्रीम अलर्ट को प्रतिवर्ती (reversible) क्रियाओं को ट्रिगर करने की अनुमति दें। फॉल्ट इंजेक्शन में चेकपॉइंट से पहले और बाद में क्रैश, सिंक टाइमआउट, रुकी हुई पार्टिशन, स्कीमा परिवर्तन और बैकलॉग कैच-अप शामिल हैं। स्वीकृति मेट्रिक्स में एंड-टू-एंड p99, अधिकतम बैकलॉग अवधि, माइक्रो-बैच पूर्णता समय, विलंबित-संशोधन दर, डुप्लिकेट एक्शन काउंट, बैच-स्ट्रीम राशि अंतर और रिकवरी समय शामिल हैं।

निकास मानदंड (exit criteria) भी परिभाषित करें। यदि माइक्रो-बैच बार-बार 5 मिनट चूकते हैं, तो निरंतर स्ट्रीमिंग पर विचार करने से पहले शेड्यूलिंग, स्क्यू, सिंक और बर्स्ट क्षमता का निरीक्षण करें। यदि 10-सेकंड का अलर्ट अब किसी कार्रवाई को संचालित नहीं करता है, तो ऑन-कॉल लागत को कम करने के लिए इसे माइक्रो-बैच में डाउनग्रेड करें। प्रोसेसिंग मोड एक सत्यापन योग्य व्यावसायिक विकल्प है, कोई स्थायी पहचान नहीं।

मजबूत नमूना उत्तर

"मैं एक अनबाउंडेड इनपुट को उसके प्रोसेसिंग मोड से अलग करता हूँ। इन उपभोक्ताओं की कार्रवाई की समय-सीमाएं अलग-अलग हैं, इसलिए मैं तकनीकी एकरूपता के लिए उन सभी को स्ट्रीमिंग में बाध्य नहीं करूँगा। इन्वेंट्री विसंगति पर वास्तव में 10 सेकंड के भीतर कार्रवाई होनी चाहिए, इसलिए मैं एक निरंतर स्ट्रीम का उपयोग करता हूँ, स्रोत, कतार, कंप्यूट, राइट और डिलीवरी में बजट आवंटित करता हूँ, और प्रत्येक कार्रवाई को event_id और नियम संस्करण द्वारा आइडमपोटेंट बनाता हूँ। ऑपरेशंस डैशबोर्ड को केवल 5 मिनट की आवश्यकता होती है, इसलिए मैं एक या दो मिनट के माइक्रो-बैच से शुरू करता हूँ जो विंडो और संस्करण द्वारा परिणामों को बदलते हैं और एक as-of समय प्रदर्शित करते हैं। वित्तीय समापन बैच में एक फ़्रीज़ किए गए व्यावसायिक-दिन के स्नैपशॉट को पढ़ता है, run_id द्वारा स्टेज करता है, मान्य करता है, फिर परमाणु रूप से प्रकाशित करता है; देर से आने वाला डेटा समायोजन रन में जाता है।

तीनों पथ रीप्ले करने योग्य कच्चे इवेंट, एक सामान्यीकृत अनुबंध और गोल्डन फ़िक्स्चर साझा करते हैं, जबकि फाइनेंस एक स्वतंत्र नियंत्रण रखता है। 20,000 इवेंट प्रति सेकंड पर थोड़े समय के दस गुना बर्स्ट के साथ, मैं 200,000-प्रति-सेकंड इनग्रेस और विफलताओं के बाद कैच-अप अनुपात का परीक्षण करता हूँ, न कि केवल स्थिर स्थिति का। स्ट्रीम चेकपॉइंट बाहरी-कार्रवाई आइडमपोटेंसी की जगह नहीं लेते हैं, और एक्जेक्टली-वन्स प्रोसेसिंग यह साबित नहीं करती है कि 6-घंटे का देर से आया टेल डेटा पूर्ण है।

माइग्रेशन के लिए, मैं उसी इतिहास को रीप्ले करता हूँ और शैडो टेबल में बैच, माइक्रो-बैच और स्ट्रीम पथों से की-स्तरीय परिणामों और संशोधनों की तुलना करता हूँ। निरंतर स्ट्रीमिंग केवल-अवलोकन अलर्ट के साथ शुरू होती है। यह स्वचालित कार्रवाइयों को केवल तभी ट्रिगर करती है जब p99 10 सेकंड से कम हो, डुप्लिकेट क्रियाएं शून्य हों, और बैकलॉग अपने लक्ष्य के भीतर साफ़ हो जाए। मेरा निर्णय नियम सबसे सरल मोड चुनना है जो कार्रवाई की समय-सीमा, पूर्णता और रिकवरी अनुबंध को पूरा करता हो। कम लेटेंसी अपने स्टेट और ऑन-कॉल लागत को तभी उचित ठहराती है जब वह किसी व्यावसायिक निर्णय को बदलती है।"

सामान्य गलतियाँ

• Kafka मौजूद होने के कारण सब कुछ स्ट्रीमिंग में ले जाना → निरंतर इनपुट प्रत्येक परिणाम को रिकॉर्ड-दर-रिकॉर्ड नहीं बनाता है, इसलिए फाइनेंस और डैशबोर्ड बिना किसी लाभ के स्टेट और ऑपरेशंस लागत प्राप्त करते हैं → उपभोक्ता कार्रवाई की समय-सीमा के अनुसार चुनें।
• केवल यह कहना कि स्ट्रीमिंग कम लेटेंसी वाली है → सिंक, कैश और सूचना वितरण पूरे बजट का उपभोग कर सकते हैं → एंड-टू-एंड पथ और प्रत्येक टेल को मापें।
• 5-मिनट के दृश्य को अंतिम कहना → इवेंट अभी भी 6 घंटे तक की देरी से आ सकते हैं → अनुमान, संशोधन, फ़्रीज़ और समायोजन सेमांटिक्स को परिभाषित करें।
• चेकपॉइंट को एक्जेक्टली-वन्स बाहरी कार्रवाइयों के रूप में मानना → पुन: प्रयास इन्वेंट्री या सूचना कॉल को दोहरा सकते हैं → एक्शन आइडमपोटेंसी की, एक ऑडिट रिकॉर्ड और रीप्ले परीक्षणों का उपयोग करें।
• प्रत्येक माइक्रो-बैच से एक नया कुल जोड़ना (appending) → एक ही विंडो को बार-बार गिना जाता है → विंडो और संस्करण द्वारा परमाणु रूप से बदलें या एक वापस लेने योग्य-डेल्टा (retractable-delta) प्रोटोकॉल परिभाषित करें।
• व्यावसायिक नियमों को स्वतंत्र रूप से बैच और स्ट्रीम में कॉपी करना → समय-क्षेत्र, रद्दीकरण और राशि की परिभाषाएँ अलग हो जाती हैं → अनुबंध और फ़िक्स्चर साझा करें, फिर की-स्तर पर तुलना करें।
• केवल स्थिर इनपुट के लिए आकार तय करना → दस गुना बर्स्ट और विफलता बैकलॉग समय-सीमा के भीतर साफ़ नहीं हो सकते हैं → पीक, शुद्ध रिकवरी दर और सिंक क्षमता का एक साथ परीक्षण करें।
• पहले परिनियोजन पर वास्तविक कार्रवाइयों को सक्षम करना → एक सेमांटिक विसंगति सीधे इन्वेंट्री को बदल देती है → धीरे-धीरे प्रतिवर्ती कार्रवाइयों को सक्षम करने से पहले शैडो-राइट करें और अलर्ट का निरीक्षण करें।

अनुवर्ती प्रश्न और उत्तर

अनुवर्ती 1: 5-मिनट के डैशबोर्ड के लिए निरंतर स्ट्रीमिंग का उपयोग क्यों न करें?

यदि एक या दो मिनट के माइक्रो-बैच पीक और रिकवरी स्थितियों के तहत मज़बूती से समाप्त होते हैं, और अंतिम लेखन तथा कैश रीफ़्रेश अभी भी 5 मिनट के भीतर हैं, तो निरंतर स्ट्रीमिंग ऑपरेशंस निर्णय को नहीं बदलती है। यह लंबे समय तक चलने वाले स्टेट, चेकपॉइंट, बैकलॉग रिकवरी और परिनियोजन लागत को जोड़ती है। यदि समय-सीमा बाद में 30 सेकंड हो जाती है, या शेड्यूलिंग और स्टार्टअप माइक्रो-बैच बजट का अधिकांश हिस्सा उपभोग कर लेते हैं, तो निरंतर स्ट्रीमिंग की तुलना करने के लिए उसी इतिहास को रीप्ले करें। SLO के विरुद्ध साक्ष्य, न कि "रीयल-टाइम" का लेबल, अपग्रेड को ट्रिगर करता है।

अनुवर्ती 2: क्या एक स्ट्रीम से अलर्ट, डैशबोर्ड और वित्तीय परिणाम उत्पन्न हो सकते हैं?

यह हो सकता है, लेकिन एक चेकपॉइंट, स्कीमा परिवर्तन या खराब विंडो को तीनों उपयोगों को अवरुद्ध नहीं करना चाहिए। एक अलर्ट सामान्यीकृत स्ट्रीम को पढ़ सकता है और संक्षिप्त स्टेट बनाए रख सकता है, एक डैशबोर्ड संस्करणित एग्रीगेट्स को पढ़ सकता है, और फाइनेंस अभी भी एक फ़्रीज़ किए गए स्नैपशॉट पर अपरिवर्तनीय इतिहास से पुनर्गणना कर सकता है। परिनियोजन और विफलता डोमेन को अलग करते हुए इनपुट और परिभाषाओं को साझा करें। रनटाइम इकाइयों को केवल यह साबित करने के बाद संयोजित करें कि विफलता का प्रभाव, बैकफ़िल और ऑडिट स्वीकार्य बने रहते हैं।

अनुवर्ती 3: क्या एक्जेक्टली-वन्स प्रोसेसिंग स्ट्रीम आउटपुट को वित्तीय समापन के लिए उपयुक्त बनाती है?

केवल वह लेबल पर्याप्त नहीं है। प्रोसेसिंग सेमांटिक्स कमिट किए गए आउटपुट को पुन: प्रयासों पर डुप्लिकेट होने से रोक सकते हैं, लेकिन वे यह गारंटी नहीं देते हैं कि देर से आने वाले रिकॉर्ड आ चुके हैं और वे बाहरी दुष्प्रभावों को स्वचालित रूप से कवर नहीं करते हैं। फाइनेंस को अभी भी एक फ़्रीज़ की गई इनपुट रेंज, नियम संस्करण, दोहराने योग्य रन, लेज़र प्रतिबंध और विसंगति अनुमोदन की आवश्यकता होती है। स्ट्रीम आउटपुट एक प्रारंभिक अनुमान हो सकता है। यह एक क्लोज़ इनपुट केवल तभी बनता है जब वे ऑडिट नियंत्रण भी लागू हों और लंबे समय तक चलने वाला समाधान समानता सिद्ध करे।

अनुवर्ती 4: आप दस गुना बर्स्ट से रिकवरी को कैसे साबित करते हैं?

बर्स्ट की अवधि और विफलता की अवधि रिकॉर्ड करें, कतारबद्ध इवेंट्स की गणना करें, और शुद्ध ड्रेन दर को मापें। यदि वर्तमान इनपुट 20,000 प्रति सेकंड है और उपभोक्ता 30,000 प्रति सेकंड प्रोसेस करते हैं, तो शुद्ध ड्रेन केवल 10,000 प्रति सेकंड है; 12 मिलियन कतारबद्ध इवेंट्स में लगभग 20 मिनट लगते हैं। स्वीकृति एंड-टू-एंड अलर्ट लेटेंसी, सिंक सीमाओं, स्टेट वृद्धि और ऑटोस्केलिंग विलंब का भी अवलोकन करती है। शुद्ध रिकवरी गणित के बिना पीक-थ्रूपुट संख्या लॉन्ग-टेल उल्लंघन को छुपाती है।

अनुवर्ती 5: निरंतर स्ट्रीमिंग को माइक्रो-बैच में कब डाउनग्रेड किया जाना चाहिए?

तब डाउनग्रेड करें जब व्यवसाय अब सेकंड-स्तरीय आउटपुट पर कार्रवाई नहीं करता है, माइक्रो-बैच नई समय-सीमा को पूरा करता है, या स्ट्रीमिंग ऑन-कॉल और स्टेट लागत लगातार उस नुकसान से अधिक हो जाती है जिसे वह रोकता है। पहले माइक्रो-बैच को शैडो-रन करें और परिणामों तथा लेटेंसी की तुलना करें। फिर रीप्ले करने योग्य इनपुट और एक रोलबैक विंडो को बनाए रखते हुए वास्तविक कार्रवाइयों को अक्षम करें। परिवर्तन के बाद देर से आने वाले संशोधनों और पीक पूर्णता समय की निगरानी जारी रखें ताकि लागत बचत पुराने डेटा को न छिपाए।