प्रतिनिधि इंटरव्यू विषय

डेटा इंजीनियरिंग इंटरव्यू: बिना कंज्यूमर्स को प्रभावित किए इवेंट स्कीमा को कैसे इवॉल्व करें?

डेटामध्यम
Offer.cc संपादकीय टीमप्रकाशित अपडेट किया गया

प्रश्न

एक ऑर्डर इवेंट को दर्जनों सर्विसेज और कई डेटा पाइपलाइनों द्वारा कंज्यूम किया जाता है। आपको एक आवश्यक (required) fulfillment_mode फ़ील्ड जोड़ना है और एक पुराने status मान को अधिक विस्तृत enums में विभाजित करना है। आप पुराने कंज्यूमर्स को क्रैश किए बिना, ऐतिहासिक रीप्ले को दूषित किए बिना या नए और पुराने प्रोड्यूसर्स को असंगत बनाए बिना इवेंट स्कीमा को कैसे इवॉल्व करेंगे?

प्रॉम्प्ट और संदर्भ

यह डेटा-इंजीनियरिंग प्रश्न दीर्घकालिक इवेंट-कॉन्ट्रैक्ट इवोल्यूशन का परीक्षण करता है। इसका उद्देश्य बैकवर्ड या फॉरवर्ड परिभाषाओं को रटना नहीं है, बल्कि वास्तविक रीडर्स, राइटर्स, सीरियलाइजेशन फॉर्मेट, ऐतिहासिक डेटा और रोलआउट क्रम से एक सुरक्षित योजना तैयार करना है। आपको कम्पैटिबिलिटी लक्ष्यों, फ़ील्ड सिमेंटिक्स, रजिस्ट्रेशन और टेस्टिंग, ड्यूल-वर्जन संचालन और अंतिम क्लीनअप की शर्तों को समझाना होगा।

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

  • क्या आप राइटर स्कीमा, रीडर स्कीमा और डिप्लॉयमेंट-समय के संयोजनों में अंतर करते हैं।
  • क्या आप कंज्यूमर रोलआउट क्रम के आधार पर बैकवर्ड, फॉरवर्ड, फुल या ट्रांजिटिव बाधाओं का चयन करते हैं।
  • क्या आप आवश्यक फ़ील्ड्स, enum परिवर्तनों, डिफॉल्ट्स, अज्ञात मानों और ऐतिहासिक रीप्ले को संभालते हैं।
  • क्या रजिस्ट्री गवर्नेंस, कॉन्ट्रैक्ट टेस्ट, मॉनिटरिंग, रोलबैक और ओनरशिप रिलीज प्रक्रिया का हिस्सा हैं।

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

इवेंट फॉर्मेट, टॉपिक या टेबल, प्रत्येक प्रोड्यूसर और कंज्यूमर, बाहरी या क्रॉस-टीम सब्सक्राइबर्स और प्रत्येक कंज्यूमर की अपग्रेड गति की सूची बनाएं। स्पष्ट करें कि क्या fulfillment_mode का नया अर्थ है या इसे पुराने status से बिना किसी नुकसान के प्राप्त (derive) किया जा सकता है, और क्या नया enum अज्ञात मानों की अनुमति देता है। यह भी पूछें कि क्या ऐतिहासिक इवेंट्स को रीप्ले किया जाना चाहिए, क्या डेटा लेक रॉ पेलोड स्टोर करता है, कम्पैटिबिलिटी नीति का मालिक कौन है, और क्या दो वर्जन संक्षेप में समानांतर रूप से चल सकते हैं।

30-सेकंड का उत्तर ढांचा

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

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

1. रीडर/राइटर मैट्रिक्स और कम्पैटिबिलिटी लक्ष्य बनाएं

पुराने राइटर के साथ पुराना रीडर, पुराने राइटर के साथ नया रीडर, नए राइटर के साथ पुराना रीडर और नए राइटर के साथ नया रीडर की सूची बनाएं। यदि कंज्यूमर्स पहले अपग्रेड हो सकते हैं, तो आपको फॉरवर्ड कम्पैटिबिलिटी की आवश्यकता होगी; यदि प्रोड्यूसर्स पहले अपग्रेड होते हैं, तो आपको बैकवर्ड कम्पैटिबिलिटी की आवश्यकता होगी; रोलिंग डिप्लॉयमेंट के लिए आमतौर पर ट्रांजिशन के दौरान दोनों की आवश्यकता होती है। कई वर्जनों में ऐतिहासिक रीप्ले के लिए केवल नवीनतम स्कीमा के साथ तुलना करने के बजाय ट्रांजिटिव जांच की भी आवश्यकता होती है।

