प्रॉम्प्ट और संदर्भ
एक टीम DuckDB के साथ Parquet परिवर्तन फ़ाइलों को पढ़ती है और स्थानीय रूप से ग्राहक डायमेंशन और मूल्य इतिहास को बनाए रखती है। बताएं कि MERGE INTO का उपयोग कब करना है, और डुप्लिकेट कीज़ (keys), डिलीट, SCD Type 2, री-रन और रिकवरी को कैसे संभालना है।
इंटरव्यूअर क्या जांचते हैं
वे मैच प्रेडिकेट्स (match predicates), एक्शन ऑर्डरिंग, सोर्स यूनीकनेस और ट्रांजैक्शन सीमाओं के बारे में आपकी समझ की जांच करते हैं, साथ ही SQL की सुविधा को गुणवत्ता, ऑडिट और रोलबैक के साथ एक दोबारा चलाए जाने योग्य (rerunnable) पाइपलाइन में बदलने की आपकी क्षमता को देखते हैं।
स्पष्ट करने योग्य प्रश्न
बिजनेस की (business key), इवेंट-टाइम क्रम, और इतिहास बनाए रखने की आवश्यकता है या नहीं, इसके बारे में पूछें। डुप्लिकेट, देर से आने वाले (late) और डिलीट रिकॉर्ड्स को स्पष्ट करें और यह भी जानें कि विफलता के बाद क्या टारगेट को फिर से बनाया जा सकता है। MERGE को स्वचालित CDC एग्जैक्टली-वन्स (exactly-once) न समझें।
30-सेकंड का उत्तर
“मैं स्टेजिंग में बिजनेस की और इवेंट टाइम के अनुसार डिडुप्लीकेशन करूंगा, यह सत्यापित करूंगा कि प्रति टारगेट की अधिकतम एक लागू परिवर्तन हो, और एक ट्रांजैक्शन के तहत MERGE चलाऊंगा। एक करंट-स्टेट टेबल मैच्ड अपडेट्स और अनमैच्ड इंसर्ट्स का उपयोग करती है; एक SCD Type 2 टेबल पुराने संस्करण को बंद करती है और एक नया संस्करण सम्मिलित करती है। डिलीट्स और री-रन्स के लिए स्पष्ट सिमेंटिक्स की आवश्यकता होती है। प्रत्येक बैच अपने इनपुट स्नैपशॉट और जांचों को रिकॉर्ड करता है, और विफलता होने पर रोलबैक करके उसी स्नैपशॉट को पुनः प्रयास करता है।”
चरण-दर-चरण विस्तृत विश्लेषण
टारगेट सिमेंटिक्स को परिभाषित करें
एक वर्तमान स्नैपशॉट को इतिहास से अलग करें। करंट टेबल को नवीनतम स्थिति चाहिए; SCD Type 2 को valid_from, valid_to, is_current, और संस्करण बाधाओं (version constraints) की आवश्यकता होती है।
पहले ऑडिट योग्य स्टेजिंग बनाएं
सोर्स फ़ाइल, बैच आईडी, पढ़ने का समय और पंक्ति हैश बनाए रखें। बिजनेस की, इवेंट टाइम और सोर्स प्राथमिकता के आधार पर डिडुप्लीकेट करें; जिन संबंधों (ties) को हल नहीं किया जा सकता, उन्हें क्वारंटाइन करें।
मैचेस और एक्शन्स को डिज़ाइन करें
मैच प्रेडिकेट में एक स्थिर बिजनेस की का उपयोग करें, परिवर्तनशील विशेषताओं (mutable attributes) का नहीं। मैच्ड अपडेट्स, अनमैच्ड इंसर्ट्स और नॉट-मैच्ड-बाय-सोर्स डिलीट नीति को स्पष्ट रूप से निर्दिष्ट करें ताकि देर से आया डेटा गलती से डिलीट न हो जाए।
SCD Type 2 को संभालें
परिवर्तित संस्करण को सम्मिलित करने से पहले वर्तमान पंक्ति को बंद करें; समान सामग्री से नया संस्करण नहीं बनना चाहिए। बाधा (constraint) या गुणवत्ता क्वेरी के साथ यह लागू करें कि प्रत्येक की के पास केवल एक ही वर्तमान पंक्ति हो।
री-रन्स और ट्रांजैक्शन की गारंटी दें
बैच आईडी और एक फ्रोज़न इनपुट स्नैपशॉट एक रन को दोहराने योग्य (repeatable) बनाते हैं। MERGE, ऑडिट और बैच स्थिति को एक ही ट्रांजैक्शन में रखें; बदलती फ़ाइलों को दोबारा पढ़ने के बजाय उसी स्टेजिंग डेटा का पुनः प्रयास करें।
मॉनिटर करें और रोलबैक करें
सोर्स और टारगेट इंसर्ट, अपडेट और डिलीट गणनाओं की तुलना करें; अनाथ कीज़ (orphan keys), डुप्लिकेट वर्तमान पंक्तियों और उल्टे समय की जांच करें। पहले का स्नैपशॉट या पुनर्निर्माण पथ बनाए रखें और विसंगतियों पर बैच के अनुसार रोलबैक करें।
मॉडल उत्तर
मैं बैच मेटाडेटा के साथ Parquet फ़ाइलों को स्टेजिंग में रखूंगा, बिजनेस की और इवेंट टाइम द्वारा डिडुप्लीकेट करूंगा, और पंक्ति गणना, नल (nulls) और डिलीट अनुपात पर गेट लगाऊंगा। करंट टेबल एक स्थिर-की अपडेट/इंसर्ट का उपयोग करती है; हिस्ट्री टेबल परिवर्तित संस्करणों को बंद करती है और नए सम्मिलित करती है ताकि प्रत्येक की की केवल एक वर्तमान पंक्ति हो। MERGE, ऑडिट और बैच स्थिति एक ट्रांजैक्शन साझा करते हैं, और विफलताओं पर उसी स्नैपशॉट का पुनः प्रयास किया जाता है। मैं प्रति-बैच डेल्टा और डुप्लिकेट संस्करणों की निगरानी करता हूं और आवश्यकता पड़ने पर बैच के अनुसार रोलबैक या पुनर्निर्माण करता हूं।
सामान्य गलतियां
सीधे रॉ (raw) फ़ाइलों को मर्ज करना
डुप्लिकेट सोर्स पंक्तियाँ परिणामों को अस्पष्ट बना सकती हैं या दो बार अपडेट कर सकती हैं; पहले स्टेज करें, डिडुप्लीकेट करें और क्वालिटी गेट लगाएं।
परिवर्तनशील कॉलमों पर मिलान करना
ग्राहक का नाम बदलने से वह एक नई की के रूप में दिख सकता है। हमेशा एक स्थिर व्यावसायिक पहचानकर्ता (business identifier) पर मिलान करें।
SCD Type 2 के लिए केवल इंसर्ट करना
पुराने संस्करण वर्तमान बने रहते हैं और क्वेरीज़ कई वर्तमान पंक्तियाँ लौटाती हैं। वैधता और विशिष्टता बनाए रखें।
पुनः प्रयास (retry) पर फ़ाइलों को दोबारा पढ़ना
फ़ाइलें बदल सकती हैं या नई फ़ाइलें दिखाई दे सकती हैं। इनपुट स्नैपशॉट और बैच आईडी को फ्रीज करें।
फॉलो-अप प्रश्न
यदि एक ही की के लिए दो अलग-अलग इवेंट एक साथ आते हैं तो क्या होगा?
स्पष्ट इवेंट-टाइम, वर्शन या सोर्स-प्राथमिकता नियम के साथ एक को चुनें; अन्यथा चुपचाप ओवरराइट करने के बजाय उसे क्वारंटाइन करें।
आप देर से आए डिलीट को कैसे संभालते हैं?
टारगेट वर्शन के साथ डिलीट इवेंट टाइम की तुलना करें, एक टॉम्बस्टोन (tombstone) रिकॉर्ड करें, और किसी पुराने डिलीट को नए अपडेट को ओवरराइट करने से रोकें।
आप कैसे साबित करेंगे कि एक असफल MERGE आंशिक रूप से कमिट नहीं हुआ था?
MERGE, ऑडिट और बैच स्थिति को एक ही ट्रांजैक्शन में रखें; विफलता के बाद टारगेट काउंट और स्थिति का निरीक्षण करें, फिर उसी स्टेजिंग स्नैपशॉट का पुनः प्रयास करें।
आप MERGE से कब बचेंगे?
लगभग पूर्ण प्रतिस्थापन (near-full replacements), जटिल मिलान, या क्रॉस-सिस्टम ट्रांजैक्शन के लिए, रो-एक्शन अनिश्चितता को कम करने के लिए एक नई टेबल बनाएं और इसे एटॉमिक रूप से स्वैप करें।