प्रश्न और परिदृश्य
यह एक मिड-टू-सीनियर डेटा-इंजीनियरिंग स्कीमा-इवोल्यूशन प्रॉम्प्ट है। यह इवेंट रियल-टाइम मेट्रिक्स और एक लेकहाउस को डेटा प्रदान करता है; उपभोक्ता विभिन्न संस्करण चलाते हैं और सभी एक ही दिन में अपग्रेड नहीं हो सकते। कम-से-कम-एक-बार डिलीवरी (at-least-once delivery) और दोबारा चलाए जा सकने वाले इवेंट्स (replayable events) मान लें। कॉन्ट्रैक्ट में फ़ील्ड प्रकार, सेमांटिक्स, गुणवत्ता, ताजगी (freshness), स्वामित्व (ownership) और सुरक्षा सीमाएं शामिल होनी चाहिए।
साक्षात्कारकर्ता क्या जांच रहा है
- एक मजबूत उत्तर "फ़ील्ड पार्स हो जाता है" को "व्यावसायिक अर्थ अपरिवर्तित है" से अलग करता है।
- क्या आप यह कहने के बजाय कि फ़ील्ड जोड़ना हमेशा सुरक्षित होता है, एक प्रोड्यूसर-कंज्यूमर कम्पैटिबिलिटी मैट्रिक्स बना सकते हैं?
- क्या आप प्रभावित कॉलम, क्वेरी और डैशबोर्ड की पहचान करने के लिए लाइनेज और उपयोग के साक्ष्यों का उपयोग करते हैं?
- क्या आप प्रतिवर्ती माइग्रेशन (reversible migration) को बनाए रखते हुए CI, रिलीज़ गेट्स और रनटाइम में कॉन्ट्रैक्ट को लागू कर सकते हैं?
पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
इवेंट प्रारूप और रजिस्ट्री, amount की वर्तमान इकाई और सीमा की पुष्टि करें, क्या उपभोक्ता अज्ञात फ़ील्ड को अस्वीकार करते हैं, क्या पुराने संदेशों को दोबारा चलाया (replayed) जाता है, और अनुपलब्ध currency का क्या अर्थ है। इकाई या राउंडिंग में बदलाव एक सेमांटिक ब्रेक है भले ही वायर प्रकार पार्स हो जाए; एक वैकल्पिक मेटाडेटा फ़ील्ड का माइग्रेशन अलग होता है। यह भी पूछें कि क्या उपभोक्ता संस्करण अवलोकन योग्य (observable) हैं, क्या एक अस्थायी डुअल-वर्जन टॉपिक स्वीकार्य है, और कौन से फ्रेशनेस और बैकफ़िल विंडो लागू होते हैं।
30-सेकंड का उत्तर ढांचा
मैं कॉन्ट्रैक्ट को स्कीमा, फ़ील्ड सेमांटिक्स, गुणवत्ता नियम, फ्रेशनेस, स्वामित्व और सुरक्षा बाधाओं के रूप में परिभाषित करूंगा, फिर लाइनेज और उपभोक्ता क्षमताओं की सूची तैयार करूंगा। मैं चुपचाप amount को नहीं बदलूंगा; मैं एक संस्करण या नए फ़ील्ड प्रकाशित करूंगा, पुराने प्रोजेक्शन को पठनीय रखूंगा, कम्पैटिबिलिटी CI और शैडो वैलिडेशन चलाऊंगा, और उपभोक्ताओं को बैचों में माइग्रेट करूंगा। रनटाइम वैलिडेशन संस्करणित साक्ष्य के साथ उल्लंघनों को अस्वीकार या क्वारंटाइन करेगा। माइग्रेशन के बाद मैं एक मापी गई डेप्रिकेशन विंडो रखूंगा, बनाए रखे गए इवेंट्स से पुराने प्रोजेक्शन का पुनर्निर्माण करूंगा, और सुलह (reconciliation) तथा रिप्ले के साथ समानता साबित करूंगा।
चरण-दर-चरण गहन विश्लेषण
- कॉन्ट्रैक्ट सीमा लिखें। नाम और प्रकार के अलावा इकाइयों, परिशुद्धता (precision), नलेबिलिटी, एनम्स, कुंजियों, इवेंट समय, फ्रेशनेस लक्ष्य, PII लेबल, मालिकों और ब्रेकिंग परिवर्तनों के लिए अनुमोदन को रिकॉर्ड करें। OpenMetadata स्कीमा, सेमांटिक्स, SLA, सुरक्षा, गुणवत्ता परीक्षण और स्वामित्व को एक शासित डेटा-कॉन्ट्रैक्ट ऑब्जेक्ट के रूप में मॉडल करता है।
- परिवर्तन को वर्गीकृत करें। एक वैकल्पिक फ़ील्ड जोड़ना अक्सर सहनशील पाठकों (tolerant readers) के लिए बैकवर्ड कम्पैटिबल होता है; हटाना, प्रकार परिवर्तन, संकीर्ण सीमाएं, इकाई परिवर्तन, या वैकल्पिक-से-आवश्यक परिवर्तन शुरुआत में ब्रेकिंग होते हैं। पूर्णांक सेंट को दशमलव मुद्रा में बदलने से सेमांटिक्स बदल जाते हैं, इसलिए पुराने को चुपचाप बदलने के बजाय एक सामान्यीकृत (normalized) फ़ील्ड या संस्करण जोड़ें।
- प्रभाव विश्लेषण करें। जॉब्स, डाउनस्ट्रीम टेबल, कॉलम लाइनेज और हाल के रन खोजने के लिए OpenLineage Dataset, Job, Run, और Schema Facet मेटाडेटा का उपयोग करें। सभी 40 उपभोक्ताओं के लिए, एक चेंज-बाय-कंज्यूमर मैट्रिक्स में पार्सर संस्करण, फ़ील्ड उपयोग, रिप्ले व्यवहार और माइग्रेशन स्वामी रिकॉर्ड करें।
- माइग्रेशन डिज़ाइन करें। एक सीमित अवधि के लिए
amount_minorऔरamount_decimalप्रकाशित करें, या एक v2 इवेंट प्रकाशित करें। पुराने उपभोक्ता पुराने प्रोजेक्शन को पढ़ते रहते हैं; नए उपभोक्ता नए फ़ील्ड को शैडो-रीड करते हैं। currency को केवल तभी वैकल्पिक के रूप में प्रकाशित करें जब एक डिफ़ॉल्ट मान व्यावसायिक अर्थ न बदलने के लिए सिद्ध हो सके। - गेट्स सेट करें। CI प्रकार, अनिवार्यता, एनम और सेमांटिक परिवर्तनों के लिए पंजीकृत संस्करण के साथ उम्मीदवार कॉन्ट्रैक्ट की तुलना करता है। फिर नमूना रिप्ले, गुणवत्ता अभिकथन (assertions) और उपभोक्ता कॉन्ट्रैक्ट परीक्षण चलाएं। प्रोडक्शन इनग्रेस इवेंट संस्करणों को मान्य करता है; अमान्य संदेश प्रोड्यूसर, कॉन्ट्रैक्ट संस्करण और कारण के साथ क्वारंटाइन में जाते हैं।
- स्विच और रोल बैक करें। पार्स त्रुटियों, अनुपलब्धता, मौद्रिक सुलह, विलंबता (latency) और रिप्ले अंतरों पर नज़र रखते हुए उपभोक्ताओं को बैचों में माइग्रेट करें। यदि नया प्रोजेक्शन गलत है, तो नए-संस्करण के लेखन को रोकें और पुराने रीड पाथ को पुनर्स्थापित करें; बनाए रखे गए इवेंट पुराने प्रोजेक्शन का पुनर्निर्माण कर सकते हैं। पुराने फ़ील्ड को तब तक न हटाएं जब तक कि अंतिम उपभोक्ता और रिप्ले विंडो डेप्रिकेशन लाइन को पार न कर लें।
- इसे जवाबदेह बनाएं। OpenLineage रन इवेंट जॉब्स, रन, इनपुट और आउटपुट का वर्णन करते हैं; एक Schema Facet डेटासेट फ़ील्ड को रिकॉर्ड करता है। लाइनेज इवेंट्स में कॉन्ट्रैक्ट संस्करण, Git रिवीजन और वैलिडेशन परिणाम डालें ताकि बाद की जांच यह पहचान सके कि किस रिलीज़ ने किस उपभोक्ता के परिणाम को बदल दिया।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं इसे एक सामान्य फ़ील्ड जोड़ने के रूप में नहीं मानूंगा। सबसे पहले मैं amount के लिए इकाई, परिशुद्धता और राउंडिंग नियमों को कॉन्ट्रैक्ट में रखूंगा, फिर लाइनेज का निरीक्षण करूंगा कि क्या 40 उपभोक्ता इसे पूर्णांक सेंट, एक डिस्प्ले मान या एकत्रीकरण कुंजी (aggregation key) के रूप में उपयोग करते हैं। OpenMetadata का डेटा-कॉन्ट्रैक्ट मॉडल स्कीमा, सेमांटिक्स, SLA, सुरक्षा, गुणवत्ता परीक्षण और स्वामित्व को कवर करता है, जो "पार्सर इसे स्वीकार करता है" जांच को व्यावसायिक गारंटी समझने की भूल से बचाता है।
मैं एक v2 या कम्पैटिबल डुअल-फ़ील्ड संस्करण पंजीकृत करूंगा: amount_minor को बनाए रखूंगा, स्पष्ट परिशुद्धता के साथ amount_decimal जोड़ूंगा, और वैकल्पिक currency जोड़ूंगा। CI कम्पैटिबिलिटी जांच चलाएगा; उपभोक्ता कॉन्ट्रैक्ट परीक्षण अज्ञात फ़ील्ड, अनुपलब्ध मुद्रा, पुराने-संदेश रिप्ले और परिशुद्धता सीमाओं को कवर करेंगे। मैं नए प्रोजेक्शन की शैडो-गणना करूंगा, उपभोक्ताओं को बैचों में माइग्रेट करूंगा, और इनग्रेस पर वैध कॉन्ट्रैक्ट संस्करण के बिना इवेंट्स को अस्वीकार करूंगा, विफलताओं को अलर्ट के साथ क्वारंटाइन करूंगा।
स्विच के दौरान मैं मौद्रिक सुलह, फ़ील्ड अनुपलब्धता, पार्स त्रुटियों, लेटेंसी और रिप्ले अंतरों पर नज़र रखूंगा। कोई भी विसंगति नए-संस्करण के लेखन को रोकती है, पुराने रीड पाथ को पुनर्स्थापित करती है, और बनाए रखे गए इवेंट्स से पुनर्निर्माण करती है। प्रत्येक उपभोक्ता के माइग्रेट होने, रिप्ले विंडो बंद होने और डेप्रिकेशन मेट्रिक्स शून्य तक पहुंचने के बाद ही मैं पुराने फ़ील्ड को हटाऊंगा। OpenLineage Job, Run, Dataset, और Schema Facet मेटाडेटा कॉन्ट्रैक्ट संस्करण और वैलिडेशन परिणाम ले जाएंगे ताकि प्रभाव विश्लेषण और ऑडिट प्रतिलिपि प्रस्तुत करने योग्य (reproducible) बने रहें।
सामान्य गलतियाँ
- केवल यह जांचना कि क्या JSON पार्स होता है → प्रकार कम्पैटिबिलिटी को सेमांटिक कम्पैटिबिलिटी के रूप में मानना → कॉन्ट्रैक्ट में इकाइयों, परिशुद्धता, नलेबिलिटी और सीमाओं को रखें और उनकी अलग से समीक्षा करें।
- प्रकाशित करना क्योंकि यह "सिर्फ एक नया फ़ील्ड" है → सख्त पार्सर या आवश्यक-फ़ील्ड जांच विफल हो जाती है → उपभोक्ताओं की सूची बनाएं और आवश्यकता पड़ने पर एक संस्करण या डुअल फ़ील्ड का उपयोग करें।
- प्रोडक्शन के बाद ही लॉग देखना → खराब डेटा को पुनर्प्राप्त करना पहले से ही कठिन होता है → CI में गेट लगाएं, नमूनों को फिर से चलाएं, और रनटाइम पर क्वारंटाइन करें।
- पुराने फ़ील्ड को तुरंत हटाना → रिप्ले करने वाले या पिछड़े हुए उपभोक्ता अपना रीड पाथ खो देते हैं → एक डेप्रिकेशन विंडो सेट करें जो उपभोक्ताओं और रिप्ले को कवर करती हो।
- लाइनेज को एक स्थिर कैटलॉग के रूप में मानना → आप इसका उत्तर नहीं दे सकते कि कौन सा रन प्रभावित हुआ था → Job, Run, Dataset, Schema Facet, संस्करण और वैलिडेशन साक्ष्य को कनेक्ट करें।
अनुवर्ती प्रश्न और उत्तर
क्या होगा यदि कोई लीगेसी उपभोक्ता अपग्रेड नहीं कर सकता है?
एक कम्पैटिबल पुराना प्रोजेक्शन या ट्रांसलेशन लेयर बनाए रखें ताकि नए इवेंट भी पुराने दृश्य का निर्माण करें। उस उपभोक्ता को एक स्वामी, समय सीमा और त्रुटि बजट (error budget) दें। कॉन्ट्रैक्ट को हमेशा के लिए फ़्रीज़ न करें या ट्रांसलेटर को चुपचाप मौद्रिक अर्थ बदलने न दें।
क्या होगा यदि मुद्रा अनुपलब्ध है और सुरक्षित रूप से अनुमानित नहीं की जा सकती है?
इसे एक कॉन्ट्रैक्ट उल्लंघन या स्पष्ट अज्ञात स्थिति के रूप में मानें; एक प्रशंसनीय डिफ़ॉल्ट का आविष्कार न करें। इवेंट को क्वारंटाइन करें और प्रोड्यूसर को सूचित करें। यदि व्यवसाय इसकी अनुमति देता है, तो एक स्पष्ट "अनिर्दिष्ट मुद्रा" मान प्रकाशित करें और इसे डाउनस्ट्रीम मेट्रिक्स में बहिष्कृत या समूहीकृत करें।
आप कैसे साबित करते हैं कि रोलबैक ने पैसे की दोहरी गणना नहीं की?
इवेंट ID, कॉन्ट्रैक्ट संस्करण और प्रोजेक्शन संस्करण को इडेम्पोटेंसी कुंजियों (idempotency keys) के रूप में उपयोग करें। दोनों प्रोजेक्शन को दोबारा चलाएं और ऑर्डर और मुद्रा के आधार पर योग की तुलना करें। अंतर नमूने, राउंडिंग नियम और इनपुट स्नैपशॉट सुरक्षित रखें; सुलह पास होने के बाद ही नए-संस्करण के लेखन को फिर से शुरू करें।