डेटा इंजीनियरिंग इंटरव्यू: Iceberg deletion vectors का सुरक्षित उपयोग

प्रॉम्प्ट और स्कोप

एक Apache Iceberg टेबल यूज़र रिकॉर्ड्स स्टोर करती है और उसे GDPR इरेज़र के साथ-साथ बार-बार होने वाले करेक्शन्स को सपोर्ट करना होगा। टीम v2 से v3 में अपग्रेड करने की योजना बना रही है और deletion vectors पर विचार कर रही है। तीनों पंक्ति-स्तरीय (row-level) डिलीट फ़ॉर्मैट्स के बीच ट्रेड-ऑफ़ और पुराने रीडर्स, समवर्ती राइटर्स, रोलबैक और कॉम्पैक्शन को सुरक्षित रखने के तरीके को समझाइए।

यह प्रश्न टेबल-फ़ॉर्मैट रीड/राइट प्रोटोकॉल का परीक्षण करता है, किसी फ़ीचर टॉगल का नहीं। Iceberg स्पेसिफिकेशन एक deletion vector (DV) को किसी एक संदर्भित डेटा फ़ाइल के लिए पोज़िशन बिटमैप के रूप में परिभाषित करता है; इसका स्कोप, मेटाडेटा और मेंटेनेंस की ज़िम्मेदारियां equality और position delete फ़ाइलों से भिन्न होती हैं।

इंटरव्यूअर क्या मूल्यांकन करता है

• क्या आप वैल्यू-आधारित, फ़ाइल-पोज़िशन और बिटमैप डिलीट्स के बीच अंतर समझते हैं।
• क्या आप जानते हैं कि deletion vectors एक Iceberg v3 क्षमता है और v2 में नए रूप से समर्थित नहीं है।
• क्या आप स्नैपशॉट रीड्स के लिए फ़ाइल-पाथ, पार्टीशन और सीक्वेंस-नंबर शर्तों की व्याख्या कर सकते हैं।
• क्या आप प्रति डेटा फ़ाइल अधिकतम एक DV और पुराने position deletes को मर्ज करने का ध्यान रखते हैं।
• क्या आप फ़ॉर्मैट चयन को रीड एम्प्लीफिकेशन, राइट एम्प्लीफिकेशन, डिलीट डेंसिटी, कम्पैटिबिलिटी और मेंटेनेंस बजट से जोड़ते हैं।
• क्या आप ऑब्ज़र्वेबिलिटी, रोलबैक ड्रिल्स और पुराने रीडर्स के लिए एक सुरक्षित पाथ डिज़ाइन करते हैं।

पहले पूछे जाने वाले स्पष्टीकरण

पुष्टि करें:

1. क्या टेबल Iceberg v2 है या v3, और प्रत्येक रीडर और राइटर के कौन से वर्ज़न्स डिप्लॉयड हैं?
2. क्या डिलीट अनुरोधों में बिज़नेस की (key) वैल्यू शामिल हैं, या वे पहले से ही किसी डेटा फ़ाइल और पंक्ति पोज़िशन की पहचान करते हैं?
3. डिलीट डेंसिटी, अपडेट रेट, क्वेरी लेटेंसी टारगेट और कॉम्पैक्शन बजट क्या हैं?
4. क्या रीड-ओनली v2 इंजन अभी भी मौजूद हैं, और क्या टाइम ट्रैवल और स्नैपशॉट रोलबैक आवश्यक हैं?
5. क्या डिलीट्स को डाउनस्ट्रीम CDC स्ट्रीम में फ़ीड करना ज़रूरी है, या वर्तमान स्नैपशॉट में अदृश्यता (invisibility) पर्याप्त है?

यदि विवरण गायब हैं, तो मान लें कि अधिकांश रीडर्स v3 का समर्थन करते हैं, v2 रीडर्स की एक छोटी संख्या बची हुई है, और एक सफल कमिट को डिलीट को कमिटेड स्नैपशॉट में दृश्यमान बनाना होगा।

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

मैं सिमेंटिक्स के आधार पर चयन करूँगा: equality deletes कॉलम वैल्यूज से मेल खाते हैं, position deletes किसी फ़ाइल और पंक्ति पोज़िशन की पहचान करते हैं और v2 कम्पैटिबिलिटी प्रदान कर सकते हैं, और एक v3 टेबल एक डेटा फ़ाइल के लिए बार-बार होने वाले position deletes को deletion vector में समेकित कर सकती है। रीडर्स को केवल बिटमैप को देखने के बजाय संदर्भित फ़ाइल, पार्टीशन और सीक्वेंस-नंबर स्कोप को वैलिडेट करना होगा।

