डेटा इंजीनियरिंग इंटरव्यू: BI, नोटबुक्स और APIs एक गवर्न की गई सिमेंटिक लेयर कैसे साझा करते हैं?

प्रॉम्प्ट और दायरा

एक कंपनी पाती है कि "active customer," "revenue," और "retention" अलग-अलग डैशबोर्ड में अलग-अलग SQL का उपयोग करते हैं। BI, नोटबुक्स, APIs और भविष्य के ऑटोमेशन एजेंट्स द्वारा साझा की जाने वाली एक सिमेंटिक लेयर डिज़ाइन करें। इसे डायमेंशन्स, टाइम ग्रेन्स, फिल्टर्स, परमिशन्स, ऐतिहासिक वर्जन्स और नियर-रियल-टाइम डेटा का समर्थन करना चाहिए। बताएं कि एक और अनटेस्टेबल रिपोर्टिंग प्लेटफॉर्म बनाने से कैसे बचा जाए।

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

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

उत्तर देने से पहले स्पष्टीकरण

1. फैक्ट ग्रेन (fact grain) क्या है? ऑर्डर्स, ऑर्डर लाइन्स और इवेंट्स को मिलाने से रेवेन्यू की दोहरी गिनती हो सकती है।
2. किन डायमेंशन्स और टाइम ग्रेन्स की आवश्यकता है? हर संयोजन सुरक्षित नहीं है; एक सपोर्ट मैट्रिक्स पब्लिश करें।
3. फ्रेशनेस और कंसिस्टेंसी के लक्ष्य क्या हैं? स्ट्रीमिंग, दैनिक बैच और बैकफिल डेटा की विजिबिलिटी स्टेट्स अलग-अलग होती हैं।
4. परिभाषाएं कौन पब्लिश कर सकता है और संवेदनशील डायमेंशन्स कौन पढ़ सकता है? मेट्रिक परमिशन्स को रो- या कॉलम-लेवल सिक्योरिटी को बायपास नहीं करना चाहिए।
5. क्या ऐतिहासिक परिभाषाएं पुनरुत्पादित (reproducible) होनी चाहिए, या केवल वर्तमान परिभाषा की आवश्यकता है? यह वर्जन रूटिंग, स्नैपशॉट्स और रीकंप्यूटेशन लागत निर्धारित करता है।

अनुशंसित डिज़ाइन और व्युत्पत्ति

एक इम्यूटिएबल मेट्रिक-डेफिनिशन एंटिटी बनाएं: नाम, विवरण, मेजर एक्सप्रेशन, डिफॉल्ट एग्रीगेशन, डायमेंशन्स, टाइम सिमेंटिक्स, फिल्टर्स, सोर्स, ओनर, वर्जन, स्टेट और क्वालिटी SLO। एक क्वेरी एक मेट्रिक ID, डायमेंशन्स और टाइम विंडो को संदर्भित करती है; एक कंपाइलर SQL जनरेट करता है या प्री-एग्रीगेटेड टेबल पर रूट करता है।

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

metric: active_customers
version: 3
owner: growth-data
source: mart_customer_daily
measure: count_distinct(customer_id)
dimensions: [plan, region]
time_grain: [day, week, month]
freshness_slo: 2h
status: published

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

विकल्प और ट्रेड-ऑफ़

प्रत्येक BI टूल में लॉजिक एम्बेड करना तेजी से शिप होता है लेकिन डेफिनिशन्स को विभाजित (fork) कर देता है। एक सिंगल फिजिकल क्यूरेटेड डेटासेट सरल है लेकिन हर ग्रेन या परमिशन को व्यक्त नहीं कर सकता। एक सेंट्रल सिमेंटिक लेयर कंपाइलर, वर्जन गवर्नेंस, परमिशन मैपिंग और डिबगिंग की कीमत पर निरंतरता और पुन: प्रयोज्य APIs प्रदान करती है। एक छोटी टीम मल्टी-टूल एक्सेस खोलने से पहले कुछ मुख्य मेट्रिक्स और एक कंज्यूमर के साथ शुरुआत कर सकती है।

विफलता के तरीके, सीमाएं और विरोधी उदाहरण

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

टेस्ट और सत्यापन चेकलिस्ट

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

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

आप ब्रेकिंग मेट्रिक-डेफिनिशन परिवर्तन को कैसे संभालते हैं?

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

यह लेयर नियर-रियल-टाइम और बैच डेटा को कैसे सर्व कर सकती है?

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

आप नेचुरल-लैंग्वेज एजेंट्स को मेट्रिक्स का दुरुपयोग करने से कैसे रोकते हैं?

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