प्रतिनिधि इंटरव्यू विषय

डेटा इंजीनियरिंग इंटरव्यू: आप मेट्रिक डेफिनिशन, ग्रेन (grain) और जॉइन्स (joins) को कैसे गवर्न करते हैं?

डेटाकठिन
Offer.cc संपादकीय टीमप्रकाशित अपडेट किया गया

प्रश्न

रिपोर्ट्स के बीच DAU, रेवेन्यू और कन्वर्जन रेट्स में अंतर आ रहा है। आप डेफिनिशन, एंटिटी ग्रेन, टाइम विंडो और जॉइन्स को कैसे गवर्न करेंगे, डबल काउंटिंग को कैसे रोकेंगे, और किसी मेट्रिक को सुरक्षित रूप से कैसे माइग्रेट करेंगे?

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

अलग-अलग रिपोर्ट्स में DAU, रेवेन्यू और कन्वर्जन रेट मेल नहीं खाते हैं। एक गवर्न की गई सिमेंटिक लेयर (semantic layer) डिज़ाइन करें ताकि एनालिस्ट, BI, एप्लिकेशन और ऑटोमेटेड जॉब्स समान मेट्रिक डेफिनिशन साझा कर सकें।

मेट्रिक कॉन्ट्रैक्ट्स, एंटिटी ग्रेन, डायमेंशन्स, जॉइन ग्राफ्स, टाइम सिमेंटिक्स, वर्जन्स, परमिशन्स, कैशिंग, क्वालिटी टेस्ट्स और माइग्रेशन पर चर्चा करें। dbt या Looker को पहले से मानकर न चलें; वे इम्प्लीमेंटेशन के विकल्प हैं, समाधान नहीं। यह असंगति अभ्यास के लिए एक काल्पनिक परिदृश्य है।

इंटरव्यूअर क्या टेस्ट कर रहा है

सुसंगत डेफिनिशन (Consistent definitions)

किसी मेट्रिक के नाम को सिर्फ एक अन्य कॉपी की गई SQL क्वेरी बनाने के बजाय उसे न्यूमरेटर, डिनॉमिनेटर, फिल्टर्स, टाइम विंडो, डिडुप्लिकेशन और डिफॉल्ट डायमेंशन्स में बदलना।

ग्रेन और जॉइन्स (Grain and joins)

फैक्ट-टेबल के ग्रेन की पहचान करना, मेनी-टू-मेनी (many-to-many) डुप्लिकेशन को रोकना, और ऐसे संयोजनों को अस्वीकार करना जो सिमेंटिक रूप से कंपोज़ करने योग्य नहीं हैं।

गवर्नेंस और बदलाव (Governance and change)

डेफिनिशन के लिए वर्जन कंट्रोल, रिव्यू, डिप्रिकेशन (deprecation) और कम्पैटिबिलिटी विंडो की आवश्यकता होती है। BI यूज़र्स को सत्य का दूसरा स्रोत (second source of truth) नहीं बनाना चाहिए।

उपयोगिता (Usability)

सिमेंटिक लेयर को मशीन-रीडेबल कॉन्ट्रैक्ट्स और ओनर्स, उदाहरणों और क्वालिटी स्टेटस वाले ह्यूमन डॉक्यूमेंटेशन की आवश्यकता होती है।

पहले स्पष्ट करने योग्य प्रश्न

  • DAU, रेवेन्यू और कन्वर्जन का वास्तव में क्या अर्थ है?
  • क्या कंज्यूमर्स को SQL, एक API, एक BI एक्सप्लोरर, या एम्बेडेड चार्ट्स की आवश्यकता है?
  • सोर्स ग्रेन और टाइमज़ोन क्या हैं?
  • क्या नियर-रियल-टाइम और अंतिम संशोधित (revised) वैल्यूज़ एक साथ रह सकती हैं?
  • क्या परमिशन्स डेटासेट, रो, कॉलम या डायमेंशन लेवल पर हैं?
  • लेगेसी रिपोर्ट्स को कब तक कम्पैटिबल रहना चाहिए?

30-सेकंड का उत्तर

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