2. फ़ील्ड सिमेंटिक्स को सुरक्षित रूप से विस्तार योग्य बनाएं

प्रत्येक पुराने रीडर के लिए एक नए फ़ील्ड को तुरंत आवश्यक (required) न बनाएं। Avro जैसे फॉर्मेट्स के साथ, एक नलेबल यूनियन (nullable union) या जहां उपयुक्त हो एक डिफॉल्ट का उपयोग करें; JSON के साथ, गायब (missing), नल (null) और अज्ञात (unknown) फ़ील्ड्स के बीच अंतर को परिभाषित करें। Enum का विस्तार करते समय, सुनिश्चित करें कि पुराने कंज्यूमर्स के पास केवल आज के मान आने की धारणा के बजाय एक सुरक्षित अज्ञात (unknown) शाखा हो। यदि पुराने status को बिना किसी नुकसान के मैप नहीं किया जा सकता है, तो चुपचाप अर्थ बदलने के बजाय एक नया इवेंट वर्जन या समानांतर फ़ील्ड जोड़ें।

3. असंगत रिलीज को रोकने के लिए रजिस्ट्री और कॉन्ट्रैक्ट टेस्ट का उपयोग करें

सब्जेक्ट या इवेंट प्रकार के अनुसार स्कीमा पंजीकृत करें और नामकरण, कम्पैटिबिलिटी स्तर और ओनर को परिभाषित करें। प्रोड्यूसर बिल्ड के दौरान नए स्कीमा की जांच करें। कंज्यूमर CI में, वास्तविक पुराने और नए नमूनों को डिसेरिएलाइज़ करें और व्यावसायिक व्यवहार की पुष्टि करें। केवल पार्स सफलता ही नहीं, बल्कि डिफॉल्ट्स, अज्ञात enums, समय और इकाई सिमेंटिक्स, नल्स और फ़ील्ड हटाने के बाद के व्यवहार का परीक्षण करें। एक विफल जांच रिलीज को ब्लॉक करती है बजाय इसके कि वह एक ऑनलाइन कंज्यूमर त्रुटि बन जाए।

4. ड्यूल राइट्स और चरणों के साथ रोल आउट करें

पहले ऐसे कंज्यूमर्स रिलीज करें जो दोनों फॉर्मेट्स को पढ़ सकें। फिर प्रोड्यूसर्स से पुराने फ़ील्ड को बनाए रखते हुए नए फ़ील्ड को पॉप्युलेट करवाएं। कंज्यूमर वर्जनों, पार्स त्रुटियों, डिफॉल्ट उपयोग और इवेंट लैग पर नज़र रखें; डेटा पाइपलाइनों को टेबल प्रकारों, विभाजनों (partitions) और बैकफिल्स को भी सत्यापित करना चाहिए। एक असंगत enum या संरचना के लिए, एक नया इवेंट प्रकार या टॉपिक बनाएं, दोनों को प्रकाशित करने के लिए एक ब्रिज का उपयोग करें, और प्रत्येक पथ को एक ओनर और रिटायरमेंट की तारीख दें।

5. रीप्ले, रोलबैक और क्लीनअप की शर्तों को परिभाषित करें

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

एक मजबूत उत्तर का उदाहरण

