डेटा इंजीनियरिंग इंटरव्यू: आप मेट्रिक वर्ज़निंग और डेप्रिकेशन कॉन्ट्रैक्ट कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और संदर्भ

एक मुख्य रेवेन्यू मेट्रिक के रिफंड ट्रीटमेंट में सुधार की आवश्यकता है, जबकि सैकड़ों डैशबोर्ड, अलर्ट और डेटा उत्पाद अभी भी पुरानी परिभाषा का उपयोग कर रहे हैं। एक ऐसा मेट्रिक वर्ज़निंग और डेप्रिकेशन कॉन्ट्रैक्ट डिज़ाइन करें जो इस बदलाव को समझाने योग्य (explainable), माइग्रेट करने योग्य (migratable) और रिवर्स करने योग्य (reversible) बनाए।

अपने उत्तर को किसी एक कैटलॉग या सिमेंटिक-लेयर वेंडर तक सीमित न रखें। परिभाषाओं, डिपेंडेंसीज़, कम्पैटिबिलिटी विंडोज़, रिलीज़ गेट्स, उपभोक्ता सूचनाओं (consumer notices) और रिटायरमेंट साक्ष्यों पर ध्यान केंद्रित करें।

इंटरव्यूअर क्या मूल्यांकन करता है

सिमेंटिक सीमाएं (Semantic boundaries)

क्या आप SQL को चुपचाप बदलने के बजाय मेट्रिक नाम को एक ऐसे कॉन्ट्रैक्ट में बदल सकते हैं जिसमें फ़ॉर्मूला, फ़िल्टर, टाइम सिमेंटिक्स, ग्रैन (grain), यूनिट, टाइमज़ोन, वर्ज़न और ओनर शामिल हों?

प्रभाव विश्लेषण (Impact analysis)

क्या आप प्रत्यक्ष और अप्रत्यक्ष डिपेंडेंसीज़ के बीच अंतर करते हुए डैशबोर्ड, अलर्ट, एक्सपोर्ट, मॉडल और APIs को सूचीबद्ध कर सकते हैं?

माइग्रेशन गवर्नेंस (Migration governance)

क्या आप अचानक होने वाले ब्रेकडाउन (big-bang break) के बजाय समय सीमा, अप्रूवर्स और माइग्रेशन स्टेटस के साथ पुराने और नए वर्ज़न्स को एक साथ चला सकते हैं?

सत्यापन योग्य रिटायरमेंट (Verifiable retirement)

क्या आप यूसेज, रीकॉन्सिलिएशन, अलर्ट रीप्ले और पुराने कॉल्स के समाप्त होने के सबूत के साथ रिटायरमेंट साबित कर सकते हैं?

पूछे जाने वाले स्पष्टीकरण प्रश्न

क्या यह बदलाव कोई बग फिक्स है, बिज़नेस-डेफिनिशन में बदलाव है, या कोई सोर्स माइग्रेशन है?
क्या फाइनेंस, ऑडिट, ऐतिहासिक रीकंप्यूटेशन, या कानूनी डेटा रिटेंशन के लिए पुरानी मेट्रिक की आवश्यकता है?
क्या उपभोक्ता SQL, BI, APIs, एक्सपोर्ट्स, या मशीन लर्निंग फीचर्स का उपयोग करते हैं?
क्या कोई क्रॉस-टीम या बाहरी-ग्राहक SLA है?
दोनों वर्ज़न कितने समय तक चल सकते हैं, और इस विंडो को कौन बढ़ा सकता है?
यदि वैल्यूज़ में अंतर आता है, तो क्या हम डेफिनिशन, डेटा या प्रेजेंटेशन लेयर को रोलबैक करते हैं?

30-सेकंड का उत्तर ढांचा (Framework)