डेफिनिशन की समीक्षा वर्जन कंट्रोल में की जाती है, जिसमें पुराने वर्जन और डिप्रिकेशन विंडो शामिल होती है। SQL APIs और BI एडेप्टर डेफिनिशन वर्जन और फ्रेशनेस लौटाते हैं। टेस्ट्स में फिक्सचर्स, रीकॉन्सिलीएशन, डुप्लिकेट जॉइन्स, लेटेंसी, परमिशन्स और हिस्टोरिकल रिग्रेशन्स शामिल हैं।”

स्टेप-बाय-स्टेप विस्तृत उत्तर

स्टेप 1: उपयोग के मामलों (use cases) की सूची बनाएं

रिपोर्ट्स, अलर्ट्स, प्रोडक्ट्स और प्रयोगों द्वारा आवश्यक क्वेरीज़, लेटेंसी और प्रिसिजन को लिस्ट करें। प्रत्येक SQL फ़ाइल को माइग्रेट करने से पहले दो या तीन हाई-वैल्यू मेट्रिक्स का पायलट परीक्षण करें।

स्टेप 2: कॉन्ट्रैक्ट लिखें

मेट्रिक का नाम, व्यावसायिक अर्थ, माप (measure), फिल्टर्स, टाइम विंडो, टाइमज़ोन, एंटिटी, डायमेंशन्स, ओनर, संवेदनशीलता, वर्जन और फ्रेशनेस SLO रिकॉर्ड करें।

स्टेप 3: ग्रेन और जॉइन्स को मॉडल करें

प्रत्येक मॉडल की प्राइमरी की (primary key) और ग्रेन को डिक्लेयर करें। केवल उन्हीं जॉइन्स को अनुमति दें जिनकी कार्डिनैलिटी और एग्रीगेशन दिशा सुरक्षित हो; मेनी-टू-मेनी पाथ्स को प्री-एग्रीगेट करें, ब्रिज करें या अस्वीकार करें।

स्टेप 4: समय और संशोधनों (revisions) को संभालें

इवेंट टाइम, प्रोसेसिंग टाइम, टाइमज़ोन, लेट डेटा और फाइनल रिवीजन नियमों को परिभाषित करें। नियर-रियल-टाइम परिणामों में फ्रेशनेस और फाइनल स्टेटस स्पष्ट होना चाहिए।

स्टेप 5: रिलीज़ और ऑथराइज़ करें

डेफिनिशन को वर्जन कंट्रोल में स्टोर करें और ओनर व डेटा-क्वालिटी रिव्यू के बाद पब्लिश करें। डेटासेट्स, रो, कॉलम और डायमेंशन्स को ऑथराइज़ करें; संवेदनशील मेट्रिक्स तक एक्सेस का ऑडिट करें। पुराने वर्जन्स के लिए माइग्रेशन की समय सीमा निर्धारित करें।

स्टेप 6: टेस्ट करें और सर्व करें

फिक्सचर्स, रीकॉन्सिलीएशन सैंपल्स, डुप्लिकेट-जॉइन चेक्स, फ्रेशनेस, नल (null) और डिस्ट्रीब्यूशन टेस्ट्स का उपयोग करें। वर्जन, टाइमज़ोन और क्वालिटी स्टेटस के साथ SQL, BI या एम्बेडेड APIs के माध्यम से वैल्यूज़ लौटाएं।

मॉडल उत्तर

“मैं DAU और रेवेन्यू का पायलट टेस्ट करूँगा। प्रत्येक डेफिनिशन में न्यूमरेटर, डिनॉमिनेटर, फिल्टर्स, इवेंट टाइम, टाइमज़ोन, एंटिटी ग्रेन, अनुमत डायमेंशन्स, ओनर, संवेदनशीलता, वर्जन और फ्रेशनेस रिकॉर्ड होगी। DAU में यह स्पष्ट होना चाहिए कि क्या यह लोगों को डिडुप्लिकेट करता है या डिवाइसेज़ को; रेवेन्यू में रिकॉग्निशन, रिफंड और टैक्स को परिभाषित किया जाना चाहिए।

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

