प्रॉम्प्ट और दायरा
यह डेटा-इंजीनियरिंग डिज़ाइन प्रश्न अस्वीकृत (rejected) रिकॉर्ड के पूरे जीवनचक्र का परीक्षण करता है: पहचान (detection), क्वारंटीन, सुधार (repair), रीप्ले और क्लोज़र। उत्तर को निर्णय को पुन: प्रस्तुत करने के लिए पर्याप्त साक्ष्य सुरक्षित रखते हुए स्वस्थ पथ पर थ्रूपुट की रक्षा करनी चाहिए।
इंटरव्यूअर क्या टेस्ट कर रहा है
- स्कीमा, बिज़नेस-नियम, डुप्लिकेट, देर से आने वाले (late), और पॉइज़न-पिल (poison-pill) विफलताओं के बीच अंतर करना।
- पेलोड साक्ष्य, सोर्स पोज़ीशन और कारण के साथ एक क्वारंटीन रिकॉर्ड डिज़ाइन करना।
- रीप्ले के लिए इडेम्पोटेंसी (idempotency), वर्ज़न वाले नियम और ऑडिट योग्य स्थिति का उपयोग करना।
- बैकप्रेशर, अलर्टिंग, प्राइवेसी, डेटा प्रतिधारण (retention), और ओनरशिप को कवर करना।
पूछे जाने वाले स्पष्टीकरण प्रश्न
स्पष्ट करें कि इनपुट बैच है, स्ट्रीमिंग है या दोनों; क्या वैध रिकॉर्ड स्वतंत्र रूप से कमिट हो सकते हैं; क्या इवेंट्स में एक स्थिर event_id, बिज़नेस टाइमस्टैम्प और सोर्स ऑफ़सेट है; क्या रीप्ले मूल इवेंट को पढ़ता है या सोर्स से दोबारा फेच करता है; और कौन से प्राइवेसी तथा रिटेंशन नियम लागू होते हैं।
30-सेकंड का उत्तर
मैं एक इम्यूटेबल रॉ लेयर, एक वैलिडेशन राउटर, एक वैध-डेटा पथ और एक क्वारंटीन पथ को अलग करूँगा। प्रत्येक विफल रिकॉर्ड अपने साक्ष्य, सोर्स पोज़ीशन, नियम वर्ज़न, कारण और स्थिति को बनाए रखता है; वैध रिकॉर्ड event_id द्वारा इडेम्पोटेंट रूप से लिखे जाते हैं। सुधार के बाद, एक रीप्ले बैच उसी ट्रांसफ़ॉर्मेशन और राइट बाउंड्री को चलाता है, जिसमें एक नियंत्रित नियम वर्ज़न और समाधान (reconciliation) मेट्रिक्स होते हैं जो यह साबित करते हैं कि रिकॉर्ड न तो अनजाने में खोए और न ही डुप्लिकेट हुए।
चरण-दर-चरण गहन विश्लेषण
1. रूटिंग से पहले तथ्यों को सुरक्षित रखें
आने वाले इवेंट को पहले इम्यूटेबल स्टोरेज या रीप्ले करने योग्य लॉग में लिखें, जिसमें सोर्स, पार्टीशन/ऑफ़सेट, प्राप्ति समय, event_id, और एक पेलोड हैश शामिल हो। पार्स या स्कीमा विफलता को त्यागने (discard) के बजाय एक एरर कोड के साथ क्वारंटीन में भेजा जाना चाहिए। पास होने वाले रिकॉर्ड सामान्य पथ से आगे बढ़ते हैं, ताकि एक खराब रिकॉर्ड किसी असंबंधित बैच या पार्टीशन को न रोके।
2. क्वारंटीन को कार्रवाई योग्य (actionable) बनाएं
पेलोड या एक नियंत्रित संदर्भ, विफल फ़ील्ड्स, नियम का नाम और वर्ज़न, पहली विफलता का समय, सोर्स पोज़ीशन, पुनः प्रयास (retry) संख्या, रिपेयर बैच, और open, ready_for_replay, replayed, या rejected जैसी स्थिति को स्टोर करें। संवेदनशील फ़ील्ड्स को एन्क्रिप्ट या न्यूनतम करें और एक रिटेंशन नीति लागू करें। क्वारंटीन टेबल एक ऑपरेशनल कतार है, असीमित संग्रह (archive) नहीं।
3. रीप्ले को समान शुद्धता सीमा (correctness boundary) दें
सुधार नियम को वर्ज़न करें और मूल इवेंट को कभी भी ओवरराइट न करें। एक रीप्ले जॉब एक स्वीकृत स्थिति और नियम वर्ज़न का चयन करता है, एक छोटे सैंपल या शैडो टारगेट को मान्य करता है, और फिर उसी ट्रांसफ़ॉर्मेशन और राइट पाथ को कॉल करता है जिसका उपयोग लाइव ट्रैफ़िक द्वारा किया जाता है। event_id और बिज़नेस वर्ज़न को इडेम्पोटेंसी कुंजी के रूप में उपयोग करें; परिभाषित करें कि क्या कोई टकराव upsert, no-op, या एक नया वर्ज़न है। दो बार रीप्ले करने पर भी वही परिणाम आना चाहिए।
4. डुप्लिकेट, देरी और पॉइज़न पिल्स को संभालें
event_id, सोर्स पोज़ीशन, या एक प्रलेखित डिडुप्लीकेशन विंडो के साथ डुप्लिकेट का पता लगाएं; केवल एक ऑफ़सेट बिज़नेस पहचान नहीं होता है। बिज़नेस समय के अनुसार देर से आए इवेंट्स को रूट करें और बताएं कि वॉटरमार्क या बैकफ़िल डाउनस्ट्रीम परिणामों को कैसे प्रभावित करते हैं। पॉइज़न पिल्स के लिए रीट्राई की सीमा तय करें और उन्हें किसी ओनर या अंतिम अस्वीकृति स्थिति में सौंपें, जिससे एक ही रिकॉर्ड सभी वर्कर क्षमता को समाप्त न कर सके।
5. ऑब्जर्वेबिलिटी के साथ स्वास्थ्य सिद्ध करें
वैध-पास दर, सोर्स और नियम द्वारा क्वारंटीन संख्या, सबसे पुरानी अनसुलझी आयु, रीप्ले सफलता दर, डुप्लिकेट-राइट टकराव, एंड-टू-एंड लेटेंसी और फ्रेशनेस को ट्रैक करें। थ्रेशोल्ड पर अलर्ट करें या पूरी पाइपलाइन को रोकने से पहले किसी एक सोर्स को अलग करें। प्रत्येक बैच या ऑफ़सेट रेंज के लिए रॉ, वैध, क्वारंटीन, रीप्ले और अस्वीकृत गणनाओं का मिलान (reconcile) करें; अस्पष्टीकृत अंतर इंसिडेंट माने जाते हैं।
एक बेहतरीन नमूना उत्तर
मैं पहले इवेंट पहचान और स्थिरता आवश्यकताओं को स्पष्ट करूँगा। फिर मैं रॉ इवेंट को इम्यूटेबल रूप से बनाए रखूँगा, स्कीमा, बिज़नेस नियमों, डुप्लिकेट्स और क्रम का सत्यापन करूँगा, और विफलताओं को हटाने के बजाय क्वारंटीन स्टोर में रूट करूँगा। क्वारंटीन रिकॉर्ड में एक पेलोड संदर्भ, सोर्स ऑफ़सेट, नियम वर्ज़न, विस्तृत कारण और जीवनचक्र स्थिति शामिल होती है। वैध रिकॉर्ड और रीप्ले किए गए रिकॉर्ड event_id और बिज़नेस वर्ज़न द्वारा निर्देशित समान इडेम्पोटेंट राइट पाथ साझा करते हैं। मरम्मत मूल इवेंट को बदले बिना एक स्वीकृत रीप्ले बैच बनाती है; मैं एक छोटे सैंपल का परीक्षण करूँगा, पॉइज़न-पिल रीट्राई को सीमित करूँगा, और देर से आने वाले इवेंट्स के व्यवहार को स्पष्ट करूँगा। अंत में, मैं संवेदनशील फ़ील्ड्स की सुरक्षा और रिटेंशन लागू करते हुए, क्वारंटीन आयु, रीप्ले सफलता, राइट टकराव, फ्रेशनेस और गणना समाधान की निगरानी करूँगा।
सामान्य गलतियाँ
- विफल पंक्तियों को छोड़ देना या केवल एक एरर स्ट्रिंग लॉग करना।
- सोर्स पोज़ीशन, इवेंट पहचान, या नियम वर्ज़न को छोड़ देना।
- एक अलग ट्रांसफ़ॉर्मेशन के साथ रीप्ले लागू करना जो लाइव ट्रैफ़िक से अलग हो सकता है।
- बिना किसी सीमा या ओनर के पॉइज़न पिल्स का पुनः प्रयास करना।
- बिना किसी स्थिति, रिटेंशन या क्लोज़र शर्त के क्वारंटीन को कचरा डंप की तरह मानना।
- सोर्स, नियम और आयु के आयामों के बजाय केवल कुल सफलता दर पर नज़र रखना।
अनुवर्ती प्रश्न और उत्तर
आप क्वारंटीन में व्यक्तिगत डेटा की सुरक्षा कैसे करते हैं?
निदान के लिए केवल आवश्यक न्यूनतम फ़ील्ड रखें, संवेदनशील पेलोड को एन्क्रिप्ट करें, पहुंच को प्रतिबंधित करें, और एक नियंत्रित संदर्भ के माध्यम से मूल डेटा प्राप्त करें। रीड्स का ऑडिट करें और रिटेंशन समय सीमा पर विलोपन (deletion) लागू करें।
यदि रीप्ले के दौरान नया डेटा आता है तो क्या होगा?
एक अलग रीप्ले बैच और स्पष्ट इवेंट वर्ज़न का उपयोग करें। इडेम्पोटेंसी कुंजी द्वारा मर्ज करें; यदि क्रम मायने रखता है, तो एक पार्टीशन या एंटिटी सीमा परिभाषित करें और टकराव के निर्णयों को रिकॉर्ड करें।
आप पूरी पाइपलाइन को कब रोकेंगे?
केवल एक ब्रेकिंग स्कीमा, अनुपलब्ध टारगेट, या डेटा दूषित होने के जोखिम के लिए जो वैध डेटा को प्रभावित कर सकता है। सामान्यतः अन्य पथों को जारी रखते हुए एक खराब सोर्स या नियम को अलग किया जाना चाहिए।
आप कैसे साबित करते हैं कि कोई डेटा हानि नहीं हुई?
प्रत्येक इनपुट बैच या ऑफ़सेट रेंज के लिए एक लेज़र बनाएं और रॉ, वैध, क्वारंटीन, रीप्ले और अस्वीकृत गणनाओं का मिलान करें। event_id सेट का सैंपल लें और गुणवत्ता SLO में अनसुलझी आयु को शामिल करें।