प्रॉम्प्ट और संदर्भ
टीम के पास पहले से ही एक चेंज स्ट्रीम मौजूद है और वह एक ऐसी डायनेमिक टेबल बनाए रखना चाहती है जो सॉफ्ट डिलीट, स्ट्रीम-स्टैटिक जॉइन या स्टेटफुल एग्रीगेशन को सपोर्ट करती हो। बताएं कि आप यह कैसे तय करेंगे कि क्या CUSTOM_INCREMENTAL उपयुक्त है, इंक्रीमेंटल लॉजिक को कैसे परिभाषित करेंगे, परिणामों को कैसे सत्यापित करेंगे और रोलबैक कैसे तैयार करेंगे। केवल Snowflake के रिलीज़ नोट को न दोहराएं।
इंटरव्यूअर क्या मूल्यांकन करता है
- यह समझ कि डेवलपर MERGE या INSERT लॉजिक को परिभाषित करता है, जबकि प्लेटफ़ॉर्म शेड्यूलिंग, पुनः प्रयास (retries) और ट्रांज़ैक्शनल गारंटी प्रदान करता है।
- इंक्रीमेंटल रिफ्रेश, फुल रिफ्रेश और स्ट्रीम/Task ऑर्केस्ट्रेशन के बीच अंतर करने की क्षमता।
- कीज़ (keys), परिवर्तनों का क्रम, डुप्लिकेट इवेंट्स, सॉफ्ट डिलीट और शुरुआती बैकफ़िल का प्रबंधन।
- रिफ्रेश लैग, पुनः प्रयास, लागत, ऑब्जर्वेबिलिटी और रोलबैक के बारे में संपूर्ण तर्क।
पूछे जाने वाले स्पष्टीकरण प्रश्न
- क्या स्रोत केवल-जोड़ने योग्य (append-only), CDC है, या इतिहास को सही करने में सक्षम है? क्या डिलीट होने पर टारगेट में एक टॉम्बस्टोन (tombstone) छूटना चाहिए?
- टारगेट टेबल की यूनिक की क्या है? डुप्लिकेट, देर से आने वाले और दोहराए गए अपडेट्स को कैसे क्रमबद्ध किया जाता है?
- क्या लॉजिक को इंक्रीमेंटल रूप से व्यक्त किया जा सकता है, या इसे समय-समय पर सब कुछ पुनर्गणना (recompute) करना होगा? कितना लैग स्वीकार्य है?
- पहली बार निर्माण, पुनः प्रयास, स्कीमा परिवर्तन और रोलबैक के दौरान परिणामों का मिलान और अलर्ट कौन करता है?
30-सेकंड उत्तर फ्रेमवर्क
मैं पहले यह सत्यापित करूंगा कि परिवर्तनों को स्थिर कीज़ और वॉटरमार्क द्वारा दर्शाया जा सकता है, फिर परीक्षण करूंगा कि क्या कस्टम इंक्रीमेंटल लॉजिक टारगेट को सुरक्षित रूप से बनाए रख सकता है। यदि यह उपयुक्त है, तो मैं प्रत्येक रिफ्रेश के लिए चेंज रेंज, आइडेम्पोटेंट MERGE/INSERT शर्तें, सॉफ्ट-डिलीट व्यवहार और देर से आने वाले इवेंट्स की नीति निर्दिष्ट करूंगा। मैं इंक्रीमेंटल आउटपुट का मिलान सैंपल्ड फुल-रिफ्रेश परिणामों के साथ करूंगा। प्लेटफ़ॉर्म शेड्यूलिंग, पुनः प्रयास और ट्रांज़ैक्शन व्यावसायिक क्रम या डिलीशन सेमेंटिक्स को परिभाषित नहीं करते हैं। लॉन्च से पहले, मैं लैग, विफलताओं, मानक रिफ्रेश पर फ़ॉलबैक और पूर्ण पुनर्निर्माण (rebuilds) के लिए मेट्रिक्स और नियंत्रण निर्धारित करूंगा।
चरण-दर-चरण विस्तृत विश्लेषण
1. इंक्रीमेंटल सीमा परिभाषित करें
प्रोजेक्शन, फ़िल्टरिंग, जॉइन्स, एग्रीगेशन और डिलीशन सेमेंटिक्स को अलग करें। इंक्रीमेंटल लॉजिक की एक परीक्षण योग्य सीमा तभी होती है जब प्रभावित इनपुट पंक्तियों और टारगेट कीज़ की पहचान की जा सके। ग्लोबल ऑर्डरिंग या गैर-नियतात्मक (nondeterministic) लॉजिक, जिसके प्रभाव को सीमित नहीं किया जा सकता, उसके लिए फुल-रिफ्रेश का विकल्प बनाए रखें।
2. चेंज-एप्लिकेशन अनुबंध डिज़ाइन करें
प्रत्येक परिवर्तन को एक व्यावसायिक की (business key), वर्ज़न या इवेंट समय दें, और एक ही की पर होने वाले टकरावों के लिए विजेता को परिभाषित करें। MERGE मैच आइडेम्पोटेंट होना चाहिए। सॉफ्ट डिलीट के लिए एक डिलीट मार्कर या टॉम्बस्टोन की आवश्यकता होती है ताकि कोई पुराना देर से आया इवेंट हटाई गई पंक्ति को फिर से न बना सके।
3. पहला रन और विफलताएं संभालें
दायरा बढ़ाने से पहले एक नियंत्रित डेटासेट से शुरुआत करें और कस्टम इंक्रीमेंटल आउटपुट की तुलना फुल-रिफ्रेश बेसलाइन से करें। डुप्लिकेट पंक्तियों के बिना पुनः प्रयासों को सुरक्षित रूप से दोहराने योग्य होना चाहिए। जब स्कीमा परिवर्तन, अस्पष्टीकृत ड्रिफ्ट, या टूटा हुआ वॉटरमार्क दिखाई दे, तो प्रकाशन को रोकें और एक सत्यापन योग्य फुल रिफ्रेश या पुनर्निर्माण पर वापस लौटें।
4. शुद्धता और लागत की निगरानी करें
रिफ्रेश लैग, प्रभावित पंक्तियों की संख्या, विफलताओं, पुनः प्रयासों और स्रोत वॉटरमार्क की निगरानी करें; समय-समय पर इंक्रीमेंटल और पूर्ण परिणामों का मिलान करें। केवल एक रिफ्रेश अवधि को देखने के बजाय वेयरहाउस कंप्यूट, स्टोरेज, पुनर्निर्माण और डाउनस्ट्रीम क्वेरी लागतों का अलग-अलग अनुमान लगाएं।
मॉडल उत्तर
मैं CUSTOM_INCREMENTAL को एक इंक्रीमेंटल-मेंटेनेंस अनुबंध के रूप में मानूंगा जिसकी शुद्धता प्रदर्शित की जानी चाहिए। सबसे पहले मुझे प्रत्येक परिवर्तन के लिए एक स्थिर व्यावसायिक की, वर्ज़न या वॉटरमार्क की आवश्यकता होगी, जिसमें सॉफ्ट डिलीट, देर से आने वाले इवेंट्स और टकरावों के लिए स्पष्ट नियम हों; यदि प्रभावित टारगेट पंक्तियों को सीमित नहीं किया जा सकता है, तो मैं फुल रिफ्रेश बनाए रखूंगा। इसके बाद मैं आइडेम्पोटेंट MERGE/INSERT लॉजिक लागू करूंगा, नियंत्रित नमूनों का पूर्ण बेसलाइन के साथ मिलान करूंगा, और दोहराव, पुनः प्रयास, शुरुआती बैकफ़िल और स्कीमा परिवर्तनों का परीक्षण करूंगा। डायनेमिक-टेबल प्लेटफ़ॉर्म शेड्यूलिंग, पुनः प्रयास और ट्रांज़ैक्शनल गारंटी प्रदान करता है, लेकिन यह इवेंट ऑर्डर या डिलीशन सेमेंटिक्स तय नहीं करता है। प्रोडक्शन में मैं वॉटरमार्क, लैग, प्रभावित पंक्तियों, ड्रिफ्ट और लागत की निगरानी करूंगा, जिसमें पॉज़, पुनर्निर्माण और मानक-रिफ्रेश फ़ॉलबैक पाथ शामिल होंगे।
सामान्य गलतियाँ
- यह मान लेना कि
CUSTOM_INCREMENTALमनमाने SQL को स्वचालित रूप से इंक्रीमेंटल बना सकता है। - स्थिर कीज़, वर्ज़न या डुप्लिकेट-इवेंट नियमों के बिना MERGE लिखना।
- सॉफ्ट डिलीट, देर से आए डेटा, या शुरुआती फुल बैकफ़िल को अनदेखा करना।
- प्लेटफ़ॉर्म ट्रांज़ैक्शन को इस बात का प्रमाण मानना कि व्यावसायिक परिणाम सही हैं।
- इंक्रीमेंटल-बनाम-फुल मिलान, ड्रिफ्ट अलर्ट, या रोलबैक को छोड़ देना।
- केवल लेटेंसी की तुलना करना और निरंतर-रिफ्रेश तथा पुनर्निर्माण लागतों की अनदेखा करना।
फॉलो-अप प्रश्न और उत्तर
आपको फुल रिफ्रेश पर कब जोर देना चाहिए?
जब प्रभाव के दायरे को सीमित नहीं किया जा सकता है, लॉजिक में ग्लोबल ऑर्डरिंग या गैर-नियतात्मक फ़ंक्शन शामिल हैं, या मिलान इंक्रीमेंटल परिणाम को साबित नहीं कर सकता है, तब फुल रिफ्रेश को प्राथमिकता दें। यह तय करने से पहले कि क्या इंक्रीमेंटलाइज़ेशन सार्थक है, डेटा रेंज और फ़्रीक्वेंसी को सीमित करें।
आप एक ही की के लिए देर से आने वाले इवेंट को कैसे संभालते हैं?
एक मोनोटोनिक वर्ज़न या तुलनीय इवेंट समय रखें और MERGE शर्त में केवल नए वर्ज़न स्वीकार करें। यदि क्रम पर भरोसा नहीं किया जा सकता है, तो चुपचाप ओवरराइट करने के बजाय टकराव को अलग करें और अलर्ट करें।
आप कैसे साबित करते हैं कि इंक्रीमेंटल परिणाम ड्रिफ्ट नहीं हुआ है?
विभाजन (partition) या की रेंज के अनुसार समय-समय पर एक पूर्ण बेसलाइन की पुनर्गणना करें, पंक्ति संख्या, चेकसम और व्यावसायिक मेट्रिक्स की तुलना करें, और अंतर नमूनों को एक ऑडिट टेबल में बनाए रखें। जब अंतर किसी सीमा से अधिक हो जाए तो प्रकाशन को रोकें या पुनर्निर्माण करें।