वैलिडेशन में रीकॉन्सिलीएशन सैंपल्स, डुप्लिकेट काउंट्स, लेट डेटा, टाइमज़ोन, परमिशन्स, फ्रेशनेस और हिस्टोरिकल रिग्रेशन शामिल हैं। एक साथ प्रत्येक SQL क्वेरी को फिर से लिखने के बजाय पहले हाई-वैल्यू रिपोर्ट्स को माइग्रेट करें और पुराने व नए परिणामों के बीच के अंतर को स्पष्ट करें।”

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

  • बिना न्यूमरेटर, डिनॉमिनेटर और फिल्टर्स के केवल मेट्रिक नाम स्टोर करना।
  • विभिन्न फैक्ट ग्रेन्स को छिपाने के लिए एक चौड़ी टेबल (wide table) का उपयोग करना।
  • ऐसे मनमाने जॉइन्स की अनुमति देना जो फैक्ट्स को डुप्लिकेट करते हैं।
  • इवेंट टाइम, प्रोसेसिंग टाइम और टाइमज़ोन को मिलाना।
  • वर्जन्स, ओनर्स, डिप्रिकेशन और माइग्रेशन विंडोज़ को छोड़ देना।
  • रिजल्ट रीकॉन्सिलीएशन या फ्रेशनेस के बिना केवल क्वेरी की सफलता का परीक्षण करना।
  • मशीन-रीडेबल कॉन्ट्रैक्ट के बिना केवल एक BI प्लग-इन बनाना।
  • डैशबोर्ड को सुरक्षित करना लेकिन अंतर्निहित डायमेंशन्स या क्वेरी ऑडिट की उपेक्षा करना।

फॉलो-अप प्रश्न

फॉलो-अप 1: आप रेवेन्यू डुप्लिकेशन को कैसे रोकते हैं?

रेवेन्यू ग्रेन और यूनिक की (unique key) डिक्लेयर करें, जॉइन्स से पहले टार्गेट एंटिटी में प्री-एग्रीगेट करें, असुरक्षित मेनी-टू-मेनी पाथ्स को अस्वीकार करें, और ज्ञात टोटल्स के साथ रीकॉन्साइल करें।

फॉलो-अप 2: क्या डेफिनिशन में बदलाव डाउनस्ट्रीम यूज़र्स को प्रभावित (break) कर सकता है?

एक नया वर्जन या कम्पैटिबल फ़ील्ड पब्लिश करें, समय सीमा तक पुराने वर्जन को बनाए रखें, रिस्पॉन्स में वर्जन शामिल करें, और ओनर व कंज्यूमर की मंज़ूरी अनिवार्य करें।

फॉलो-अप 3: नियर-रियल-टाइम और फाइनल वैल्यूज़ एक साथ कैसे रह सकती हैं?

फ्रेशनेस, वॉटरमार्क (watermark) और फाइनल स्टेटस के साथ वैल्यू लौटाएं। कंज्यूमर्स एक अनंतिम (provisional) वैल्यू को अंतिम वित्तीय डेटा मानने के बजाय स्वीकार्य लेटेंसी और रिवीजन सिमेंटिक्स चुनते हैं।

फॉलो-अप 4: आप मेट्रिक्स को कैसे ऑथराइज़ करते हैं?

डेटासेट, रो, कॉलम और डायमेंशन नीतियों को न्यूनतम विशेषाधिकार (least privilege) के साथ जोड़ें। रिक्वेस्टर, डेफिनिशन वर्जन और एक्सपोर्ट को रिकॉर्ड करें, फिर नियमित रूप से ऑडिट करें।

फॉलो-अप 5: आप कैसे साबित करते हैं कि लेयर वैल्यू बना रही है?

माइग्रेशन से पहले और बाद में डेफिनिशन कॉन्फ्लिक्ट्स, डुप्लिकेट SQL, रीकॉन्सिलीएशन अंतर, क्वेरी सफलता, फ्रेशनेस, एडॉप्शन और घटनाओं की तुलना करें, साथ ही यह जांचें कि यूज़र्स परिणामों को समझा सकते हैं या नहीं।

सार्वजनिक स्रोत

संबंधित प्रश्न