प्रॉम्प्ट और संदर्भ
आप पाँच मिनट के ऑर्डर राशि और ऑर्डर-काउंट मेट्रिक्स की गणना करते हैं। ऑफ़लाइन क्लाइंट्स, पुनः प्रयास (retries), और मल्टी-रीजन डिलीवरी के कारण इवेंट्स देर से आते हैं, और एक ही ऑर्डर एक से अधिक बार भेजा जा सकता है। व्यवसाय को एक मिनट के भीतर प्रारंभिक मान और 24 घंटों के भीतर रिपोर्ट के लिए सुधार (corrections) उपलब्ध होने की आवश्यकता है।
इवेंट टाइम (event time) को प्रोसेसिंग टाइम (processing time) से अलग करें, यह परिभाषित करें कि विंडो कब परिणाम उत्सर्जित (emit) करती है, और दिखाएं कि लेट इवेंट्स कहाँ जाते हैं और उपभोक्ता (consumers) सुधारों की पहचान कैसे करते हैं।
इंटरव्यूअर क्या जांच रहा है
टाइम सेमेंटिक्स
एक मजबूत उत्तर यह समझाने से पहले कि वॉटरमार्क एक अनुमान है कि विंडो के लिए अधिकांश डेटा आ चुका है, इवेंट टाइमस्टैम्प, प्रोसेसिंग टाइम, विंडो सीमाओं और टाइम ज़ोन को परिभाषित करता है।
परिणाम का जीवन चक्र (लाइफसाइकिल)
प्रारंभिक परिणाम, समय पर परिणाम (on-time result), देर से किए गए सुधार और कटऑफ के बाद के डेटा को अलग करें। एक बार का उत्सर्जन स्वचालित रूप से स्थायी सत्य नहीं होता है।
स्टेट और लागत
स्टेट रिटेंशन, अलाउड लेटनेस, पुनः गणना का दायरा, हॉट कीज़ (hot keys) और चेकपॉइंट्स पर चर्चा करें। हमेशा के लिए प्रतीक्षा करने से स्टेट और लागत असीमित हो जाती है।
ऑब्जर्वेबिलिटी (निगरानी क्षमता)
वॉटरमार्क लैग, लेटनेस वितरण, सुधार अनुपात, ड्रॉप किए गए इवेंट्स, डुप्लिकेट अनुपात और परिणाम की ताजगी (freshness) को ट्रैक करें।
स्पष्टीकरण के लिए पूछे जाने वाले प्रश्न
- क्या मेट्रिक्स को इवेंट टाइम द्वारा समूहीकृत (group) किया गया है या आगमन समय (arrival time) द्वारा?
- पहले परिणाम के लिए कितनी त्रुटि स्वीकार्य है, और अंतिम कटऑफ कब है?
- क्या लेट इवेंट्स को उन रिपोर्टों को सही करना चाहिए जो पहले ही प्रकाशित हो चुकी हैं?
- क्या प्रत्येक इवेंट में डिडुप्लिकेशन के लिए एक स्थिर event_id होता है?
- प्रति कुंजी (key) पीक रेट और अधिकतम स्टेट बजट क्या है?
- क्या कटऑफ के बाद के इवेंट्स को ड्रॉप किया जाना चाहिए, क्वारंटाइन किया जाना चाहिए, या ऑफ़लाइन पुनः गणना की जानी चाहिए?
30-सेकंड का उत्तर ढांचा (फ़्रेमवर्क)
"मैं इवेंट-टाइम विंडो का उपयोग करूँगा और एक event_id तथा इवेंट टाइमस्टैम्प की आवश्यकता रखूँगा। स्ट्रीम प्रोसेसर प्रारंभिक परिणाम उत्सर्जित करने के लिए वॉटरमार्क का और सुधारों के लिए एक सीमित अलाउड-लेटनेस अवधि का उपयोग करता है; सुधार एक रिविजन के साथ समान विंडो कुंजी का उपयोग करते हैं। कटऑफ के बाद के इवेंट्स इतिहास को चुपचाप फिर से लिखने के बजाय क्वारंटाइन और बैच रीकंप्यूटेशन में जाते हैं। मैं वॉटरमार्क लैग, लेटनेस परसेंटाइल, सुधार दर, ड्रॉप्स और स्टेट साइज़ की निगरानी करूँगा।"
चरण-दर-चरण गहन विवरण
चरण 1: विंडो और समय को परिभाषित करें
UTC इवेंट टाइम और [10:00, 10:05) जैसी फिक्स्ड विंडो का उपयोग करें। प्रोसेसिंग टाइम ऑपरेशनल अलर्ट और शुरुआती ट्रिगर्स के लिए है, व्यावसायिक समूहीकरण के लिए नहीं। कुंजी में टेनेंट, उत्पाद या क्षेत्र को शामिल करें।
चरण 2: वॉटरमार्क को आगे बढ़ाएं
प्रत्येक पार्टीशन देखे गए इवेंट टाइमस्टैम्प से आगे बढ़ता है, जबकि एक वैश्विक नीति एक सुरक्षित निचली सीमा (lower bound) लेती है। निष्क्रिय (idle) पार्टीशन्स का पता लगाएं; एक शांत पार्टीशन को पूरी पाइपलाइन को बंधक नहीं बनाना चाहिए।
चरण 3: ट्रिगर करें और संचित करें
प्रोसेसिंग-टाइम ट्रिगर के साथ एक सन्निकटन (approximation) उत्सर्जित करें, फिर जब वॉटरमार्क विंडो के अंत को पार कर जाए तो समय पर परिणाम उत्सर्जित करें। एक्यूमुलेटिंग या डिस्कार्डिंग पैन चुनें और प्रत्येक आउटपुट में window_end, revision, और is_final शामिल करें।
चरण 4: लेट और डुप्लिकेट इवेंट्स को संभालें
अलाउड लेटनेस के भीतर, event_id द्वारा डिडुप्लिकेट करें, स्टेट अपडेट करें, और एक नया रिविजन उत्सर्जित करें। रीप्ले में राशि को दो बार नहीं जोड़ा जाना चाहिए। व्यावसायिक कटऑफ तक स्टेट बनाए रखें, फिर इसे साफ़ करें।
चरण 5: लेट-डेटा फ़ॉलबैक को परिभाषित करें
कारण और मूल पेलोड के साथ अलाउड लेटनेस के बाद के इवेंट्स को क्वारंटाइन में लिखें। एक बैच जॉब पिछले 24 घंटों की पुनः गणना करता है और करेक्शन स्टोर पर एक इडेम्पोटेंट अपसर्ट (upsert) या उच्चतर रिविजन लागू करता है।
चरण 6: परीक्षण करें और प्रकाशित करें
रीऑर्डरिंग, डुप्लिकेट्स, निष्क्रिय पार्टीशन्स, रीस्टार्ट रिकवरी, और बाउंड्री लेटनेस का परीक्षण करने के लिए नियंत्रित टाइमस्टैम्प का उपयोग करें। उपभोक्ता (metric, window_end, revision) को डिडुप्लिकेट करते हैं और रिपोर्ट के लिए अंतिम या कटऑफ-स्वीकृत रिविजन्स का उपयोग करते हैं।
उच्च-गुणवत्ता वाला नमूना उत्तर
"मैं सबसे पहले इवेंट टाइम, विंडो और कटऑफ को एक स्पष्ट अनुबंध बनाता हूँ। प्रत्येक इवेंट में एक स्थिर eventid, eventtime, और schema_version होता है। प्रोसेसर टेनेंट और मेट्रिक द्वारा पांच मिनट के लिए विंडो करता है। पार्टीशन वॉटरमार्क निष्क्रिय पार्टीशन्स का ध्यान रखते हैं, और ग्लोबल वॉटरमार्क विंडो पूर्णता का एक रूढ़िवादी अनुमान है।
सिस्टम तुरंत एक प्रारंभिक रिविजन उत्सर्जित करता है, वॉटरमार्क द्वारा अंत पार करने के बाद समय पर रिविजन उत्सर्जित करता है, और 30 मिनट के लिए लेट इवेंट्स स्वीकार करता है। प्रत्येक आउटपुट में विंडो सीमाएं, एक रिविजन और एक फ़ाइनल फ़्लैग शामिल होता है, इसलिए डाउनस्ट्रीम राइट्स इडेम्पोटेंट होते हैं। 30 मिनट से अधिक देर के इवेंट्स क्वारंटाइन में प्रवेश करते हैं; 24 घंटे का रीकंप्यूटेशन जॉब एक उच्चतर रिविजन तैयार करता है। रिपोर्ट कटऑफ के बाद, हम इवेंट का ऑडिट करते हैं लेकिन व्यावसायिक लेज़र को चुपचाप दोबारा नहीं लिखते हैं।
मैं वॉटरमार्क लैग, p50/p95/p99 लेटनेस, सुधार और ड्रॉप दरें, डुप्लिकेट्स, स्टेट बाइट्स, रीकंप्यूटेशन बैकलॉग और अंतिम-परिणाम देरी की निगरानी करता हूँ। क्षमता सक्रिय विंडो गुणा प्रति विंडो स्टेट है, जो चेकपॉइंट्स और स्टेट TTL द्वारा सीमित है।"
सामान्य गलतियाँ
- इवेंट टाइम को प्रोसेसिंग टाइम से बदलना → ऑफ़लाइन इवेंट्स गलत विंडो में चले जाते हैं → event_time बनाए रखें और संचालन के लिए प्रोसेसिंग टाइम आरक्षित रखें।
- वॉटरमार्क को पूर्ण सत्य मानना → लेट इवेंट्स चुपचाप गायब हो जाते हैं → इसे एक अनुमान के रूप में दस्तावेजित करें और अलाउड लेटनेस तथा क्वारंटाइन कॉन्फ़िगर करें।
- एक ही अपरिवर्तनीय परिणाम उत्सर्जित करना → सुधार प्रसारित नहीं हो सकते → इडेम्पोटेंट अपडेट के लिए रिविजन्स और एक फ़ाइनल फ़्लैग का उपयोग करें।
- हमेशा के लिए प्रतीक्षा करना → स्टेट और लागत की कोई सीमा नहीं होती → एक व्यावसायिक कटऑफ निर्धारित करें और इसके बाद ऑफ़लाइन पुनः गणना करें।
- केवल पेलोड द्वारा डिडुप्लिकेट करना → रीट्राई ऑर्डर डबल-काउंटिंग में बदल जाता है → एक स्थिर event_id और टिकाऊ डिडुप स्टेट का उपयोग करें।
- निष्क्रिय पार्टीशन्स को अनदेखा करना → वॉटरमार्क रुक जाता है और अलर्ट गलत जानकारी देते हैं → निष्क्रिय पार्टीशन्स का पता लगाएं और उन्हें निचली सीमा से अस्थायी रूप से बाहर निकालें।
- केवल क्रमित (ordered) इनपुट का परीक्षण करना → बाउंड्री विफलताएं प्रोडक्शन में दिखाई देती हैं → रीऑर्डरिंग, डुप्लिकेट्स, लेट डेटा, रीस्टार्ट और रिकवरी को इंजेक्ट करें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: वॉटरमार्क क्यों रुक (stall) सकता है?
हो सकता है कि कोई पार्टीशन शांत हो, डिस्कनेक्ट हो, या प्रगति का अत्यधिक सावधानी से अनुमान लगा रहा हो। शांति और विफलता के बीच अंतर करने के लिए आइडल टाइमआउट्स, पार्टीशन हार्टबीट्स और वॉटरमार्क-लैग अलर्ट्स को संयोजित करें।
फॉलो-अप 2: आप अलाउड लेटनेस कैसे चुनते हैं?
ऐतिहासिक लेटनेस, व्यावसायिक कटऑफ और स्टेट बजट का उपयोग करें। p99 लेटनेस अनुमान से शुरू करें और रीप्ले द्वारा इसे मान्य करें। लंबा समय स्वचालित रूप से अधिक सही नहीं होता है; यह स्टेट और सुधार लागत को बढ़ाता है।
फॉलो-अप 3: आप सुधारों के तूफान (correction storm) को कैसे रोकते हैं?
लेट इवेंट्स को माइक्रो-बैच करें, प्रति विंडो सुधारों को सीमित करें, और डाउनस्ट्रीम में केवल नवीनतम रिविजन रखें। स्पाइक्स के दौरान, गैर-महत्वपूर्ण मेट्रिक्स को बैच करेक्शन में डाउनग्रेड करें।
फॉलो-अप 4: क्या कटऑफ के बाद के इवेंट्स को ड्रॉप किया जा सकता है?
उन्हें कभी भी चुपचाप ड्रॉप न करें। क्वारंटाइन और ऑडिट डेटा रिकॉर्ड करें और व्यावसायिक प्रभाव को मापें। लेखांकन या अनुपालन आवश्यकताओं के लिए पुनः गणना या मैनुअल हैंडलिंग की आवश्यकता हो सकती है।
फॉलो-अप 5: आप रीस्टार्ट के बाद परिणामों को पीछे जाने (moving backward) से कैसे रोकते हैं?
विंडो स्टेट, डिडुप स्टेट और वॉटरमार्क को चेकपॉइंट करें। मोनोटोनिक रिविजन्स का उपयोग करें, डाउनस्ट्रीम में पुराने रिविजन्स को अस्वीकार करें, लॉग को रीप्ले करें, और रिकवरी के बाद निरंतरता (कंसिस्टेंसी) जांच चलाएं।
स्रोत 1: Apache Beam Programming Guide
Beam वॉटरमार्क, ट्रिगर्स, अलाउड लेटनेस और संचय मोड को परिभाषित करता है, जिसमें यह भी शामिल है कि लेट डेटा कैसे नए पैन उत्पन्न कर सकता है।
स्रोत 2: Apache Kafka Streams Core Concepts
Kafka Streams आउट-ऑफ-ऑर्डर रिकॉर्ड्स के लिए ग्रेस पीरियड और विंडो एंड प्लस ग्रेस के बाद डिस्कार्ड सेमेंटिक्स का दस्तावेजीकरण करता है।
स्रोत 3: Dataford streaming interview question
सार्वजनिक इंटरव्यू प्रॉम्प्ट वॉटरमार्क, लेट-इवेंट रूटिंग, पुनः गणना और निगरानी को इस परिदृश्य के लिए गहराई से जांचने वाले बिंदुओं के रूप में मानता है।