“मैं मेट्रिक परिभाषा को एक वर्ज़न्ड कॉन्ट्रैक्ट मानूंगा जिसमें फ़ॉर्मूला, फ़िल्टर, ग्रैन, टाइम सिमेंटिक्स और ओनर शामिल हों। सबसे पहले मैं एक डिपेंडेंसी ग्राफ और यूसेज स्नैपशॉट बनाऊंगा, फिर पुराने वर्ज़न को बनाए रखते हुए एक नया वर्ज़न पब्लिश करूंगा; प्रत्येक रिस्पॉन्स वर्ज़न और प्रभावी समय को प्रदर्शित करेगा। माइग्रेशन में उच्च जोखिम वाले उपभोक्ताओं को प्राथमिकता दी जाएगी और फिक्स्ड सैंपल्स, ऐतिहासिक रीप्ले और रीकॉन्सिलिएशन का उपयोग किया जाएगा। डेप्रिकेशन के दौरान मैं ओनर्स को सूचित करूंगा और नए उपयोग को ब्लॉक करूंगा। मैं पुराने कॉल्स के शून्य होने, क्रिटिकल उपभोक्ताओं द्वारा पुष्टि करने और ऑडिट रिकॉर्ड्स के पूरा होने के बाद ही इसे रिटायर करूंगा, साथ ही रिकवर करने योग्य परिभाषाओं और रिज़ल्ट स्नैपशॉट्स को बनाए रखूंगा।”

चरण-दर-चरण विस्तृत विवरण

स्टेप 1: वर्तमान कॉन्ट्रैक्ट को फ़्रीज़ करें

पुराने वर्ज़न का नाम, फ़ॉर्मूला, फ़िल्टर, ग्रैन, यूनिट, टाइमज़ोन, सोर्स, फ्रेशनेस, ओनर, संवेदनशीलता और प्रभावी समय रिकॉर्ड करें। प्रत्येक परिवर्तन के लिए एक इम्यूटेबल (immutable) वर्ज़न बनाएं; कभी भी चुपचाप ओवरराइट न करें।

स्टेप 2: डिपेंडेंसी और रिस्क ग्राफ बनाएं

सिमेंटिक लेयर, क्वेरी लॉग्स, BI मेटाडेटा, शेड्यूल्ड जॉब्स, अलर्ट डेफिनिशन्स और API कॉल्स से डिपेंडेंसीज़ एकत्र करें। फाइनेंस, ग्राहक-दृश्यमान, नियर-रियल-टाइम और मशीन लर्निंग उपभोक्ताओं को चिह्नित करें, फिर प्रभाव और उपयोग के आधार पर माइग्रेशन को रैंक करें।

स्टेप 3: कम्पैटिबिलिटी को परिभाषित करें

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

स्टेप 4: नई रिलीज़ के लिए गेट्स (Gates) निर्धारित करें

नए वर्ज़न को एक सैंडबॉक्स में और उपभोक्ताओं के एक छोटे समूह के साथ चलाएं। गेट्स एक्सप्रेशन पार्सिंग, सैंपल वैल्यूज़, ऐतिहासिक रीप्ले, नल (nulls), यूनिट्स, परमिशन, लेटेंसी और लागत की जांच करते हैं। विस्तार से पहले ओनर्स और प्रभावित उपभोक्ता मंज़ूरी देते हैं।

स्टेप 5: माइग्रेट करें और सूचित करें

प्रत्येक डिपेंडेंसी को एक ओनर, समय सीमा और स्टेटस असाइन करें। पुराने वर्ज़न के उपयोगकर्ताओं को सूचित करने के लिए कैटलॉग स्टेटस, CI चेक्स, क्वेरी हिंट्स और रिकरिंग रिपोर्ट्स का उपयोग करें। नए डैशबोर्ड को पुराने वर्ज़न को संदर्भित करने से रोकें; अपवादों के लिए एक समाप्ति तिथि आवश्यक है।

स्टेप 6: स्वीकार करें, रोलबैक करें और रिटायर करें

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

एक सशक्त नमूना उत्तर

“मैं रेवेन्यू की वर्तमान परिभाषा को v1 के रूप में फ़्रीज़ करूंगा, जिसमें रिकॉग्निशन टाइम, रिफंड ट्रीटमेंट, करेंसी, टाइमज़ोन, ग्रैन और ओनर का स्पष्ट रूप से दस्तावेज़ीकरण होगा। क्वेरी लॉग्स और कैटलॉग मेटाडेटा एक डिपेंडेंसी ग्राफ तैयार करेंगे, जिसमें वित्तीय रिपोर्ट, ग्राहक चालान (invoices) और अलर्ट्स को उच्च जोखिम के रूप में चिह्नित किया जाएगा।

