प्रॉम्प्ट और दायरा
एक बैच जॉब 90 दिनों के ऑर्डर डायमेंशन का बैकफ़िल करता है और बाद में पता चलता है कि उसका ट्रांसफ़ॉर्मेशन लॉजिक गलत था। इस रन के दौरान स्ट्रीमिंग राइट्स जारी रहे। डिज़ाइन करें कि खराब स्नैपशॉट का पता कैसे लगाया जाए, प्रभावित क्वेरीज़ को कैसे रीप्रोड्यूस किया जाए, फ़िक्स को कैसे अलग (आइसोलेट) किया जाए, कमिट विरोधों को कैसे संभाला जाए, और रिटेंशन कैसे सेट किया जाए। मुख्य कौशल टेबल-फ़ॉर्मेट वर्ज़निंग, वंशावली (लीनिएज), और रिकवर करने योग्य संचालन हैं, इसलिए यह डेटा इंजीनियरिंग के अंतर्गत आता है।
इंटरव्यूअर क्या मूल्यांकन करता है
उत्तर में यह समझाया जाना चाहिए कि स्नैपशॉट एक मेटाडेटा पॉइंटर है, कोई साधारण फ़ाइल कॉपी नहीं, और टाइम ट्रैवल रिटेंशन पर निर्भर करता है। समवर्ती कमिट (कनकconcurrent कमिट), रोलबैक के प्रभाव, डाउनस्ट्रीम रीड कंसिस्टेंसी, स्नैपशॉट एक्सपायरी, और ऑर्फ़न-फ़ाइल क्लीनअप को कवर करें। केवल "कल की स्थिति पर रीस्टोर करें" कहना सुरक्षा प्रदर्शित नहीं करता है।
पहले स्पष्ट करने योग्य प्रश्न
- किस कैटलॉग, इंजन, और कमिट लॉक का उपयोग किया जा रहा है, और स्नैपशॉट ID का ऑडिट कैसे किया जाता है?
- कौन से पार्टीशन, स्नैपशॉट, और डाउनस्ट्रीम टेबल प्रभावित हुए थे?
- क्या खराब बैकफ़िल के दौरान स्ट्रीमिंग जॉब्स ने कमिट किया था, और क्या उन्हें रोका जा सकता है या किसी स्नैपशॉट से फिर से चलाया जा सकता है?
- क्या बिज़नेस टेबल रोलबैक, पार्टीशन रीराइट, या वैलिडेशन के लिए एक रिप्लेसमेंट टेबल की मांग कर रहा है?
- स्नैपशॉट और डेटा फ़ाइलों को कितने समय तक बनाए रखा जाता है, और क्या क्लीनअप से रिकवरी के साक्ष्य हट सकते हैं?
30-सेकंड का उत्तर फ़्रेमवर्क
“मैं पहले टेबल हिस्ट्री और जॉब लॉग से बैकफ़िल कमिट की पहचान करता हूँ, फिर प्रभावित पार्टीशनों को सीमित करने के लिए टाइम-ट्रैवल क्वेरीज़ का उपयोग करके इसके स्नैपशॉट की तुलना पेरेंट से करता हूँ। मैं सही इनपुट को आइसोलेट करता हूँ, वैलिडेशन दोबारा चलाता हूँ, और पार्टीशन रीराइट, रिपेयर स्नैपशॉट, या रोलबैक केवल तभी चुनता हूँ जब बाद के किसी भी मान्य कमिट को बनाए रखने की आवश्यकता न हो। पॉइंटर बदलने से पहले मैं समवर्ती कमिट्स और रीडर्स की जाँच करता हूँ; इसके बाद मैं डाउनस्ट्रीम टेबल को फिर से बनाता हूँ। रिकवरी विंडो बंद होने तक स्नैपशॉट एक्सपायरी और ऑर्फ़न क्लीनअप में देरी करें, और स्नैपशॉट, फ़ाइल, और डेटा-क्वालिटी मेट्रिक्स की निगरानी करें।”
चरण-दर-चरण समाधान
टेबल हिस्ट्री, स्नैपशॉट सूची, और कमिट सारांश पढ़ें। स्नैपशॉट ID, कमिट समय, रन ID, पार्टीशन रेंज, और इनपुट वर्ज़न रिकॉर्ड करें। केवल वॉल-क्लॉक समय से लक्ष्य का अनुमान न लगाएं क्योंकि समवर्ती कमिट आपस में इंटरलीव हो सकते हैं। मेटाडेटा और डेटा फ़ाइलों में खराब स्नैपशॉट की तुलना उसके पेरेंट से करें, फिर प्रभाव को सीमित करने के लिए जॉब लॉग, क्वालिटी अलर्ट, और पार्टीशन आंकड़ों का उपयोग करें।
खराब राइट से पहले और बाद में समान बिज़नेस मेट्रिक्स को रीप्रोड्यूस करने के लिए टाइम-ट्रैवल क्वेरीज़ का उपयोग करें। एक स्नैपशॉट एक सुसंगत रीड व्यू प्रदान करता है, लेकिन यह अनंत इतिहास को बनाए नहीं रखता है; एक्सपायरी से पहले क्वेरीज़ पूरी करें या आवश्यकता पड़ने पर वैलिडेशन नमूने और मेटाडेटा संदर्भ निर्यात करें।
यदि स्ट्रीमिंग राइट्स अभी भी सक्रिय हैं, तो परस्पर विरोधी पार्टीशनों को रोकें या एक अलग ब्रांच या अस्थायी टेबल बनाएं। उपयुक्त स्नैपशॉट के अनुसार सही इनपुट पढ़ें, ट्रांसफ़ॉर्मेशन को ठीक करें, और यह जाँचने के बाद ही रिपेयर कमिट करें कि पेरेंट स्नैपशॉट अभी भी अपेक्षित वर्ज़न है। किसी विरोध की स्थिति में, मान्य राइट्स को बलपूर्वक ओवरराइट करने के बजाय नवीनतम स्नैपशॉट को फिर से पढ़ें और पुनर्गणना (रीकंप्यूट) करें।
टेबल-व्यापी रोलबैक केवल तभी उपयुक्त होता है जब रोलबैक बिंदु के बाद के किसी भी मान्य कमिट को सुरक्षित रखने की आवश्यकता न हो और रीडर्स अस्थायी प्रतिगमन (रिग्रेशन) को स्वीकार करते हों। अधिक बार, प्रभावित पार्टीशनों को फिर से लिखा जाता है या एक रिपेयर की गई टेबल प्रकाशित की जाती है और डाउनस्ट्रीम संदर्भों को स्विच किया जाता है। मेटाडेटा पॉइंटर को स्थानांतरित करने से वह डेटा ठीक नहीं होता है जो पहले से ही अन्य तालिकाओं में भौतिक (मटेरियलाइज़) हो चुका है।
रिपेयर के बाद, विशिष्टता (यूनिकनेस), काउंट, राशि, लेटेंसी, और बिज़नेस समाधान (रिकॉन्सिलीएशन) जाँच को फिर से चलाएं। खराब स्नैपशॉट, रिपेयर स्नैपशॉट, और रॉ इवेंट्स की तुलना करें। रिपेयर वर्ज़न से डाउनस्ट्रीम टेबल की पुनर्गणना करें और नया स्नैपशॉट तथा कोड वर्ज़न रिकॉर्ड करें ताकि रन पुनरुत्पादित (रीप्रोड्यूसिबल) करने योग्य हो।
रिटेंशन में बैकफ़िल, समीक्षा, डाउनस्ट्रीम पुनर्गणना, और ऑडिट की समय-सीमा शामिल होनी चाहिए। बहुत जल्दी स्नैपशॉट समाप्त होने से टाइम ट्रैवल विफल हो सकता है। केवल वही फ़ाइलें हटाई जानी चाहिए जो अब बनाए रखे गए स्नैपशॉट द्वारा संदर्भित नहीं हैं, यह पुष्टि करने के बाद कि किसी भी पाठक को उनकी आवश्यकता नहीं है; ऑर्फ़न क्लीनअप को उन फ़ाइलों को नहीं हटाना चाहिए जो अभी भी किसी अनकमिटेड या समवर्ती जॉब द्वारा संदर्भित हैं।
स्नैपशॉट की आयु, कमिट विरोध, रोलबैक संख्या, ऑर्फ़न-फ़ाइल संख्या, एक्सपायरी विफलताएं, पार्टीशन गुणवत्ता, डाउनस्ट्रीम पुनर्गणना में देरी, और समाधान अंतराल की निगरानी करें। स्नैपशॉट ID, रन ID, कोड वर्ज़न, और इनपुट पार्टीशन को एक ऑडिट टेबल में लिखें ताकि परिणाम को उसके कमिट तक ट्रैक किया जा सके।
मॉडल उच्च-गुणवत्ता उत्तर
“मैं टेबल हिस्ट्री, स्नैपशॉट ID, और रन ID को सुरक्षित रखता हूँ, बैकफ़िल कमिट की पहचान करता हूँ, और प्रभावित पार्टीशनों को सीमित करने के लिए इसके पेरेंट और चाइल्ड के बीच टाइम-ट्रैवल क्वेरीज़ का उपयोग करता हूँ। यदि स्ट्रीमिंग राइट्स जारी रहते हैं, तो मैं विरोध रेंज को रोकता हूँ या रिपेयर को एक अलग टेबल में लिखता हूँ, कमिट समय पर पेरेंट स्नैपशॉट को वैलिडेट करता हूँ, और फ़ोर्स-ओवरराइट करने के बजाय विरोध पर फिर से पढ़ता हूँ।
यदि बाद के किसी भी मान्य कमिट को बनाए रखने की आवश्यकता नहीं है, तो मैं मेटाडेटा पॉइंटर को रोलबैक कर सकता हूँ; अन्यथा मैं पार्टीशनों को फिर से लिखता हूँ और एक रिपेयर स्नैपशॉट प्रकाशित करता हूँ। रोलबैक से डाउनस्ट्रीम मटेरियलाइज़्ड टेबल ठीक नहीं होती हैं, इसलिए मैं रिपेयर वर्ज़न से उनकी पुनर्गणना करता हूँ और गुणवत्ता तथा समाधान जाँच को फिर से चलाता हूँ। स्नैपशॉट एक्सपायरी और ऑर्फ़न क्लीनअप ऑडिट विंडो के बाद तक प्रतीक्षा करते हैं, और प्रत्येक स्नैपशॉट, कोड वर्ज़न, और इनपुट रेंज को रिकॉर्ड किया जाता है।”
सामान्य गलतियाँ
- इसके टाइमस्टैम्प से स्नैपशॉट का अनुमान लगाना → समवर्ती कमिट इंटरलीव हो सकते हैं → हिस्ट्री, पेरेंटेज, और रन ID का उपयोग करें।
- स्नैपशॉट को फ़ाइल बैकअप के रूप में मानना → रोलबैक डाउनस्ट्रीम टेबल को ठीक नहीं कर सकता है → मेटाडेटा पॉइंटर्स और व्युत्पन्न (डिराइव्ड) डेटा की सूची बनाएं।
- नवीनतम स्नैपशॉट को फ़ोर्स-ओवरराइट करना → मान्य समवर्ती राइट्स खो देना → पेरेंट की जाँच करें और विरोधों पर पुनः प्रयास करें।
- पुराने स्नैपशॉट को तुरंत साफ़ करना → टाइम ट्रैवल और ऑडिट साक्ष्य गायब हो जाते हैं → एक रिकवरी विंडो बनाए रखें।
- केवल नमूना पंक्तियों को मान्य करना → समग्र त्रुटियां बनी रहती हैं → पार्टीशन, मेट्रिक्स, विशिष्टता, और समाधान की जाँच करें।
- केवल मुख्य टेबल को रोलबैक करना → डाउनस्ट्रीम परिणाम गलत रहते हैं → रिपेयर वर्ज़न से व्युत्पन्न टेबल की पुनर्गणना करें।
- यह मान लेना कि ऑर्फ़न क्लीनअप हानिरहित है → समवर्ती जॉब्स अभी भी फ़ाइलों को संदर्भित कर सकते हैं → कमिट और रीडर स्थिति के साथ साफ़ करें।
- कोड और इनपुट वर्ज़न छोड़ना → रिपेयर को रीप्रोड्यूस नहीं किया जा सकता → ऑडिट डेटा में स्नैपशॉट, रन, और वर्ज़न को लिंक करें।
फ़ॉलो-अप प्रश्न और उत्तर
फ़ॉलो-अप 1: टेबल रोलबैक पार्टीशन रीराइट से बेहतर कब होता है?
केवल तब जब रोलबैक बिंदु के बाद के किसी भी मान्य कमिट को रखने की आवश्यकता न हो और रीडर्स अस्थायी रिग्रेशन को स्वीकार करते हों। अन्यथा पार्टीशनों को फिर से लिखें या एक रिपेयर की गई टेबल प्रकाशित करें।
फ़ॉलो-अप 2: टाइम ट्रैवल विफल क्यों हो सकता है?
लक्षित स्नैपशॉट समाप्त (एक्सपायर) हो गया हो सकता है, या उसकी फ़ाइलें हटा दी गई हो सकती हैं। रिटेंशन में जांच और पुनर्गणना शामिल होनी चाहिए, और क्लीनअप की निगरानी की जानी चाहिए।
फ़ॉलो-अप 3: आप नए स्ट्रीमिंग डेटा को ओवरराइट करने से कैसे बचते हैं?
रिपेयर को प्रभावित पार्टीशनों तक सीमित करें, परस्पर विरोधी राइटर्स को रोकें या कार्य को अलग करें, पेरेंट स्नैपशॉट को वैलिडेट करें, और विरोध के बाद नवीनतम वर्ज़न से पुनर्गणना करें।
फ़ॉलो-अप 4: क्या रोलबैक डाउनस्ट्रीम इवेंट्स को पूर्ववत (अनडू) करता है?
नहीं। यह टेबल के मेटाडेटा पॉइंटर को बदलता है। भेजे गए इवेंट्स, मटेरियलाइज़्ड टेबल, और बाहरी प्रभावों के लिए अलग से कंपेंसेशन या पुनर्गणना की आवश्यकता होती है।
फ़ॉलो-अप 5: स्नैपशॉट पूर्ण बैकअप से किस प्रकार भिन्न है?
एक स्नैपशॉट आमतौर पर फ़ाइल सेट का एक मेटाडेटा व्यू होता है और फ़ाइल रिटेंशन पर निर्भर करता है। एक पूर्ण बैकअप के लिए क्रॉस-स्टोरेज प्रतियां, कैटलॉग स्थिति, और रिकवरी प्रक्रिया की भी आवश्यकता होती है।
फ़ॉलो-अप 6: आप कैसे साबित करते हैं कि बैकफ़िल रिपेयर सही है?
इनपुट स्नैपशॉट और कोड वर्ज़न को पिन करें, पार्टीशनों को फिर से चलाएं, रॉ इवेंट्स और बिज़नेस मेट्रिक्स की तुलना करें, विशिष्टता और राशियों की जांच करें, समाधान करें, और समीक्षा के लिए रिपेयर स्नैपशॉट बनाए रखें।
फ़ॉलो-अप 7: कमिट विरोध क्यों मायने रखते हैं?
Iceberg कमिट एक पेरेंट स्नैपशॉट से अपडेट होते हैं। विरोधों को नज़रअंदाज़ करना और राइट को फ़ोर्स करना किसी अन्य जॉब के मान्य कमिट को खारिज कर सकता है; विरोध होने पर पुनः पढ़ने, पुनर्गणना, या मानवीय निर्णय की प्रक्रिया शुरू होनी चाहिए।