प्रॉम्प्ट और दायरा
आपकी टीम टेबल डेटा को ऑब्जेक्ट स्टोरेज में स्टोर करती है, जबकि कंप्यूट Spark से बढ़कर Trino और एक इन-हाउस सर्विस तक विस्तृत हो रहा है। पुराना Hive Metastore दृष्टिकोण कई क्लाइंट इम्प्लीमेंटेशन्स की मांग करता है, और समवर्ती (concurrent) मेटाडेटा अपडेट्स एक-दूसरे को ओवरराइट कर सकते हैं। एक Apache Iceberg REST Catalog डिज़ाइन करें, जिसमें यह शामिल हो कि यह क्या मैनेज करता है, स्नैपशॉट कमिट्स, ऑथेंटिकेशन और ऑथराइजेशन, और विफलताओं से रिकवरी।
Apache Iceberg REST Catalog विनिर्देश भाषा-तटस्थ (language-neutral) HTTP API के माध्यम से कैटलॉग ऑपरेशन्स को एक्सपोज़ करता है और सर्वर को समवर्ती अपडेट्स और पुनः प्रयासों के कॉन्फ्लिक्ट्स को हल करने में मदद करने के लिए परिवर्तन-आधारित कमिट्स का उपयोग करता है। यह नेमस्पेस, टेबल मेटाडेटा और स्नैपशॉट संदर्भों को प्रबंधित करता है; डेटा फ़ाइलें अंतर्निहित ऑब्जेक्ट स्टोर में ही रहती हैं। यह इंटरव्यू मेटाडेटा कंट्रोल प्लेन के बारे में है, न कि क्वेरी इंजन या ऑब्जेक्ट स्टोरेज को फिर से बनाने के बारे में।
इंटरव्यूअर क्या जांच रहा है
एक मजबूत उत्तर डेटा प्लेन को मेटाडेटा कंट्रोल प्लेन से अलग करता है, फिर क्लाइंट कम्पैटिबिलिटी, कमिट कॉनकरेंसी, ऑथराइजेशन सीमाओं और रिकवरी से घटकों को व्युत्पन्न करता है। इंटरव्यूअर कॉन्फ़िगरेशन डिस्कवरी, टेबल लोडिंग, अपडेट्स, ऑप्टिमिस्टिक कॉनकरेंसी, स्नैपशॉट कैशिंग और क्रेडेंशियल वेंडिंग के बीच संबंध की उम्मीद करता है।
एक कमजोर उत्तर केवल "एक REST सर्विस" जोड़ता है, बिना यह समझाए कि दो राइटर्स स्नैपशॉट को ओवरराइट करने से कैसे बचते हैं या कैटलॉग द्वारा जारी किए गए डेटा क्रेडेंशियल्स, क्रॉस-इंजन ऑथेंटिकेशन और पुराने क्लाइंट्स को कैसे संभाला जाता है।
पहले स्पष्ट करने योग्य प्रश्न
एक्सेस पैटर्न और कंसिस्टेंसी लक्ष्य
टेबल के आकार, नेमस्पेस की संख्या, रीड/राइट अनुपात, स्नैपशॉट कमिट दर, और क्या मल्टी-टेबल एटॉमिक कमिट्स की आवश्यकता है, इस बारे में पूछें। कम आवृत्ति वाले बैच वर्कलोड के लिए केवल एक साधारण मेटाडेटा डेटाबेस की आवश्यकता हो सकती है। समवर्ती रूप से कमिट करने वाले कई इंजनों के लिए स्पष्ट कॉन्फ्लिक्ट डिटेक्शन, पुनः प्रयास बजट (retry budgets) और कमिट-लेटेंसी लक्ष्यों की आवश्यकता होती है।
स्टोरेज और कैटलॉग की सीमा
पुष्टि करें कि ऑब्जेक्ट स्टोरेज, FileIO, कैटलॉग डेटाबेस और कंप्यूट इंजन का स्वामित्व किसके पास है। REST Catalog मेटाडेटा और कॉन्फ़िगरेशन लौटाता है, लेकिन कैटलॉग सर्विस के माध्यम से बड़ी डेटा फ़ाइलों को प्रॉक्सी नहीं करना चाहिए। सीमित अनुमतियों और कम समय (short lifetime) के साथ किसी टेबल या लोकेशन के लिए डेटा क्रेडेंशियल्स वेंड किए जा सकते हैं।
ऑथेंटिकेशन और गवर्नेंस
पूछें कि क्या क्लाइंट्स OAuth2, क्लाउड रिक्वेस्ट साइनिंग, या सर्विस अकाउंट्स का उपयोग करते हैं, और क्या टेनेंट आइसोलेशन, ऑडिट, या कॉलम और रो नीतियों की आवश्यकता है। कैटलॉग ऑथराइजेशन डिस्कवरी, रीड्स और कमिट्स को नियंत्रित करता है; ऑब्जेक्ट स्टोरेज को फिर से न्यूनतम विशेषाधिकार (least privilege) लागू करना चाहिए, ताकि कैटलॉग ही एकमात्र सुरक्षा सीमा न हो।
30-सेकंड उत्तर फ्रेमवर्क
"मैं REST Catalog को एक स्टेटलेस मेटाडेटा कंट्रोल प्लेन बनाऊंगा। एक क्लाइंट पहले कॉन्फ़िगरेशन एंडपॉइंट को कॉल करता है, फिर मेटाडेटा लोड करने के लिए नेमस्पेस और टेबल APIs का उपयोग करता है। कैटलॉग डेटाबेस वर्तमान मेटाडेटा लोकेशन, स्नैपशॉट संदर्भ और कमिट वर्ज़न स्टोर करता है; एक राइटर अपेक्षित वर्ज़न के आधार पर परिवर्तन सबमिट करता है, और सर्वर कॉन्फ्लिक्ट्स का पता लगाता है और एक पुनः प्रयास करने योग्य परिणाम लौटाता है। ऑथेंटिकेशन OAuth2 या क्लाउड साइनिंग का उपयोग करता है, जबकि कैटलॉग अनुमतियां और ऑब्जेक्ट-स्टोर क्रेडेंशियल्स अलग-अलग होते हैं। मेटाडेटा को संक्षेप में कैश किया जा सकता है, लेकिन इसे वर्ज़न या ETag के साथ जांचा जाना चाहिए। जब कैटलॉग अनुपलब्ध हो, तो रीड्स एक सत्यापित पुराने स्नैपशॉट का उपयोग कर सकते हैं, लेकिन राइट्स को कमिट प्रोटोकॉल को बायपास नहीं करना चाहिए और सीधे रूट मेटाडेटा को संपादित नहीं करना चाहिए।"
चरण-दर-चरण समाधान
चरण 1: कंट्रोल-प्लेन मॉडल को परिभाषित करें
कैटलॉग को कम से कम एक नेमस्पेस, टेबल पहचानकर्ता (identifier), वर्तमान मेटाडेटा लोकेशन, स्नैपशॉट संदर्भ, एक वर्ज़न और ऑडिट फ़ील्ड की आवश्यकता होती है। टेबल मेटाडेटा फ़ाइलें ऑब्जेक्ट स्टोरेज में रहती हैं; कैटलॉग उनकी लोकेशन्स और कमिट वर्ज़न्स को रिकॉर्ड करता है। क्लाइंट मांग पर स्नैपशॉट लोड कर सकते हैं, और कैटलॉग एक बड़ी फ़ाइल ट्रांसफ़र पथ नहीं बनता है।
चरण 2: सबसे छोटा उपयोगी API डिज़ाइन करें
कॉन्फ़िगरेशन एंडपॉइंट सर्वर डिफॉल्ट्स, ओवरराइड्स और समर्थित एंडपॉइंट्स लौटाता है। नेमस्पेस APIs प्रॉपर्टीज़ बनाते हैं, सूचीबद्ध करते हैं और प्रबंधित करते हैं। टेबल APIs टेबल्स बनाते हैं, लोड करते हैं, अपडेट करते हैं, कमिट करते हैं, हटाते हैं और उनका नाम बदलते हैं। एक लोड प्रतिक्रिया में टेबल और डेटा-एक्सेस कॉन्फ़िगरेशन शामिल हो सकता है, जिसके बाद क्लाइंट सीधे ऑब्जेक्ट स्टोरेज से बात करता है। एक कमिट प्रतिक्रिया नया वर्ज़न लौटाती है ताकि क्लाइंट अपने कैश को रीफ्रेश कर सकें।
चरण 3: ऑप्टिमिस्टिक कॉनकरेंसी के साथ कमिट्स को सुरक्षित करें
एक राइटर वर्ज़न V पढ़ता है, नया मेटाडेटा लिखता है, और सबमिट करता है "मैं V पर आधारित हूँ और लोकेशन M पर स्विच करना चाहता हूँ।" सर्वर कैटलॉग को एटॉमिक रूप से केवल तभी अपडेट करता है यदि वर्तमान वर्ज़न अभी भी V है। यदि किसी अन्य राइटर ने पहले कमिट कर दिया है, तो यह एक कॉन्फ्लिक्ट लौटाता है; क्लाइंट पुनः लोड करता है, अपने परिवर्तन को मर्ज करता है, और पुनः प्रयास करता है। पुनः प्रयासों के लिए एक सीमा और जिटर (jitter) की आवश्यकता होती है ताकि कई इंजन एक कॉन्फ्लिक्ट को कमिट स्टॉर्म में न बदल दें।
चरण 4: कैश और रीड कंसिस्टेंसी को संभालें
क्लाइंट्स टेबल कॉन्फ़िगरेशन और स्नैपशॉट संदर्भों को कैश कर सकते हैं, लेकिन की (key) में पूरा टेबल पहचानकर्ता और सर्वर पहचान शामिल होनी चाहिए। केवल टाइम-टू-लाइव (TTL) की तुलना में ETag, वर्ज़न या स्नैपशॉट-रेफरेंस वैलिडेशन को प्राथमिकता दें। रीड्स एक स्पष्ट बासीपन बजट (staleness budget) के भीतर कमिट किए गए स्नैपशॉट का उपयोग कर सकते हैं; नवीनतम ब्रांच, अनुमति परिवर्तन, या रीड-आफ्टर-राइट की आवश्यकता वाले अनुरोधों को कैटलॉग वर्ज़न को फिर से सत्यापित करना चाहिए।
चरण 5: ऑथेंटिकेशन, ऑथराइजेशन और क्रेडेंशियल वेंडिंग को अलग करें
कैटलॉग API OAuth2, क्लाउड साइनिंग या एंटरप्राइज सर्विस अकाउंट से ऑथेंटिकेट होता है। ऑथराइजेशन नेमस्पेस, टेबल और ऑपरेशन में अंतर करता है। यदि कैटलॉग अस्थायी ऑब्जेक्ट-स्टोर क्रेडेंशियल्स वेंड करता है, तो उन्हें केवल आवश्यक लोकेशन और क्रियाओं को कवर करना चाहिए, उनका TTL कम होना चाहिए, और उन्हें निरस्तीकरण (revocation) पथ वाले ऑडिट रिकॉर्ड से जोड़ा जाना चाहिए। क्लाइंट्स को उन क्रेडेंशियल्स को स्थायी कुंजियों के रूप में लॉग या साझा कॉन्फ़िगरेशन में नहीं लिखना चाहिए।
चरण 6: विफलता और रिकवरी पथ डिज़ाइन करें
जब कैटलॉग डेटाबेस अनुपलब्ध होता है, तो सत्यापित कैश्ड स्नैपशॉट एक दृश्यमान स्टेलनेस टाइमस्टैम्प के साथ रीड्स की सेवा कर सकते हैं। क्रिएट, कमिट और डिलीट ऑपरेशन्स विफल होने चाहिए और बाद में पुनः प्रयास किए जाने चाहिए; उन्हें सीधे ऑब्जेक्ट स्टोर के रूट मेटाडेटा को संपादित नहीं करना चाहिए। यदि ऑब्जेक्ट स्टोरेज अस्थायी रूप से अनुपलब्ध है, तो कैटलॉग को किसी अनुपलब्ध फ़ाइल की ओर इशारा करते हुए नए कैटलॉग वर्ज़न के साथ सफलता की रिपोर्ट नहीं करनी चाहिए। राइट्स को फिर से खोलने से पहले रिकवरी मेटाडेटा लोकेशन्स, स्नैपशॉट संदर्भों और फ़ाइल मैनिफ़ेस्ट्स को सत्यापित करती है।
चरण 7: ऑब्जर्वेबिलिटी और कम्पैटिबिलिटी विकास जोड़ें
रिक्वेस्ट ID, क्लाइंट इंजन, टेबल पहचानकर्ता, अपेक्षित और वास्तविक वर्ज़न्स, कॉन्फ्लिक्ट काउंट, पुनः प्रयास काउंट और क्रेडेंशियल स्कोप रिकॉर्ड करें, लेकिन टोकन या कुंजियाँ कभी नहीं। API, नेमस्पेस और इंजन द्वारा कमिट लेटेंसी, कॉन्फ्लिक्ट दर, कैश हिट दर और स्टेल-रीड अनुपात को ट्रैक करें। नए एंडपॉइंट्स या फ़ील्ड्स को कैपेबिलिटी डिस्कवरी और बैकवर्ड-कम्पैटिबल डिफॉल्ट्स का उपयोग करना चाहिए; एक अज्ञात फ़ील्ड को पुराने क्लाइंट्स के लिए मौजूदा कमिट सेमेंटिक्स को नहीं बदलना चाहिए।
उच्च-गुणवत्ता वाला नमूना उत्तर
मैं Iceberg REST Catalog को मेटाडेटा कंट्रोल प्लेन के रूप में परिभाषित करूँगा। ऑब्जेक्ट स्टोरेज डेटा फ़ाइलों और टेबल मेटाडेटा फ़ाइलों को रखता है। कैटलॉग डेटाबेस टेबल पहचानकर्ता, वर्तमान मेटाडेटा लोकेशन, स्नैपशॉट संदर्भ, वर्ज़न और ऑथराइजेशन ऑडिट डेटा संग्रहीत करता है। Spark, Trino और अन्य भाषा क्लाइंट्स तब एक HTTP प्रोटोकॉल लागू करते हैं।
क्लाइंट कॉन्फ़िगरेशन पढ़ता है और टेबल लोड करता है। एक राइटर वर्ज़न V पढ़ता है, नया मेटाडेटा लिखता है, और एक अपेक्षित वर्ज़न V सबमिट करता है। सर्वर एक ट्रांजैक्शन के अंदर उस वर्ज़न की जाँच करता है; यदि यह अभी भी V है, तो यह एटॉमिक रूप से नई लोकेशन पर स्विच हो जाता है। अन्यथा यह एक कॉन्फ्लिक्ट लौटाता है। क्लाइंट पुनः लोड और मर्ज करता है, फिर एक्सपोनेंशियल बैकऑफ़ और एक सीमित बजट के साथ पुनः प्रयास करता है। यह लास्ट-राइटर-विन्स (last-writer-wins) से अधिक सुरक्षित है, जो चुपचाप किसी अन्य राइटर के स्कीमा या स्नैपशॉट परिवर्तन को खो सकता है।
ऑथेंटिकेशन OAuth2 या क्लाउड साइनिंग का उपयोग कर सकता है। कैटलॉग ऑथराइजेशन डिस्कवरी, रीड्स और कमिट्स को नियंत्रित करता है। यदि कैटलॉग ऑब्जेक्ट-स्टोर क्रेडेंशियल्स वेंड करता है, तो मैं उन्हें लोकेशन और एक छोटे TTL तक सीमित रखता हूँ। मेटाडेटा कैश ETags या वर्ज़न्स का उपयोग करते हैं, इसलिए अनुमति परिवर्तन और रीड-आफ्टर-राइट किसी अनियंत्रित बासी प्रविष्टि पर निर्भर नहीं होते हैं। कैटलॉग आउटेज के दौरान मैं केवल एक स्पष्ट स्टेलनेस मार्कर के साथ रीड्स की अनुमति देता हूँ और राइट्स को विफल कर देता हूँ। रिकवरी के बाद मैं मेटाडेटा लोकेशन्स, स्नैपशॉट संदर्भों और फ़ाइल के अस्तित्व को सत्यापित करता हूँ। मैं समवर्ती कमिट्स, डुप्लिकेट पुनः प्रयासों, कैटलॉग विफलता, एक्सपायर्ड क्रेडेंशियल्स, बासी कैश और पुराने-क्लाइंट अनुरोधों के लिए कम्पैटिबिलिटी परीक्षणों के साथ समाप्त करता हूँ।
सामान्य गलतियाँ
- गलती: कैटलॉग के माध्यम से प्रत्येक डेटा फ़ाइल को प्रॉक्सी करना। → यह क्यों विफल होता है: मेटाडेटा कंट्रोल प्लेन एक हाई-बैंडविड्थ बॉटलनेक बन जाता है और ऑथराइजेशन को डेटा ट्रांसफर से जोड़ देता है। → समाधान: मेटाडेटा और स्कोप्ड एक्सेस कॉन्फ़िगरेशन लौटाएं, फिर क्लाइंट्स को सीधे ऑब्जेक्ट स्टोरेज पढ़ने दें।
- गलती: समवर्ती कमिट्स के लिए लास्ट-राइटर-विन्स का उपयोग करना। → यह क्यों विफल होता है: बाद का राइटर चुपचाप किसी अन्य राइटर के स्कीमा या स्नैपशॉट को ओवरराइट कर सकता है। → समाधान: एक अपेक्षित वर्ज़न सबमिट करें, एक एटॉमिक सशर्त अपडेट के साथ कॉन्फ्लिक्ट्स का पता लगाएं, और एक बजट के भीतर पुनः प्रयास करें।
- गलती: ताजगी (freshness) के लिए केवल एक निश्चित TTL पर निर्भर रहना। → यह क्यों विफल होता है: TTL समाप्त होने से पहले रीड-आफ्टर-राइट और अनुमति परिवर्तन एक गलत दृश्य देख सकते हैं। → समाधान: ETags, वर्ज़न्स, या स्नैपशॉट संदर्भों के साथ सत्यापित करें और अनुरोध जोखिम के आधार पर रीफ्रेश करने के लिए बाध्य करें।
- गलती: कैटलॉग डाउन होने पर सीधे रूट मेटाडेटा को संपादित करना। → यह क्यों विफल होता है: यह कमिट प्रोटोकॉल को बायपास करता है और फ़ाइल स्थिति से कैटलॉग इंडेक्स को विभाजित (split) कर देता है। → समाधान: राइट्स को विफल करें और पुनः प्रयास करें, फिर रिकवरी के दौरान लोकेशन्स, स्नैपशॉट्स और मैनिफ़ेस्ट्स को सत्यापित करें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: दो राइटर्स वर्ज़न V पर आधारित हैं। आप स्कीमा परिवर्तनों को कैसे मर्ज करते हैं?
सर्वर अनुमान लगाने के बजाय दूसरे कमिट को अस्वीकार कर देता है। क्लाइंट वर्तमान मेटाडेटा को पुनः लोड करता है और जांचता है कि क्या इसके स्कीमा, पार्टीशन या प्रॉपर्टी परिवर्तन नई स्थिति के साथ टकराव करते हैं। यह केवल तभी नया मेटाडेटा बनाता और सबमिट करता है जब मर्ज सुरक्षित हो। जो परिवर्तन स्वचालित रूप से मर्ज नहीं किया जा सकता है वह ऑपरेटर या जॉब-लेवल निर्णय के लिए एक स्पष्ट कॉन्फ्लिक्ट बन जाता है।
फॉलो-अप 2: क्या होगा यदि कैटलॉग कैश और ऑब्जेक्ट स्टोरेज असहमत हों?
कैटलॉग वर्ज़न को कमिट फैक्ट के रूप में और ऑब्जेक्ट-स्टोर मेटाडेटा लोकेशन को एक सत्यापन योग्य कॉपी के रूप में मानें। एक बैकग्राउंड चेकर सत्यापित करता है कि लोकेशन पठनीय है, स्नैपशॉट संदर्भ पूर्ण हैं, और मैनिफ़ेस्ट्स हल होते हैं। यदि कैटलॉग किसी अनुपलब्ध लोकेशन की ओर इशारा करता है, तो बाद के राइट्स को फ़्रीज़ करें, सबसे हाल के सत्यापन योग्य वर्ज़न को पुनर्स्थापित करें, और एक ऑडिट रिकॉर्ड रखें। कैश TTL बढ़ाने से केवल विफलता छिपती है।
फॉलो-अप 3: प्रत्येक इंजन को सीधे Hive Metastore से बात क्यों नहीं करने दी जाती?
विभिन्न भाषाओं के क्लाइंट्स ऑथेंटिकेशन, कॉन्फ्लिक्ट हैंडलिंग और फीचर विकास को दोहराएंगे, जिससे नए इंजन जोड़े जाने पर लागत बढ़ेगी। REST Catalog एक एकल प्रोटोकॉल और कैपेबिलिटी डिस्कवरी प्रदान करता है, जबकि सर्वर डीकॉन्फ्लिक्शन, कैशिंग और क्रेडेंशियल वेंडिंग को केंद्रीकृत करता है। यदि किसी संगठन के पास एक स्थिर Hive परिनियोजन (deployment) और एक ही इंजन है, तो उसे बनाए रखना सरल हो सकता है; माइग्रेशन को क्रॉस-इंजन कम्पैटिबिलिटी और गवर्नेंस लाभों द्वारा उचित ठहराया जाना चाहिए।
फॉलो-अप 4: क्या होगा यदि कोई क्लाइंट ऑब्जेक्ट-स्टोर क्रेडेंशियल को लॉग कर देता है?
क्रेडेंशियल्स अल्पकालिक, न्यूनतम-विशेषाधिकार वाले और अनुरोध ID से जुड़े होने चाहिए। रिडक्शन (रेडैक्शन) क्लाइंट और कैटलॉग सर्विस दोनों में चलता है। एक्सपोज़र होने पर, सत्र को रद्द या छोटा करें, एक्सेस ऑडिट लॉग का निरीक्षण करें और एक प्रतिस्थापन जारी करें। अत्यधिक संवेदनशील डेटा के लिए, एक सर्वर प्रॉक्सी या रिमोट साइनिंग डायरेक्ट-रीड प्रदर्शन की कीमत पर क्रेडेंशियल एक्सपोज़र को कम कर सकता है।