प्रश्न और यह कब लागू होता है
एक इंटरव्यूअर पूछ सकता है, “डाउनस्ट्रीम कंज्यूमर्स को प्रभावित किए बिना आप OpenLineage इवेंट स्कीमा को कैसे विकसित करेंगे?” यह डेटा-प्लेटफ़ॉर्म, डेटा-इन्फ्रास्ट्रक्चर और लिनिएज-सिस्टम भूमिकाओं के लिए उपयुक्त है। यह परीक्षण करता है कि क्या आप JSON Schema, Facet एक्सटेंशन, जनरेटेड क्लाइंट्स, इवेंट वर्ज़न और कंज्यूमर कम्पैटिबिलिटी को एक रिलीज़ प्रक्रिया में बदल सकते हैं।
इंटरव्यूअर क्या मूल्यांकन कर रहा है
मुख्य बात फ़ील्ड के नामों को याद रखना नहीं है; यह बदलाव की सीमाओं (change boundaries) को पहचानना है। OpenLineage अपने स्पेक को JSON Schema के रूप में दस्तावेज़ित करता है और जब कोई मौजूदा JSON फ़ाइल बदलती है तो वर्ज़न बम्प की आवश्यकता होती है; Java और Python क्लाइंट इससे जनरेट किए जाते हैं। इंटरव्यूअर आपसे यह भी अपेक्षा करता है कि आप RunEvent, JobEvent और DatasetEvent के बीच अंतर समझें, और यह जानें कि कस्टम Facets को एक विशिष्ट प्रीफ़िक्स और एक इम्यूटेबल वर्ज़न्ड स्कीमा URL की आवश्यकता होती है।
खुद से पूछने वाले स्पष्टीकरण प्रश्न
स्पष्ट करें कि क्या बदलाव किसी कोर ऑब्जेक्ट, किसी मौजूदा Facet, या एक नए कस्टम Facet को प्रभावित करता है। कौन से प्रोड्यूसर्स इवेंट उत्सर्जित (emit) करते हैं और कौन से कंज्यूमर्स इसे पार्स करते हैं? क्या पुराने क्लाइंट्स, रिप्ले जॉब्स या क्रॉस-लैंग्वेज SDKs मौजूद हैं? क्या कम्पैटिबिलिटी का लक्ष्य पुराने इवेंट्स को पढ़ना, वर्ज़न्स का डुअल-राइटिंग, या एक बार का कटओवर है? यह भी पूछें कि क्या कोई फ़ील्ड अनिवार्य (required) है, वैकल्पिक (optional) है, या अर्थ बदल रहा है, और विफल इवेंट्स को कैसे संभाला जाता है।
30-सेकंड का उत्तर ढाँचा
पाँच चरणों का उपयोग करें:
- प्रोड्यूसर्स, कंज्यूमर्स, इवेंट प्रकारों और वर्तमान स्कीमा वर्ज़न्स की सूची बनाएं।
- मौजूदा सिमेंटिक्स को बदलने के बजाय एक वैकल्पिक फ़ील्ड या नए Facet को प्राथमिकता दें।
- वर्ज़न बम्प करें, उदाहरणों और जनरेटेड क्लाइंट्स को अपडेट करें, और एक कम्पैटिबिलिटी मैट्रिक्स बनाएं।
- रिप्ले और शैडो ट्रैफ़िक के साथ वैलिडेट करें, फिर पार्स विफलताओं और गायब फ़ील्ड्स की निगरानी करते हुए प्रोड्यूसर्स का कैनरी रोलआउट करें।
- एक डेप्रिकेशन विंडो, रोलबैक पाथ और कंज्यूमर-माइग्रेशन एग्जिट क्राइटेरिया निर्धारित करें।
चरण-दर-चरण विस्तृत उत्तर
1. इवेंट और डिपेंडेंसी सीमाओं का मानचित्रण करें
OpenLineage ऑब्जेक्ट मॉडल में Jobs, Runs और Datasets शामिल हैं। RunEvent रनटाइम स्थिति का प्रतिनिधित्व करता है, जबकि JobEvent और DatasetEvent डिज़ाइन-टाइम मेटाडेटा का प्रतिनिधित्व करते हैं। पुष्टि करें कि कौन सा इवेंट, Facet और क्लाइंट्स प्रभावित हैं। स्कीमा रिपॉजिटरी, जनरेटेड कोड, मैसेज बस, इंडेक्स और क्वेरी APIs को मैप करें ताकि बदलाव केवल प्रोड्यूसर तक ही सीमित न रहे।
2. एक अनुकूल (compatible) विकास चुनें
किसी मौजूदा फ़ील्ड को हटाने, उसका प्रकार बदलने या पुनर्परिभाषित करने की तुलना में एक वैकल्पिक फ़ील्ड जोड़ना आमतौर पर अधिक सुरक्षित होता है। यदि अर्थ बदलता है, तो एक नया फ़ील्ड या Facet जोड़ें और कुछ समय के लिए डुअल-राइट करें। टकराव से बचने के लिए कस्टम Facet के लिए प्रोजेक्ट-विशिष्ट प्रीफ़िक्स का उपयोग करें; समान नाम वाला Facet किसी एंटिटी पर पिछले इंस्टेंस को बदल देता है, इसलिए नाम और वर्ज़न स्थिर रहने चाहिए।
3. कोड जेनरेशन के साथ वर्ज़न बदलें
जब कोई मौजूदा JSON Schema बदलता है, तो OpenLineage को फ़ाइल-वर्ज़न बम्प की आवश्यकता होती है, और वर्ज़न URL को एक इम्यूटेबल वर्ज़न की ओर इंगित करना चाहिए। Java और Python क्लाइंट्स जनरेट करें, उनके टेस्ट्स चलाएं, और सत्यापित करें कि प्रत्येक प्रोड्यूसर और कंज्यूमर इच्छित वर्ज़न पर पिन किया गया है। केवल दस्तावेज़ीकरण अपडेट न करें या हाथ से प्रकारों को कॉपी न करें।
4. एक कम्पैटिबिलिटी मैट्रिक्स स्पष्ट करें
कम से कम एक नए प्रोड्यूसर का पुराने कंज्यूमर के साथ, एक पुराने प्रोड्यूसर का नए कंज्यूमर के साथ, और दोनों वर्ज़न्स का रीप्ले किए गए डेटा के साथ परीक्षण करें। प्रत्येक फ़ील्ड के लिए रिकॉर्ड करें कि क्या यह गायब हो सकता है, क्या अज्ञात फ़ील्ड्स को अनदेखा किया जाता है, क्या नए enum मान सुरक्षित हैं, और क्या रूपांतरण प्रतिवर्ती (reversible) है। यदि कोई पुराना कंज्यूमर अज्ञात फ़ील्ड्स को अस्वीकार करता है, तो सीधे प्रोडक्शन ट्रैफ़िक का विस्तार न करें।
5. उदाहरणों, रिप्ले और शैडो ट्रैफ़िक के साथ वैलिडेट करें
प्रत्येक Facet के लिए न्यूनतम, पूर्ण और अमान्य उदाहरण रखें। नए पार्सर के माध्यम से ऐतिहासिक इवेंट्स को रिप्ले करें और संरचित आउटपुट और क्वेरी इंडेक्स की तुलना करें। फिर लाइव लिनिएज ग्राफ़ को बदले बिना नए प्रोड्यूसर से इवेंट्स को एक शैडो टॉपिक पर कॉपी करें। पार्स विफलताओं, अज्ञात Facets, वर्ज़न वितरण और एंड-टू-एंड लेटेंसी की निगरानी करें; विसंगतियों पर कैनरी को रोकें।
6. डेप्रिकेशन और रोलबैक डिज़ाइन करें
पुराने वर्ज़न की कटऑफ़ तिथि, माइग्रेशन ओनर और कंज्यूमर सूची प्रकाशित करें। प्रोड्यूसर्स पहले डुअल-राइट कर सकते हैं और कंज्यूमर्स के अपग्रेड होने के बाद पुराने फ़ील्ड्स को बंद कर सकते हैं। रोलबैक में पुराने स्कीमा, क्लाइंट्स और रिप्ले क्षमता को बनाए रखना चाहिए; पुराने वर्ज़न के इवेंट्स को हटाने से कोड तो रीस्टोर हो जाएगा लेकिन डेटा की व्याख्या करने की क्षमता नहीं रहेगी।
उच्च गुणवत्ता वाला नमूना उत्तर
इस काल्पनिक उत्तर को आपके इवेंट प्रकारों और संगठनात्मक बाधाओं के साथ बदला जाना चाहिए:
मैं RunEvent, JobEvent और DatasetEvent के लिए प्रोड्यूसर्स, कंज्यूमर्स, क्लाइंट वर्ज़न्स और रिप्ले जॉब्स की सूची बनाऊंगा, फिर पहचानूंगा कि बदलाव कोर स्कीमा में है या कस्टम Facet में। मैं बैकवर्ड-कम्पैटिबल वैकल्पिक फ़ील्ड को प्राथमिकता दूंगा; यदि अर्थ बदलता है, तो मैं प्रोजेक्ट-विशिष्ट प्रीफ़िक्स के साथ एक फ़ील्ड या Facet जोड़ूंगा। मैं JSON Schema वर्ज़न बम्प करूंगा, Java और Python क्लाइंट्स जनरेट करूंगा, और न्यूनतम, पूर्ण और अमान्य उदाहरणों को अपडेट करूंगा। वैलिडेशन में पुराने कंज्यूमर के साथ नया प्रोड्यूसर, नए कंज्यूमर के साथ पुराना प्रोड्यूसर और ऐतिहासिक रिप्ले शामिल होगा, जिसके बाद शैडो-ट्रैफ़िक कैनरी होगी। मैं पार्स विफलताओं, अज्ञात Facets, वर्ज़न वितरण और लेटेंसी की निगरानी करूंगा। कंज्यूमर्स द्वारा माइग्रेशन मानदंडों को पूरा करने के बाद, मैं एक दस्तावेज़ित डेप्रिकेशन विंडो के दौरान डुअल-राइटिंग समाप्त कर दूंगा। पुराना स्कीमा, क्लाइंट्स और रिप्ले पाथ उपलब्ध रहेंगे ताकि रोलबैक इवेंट के अर्थ को न मिटाए।
सामान्य गलतियाँ
यह कहना कि फ़ील्ड जोड़ना हमेशा कम्पैटिबल होता है
वैकल्पिकता, अज्ञात-फ़ील्ड व्यवहार और जनरेटेड-क्लाइंट अपडेट परिणाम को बदल देते हैं। एक कम्पैटिबिलिटी मैट्रिक्स और ठोस फिक्स्चर प्रदान करें।
बिना वर्ज़न बम्प किए स्कीमा बदलना
वर्ज़न URL कंज्यूमर्स को सिमेंटिक्स की पहचान करने की अनुमति देता है। बम्प न करने से कोड जेनरेशन टूट सकता है या अलग-अलग कंज्यूमर्स पुरानी परिभाषा मान सकते हैं।
कस्टम Facet को मनमाना JSON मानना
कस्टम Facets को एक अद्वितीय प्रीफ़िक्स और एक इम्यूटेबल वर्ज़न्ड स्कीमा URL की आवश्यकता होती है। नाम का टकराव किसी एंटिटी के पिछले Facet इंस्टेंस को चुपचाप बदल सकता है।
केवल नए इवेंट्स का परीक्षण करना, रिप्ले का नहीं
लिनिएज सिस्टम अक्सर इतिहास को रिप्ले करते हैं। रिप्ले परीक्षणों के बिना, गायब फ़ील्ड्स, मिश्रित वर्ज़न्स और इंडेक्स माइग्रेशन छिपे रह जाते हैं।
फॉलो-अप और उन्नत अभ्यास
एक पुराना कंज्यूमर किसी अज्ञात Facet पर विफल हो जाता है। आप इसे कैसे रिलीज़ करेंगे?
पहले कंज्यूमर को अज्ञात Facets को अनदेखा करने के लिए कहें या नए Facet को शैडो ट्रैफ़िक पर रूट करें। पार्सर और मेट्रिक व्यवहार सुरक्षित होने के बाद ही प्रोड्यूसर को कैनरी करें; कभी यह न मानें कि प्रत्येक JSON कंज्यूमर उदार (permissive) है।
आप कोर फ़ील्ड के बजाय एक नए Facet का उपयोग कब करेंगे?
उस संदर्भ के लिए Facet का उपयोग करें जो स्वतंत्र रूप से विकसित हो सकता है। कोर स्कीमा परिवर्तन पर केवल तभी विचार करें जब जानकारी किसी Job, Run या Dataset की पहचान या जीवनचक्र को बदलती हो। बताएं कि फ़ील्ड की संख्या से अधिक क्वेरी और ओनरशिप की सीमाएं क्यों मायने रखती हैं।
Java जेनरेशन पास हो जाती है लेकिन Python विफल हो जाती है। आप क्या करेंगे?
रिलीज़ को रोकें, तुलना करें कि जनरेटर वैकल्पिक फ़ील्ड्स, enums और अज्ञात गुणों को कैसे संभालते हैं, फिर स्कीमा या टेम्प्लेट को ठीक करें और दोनों क्लाइंट सुइट्स चलाएं। केवल एक भाषा का पास होना माइग्रेशन एग्जिट क्राइटेरिया नहीं है।
माइग्रेशन विंडो के बाद भी पुराने प्रोड्यूसर्स बने रहते हैं। आप उन्हें कैसे संभालते हैं?
प्रोड्यूसर और टीम द्वारा शेष स्रोतों को सूचीबद्ध करें, पुराने वर्ज़न के राइट्स को प्रतिबंधित करें, और एक स्पष्ट त्रुटि या डिग्रेडेशन पाथ प्रदान करें। यदि हार्ड स्टॉप से महत्वपूर्ण लिनिएज का नुकसान होगा, तो रिकॉर्ड किए गए जोखिम के साथ विंडो बढ़ाएं; पुराने इवेंट्स या स्कीमा को न हटाएं।