डेटा इंजीनियरिंग इंटरव्यू: आपको SLO के आधार पर स्ट्रीमिंग पाइपलाइनों को कब अलग करना चाहिए?

प्रॉम्प्ट और दायरा

यह डेटा-प्लेटफ़ॉर्म, रियल-टाइम एनालिटिक्स और सीनियर डेटा-इंजीनियरिंग भूमिकाओं के लिए एक सामान्य डिज़ाइन प्रश्न है। मान लें कि पीक लोड 50,000 इवेंट्स प्रति सेकंड है, डैशबोर्ड का फ्रेशनेस लक्ष्य 60 सेकंड है, और पिछले दिन की रिपोर्ट 07:00 बजे तक पूरी होनी है। यह इंटरव्यू यह जांचता है कि कब एक शेयर्ड एक्ज़ीक्यूशन ग्राफ़ प्रत्येक कंज्यूमर को सबसे सख्त SLO अपनाने के लिए मजबूर करता है, और इंडिपेंडेंट प्रोग्रेस और रिसोर्स पूल कपलिंग को कैसे कम करते हैं।

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

• क्या आप टूल्स के नाम लेने से पहले "रियल टाइम" और "ऑन टाइम" को एंड-टू-एंड SLOs में बदलते हैं।
• क्या आप एक Beam ग्राफ़ के भीतर की ब्रांचेस, एक ही सोर्स के इंडिपेंडेंट सब्सक्रिप्शन और पूरी तरह से इंडिपेंडेंट कंप्यूट रिसोर्सेज के बीच अंतर समझते हैं।
• क्या आप डुप्लिकेट रीड्स, लागत, बैकप्रेशर, रीप्ले, लेट इवेंट्स और फेलियर डोमेन के बीच ट्रेड-ऑफ को समझा सकते हैं।
• क्या आप ऐसे मेट्रिक्स, कैनरी, रोलबैक और रीकंसीलिएशन प्रदान करते हैं जो यह साबित करते हैं कि पाइपलाइन को अलग करने से यूजर्स के परिणामों में सुधार होता है।

पहले पूछे जाने वाले स्पष्टीकरण प्रश्न

पूछें कि क्या 60 सेकंड का अर्थ इवेंट-टाइम-टू-क्वेरीएबल फ्रेशनेस (event-time-to-queryable freshness) है या केवल प्रोसेसर लेटेंसी; क्या फाइनेंस रिपोर्ट लेट पार्टिशन्स को बैकफिल कर सकती है; क्या दोनों कंज्यूमर्स एक इम्यूटेबल रॉ स्टोरेज साझा कर सकते हैं; क्या इवेंट्स को टेनेंट या प्रायोरिटी निष्पक्षता की आवश्यकता है; किस प्रकार के डुप्लिकेशन, लॉस और ऑर्डरिंग गारंटी की आवश्यकता है; और क्या बजट लागत के पक्ष में है या डैशबोर्ड टेल लेटेंसी के पक्ष में। यदि रिपोर्ट T+1 है लेकिन डैशबोर्ड का कम-लेटेंसी का कड़ा लक्ष्य है, तो आइसोलेशन मूल्यांकन करने के लिए पहले से ही एक विश्वसनीय डिफ़ॉल्ट विकल्प है।

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

मैं दोनों कंज्यूमर्स के एंड-टू-एंड SLOs, शुद्धता की गारंटी (correctness guarantees), और रिकवरी लक्ष्यों को नोट करूँगा। यदि एक शेयर्ड पाइपलाइन को 60-सेकंड के सख्त लक्ष्य को पूरा करना है, तो मैं एक शेयर्ड बेसलाइन स्थापित करूँगा, फिर रियल-टाइम और बैच प्रोग्रेस को अलग करने के लिए इंडिपेंडेंट सब्सक्रिप्शन का उपयोग करूँगा। मैं महंगे सामान्य पार्सिंग को साझा करूँगा, लेकिन रिसोर्स प्रेशर या विफलता के प्रसार के महत्वपूर्ण होने पर कंप्यूट को अलग कर दूँगा। प्रत्येक पाथ को अपने स्वयं के फ्रेशनेस, बैकलॉग, लेट-डेटा, डुप्लिकेट और रिपोर्ट-कम्प्लीशन मेट्रिक्स मिलते हैं, और रीप्ले व फॉल्ट इंजेक्शन यह तय करते हैं कि अतिरिक्त आइसोलेशन लागत के लायक है या नहीं।

विस्तृत उत्तर

