डेटा इंजीनियरिंग इंटरव्यू: Iceberg v3 रो लाइनेज रो की विशिष्ट पहचान (row identity) को कैसे सुरक्षित रखता है?

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

एक Iceberg v3 इवेंट टेबल को CDC, पुनः गणना (recomputation) और क्रॉस-स्नैपशॉट ऑडिटिंग का समर्थन करना चाहिए। टीम एक ट्रैसेबल रो आइडेंटिटी और वह कमिट चाहती है जिसने प्रत्येक रो को अंतिम बार अपडेट किया था। रो-लाइनेज फ़ील्ड्स, इनहेरिटेंस टाइमिंग, कमिट पुनः प्रयास (retries), equality-delete सीमाएं और सत्यापन की व्याख्या करें।

इंटरव्यूअर क्या जांच रहा है

• क्या आप राइट टाइम पर वैल्यू गढ़ने के बजाय _row_id और _last_updated_sequence_number के इनहेरिटेंस को समझते हैं।
• क्या आप first-row-id, next-row-id और मैनिफ़ेस्ट्स को आपस में जोड़ सकते हैं।
• क्या आप ऑप्टिमिस्टिक-कमिट पुनः प्रयासों (retries), समवर्ती राइटर्स (concurrent writers) और पुराने रीडर्स को संभालते हैं।
• क्या आप रो लाइनेज, बिज़नेस कीज़, equality deletes और फ़िज़िकल क्लीनअप को अलग-अलग रखते हैं।

पूछने के लिए स्पष्टीकरण संबंधी प्रश्न

1. क्या हमें फ़िज़िकल रो आइडेंटिटी, बिज़नेस-एंटीटी आइडेंटिटी, या दोनों की आवश्यकता है?
2. क्या प्रत्येक रीडर Iceberg v3 का समर्थन करता है, और पुराने इंजन के लिए फ़ॉलबैक क्या है?
3. क्या अपडेट copy-on-write, merge-on-read, या equality deletes हैं?
4. क्या स्नैपशॉट्स के पार ऑडिटिंग आवश्यक है, या केवल वर्तमान टेबल वर्ज़न की?

30-सेकंड का उत्तर फ़्रेमवर्क

Iceberg v3 टेबल रो आइडेंटिटी के लिए _row_id और अंतिम अपडेट कमिट के लिए _last_updated_sequence_number का उपयोग करता है। रीडर्स इन्हें डेटा फ़ाइल के first-row-id, रो पोज़ीशन और मैनिफ़ेस्ट सीक्वेंस नंबर से इनहेरिट करते हैं। राइटर्स कमिट से पहले नल (null) फ़ील्ड्स उत्सर्जित कर सकते हैं, इसलिए एक पुनः प्रयास को मेटाडेटा को फिर से पढ़ना चाहिए और एक नया first-row-id असाइन करना चाहिए। रो लाइनेज कोई बिज़नेस की (business key) नहीं है, और equality deletes पुरानी रो आईडी को सुरक्षित नहीं रखते हैं। एक v2/v3 क्षमता मैट्रिक्स स्थापित करें, फिर स्नैपशॉट्स, कन्फ्लिक्ट्स और पुनः प्रयासों का परीक्षण करें।

चरण-दर-चरण विस्तृत विश्लेषण

1. पहचानों को अलग करें

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

2. फ़ील्ड इनहेरिटेंस को समझें

एक नई रो का _row_id और _last_updated_sequence_number डेटा फ़ाइल में नल (null) हो सकता है। रीड पर, रो आईडी फ़ाइल के first-row-id और रो पोज़ीशन से प्राप्त होती है, जबकि अपडेट सीक्वेंस मैनिफ़ेस्ट एंट्री से आती है। इससे राइटर्स को कमिट सफल होने से पहले डेटा फ़ाइलों को फिर से लिखने से बचने में मदद मिलती है।

row_id = data_file.first_row_id + row_position
last_updated = manifest_entry.data_sequence_number

3. कमिट पुनः प्रयासों को संभालें

एक ऑप्टिमिस्टिक कन्फ्लिक्ट के बाद, टेबल का next-row-id बदल गया हो सकता है। एक पुनः प्रयास को वर्तमान मेटाडेटा को फिर से पढ़ना चाहिए, एक नया first-row-id आवंटित करना चाहिए, और मैनिफ़ेस्ट सूची को फिर से बनाना चाहिए; यह पहले प्रयास की रेंज का पुन: उपयोग नहीं कर सकता है। प्रयास, कन्फ्लिक्ट का कारण और अंतिम स्नैपशॉट आईडी रिकॉर्ड करें।

4. equality-delete सीमा