मैं दर्जनों कंज्यूमर्स और कई डेटा पाइपलाइनों की इन्वेंट्री बनाऊंगा, रोलिंग डिप्लॉयमेंट के दौरान चार रीडर/राइटर संयोजनों को रेखांकित करूंगा, और यह निर्धारित करूंगा कि क्या fulfillment_mode पुराने status से बिना नुकसान के प्राप्त किया जा सकता है या यह एक नया तथ्य है। यदि यह प्राप्त करने योग्य है, तो मैं फ़ील्ड को एक स्थिर डिफॉल्ट के साथ वैकल्पिक बनाऊंगा और पुराने status को बनाए रखूंगा; enum में एक सुरक्षित अज्ञात शाखा शामिल होगी। मैं दोनों फॉर्मेट्स को पढ़ने वाले कंज्यूमर्स को रिलीज करूंगा, फिर प्रोड्यूसर्स से ड्यूल-राइट करवाऊंगा जबकि रजिस्ट्री कम्पैटिबिलिटी लागू करेगी। CI पुराने और नए इवेंट्स, गायब फ़ील्ड्स, अज्ञात enums और ऐतिहासिक रीप्ले का परीक्षण करेगा, जबकि प्रोडक्शन मॉनिटरिंग पार्स विफलताओं, डिफॉल्ट उपयोग, कंज्यूमर वर्जनों और टेबल गुणवत्ता को ट्रैक करेगी। यदि संरचना वास्तव में असंगत है, तो मैं एक नया इवेंट वर्जन बनाऊंगा और दोनों पथों को ब्रिज करूंगा। प्रत्येक कंज्यूमर के माइग्रेट होने, पुराने-फ़ील्ड के रीड शून्य तक पहुंचने, रीप्ले सत्यापन पास होने और रोलबैक विंडो बंद होने के बाद ही मैं पुराने फ़ील्ड और ब्रिज को हटाऊंगा।

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

  • प्रोड्यूसर और कंज्यूमर रोलआउट क्रम को सूचीबद्ध किए बिना केवल "बैकवर्ड कम्पैटिबिलिटी सक्षम करें" कहना।
  • बिना किसी डिफॉल्ट, गायब-फ़ील्ड नियम, या पुराने रीडर्स के लिए सुरक्षित पथ के बिना एक आवश्यक फ़ील्ड जोड़ना।
  • Enum का इस तरह विस्तार करना कि पुराने कंज्यूमर्स अपवाद (exception) थ्रो करें या किसी अज्ञात मान को गलत व्यावसायिक स्थिति मानें।
  • वास्तविक पुराने नमूनों, रीप्ले, टेबल प्रकारों और व्यावसायिक परिणामों का परीक्षण करने के बजाय केवल यह जांचना कि स्कीमा रजिस्टर होता है या नहीं।
  • फ़ील्ड के अर्थ को ओवरराइट करना जिससे ऐतिहासिक रीप्ले की गलत व्याख्या हो।
  • बिना किसी ओनर, मॉनिटर, रिटायरमेंट तिथि या रोलबैक शर्त के हमेशा के लिए ड्यूल राइट्स और ब्रिज कोड को बनाए रखना।

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

आप बैकवर्ड, फॉरवर्ड या फुल कम्पैटिबिलिटी का चयन कैसे करते हैं?

रोलआउट क्रम और कंजम्पशन व्यवहार का उपयोग करें। प्रोड्यूसर-पहले रोलआउट के लिए पुराने रीडर्स को नया डेटा पढ़ने की आवश्यकता होती है, इसलिए बैकवर्ड कम्पैटिबिलिटी पर जोर दें। कंज्यूमर-पहले रोलआउट के लिए नए रीडर्स को पुराना डेटा पढ़ने की आवश्यकता होती है, इसलिए फॉरवर्ड कम्पैटिबिलिटी पर जोर दें। यदि क्रम अनियंत्रित है या दोनों दिशाओं को काम करना चाहिए, तो फुल का उपयोग करें। सभी ऐतिहासिक वर्जनों के लिए, ट्रांजिटिव का उपयोग करें और फॉर्मेट के वास्तविक नियमों की पुष्टि करें।

एक नए फ़ील्ड में आमतौर पर डिफॉल्ट क्यों होना चाहिए?

पुराने इवेंट्स में यह शामिल नहीं होता है, इसलिए पुराना डेटा पढ़ने के लिए स्पष्ट व्यवहार की आवश्यकता होती है। एक डिफॉल्ट रीडर को पार्स करने की अनुमति देता है, लेकिन इसका अर्थ ऐतिहासिक तथ्य होने का दिखावा करने के बजाय अज्ञात या प्रदान नहीं किया गया होना चाहिए। सार्थक डिफॉल्ट के बिना, नलेबल प्रकार, एक नए इवेंट वर्जन, या एक स्पष्ट बैकफिल का उपयोग करें।

ऐतिहासिक रीप्ले के दौरान आप एक नए enum को कैसे संभालते हैं?

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

आप पुराना फ़ील्ड कब हटा सकते हैं?

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

सार्वजनिक स्रोत

संबंधित प्रश्न