प्रॉम्प्ट और दायरा
यह डेटा-प्लेटफ़ॉर्म और एनालिटिक्स-इंजीनियरिंग का एक सामान्य डिज़ाइन प्रश्न है। इसका उद्देश्य केवल कुछ चेक्स की सूची बनाने के बजाय "विश्वसनीय डेटा" को मापने योग्य आयामों में विभाजित करना और उन्हें उपभोक्ता के उपयोग व समाधान (remediation) से जोड़ना है।
इंटरव्यूअर क्या मूल्यांकन कर रहा है
- क्या आप फ्रेशनेस, कम्प्लीटनेस, वैलिडिटी, एक्यूरेसी, कंसिस्टेंसी और यूनीकनेस में अंतर करते हैं।
- क्या लक्ष्य किसी एक वैश्विक थ्रेशोल्ड के बजाय प्रत्येक डेटा उत्पाद और उपभोक्ता को दर्शाते हैं।
- क्या डिटेक्शन, गंभीरता-आधारित अलर्टिंग, डाउनस्ट्रीम ब्लॉकिंग और रिकवरी को एक साथ डिज़ाइन किया गया है।
- क्या क्वालिटी साक्ष्य, वर्ज़न और लाइनेज (lineage) को बनाए रखा गया है ताकि अलर्ट कार्रवाई-योग्य बने रहें।
पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
बैच बनाम स्ट्रीमिंग इनपुट, इवेंट टाइम बनाम अराइवल टाइम, ग्राहकों, वित्त या मॉडल द्वारा उपयोग की जाने वाली टेबल या फ़ील्ड, सहन करने योग्य देरी, देर से आने वाले पार्टिशन और टाइम ज़ोन, और क्या किसी घटना (incident) के दौरान उपभोक्ताओं को ब्लॉक होना चाहिए, डिग्रेड होना चाहिए, या अंतिम विश्वसनीय स्नैपशॉट दिखाना चाहिए, इसकी पुष्टि करें।
30-सेकंड की उत्तर संरचना
मैं उपभोक्ता उपयोग के आधार पर एक डेटा अनुबंध (data contract) परिभाषित करूँगा, फिर प्रत्येक डेटासेट के लिए फ्रेशनेस, वॉल्यूम, कम्प्लीटनेस और वैलिडिटी चेक्स कॉन्फ़िगर करूँगा। पाइपलाइन क्वालिटी परिणामों और लाइनेज को स्टोर करती है, चेतावनियों और ब्लॉकिंग विफलताओं को मालिकों तक पहुँचाती है, और डाउनस्ट्रीम जॉब्स को क्वालिटी स्थिति पढ़ने देती है। ब्लॉक की गई रिलीज़ के लिए, उपभोक्ताओं को टाइमस्टैम्प वाला विश्वसनीय स्नैपशॉट मिलता है; रिकवरी घटना को समाप्त करने के लिए बैकफ़िल, पुनः गणना और मिलान (reconciliation) का उपयोग करती है।
विस्तृत उत्तर
1. क्वालिटी आयामों को उपयोग से जोड़ें
फ्रेशनेस यह जांचती है कि नवीनतम उपयोग योग्य डेटा कब तैयार किया गया था; कम्प्लीटनेस यह जांचती है कि क्या आवश्यक फ़ील्ड या पार्टिशन आ गए हैं; वॉल्यूम अपेक्षित पंक्तियों या बाइट्स की जांच करता है; वैलिडिटी फ़ॉर्मेट और रेंज की जांच करती है; कंसिस्टेंसी टेबल के बीच संबंधों की जांच करती है; यूनीकनेस डुप्लिकेट की जांच करती है। सेटलमेंट, ऑपरेशनल डैशबोर्ड और ऑफ़लाइन ट्रेनिंग के लिए थ्रेशोल्ड अलग-अलग होने चाहिए।
2. निष्पादन योग्य SLAs और SLOs परिभाषित करें
प्रत्येक डेटासेट के लिए एक व्यावसायिक समय सीमा (deadline), अधिकतम देरी, सहन करने योग्य मिसिंग अनुपात, ब्लॉकिंग शर्त, मालिक और एस्केलेशन समय रिकॉर्ड करें। "डेटा आ गया लेकिन वैलिडेशन विफल रहा" को "अपस्ट्रीम ने कोई नया डेटा उत्पन्न नहीं किया" से अलग ट्रैक करें। देर से आने वाले डेटा को एक सीमित बैकफ़िल विंडो दें; इसके समाप्त होने के बाद, हमेशा के लिए प्रतीक्षा करने के बजाय पार्टिशन को अनुपलब्ध (unavailable) चिह्नित करें।
3. वर्ज़न-युक्त साक्ष्य स्टोर करें
नियम वर्ज़न, बैच या पार्टिशन, प्रेक्षित मान (observed value), थ्रेशोल्ड, रन टाइम, इनपुट और आउटपुट लाइनेज, और परिणाम को सुरक्षित रखें। Expectations या कोई अन्य डिक्लेरेटिव सिस्टम चेक्स को परिभाषित कर सकता है, जबकि एक क्वेरी-सक्षम क्वालिटी लेज़र विफलताओं को ऑडिट योग्य बनाता है। ऐतिहासिक बेसलाइन के विरुद्ध एक नए थ्रेशोल्ड का मूल्यांकन करें ताकि कॉन्फ़िगरेशन परिवर्तन किसी रिग्रेशन को छिपा न सके।
4. अलर्टिंग, ब्लॉकिंग और डिग्रेडेशन डिज़ाइन करें
डेटा मालिकों, प्लेटफ़ॉर्म ऑन-कॉल और व्यावसायिक उपभोक्ताओं को प्रभाव और गंभीरता के आधार पर अलर्ट भेजें। एक पुनर्प्राप्ति योग्य (recoverable) मिसिंग पार्टिशन को विलंबित चिह्नित किया जा सकता है जबकि एक विश्वसनीय स्नैपशॉट उपलब्ध रहता है; ऐसी विफलता जो वित्त या किसी मॉडल को दूषित कर सकती है, उसे पब्लिकेशन को ब्लॉक कर देना चाहिए। प्रत्येक ब्लॉक के लिए एस्केलेशन, अनुमोदन और रिलीज़ शर्तों की आवश्यकता होती है ताकि उपभोक्ता इसे आसानी से बायपास न कर सकें।
5. बैकफ़िल और मिलान के साथ प्रक्रिया पूर्ण करें
अपस्ट्रीम को ठीक करने के बाद, पार्टिशन या व्यावसायिक समय के अनुसार बैकफ़िल करें, समान ट्रांसफ़ॉर्मेशन और नियम वर्ज़न को फिर से चलाएं, और डुप्लिकेट राइट्स को रोकने के लिए एक रिपेयर बैच रिकॉर्ड करें। इनपुट पंक्तियों, आउटपुट पंक्तियों, अस्वीकृत (rejects), देर से आए रिकॉर्ड और डाउनस्ट्रीम उपभोग का मिलान करें। घटना को तभी बंद करें जब मेट्रिक्स बेसलाइन पर वापस आ जाएं, फिर समीक्षा में नियमों, थ्रेशोल्ड या ओनरशिप को समायोजित करें।
एक मजबूत उत्तर का उदाहरण
मैं उपभोक्ता के आधार पर अनुबंध को परिभाषित करूँगा। एक सेटलमेंट टेबल को अपनी दैनिक समय सीमा के एक घंटे के भीतर आवश्यक कम्प्लीटनेस थ्रेशोल्ड के साथ पहुंचना चाहिए, जबकि एक खोजपूर्ण (exploratory) डैशबोर्ड अधिक देरी सहन कर सकता है। प्रत्येक डेटासेट को फ्रेशनेस, पार्टिशन-काउंट, आवश्यक-फ़ील्ड, रेंज और क्रॉस-टेबल चेक्स मिलते हैं; प्रत्येक परिणाम नियम वर्ज़न, प्रेक्षण, बैच, लाइनेज और मालिक को स्टोर करता है। एक फ्रेशनेस टाइमआउट पहले चेतावनी देता है, लेकिन वित्त डेटा पर कम्प्लीटनेस की विफलता पब्लिकेशन को ब्लॉक कर देती है और एक टाइमस्टैम्प वाला विश्वसनीय स्नैपशॉट प्रस्तुत करती है। अपस्ट्रीम फिक्स के बाद, मैं व्यावसायिक समय के अनुसार बैकफ़िल करता हूँ, उसी ट्रांसफ़ॉर्मेशन और चेक्स का पुन: उपयोग करता हूँ, इनपुट, आउटपुट, रिजेक्ट्स और उपभोक्ता काउंट्स का मिलान करता हूँ, और मेट्रिक्स के ठीक होने पर ही घटना को बंद करता हूँ।
सामान्य गलतियाँ
- डेटा फ्रेश, पूर्ण और मान्य है या नहीं, इसकी जांच किए बिना केवल जॉब की सफलता की निगरानी करना।
- विभिन्न उपभोक्ताओं और समय सीमाओं वाले डेटासेट पर एक ही वैश्विक थ्रेशोल्ड लागू करना।
- क्वालिटी परिणामों को केवल लॉग में लिखना, बिना किसी बैच, नियम-वर्ज़न या लाइनेज लिंक के।
- केवल एक डेटासेट या पार्टिशन तक सीमित विफलता के लिए प्रत्येक डाउनस्ट्रीम उपभोक्ता को ब्लॉक करना।
- बैकफ़िल बैच, मिलान या डीडुप्लिकेशन गार्ड के बिना रिपेयर के दौरान इतिहास को ओवरराइट करना।
- एक ऐसा एकल स्कोर रिपोर्ट करना जो उपभोक्ताओं को यह नहीं बताता कि कौन सा आयाम अनुपलब्ध है।
फॉलो-अप प्रश्न
क्या होगा यदि अपस्ट्रीम जॉब सफल हो जाता है लेकिन कोई नया डेटा नहीं आता है?
आगमन समय और व्यावसायिक समय की अलग-अलग जांच करें, फिर अपेक्षित अपडेट आवृत्ति के साथ अंतिम विश्वसनीय पार्टिशन की तुलना करें। एक सफल जॉब केवल निष्पादन को साबित करता है, SLA अनुपालन को नहीं; एक टाइमआउट को क्वालिटी इंसिडेंट बनाना चाहिए।
आप क्वालिटी नियमों में फ़ॉल्स पॉज़िटिव को कैसे संभालते हैं?
प्रेक्षणों, थ्रेशोल्ड और नियम वर्ज़न को बनाए रखें; लागू करने से पहले शैडो मोड में बेसलाइन का निरीक्षण करें। टियर वाले थ्रेशोल्ड और विसंगति अनुपात का उपयोग करें, उपभोक्ता प्रभाव रिकॉर्ड करें, और अलर्ट को चुपचाप अक्षम करने के बजाय परिवर्तनों की समीक्षा करें।
क्या प्रत्येक विफलता को सभी डाउनस्ट्रीम सिस्टम को ब्लॉक करना चाहिए?
लाइनेज और उपयोग के आधार पर प्रतिक्रिया का दायरा तय करें। ऐसी विफलता जो सेटलमेंट या किसी मॉडल को दूषित कर सकती है, संबंधित पब्लिकेशन को ब्लॉक कर सकती है, जबकि एक स्वतंत्र खोजपूर्ण डेटासेट चेतावनी के साथ पिछले वर्ज़न का उपयोग कर सकता है। दायरा और रिलीज़ शर्त दोनों ऑडिट-योग्य होने चाहिए।
आप कैसे साबित करेंगे कि रिकवरी में पंक्तियाँ नहीं खोईं?
बैच, पार्टिशन, इनपुट और आउटपुट काउंट्स, रिजेक्ट्स, देर से आए रिकॉर्ड और डाउनस्ट्रीम उपभोग का मिलान करें, फिर प्राथमिक-कुंजी (primary-key) सेट का नमूना लें। रिपेयर बैच दोबारा चलाने योग्य (replayable) और ट्रेस करने योग्य होने चाहिए, और बार-बार निष्पादन से समान परिणाम मिलना चाहिए।