एक equality-delete इंजन आमतौर पर पुरानी डेटा रो को पढ़े बिना परिवर्तन लिखता है, इसलिए यह प्रतिस्थापित रो की मूल आईडी प्रदान नहीं कर सकता है। विनिर्देश ऐसे अपडेट को पुरानी रो को हटाने और एक अद्वितीय नई रो जोड़ने के रूप में मानता है। जब एंटिटी पहचान महत्वपूर्ण हो, तो बिज़नेस कीज़ और चेंज इवेंट्स को अलग से सुरक्षित रखें।

5. अनुकूलता और रीड्स

रो लाइनेज एक v3 क्षमता है, और पुराने रीडर्स इसके आरक्षित फ़ील्ड्स को नहीं समझ सकते हैं। अपग्रेड करने से पहले, एक इंजन मैट्रिक्स बनाएं और सत्यापित करें कि क्या कोई पुराना रीडर नल देखता है, फ़ील्ड्स को अनदेखा करता है, या विफल हो जाता है। एक्सपोर्ट्स इस बात पर निर्भर नहीं होने चाहिए कि प्रत्येक रीडर रो आईडी प्राप्त कर रहा है; एक v3-अवेयर सेवा पहले ऑडिट फ़ील्ड्स को मटीरियलाइज़ कर सकती है।

6. सत्यापन, रोलबैक और क्लीनअप

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

मॉडल उच्च-गुणवत्ता उत्तर

मैं बिज़नेस कीज़ को Iceberg रो लाइनेज से अलग रखूँगा। v3 में, _row_id और _last_updated_sequence_number रीड टाइम पर first-row-id, रो पोज़ीशन और मैनिफ़ेस्ट सीक्वेंस नंबर से इनहेरिट होकर टेबल-रो पहचान और कमिट क्रम प्रदान करते हैं। राइटर्स कमिट से पहले फ़ील्ड्स को नल छोड़ते हैं; कन्फ्लिक्ट पुनः प्रयास पुराने मैनिफ़ेस्ट का पुन: उपयोग करने के बजाय मेटाडेटा को फिर से पढ़ते हैं और एक नई रेंज आवंटित करते हैं। equality deletes पुरानी रो आईडी की गारंटी नहीं देते हैं, इसलिए ऑडिट डेटा बिज़नेस कीज़, स्नैपशॉट आईडी और चेंज इवेंट्स को भी संग्रहीत करता है। रोलआउट से पहले, v2/v3 रीडर्स, कन्फ्लिक्ट्स, स्नैपशॉट रीड्स, कॉम्पैक्शन और क्लीनअप का परीक्षण करें, जिसमें रोलबैक केवल स्नैपशॉट संदर्भों को स्विच करने तक सीमित हो।

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

• रो आईडी को बिज़नेस की के रूप में मानना → डिलीट-एंड-रीराइट सिमेंटिक्स टूट जाते हैं → दोनों पहचानों को बनाए रखें।
• फ़ाइलें लिखते समय स्थायी रो आईडी आवंटित करना → पुनः प्रयास रेंजेस को डुप्लिकेट या बर्बाद कर सकते हैं → कमिट-टाइम इनहेरिटेंस पर भरोसा करें।
• कन्फ्लिक्ट वाले मैनिफ़ेस्ट का पुन: उपयोग करना → इसमें एक पुराना next-row-id होता है → प्रत्येक पुनः प्रयास पर मेटाडेटा को फिर से पढ़ें।
• यह मान लेना कि equality deletes रो आईडी को सुरक्षित रखते हैं → विनिर्देश इसकी गारंटी नहीं देता है → बिज़नेस इवेंट्स के साथ एंटिटीज को ट्रैक करें।
• केवल वर्तमान क्वेरी को मान्य करना → स्नैपशॉट्स और पुराने रीडर्स जोखिम भरे बने रहते हैं → क्रॉस-स्नैपशॉट व्यवहार और क्षमताओं का परीक्षण करें।

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

_row_id को बिज़नेस की से क्यों नहीं बदला जा सकता?

बिज़नेस कीज़ दोहराई जा सकती हैं, बदल सकती हैं, या तालिकाओं में गैर-अद्वितीय हो सकती हैं। रो लाइनेज टेबल-रो की पहचान है; ये दोनों अलग-अलग ऑडिट प्रश्नों के उत्तर देते हैं और दोनों को बनाए रखा जाना चाहिए।

क्या कन्फ्लिक्ट पुनः प्रयास रो आईडी में अंतराल (gaps) छोड़ सकते हैं?

कार्यान्वयन के आधार पर अप्रयुक्त रेंजेस मौजूद हो सकती हैं। सुरक्षा नियम यह है कि किसी सफल स्नैपशॉट द्वारा उजागर की गई आईडी का कभी भी पुन: उपयोग न करें और अंतिम स्नैपशॉट में आईडी को अद्वितीय रखें।

क्या कॉम्पैक्शन रो आईडी को बदलता है?

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