राइटर्स को एक स्नैपशॉट में प्रति डेटा फ़ाइल अधिकतम एक DV रखना होगा और मौजूदा position deletes को इसमें मर्ज करना होगा। कमिट्स Iceberg स्नैपशॉट समवर्ती जांच का उपयोग करते हैं। चूंकि v2 रीडर्स DVs की व्याख्या नहीं कर सकते, इसलिए मैं राइट्स सक्षम करने से पहले एक क्षमता मैट्रिक्स, डुअल-रीड तुलना और रोलबैक योजना बनाऊँगा। स्वीकृति परीक्षण डिलीट विजिबिलिटी, पुराने स्नैपशॉट्स, संघर्षों (conflicts), कॉम्पैक्शन और परफ़ॉर्मेंस को कवर करते हैं।

स्टेप-बाय-स्टेप डीप डाइव

1. प्रत्येक फ़ॉर्मैट के सिमेंटिक्स को परिभाषित करें

एक equality delete किसी भी लागू डेटा फ़ाइल में पंक्तियों का एक या अधिक कॉलम मानों, जैसे कि id = 5 द्वारा मिलान करता है। एक position delete एक फ़ाइल पाथ और शून्य-आधारित पंक्ति पोज़िशन की पहचान करता है। एक deletion vector संदर्भित एक डेटा फ़ाइल के लिए एक पोज़िशन बिटमैप स्टोर करता है; एक सेट बिट का अर्थ है कि वह पंक्ति डिलीट कर दी गई है।

ये केवल कम्प्रेशन लेवल्स नहीं हैं। Equality deletes की-आधारित इवेंट्स के लिए उपयुक्त हैं लेकिन स्कैन के दौरान प्रेडिकेट मैचिंग की आवश्यकता होती है। Position deletes सटीक और v2-कम्पैटिबल हैं लेकिन कई फ़ाइलों को जमा कर सकते हैं। DVs एक डेटा फ़ाइल के लिए कई पोज़िशन्स को सीधे एड्रेस किए जा सकने वाले बाइनरी ऑब्जेक्ट में समेकित करते हैं।

2. वर्ज़न्स और रीडर क्षमता को संभालें

Iceberg v1 के बाद रो-लेवल डिलीट्स पेश करता है, जबकि deletion vectors v3 में जोड़े जाते हैं। एक v3 टेबल को नई position delete फ़ाइलें नहीं जोड़नी चाहिए, लेकिन अपग्रेड की गई v2 टेबल से मौजूदा position deletes मान्य रहते हैं और DV बनाते समय उन्हें मर्ज किया जाना चाहिए।

इसलिए केवल कैटलॉग अपग्रेड पर्याप्त नहीं है। इस बात की समीक्षा करें कि क्या प्रत्येक रीडर v3 मेटाडेटा, deletion-vector-v1 Puffin ब्लॉब और डिलीट मैनिफ़ेस्ट्स को पार्स कर सकता है। एक असमर्थित रीडर को एक कम्पैटिबल स्नैपशॉट या पूरे किए गए माइग्रेशन की आवश्यकता होती है; उससे नए लिखे गए DVs को चुपचाप अनदेखा करने की उम्मीद नहीं की जा सकती।

3. स्नैपशॉट रीड स्कोप का सम्मान करें

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

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

4. राइटर मर्जिंग और समवर्ती कमिट्स डिज़ाइन करें

एक स्नैपशॉट डेटा फ़ाइल के लिए अधिकतम एक DV की अनुमति देता है। डिलीट्स जोड़ते समय, एक राइटर वर्तमान डिलीट स्थिति को पढ़ता है, नए पोज़िशन्स को पुराने DV और position-delete फ़ाइलों के साथ मर्ज करता है, और एक प्रतिस्थापन DV लिखता है। यदि डेटा फ़ाइल हटा दी जाती है, तो लागू DV प्रविष्टियों को डिलीट मैनिफ़ेस्ट्स से हटा दिया जाना चाहिए।