1. SLOs से संरचना प्राप्त करना

रियल-टाइम SLO को 60 सेकंड से कम p99 इवेंट-टाइम-टू-क्वेरीएबल फ्रेशनेस के रूप में परिभाषित करें। बैच SLO को पिछले दिन के वैध इवेंट्स को 07:00 बजे तक पूरा करने के रूप में परिभाषित करें, जिसमें लेट डेटा एक सीमित रिपेयर विंडो में प्रवेश करता है। Google का Dataflow मार्गदर्शन नोट करता है कि मिक्स्ड SLOs की सेवा करने वाली एकल पाइपलाइन को अधिक सख्त लक्ष्य को पूरा करना होगा, जिससे कम प्राथमिकता वाला कार्य रियल-टाइम क्षमता का उपभोग कर सकता है। विभिन्न एरर बजट, अलर्ट रूट, या ऑटोस्केलिंग नीतियां पाथ्स को अलग करने के मजबूत कारण हैं।

2. तीन टोपोलॉजी की तुलना

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

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

3. अनुशंसित पाथ डिज़ाइन करें

एक इम्यूटेबल रॉ-इवेंट लेयर रखें और उसी सोर्स से एक रियल-टाइम सब्सक्रिप्शन और एक बैच सब्सक्रिप्शन बनाएं। रियल-टाइम जॉब एक लो-लेटेंसी सर्विंग स्टोर में लाइटवेट एग्रीगेशन करता है। बैच जॉब इवेंट की तारीख के अनुसार रिटेन किए गए डेटा को पढ़ता है और पार्टिशन्ड टेबल्स लिखता है। यदि सामान्य पार्सिंग कुल CPU का 20% से अधिक है, तो इसे इनग्रेस (ingress) पर एक बार नॉर्मलाइज़ करें और रॉ लेयर में वर्ज़न किए गए इवेंट्स लिखें; रियल-टाइम कंज्यूमर की प्रोग्रेस को इस बात का प्रमाण न मानें कि बैच पाथ कमिट हो चुका है।

raw-events
  -> realtime-subscription -> stream-aggregate -> serving-store
  -> batch-subscription or retained-raw -> daily-transform -> partitioned-lake

4. बैकप्रेशर, प्राथमिकता और लागत को संभालना

रियल-टाइम पाथ को इसकी अपनी समवर्ती सीमा (concurrency cap) और बैकलॉग अलर्ट दें। जब रियल-टाइम रिसोर्सेज सीमित हों तो बैच को समवर्ती कम करने की अनुमति दें, लेकिन दोनों को एक अनबाउंडेड कतार के पीछे न रखें। यदि दो पूर्ण कंप्यूट बहुत महंगे हैं, तो रॉ डिकोडिंग और लैंडिंग को साझा करें, फिर डाउनस्ट्रीम चरणों को अलग करें। जब रियल-टाइम बैकलॉग 60 सेकंड से अधिक हो जाता है, तो बैच क्षमता का विस्तार करना बंद कर दें और पहले रियल-टाइम SLO को रिकवर करें। जॉब्स की संख्या की तुलना करने के बजाय प्रत्येक पाथ के लिए इनपुट बाइट्स, CPU, बैकलॉग एज और प्रति मिलियन इवेंट लागत का श्रेय दें।

5. लेट-डेटा, रीप्ले और रिकवरी को संभालना

रियल-टाइम विंडोज़ के लिए वॉटरमार्क और सीमित स्वीकार्य लेट-डेटा (bounded allowed lateness) का उपयोग करें। विंडो से बाहर के इवेंट्स को लेट-डेटा कतार या रॉ लेयर पर रूट करें, फिर बैच को वर्ज़न किए गए, इडेम्पोटेंट (idempotent) राइट के साथ प्रभावित पार्टिशन्स को रिपेयर करने दें। एक नया सब्सक्रिप्शन बनाकर सहेजी गई सोर्स पोजीशन से रीप्ले करें; प्रोडक्शन कंज्यूमर की एक्नॉलेजमेंट पोजीशन को कभी रिवाइंड न करें। रियल-टाइम विफलता के बाद भी बैच पाथ को रॉ डेटा से रिकवर होना चाहिए। यदि रॉ स्टोरेज अनुपलब्ध है, तो दोनों पाथ्स को स्पष्ट डिग्रेडेशन और अलर्ट की आवश्यकता होती है।

6. स्वीकृति प्रयोग से निर्णय लें

