संकेत और संदर्भ
अपस्ट्रीम जॉब्स प्रत्येक दिन कई डेटा संपत्तियां (assets) उत्पन्न करते हैं। रिपोर्ट्स और गुणवत्ता जांच उनकी निर्भरताओं के अपडेट होने के बाद चलनी चाहिए। बताएं कि आप Airflow asset-aware scheduling के साथ उत्पादकों (producers), उपभोक्ताओं (consumers), विभाजनों (partitions) और रिकवरी को कैसे मॉडल करेंगे, और यह समय-आधारित शेड्यूल्स और बाहरी सेंसरों से कैसे भिन्न है।
साक्षात्कारकर्ता क्या जांच रहा है
- किसी asset को केवल एक फ़ाइल नाम या cron लेबल के रूप में नहीं, बल्कि एक तार्किक डेटा निर्भरता के रूप में मानना जिसे एक कार्य अपडेट करता है।
- Asset events, DAG timetables, एक्सप्रेशन संयोजन और इवेंट ट्रिगर्स के बीच अंतर करना।
- डुप्लिकेट इवेंट्स, विलंबित डेटा, विभाजन ग्रैन्युलैरिटी, गुणवत्ता नियंत्रण (quality gates), और बैकफ़िल्स को ध्यान में रखना।
- मॉनिटरिंग, ऑथराइजेशन, आइडम्पोटेंसी (idempotency), पुनः प्रयास (retries), और पॉज़/रिज़्यूमे व्यवहार की व्याख्या करना।
स्पष्टीकरण के लिए पूछे जाने वाले प्रश्न
- क्या कोई asset पूरी तालिका, किसी विभाजन या ऑब्जेक्ट-स्टोरेज पथ का प्रतिनिधित्व करता है? क्या इवेंट्स विभाजन और बैच पहचान साथ लेकर चलते हैं?
- क्या उपभोक्ता को प्रत्येक अपस्ट्रीम asset की प्रतीक्षा करनी चाहिए, या कोई भी एक अपडेट इसे ट्रिगर कर सकता है? क्या क्रॉस-DAG asset expressions की आवश्यकता है?
- यदि कोई इवेंट आता है लेकिन गुणवत्ता जांच विफल हो जाती है, तो क्या उपभोक्ता को ब्लॉक किया जाना चाहिए, उत्पादक का पुनः प्रयास किया जाना चाहिए, या किसी मानव द्वारा इसे रिलीज़ किया जाना चाहिए?
- क्या हमें ऐतिहासिक बैकफ़िल्स, इवेंट रीप्ले, या मौजूदा cron शेड्यूल के साथ संगतता की आवश्यकता है? डुप्लिकेट ट्रिगर की लागत क्या है?
एक 30-सेकंड का उत्तर
मैं डेटा उत्पाद को अपडेट अनुबंधों वाले assets के रूप में मॉडल करूंगा, फिर उत्पादक DAG को केवल एक परमाणु लेखन (atomic write) और गुणवत्ता जांच सफल होने के बाद ही asset अपडेट उत्सर्जित करने दूंगा। एक उपभोक्ता DAG छोटे cron अंतराल के साथ तत्परता का अनुमान लगाने के बजाय अपनी ट्रिगर स्थिति को परिभाषित करने के लिए asset निर्भरताओं या अभिव्यक्तियों का उपयोग करता है। मैं विभाजन, आइडम्पोटेंसी, डुप्लिकेट-इवेंट, विलंबित-अपडेट और बैकफ़िल नियमों को परिभाषित करूंगा, फिर इवेंट विलंबता, प्रतीक्षारत DAGs, पुनः प्रयास और ताज़गी की निगरानी करूंगा। यदि अपडेट Airflow के बाहर से उत्पन्न होते हैं, तो मैं इवेंट-संचालित ट्रिगर की पुनर्प्राप्ति और सुरक्षा सीमाओं का मूल्यांकन करूंगा।
चरण-दर-चरण गहन विश्लेषण
1. एक asset अनुबंध स्थापित करें
आधिकारिक Airflow Assets दस्तावेज़ीकरण assets को DAGs के बीच साझा की गई डेटा निर्भरताओं के रूप में परिभाषित करता है। एक उत्पादक को डेटा कमिट और अनुबंध जांच सफल होने के बाद ही किसी asset को अपडेट करना चाहिए; एक अस्थायी फ़ाइल बनाना, कार्य शुरू करना, या आंशिक रूप से डेटा लिखना तत्परता नहीं है। Asset URI, स्वामी और विभाजन ग्रैन्युलैरिटी को स्थिर रखें ताकि उपभोक्ता नए डेटा को पुराने डेटा से अलग पहचान सकें।
2. ट्रिगर लॉजिक का चयन करें
एक उपभोक्ता DAG एक या अधिक assets पर निर्भर हो सकता है। आधिकारिक Asset-Aware Scheduling दस्तावेज़ीकरण तार्किक संयोजनों का समर्थन करता है जो ऐसी स्थितियों को व्यक्त करते हैं जैसे कि सभी assets अपडेट किए गए या कोई भी asset अपडेट किया गया; एक timetable एक स्वतंत्र बाधा के रूप में बना रह सकता है। परिभाषित करें कि इवेंट और समय की स्थिति मेल खाने पर क्या होता है, और किसी अभिव्यक्ति को पंक्ति सामग्री पर फ़िल्टर समझने की भूल न करें।
3. विभाजन और डुप्लिकेट्स को संभालें
एक asset इवेंट डेटा-विभाजन वॉटरमार्क का स्थान नहीं लेता है। एक ट्रेस करने योग्य बैच या विभाजन पहचान साथ रखें, और आइडम्पोटेंसी के लिए वॉटरमार्क तालिका, अद्वितीय कुंजी, या ट्रांजेक्शनल लेखन का उपयोग करें। डुप्लिकेट इवेंट्स, कार्य के पुनः प्रयास और शेड्यूलर रिकवरी सभी निर्भरताओं का पुनर्मूल्यांकन कर सकते हैं, इसलिए उपभोक्ताओं को ठीक एक इवेंट मानकर चलने के बजाय सुरक्षित रूप से पुनः चलाने योग्य (rerunnable) होना चाहिए।
4. बाहरी इवेंट्स, गुणवत्ता और रिकवरी
जब अपडेट किसी कतार या अन्य सिस्टम से आते हैं, तो ट्रिगर चुनने के लिए आधिकारिक इवेंट-संचालित शेड्यूलिंग दस्तावेज़ों का उपयोग करें, फिर पुनर्प्राप्ति योग्य जांच, कनेक्शन क्रेडेंशियल्स और संसाधन रिलीज़ को सत्यापित करें। गुणवत्ता विफल होने पर asset को गैर-तैयार रखें, और पुनः प्रयास करें या स्पष्ट रिलीज़ की मांग करें। बैकफ़िल्स के लिए, तय करें कि इवेंट्स उत्सर्जित करने हैं या नहीं, ऐतिहासिक विभाजनों को अलग करना है, और रीप्ले को रीयल-टाइम परिणाम को अधिलेखित (overwrite) करने से रोकना है।
मॉडल उत्तर
मैं पहले asset अनुबंध को परिभाषित करूंगा: URI, विभाजन कुंजी, उत्पादक, गुणवत्ता गेट और बैच पहचान। एक उत्पादक DAG केवल एक परमाणु लेखन और गुणवत्ता जांच के बाद ही asset को अपडेट करता है। एक उपभोक्ता DAG सभी-अपस्ट्रीम बनाम किसी-भी-अपस्ट्रीम स्थितियों के लिए asset निर्भरताओं या अभिव्यक्तियों का उपयोग करता है, जिसे वैकल्पिक रूप से एक timetable के साथ जोड़ा जा सकता है। इवेंट्स विभाजन और बैच पहचान ले जाते हैं; उपभोक्ता डुप्लिकेट्स, पुनः प्रयास और शेड्यूलर रिकवरी के लिए वॉटरमार्क और आइडम्पोटेंसी कुंजियों का उपयोग करता है। बाहरी अपडेट सीमित क्रेडेंशियल्स और संसाधन जीवनकाल के साथ एक नियंत्रित ट्रिगर का उपयोग करते हैं। मैं इवेंट विलंबता, प्रतीक्षारत कार्यों, ताज़गी और रीप्ले विफलताओं की निगरानी करता हूं। बैकफ़िल और रीयल-टाइम पथ अलग-अलग बैच सीमाओं का उपयोग करते हैं ताकि ऐतिहासिक रीप्ले नवीनतम परिणाम को अधिलेखित न कर सके।
सामान्य गलतियाँ
- अपडेट स्वामित्व और तत्परता को परिभाषित किए बिना किसी asset को एक मनमाना पथ मानना।
- डेटा-तैयार सिग्नल, विभाजन अनुबंध, या गुणवत्ता गेट के बिना cron अंतराल को छोटा करना।
- यह मान लेना कि asset इवेंट्स ठीक एक बार वितरित किए जाते हैं और पुनः प्रयास, डुप्लिकेट्स या शेड्यूलर रिकवरी की अनदेखी करना।
- किसी asset अभिव्यक्ति को पंक्ति-सामग्री फ़िल्टर के रूप में मानना और वास्तविक विभाजन वॉटरमार्क को छोड़ देना।
- किसी बाहरी ट्रिगर को बिना टाइमआउट और क्लीनअप के अनिश्चित काल तक कनेक्शन या क्रेडेंशियल बनाए रखने की अनुमति देना।
- बैकफ़िल्स के लिए रीयल-टाइम DAG का पुन: उपयोग करना और ऐतिहासिक रीप्ले को लाइव आउटपुट को अधिलेखित करने की अनुमति देना।
फॉलो-अप प्रश्न और उत्तर
क्या होगा यदि दो अपस्ट्रीम assets अलग-अलग समय पर आते हैं?
तय करें कि उपभोक्ता सभी assets की प्रतीक्षा करता है या आंशिक परिणाम प्रकाशित कर सकता है। सभी-assets सेमेन्टिक्स के लिए, प्रत्येक विभाजन के आगमन वॉटरमार्क को ट्रैक करें और टाइमआउट पर अलर्ट करें। आंशिक परिणामों के लिए, एक संस्करण प्रकाशित करें ताकि उपभोक्ताओं को पता चले कि बाद का asset इसे अपडेट कर सकता है।
आप डुप्लिकेट इवेंट्स का परीक्षण कैसे करेंगे?
परीक्षण परिवेश में, एक ही asset अपडेट को दो बार प्रकाशित करें, उत्पादक का पुनः प्रयास करें और शेड्यूलर को पुनरारंभ करें। पंक्ति गणना, संस्करण और सूचनाएं या शुल्क जैसे बाहरी दुष्प्रभावों सहित उपभोक्ता अद्वितीय कुंजियों, वॉटरमार्क और ट्रांजेक्शन सीमाओं को सत्यापित करें।
आप किसी बाहरी सेंसर को कब बनाए रखेंगे?
अस्थायी रूप से इसे तब बनाए रखें जब निर्भरता प्रणाली Airflow asset इवेंट्स उत्सर्जित नहीं कर सकती है, केवल एक नियंत्रित पोलिंग इंटरफ़ेस प्रदर्शित करती है, या माइग्रेशन के दौरान संगत बनी रहनी चाहिए। माइग्रेशन की समय सीमा और पोलिंग लागत को रिकॉर्ड करें, फिर अपस्ट्रीम सिस्टम को एक सत्यापन योग्य asset अपडेट सिग्नल की ओर स्थानांतरित करें।