कमिट्स अभी भी Iceberg स्नैपशॉट आशावादी समवर्तीता (optimistic concurrency) का उपयोग करते हैं। एक कॉन्फ़्लिक्ट पुनः प्रयास (retry) को वर्तमान मेटाडेटा और डिलीट मैनिफ़ेस्ट्स को फिर से पढ़ना चाहिए; यह पहले प्रयास के दौरान उत्पन्न बिटमैप का पुनः उपयोग नहीं कर सकता है। पुनः प्रयास की संख्या, कॉन्फ़्लिक्ट के कारण और अंतिम स्नैपशॉट आईडी रिकॉर्ड करें।

5. रीड और राइट एम्प्लीफिकेशन को संतुलित करें

कम और बिखरे हुए (sparse, distributed) डिलीट्स के लिए, equality deletes मूल फ़ाइलों का पता लगाने से बचाते हैं लेकिन स्कैन के दौरान मैचिंग का काम बढ़ाते हैं। कुछ फ़ाइलों में केंद्रित बार-बार होने वाले डिलीट्स के लिए, DVs position-delete फ़ाइल प्रबंधन और मर्ज के काम को कम कर सकते हैं। व्यापक डिलीट या ऐसी फ़ाइल के लिए जिसे पहले से रीराइट किया जाना है, डेटा को रीराइट करना और डिलीट फ़ाइलों को साफ़ करना सस्ता हो सकता है।

यह दावा न करें कि DVs हमेशा तेज़ होते हैं। कई डिलीट डेंसिटी पर स्कैंड बाइट्स, डिलीट-फ़ाइल काउंट, बिटमैप साइज़, मैनिफ़ेस्ट-रीड टाइम, कॉम्पैक्शन CPU और एंड-टू-एंड लेटेंसी की तुलना करें।

6. मेंटेनेंस, रोलबैक और कम्प्लायंस साक्ष्य की योजना बनाएं

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

रोलबैक ड्रिल्स में DV कमिट के बाद रोलबैक, इसकी Puffin फ़ाइल की निरंतर उपलब्धता, पुराने position deletes का अनुप्रयोग और नए स्नैपशॉट में डिलीट की गारंटी शामिल होनी चाहिए। लॉग्स में व्यक्तिगत डेटा डाले बिना ऑडिट रिकॉर्ड में अनुरोध आईडी, कमिटेड स्नैपशॉट आईडी और सत्यापन परिणाम रखें।

7. कम्पैटिबिलिटी और ऑब्ज़र्वेबिलिटी गेट्स स्थापित करें

रिलीज़ से पहले, v2 रीडर्स, v3 रीडर्स, बैच जॉब्स, स्ट्रीमिंग रीडर्स और मेंटेनेंस टूल्स के लिए एक मैट्रिक्स बनाएं। प्रत्येक के लिए equality, position और DV व्यवहार का परीक्षण करें। DV एप्लिकेशन विफलताएं, बेमेल डेटा फ़ाइलें, डिलीट-मैनिफ़ेस्ट वृद्धि, कॉन्फ़्लिक्ट पुनः प्रयास, पुराने-स्नैपशॉट विफलताएं और कॉम्पैक्शन बैकलॉग को ट्रैक करें।

रोलआउट के दौरान, एक ही स्नैपशॉट पर पुराने और नए रीडर्स के परिणामों की तुलना करें: रो काउंट्स, की सेट्स और सैंपल किए गए वैल्यूज। यदि कोई पुराना रीडर v3 डिलीट की व्याख्या नहीं कर सकता है, तो ब्लास्ट रेडियस का विस्तार करने के बजाय DV राइट्स को रोकें या किसी कम्पैटिबल फ़ॉर्मैट पर स्विच करें।

उच्च गुणवत्ता वाला नमूना उत्तर

मैं डिलीट सिमेंटिक्स और रीडर मैट्रिक्स से शुरुआत करूँगा। की-आधारित डिलीट्स equality deletes का उपयोग करते हैं। यदि अनुरोध पहले से ही डेटा फ़ाइल और रो पोज़िशन की पहचान करता है और v2 कम्पैटिबिलिटी की आवश्यकता है, तो position deletes उपयुक्त हैं। एक बार जब टेबल v3 हो जाती है और डिलीट्स एक डेटा फ़ाइल में केंद्रित हो जाते हैं, तो मैं पोज़िशन्स को एक deletion vector में समेकित करूँगा। एक DV एक प्रति-फ़ाइल बिटमैप है, जिसमें स्नैपशॉट में उस डेटा फ़ाइल के लिए अधिकतम एक DV होता है, और एक नया बनाते समय मौजूदा position deletes को मर्ज करना होगा।

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