पहले शेयर्ड बेसलाइन चलाएं, फिर एक छोटे टेनेंट स्लाइस के लिए आइसोलेटेड रिसोर्सेज सक्षम करें। डैशबोर्ड p50/p95/p99 फ्रेशनेस, रिपोर्ट कम्प्लीशन, बैकलॉग एज, डुप्लिकेट रेट, रीप्ले टाइम, CPU, स्टोरेज और प्रति मिलियन इवेंट लागत की तुलना करें। बैच बर्स्ट, प्रोसेसर रीस्टार्ट, डुप्लिकेट मैसेजेस, लेट पार्टिशन्स और रोके गए सब्सक्रिप्शन इंजेक्ट करें। यदि विभाजन केवल प्रोसेसर लेटेंसी में सुधार करता है जबकि डुप्लिकेट डेटा बढ़ाता है या लागत बजट से अधिक हो जाता है, तो शेयर्ड योजना बनाए रखें और सामान्य चरण को ऑप्टिमाइज़ करें।

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

मैं पहले दो एंड-टू-एंड SLOs को परिभाषित करूँगा: डैशबोर्ड p99 इवेंट-टाइम-टू-क्वेरीएबल फ्रेशनेस 60 सेकंड से कम, और एक सीमित लेट-डेटा रिपेयर विंडो के साथ 07:00 बजे तक पिछले दिन की फाइनेंस रिपोर्ट का पूरा होना। मैं एक शेयर्ड बेसलाइन बनाऊंगा लेकिन कभी भी रियल-टाइम और बैच के बीच एक्नॉलेजमेंट पोजीशन साझा नहीं करूँगा। मेरा डिफ़ॉल्ट डिज़ाइन एक इम्यूटेबल रॉ-इवेंट लेयर, दो इंडिपेंडेंट सब्सक्रिप्शन और दो डाउनस्ट्रीम जॉब्स हैं। रियल-टाइम जॉब लाइटवेट एग्रीगेशन करता है; बैच जॉब इवेंट की तारीख के अनुसार रिटेन किए गए डेटा को पढ़ता है। सामान्य पार्सिंग को इनग्रेस पर एक बार वर्ज़न किया जा सकता है, जबकि पूर्ण जॉब्स को केवल तभी अलग किया जाता है जब रिसोर्सेज या फेलियर डोमेन की मांग हो। प्रत्येक पाथ फ्रेशनेस, बैकलॉग, लेट-डेटा, डुप्लिकेट, रिपोर्ट कम्प्लीशन और यूनिट-लागत मेट्रिक्स का मालिक है; रीप्ले एक नए सब्सक्रिप्शन और इडेम्पोटेंसी कीज़ का उपयोग करता है। मैं SLOs को सत्यापित करने के लिए बर्स्ट, रीस्टार्ट और लेट इवेंट्स इंजेक्ट करूँगा। यदि आइसोलेशन से यूजर्स के परिणामों में सुधार नहीं होता है, तो मैं शेयर्ड कंप्यूट रखूँगा और सामान्य चरण को ऑप्टिमाइज़ करूँगा।

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

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

फॉलो-अप प्रश्न

क्या होगा यदि दोनों पाथ्स को समान महंगे फीचर कैलकुलेशन की आवश्यकता हो?

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

क्या इंडिपेंडेंट सब्सक्रिप्शन इनपुट लागत को दोगुना कर देंगे?

वे रीड और एक्नॉलेजमेंट ओवरहेड जोड़ते हैं, लेकिन इम्यूटेबल लैंडिंग, कम्प्रेशन, रिटेंशन विंडोज़ और ऑन-डिमांड रीप्ले इसे नियंत्रित कर सकते हैं। रियल-टाइम SLO और फेलियर आइसोलेशन के साथ प्रति मिलियन इवेंट लागत का मूल्यांकन करें; केवल स्टोरेज लागत पर विचार करना अधूरा है।

क्या बैच पीछे छूट जाने पर रियल-टाइम क्षमता उधार ले सकता है?

एक लीज और स्वचालित रिक्लेमेशन के साथ सीमित, प्रीम्प्टिबल लो-प्रायोरिटी क्षमता का उपयोग करें। रियल-टाइम एक सख्त सीमा और एक इंडिपेंडेंट बैकलॉग मेट्रिक रखता है, इसलिए उधार ली गई क्षमता इसके p99 को 60 सेकंड से आगे नहीं धकेल सकती है।

आप कैसे साबित करते हैं कि दोनों पाथ्स अंततः सहमत हैं?

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