यदि रिफंड को सही करने से फ़ॉर्मूला बदलता है, तो मैं v1 को ओवरराइट करने के बजाय v2 पब्लिश करूंगा। दोनों वर्ज़न समानांतर में चलेंगे, और वैल्यूज़ में वर्ज़न, यूनिट और फ्रेशनेस शामिल होगी। CI नए v1 संदर्भों को ब्लॉक करेगा, जबकि माइग्रेशन सूची में ओनर्स और समय सीमा दर्ज होगी। मैं ज्ञात ऑर्डर्स और फिक्स्ड महीनों का रीकॉन्सिलिएशन करूंगा, फिर अलर्ट, एक्सपोर्ट और APIs को रीप्ले करूंगा; प्रत्येक अंतर के लिए एक स्पष्टीकरण आवश्यक है।

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

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

समान नाम वाले SQL को एडिट करना जिससे ऐतिहासिक रिपोर्ट का अर्थ चुपचाप बदल जाए।
केवल कैटलॉग संदर्भों का निरीक्षण करना और क्वेरी लॉग्स, अलर्ट, एक्सपोर्ट्स या APIs को छोड़ देना।
पुराने और नए वर्ज़न्स के लिए एक ही कैश की (cache key) या रिज़ल्ट टेबल का पुन: उपयोग करना।
यूनिट, टाइमज़ोन, ग्रैन या वर्ज़न फ़ील्ड्स को छोड़ देना और उपभोक्ताओं को अनुमान लगाने पर मजबूर करना।
बिना ओनर, समय सीमा या प्रवर्तन (enforcement) के घोषणा भेजना।
किसी महत्वपूर्ण महीने या उच्च जोखिम वाले ग्राहक के विचलन को छिपाने के लिए औसत अंतर का उपयोग करना।
ऐतिहासिक स्पष्टीकरण या रोलबैक संभव होने से पहले पुरानी परिभाषा को हटाना।
उपयोग में एक बार आई गिरावट को सबूत मानना और बैच जॉब्स तथा कभी-कभार होने वाली ऑडिट क्वेरीज़ को अनदेखा करना।

फॉलो-अप प्रश्न और उत्तर

फॉलो-अप 1: ब्रेकिंग चेंज (Breaking change) किसे माना जाता है?

फ़ॉर्मूला, फ़िल्टर, ग्रैन, यूनिट, टाइमज़ोन, सोर्स-विश्वसनीयता, या परमिशन-सिमेंटिक्स में बदलाव एक ब्रेकिंग चेंज है। एलियास या विवरण में संपादन केवल तभी कम्पैटिबल होता है जब रिज़ल्ट कॉन्ट्रैक्ट अपरिवर्तित रहता है।

फॉलो-अप 2: आप नए डैशबोर्ड्स को पुराने वर्ज़न को अपनाने से कैसे रोकते हैं?

पुराने वर्ज़न को डेप्रिकेटेड के रूप में चिह्नित करें, और CI तथा सिमेंटिक लेयर से नए संदर्भों को अस्वीकार करवाएं। क्वेरी हिंट्स प्रतिस्थापन (replacement) दिखाते हैं; अपवादों के लिए ओनर, कारण और समाप्ति तिथि की आवश्यकता होती है।

फॉलो-अप 3: आप यह कैसे दिखाते हैं कि संख्यात्मक अंतर कोई बग नहीं है?

फिक्स्ड सैंपल्स, ऐतिहासिक विंडोज़, बाउंड्री ऑर्डर्स और रीकॉन्सिलिएशन टोटल्स को रीप्ले करें। रिफंड, विलंबता, करेंसी और टाइमज़ोन के आधार पर अंतर को अलग-अलग स्पष्ट करें, फिर बिज़नेस ओनर से साइन-ऑफ प्राप्त करें।

फॉलो-अप 4: क्या होगा यदि कोई कम आवृत्ति (low-frequency) वाला उपभोक्ता कभी माइग्रेट ही न करे?

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

फॉलो-अप 5: क्या आप रिटायरमेंट के बाद ऐतिहासिक प्रश्नों के उत्तर दे सकते हैं?

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