माइग्रेशन से पहले मैं प्रत्येक रीडर में v3, Puffin और DV समर्थन को सत्यापित करूँगा और DV राइट्स के लिए एक किल स्विच रखूँगा। स्वीकृति वर्तमान-स्नैपशॉट विजिबिलिटी, टाइम ट्रैवल, समवर्ती डिलीट्स, रोलबैक, कॉम्पैक्शन, पुराने-रीडर तुलना और कम्प्लायंस साक्ष्य को कवर करती है। परफ़ॉर्मेंस स्कैंड बाइट्स, मैनिफ़ेस्ट टाइम, DV साइज़, कॉम्पैक्शन CPU और एंड-टू-एंड लेटेंसी की तुलना करती है। उच्च डिलीट डेंसिटी पर, अधिक DVs जमा करने की तुलना में डेटा फ़ाइल को रीराइट करना बेहतर हो सकता है।

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

• DV को एक कंप्रेस्ड equality delete मानना और मैचिंग सिमेंटिक्स की अनदेखी करना।
• यह दावा करना कि Iceberg v2 deletion vectors लिख सकता है।
• पार्टीशन और सीक्वेंस-नंबर जांच के बिना, केवल फ़ाइल पाथ द्वारा DV लागू करना।
• एक डेटा फ़ाइल के लिए कई DVs रखना या पुराने position deletes को मर्ज करने में विफल होना।
• प्रत्येक रीडर और मेंटेनेंस टूल का परीक्षण किए बिना कैटलॉग को अपग्रेड करना।
• रीड और राइट एम्प्लीफिकेशन की तुलना किए बिना कॉम्पैक्शन के एकल रन को सार्वभौमिक उत्तर के रूप में उपयोग करना।
• डिलीट मैनिफ़ेस्ट्स को इस तरह साफ़ करना जिससे सुरक्षित टाइम-ट्रैवल स्नैपशॉट्स टूट जाएं।
• लॉग्स में व्यक्तिगत डेटा डालना और इसे डिलीट करने का प्रमाण कहना।

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

फ़ॉलो-अप 1: v2 रीडर्स को DVs को अनदेखा क्यों नहीं करने दिया जाता?

डिलीट मेटाडेटा की अनदेखी करने से वे पंक्तियाँ लौटाई जा सकती हैं जो पहले ही डिलीट हो चुकी थीं, जिससे एक मूक शुद्धता विफलता (silent correctness failure) उत्पन्न होती है। पहले एक क्षमता मैट्रिक्स और परिणाम तुलना पूरी करें, फिर माइग्रेशन, कम्पैटिबल राइट्स, या DV राइट्स पर रोक का विकल्प चुनें।

फ़ॉलो-अप 2: आपको उस फ़ाइल को कब रीराइट करना चाहिए जिसके डिलीट्स बढ़ते जा रहे हैं?

डिलीट डेंसिटी, बिटमैप साइज़, स्कैन CPU, क्वेरी लेटेंसी और कॉम्पैक्शन बजट का उपयोग करके एक थ्रेशोल्ड सेट करें। इसके ऊपर, डेटा फ़ाइल को रीराइट करें, एक नए स्नैपशॉट में इसके लागू DV को हटाएं, और टाइम-ट्रैवल रिटेंशन नीति को सत्यापित करें।

फ़ॉलो-अप 3: कॉन्फ़्लिक्ट पुनः प्रयास के दौरान सबसे आसानी से क्या छूट जाता है?

नवीनतम डिलीट मैनिफ़ेस्ट्स और डेटा सीक्वेंस नंबर को फिर से पढ़ना। प्रत्येक पुनः प्रयास को वर्तमान टेबल मेटाडेटा के विरुद्ध मर्ज होना चाहिए और कॉन्फ़्लिक्ट के साथ-साथ अंतिम स्नैपशॉट आईडी को रिकॉर्ड करना चाहिए।

फ़ॉलो-अप 4: आप विनियामक (regulatory) डिलीट को कैसे साबित करते हैं?

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

फ़ॉलो-अप 5: Equality delete कब बेहतर होता है?

जब इवेंट्स में केवल बिज़नेस कीज होती हैं, फ़ाइलें बार-बार रीराइट की जाती हैं, या एक प्रेडिकेट को कई फ़ाइलों को कवर करना होता है, तो equality deletes अधिक प्रत्यक्ष होते हैं। फिर भी स्कैन मैचिंग लागत को मापें और एक रीराइट नीति परिभाषित करें।