डेटा इंजीनियरिंग इंटरव्यू: आप एक ऑडिट करने योग्य (auditable) डेटा-क्वालिटी क्वारंटाइन पाइपलाइन कैसे डिज़ाइन करेंगे?

समस्या और संदर्भ

एक अपस्ट्रीम सिस्टम प्रति दिन 20 करोड़ ऑर्डर इवेंट्स भेजता है, और लगभग 0.2% में आवश्यक फ़ील्ड्स गायब हो सकते हैं, पार्सिंग विफलताएँ हो सकती हैं, या बिज़नेस-नियम के उल्लंघन हो सकते हैं। मान्य इवेंट्स को फ़ैक्ट टेबल और डाउनस्ट्रीम मेट्रिक्स में जाना जारी रखना चाहिए। अमान्य इवेंट्स चुपचाप गायब नहीं हो सकते; मरम्मत के बाद उन्हें मूल इनपुट से उसी इवेंट को दो बार गिने बिना पुनः चलाने (replay) योग्य होना चाहिए।

प्रति इनपुट एक स्थिर event_id, एक अपरिवर्तनीय (immutable) रॉ कॉपी, स्कीमा-वर्जन वाले नियम, और विफलता के कारणों, नियम संस्करणों और पुनः प्रयास (retry) स्थिति को बनाए रखने वाले क्वारंटाइन रिकॉर्ड्स के साथ एक बैच-और-स्ट्रीम डिज़ाइन मान लें। इंटरव्यू की समस्या किसी एकल Spark विकल्प के बजाय डेटा-इंजीनियरिंग रूटिंग, ऑब्जर्वेबिलिटी और रिकवरी के बारे में है।

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

पार्स विफलताओं, गायब फ़ील्ड्स और बिज़नेस सत्यापन विफलताओं को कार्रवाई योग्य श्रेणियों में अलग करना।
ऑडिट और रिप्ले के लिए रॉ साक्ष्य, नियम संस्करण और वंशावली (lineage) को संरक्षित करना।
ब्लास्ट रेडियस के आधार पर fail-fast, drop और redirect/quarantine के बीच चयन करना।
दोहरी गिनती को रोकने के लिए आइडेम्पोटेंसी कीज़, डिडप्लीकेशन स्थिति और आउटपुट संस्करणों का उपयोग करना।
गुणवत्ता मेट्रिक्स, अलर्ट थ्रेसहोल्ड, मरम्मत वर्कफ़्लो और रिप्ले गेट्स को डिज़ाइन करना।
क्वारंटाइन क्षेत्र में टॉक्सिक डेटा, PII, डेटा प्रतिधारण (retention) और एक्सेस नियंत्रण को संबोधित करना।

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

क्या 0.2% एक स्वीकृत दोष बजट (defect budget) है, या किसी भी उल्लंघन पर रिलीज़ को ब्लॉक करना आवश्यक है? यह थ्रेसहोल्ड बनाम ज़ीरो-टॉलरेंस गेटिंग तय करता है।
क्या इवेंट्स को पुनः प्रयास किया जा सकता है, वे क्रम से बाहर आ सकते हैं, या डुप्लिकेट हो सकते हैं? यदि हाँ, तो event_id को आइडेम्पोटेंसी सीमा को परिभाषित करना होगा।
क्या नियम विफलताओं की स्वतः मरम्मत की जा सकती है, या मानवीय स्वीकृति आवश्यक है? यह रिप्ले कतार और नियंत्रणों को बदल देता है।
क्या डाउनस्ट्रीम मेट्रिक्स देरी या सुधार को सहन कर सकते हैं? यदि नहीं, तो सुधारे गए डेटा को क्षतिपूर्ति पार्टीशन (compensating partitions) और संस्करणित रिपोर्टों की आवश्यकता होती है।
क्या रॉ पेलोड में व्यक्तिगत डेटा (PII) शामिल है? यह एन्क्रिप्शन, मास्किंग, एक्सेस और डिलीशन आवश्यकताओं को बदल देता है।

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

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

चरण-दर-चरण विस्तृत विवरण

1. पहले रॉ साक्ष्य को सुरक्षित रखें

बैच, स्रोत और प्राप्त समय के आधार पर अपरिवर्तनीय ऑब्जेक्ट्स या लॉग्स को पार्टीशन करें, और एक चेकसम स्टोर करें। प्रोसेसिंग जॉब्स रॉ पेलोड को अधिलेखित (overwrite) करने के बजाय स्थिति को अपेंड करती हैं। यह नियम अपग्रेड, पार्सर फिक्स और सप्लायर विवादों को समान इनपुट से पुनरुत्पादित करने योग्य बनाता है। रॉ और क्वारंटाइन लेयर्स के लिए अलग-अलग अनुमतियाँ सहायता उपयोगकर्ताओं को सीधे फ़ैक्ट्स को संपादित करने से रोकती हैं।

2. विफलताओं को वर्गीकृत करें और कारण बनाए रखें

पहले बाइट/फ़ॉर्मैट पार्सिंग चलाएं, दूसरे पर स्कीमा टाइप और आवश्यक-फ़ील्ड जांचें, और तीसरे पर क्रॉस-फ़ील्ड बिज़नेस नियम चलाएं। MALFORMED_JSON, MISSING_ORDER_ID, या INVALID_CURRENCY जैसे संरचित reason_code मान स्टोर करें। एक रिकॉर्ड में कई कारण हो सकते हैं, लेकिन पहले विफल होने वाले चरण और नियम संस्करण को सुरक्षित रखें ताकि बाद में की गई मरम्मत व्याख्या योग्य बनी रहे।

text

quarantine_record = {
  event_id, source_batch, raw_uri, payload_hash,
  schema_version, rule_version, failed_stage,
  reason_codes, first_seen_at, status
}

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

3. Fail, Drop, या Quarantine चुनें

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

4. आइडेम्पोटेंट मान्य राइट को परिभाषित करें

event_id के साथ स्रोत संस्करण को एक अद्वितीय कुंजी के रूप में उपयोग करें, और एक आइडेम्पोटेंट अपसर्ट (upsert) या कमिट लॉग के माध्यम से फ़ैक्ट टेबल लिखें। क्वारंटाइन को रिप्ले करने से पहले, जांचें कि क्या लक्ष्य ने पहले ही इवेंट को स्वीकार कर लिया है, फिर छोड़ें (skip), अपडेट करें, या एक क्षतिपूर्ति संस्करण चुनें। ऑर्डर राशि जैसे सुधारने योग्य तथ्यों के लिए, इतिहास को चुपचाप अधिलेखित न करें; एक सुधार इवेंट जारी करें और डाउनस्ट्रीम रिपोर्टों को संस्करण या प्रभावी समय के अनुसार पुनर्गणना करने दें।

5. मरम्मत, अनुमोदन और रिप्ले

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

6. गुणवत्ता मेट्रिक्स और रिलीज़ गेट्स

कुल इनटेक, मान्य दर, प्रत्येक reason_code अनुपात, क्वारंटाइन-आयु पर्सेंटाइल, रिप्ले सफलता, डुप्लिकेट इवेंट्स और डाउनस्ट्रीम सुधारों की निगरानी करें। गंभीरता के आधार पर गेट लगाएं: एक हस्ताक्षर विफलता ज़ीरो टॉलरेंस हो सकती है जबकि एक गायब वैकल्पिक फ़ील्ड केवल अलर्ट उत्पन्न करती है। यहाँ तक कि 0.2% की भी सामान्य घोषित करने के बजाय ऐतिहासिक आधार रेखाओं, स्रोत मिश्रण और व्यावसायिक नुकसान से तुलना की जानी चाहिए। जब कोई गेट ट्रिप होता है, तो डाउनस्ट्रीम प्रकाशन को फ्रीज करें या पिछले नियम संस्करण पर वापस लौटें (rollback) और किसी भी मैन्युअल रिलीज़ को रिकॉर्ड करें।

7. डेटा प्रतिधारण, गोपनीयता और रिकवरी

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

उच्च-गुणवत्ता वाला मॉडल उत्तर

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

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

ignoreCorruptFiles को सक्षम करना और सफलता घोषित करना → जॉब जारी रहती है लेकिन रिकॉर्ड्स गायब हो सकते हैं → पुनर्प्राप्ति योग्य रिकॉर्ड्स को कारण-कोड वाले क्वारंटाइन में रूट करें।
विफलताओं को एक संपादन योग्य तालिका में संग्रहीत करना → रॉ साक्ष्य बदला जा सकता है → रॉ को अपरिवर्तनीय रखें और नए मरम्मत संस्करण बनाएं।
रिप्ले किए गए इवेंट्स को सीधे पुनः सम्मिलित करना → डाउनस्ट्रीम मेट्रिक्स में दोहरी गिनती होती है → एक event_id विशिष्टता सीमा और कमिट लॉग का उपयोग करें।
प्रत्येक त्रुटि के लिए पूरे बैच को ब्लॉक करना → एक छोटा सा खराब हिस्सा ताजगी (freshness) को नष्ट कर देता है → चरण और गंभीरता के अनुसार fail या quarantine चुनें।
केवल कुल विफलताओं की गिनती करना → स्रोत और नियम प्रतिगमन (regressions) छिपे रहते हैं → मेट्रिक्स को कारण, स्कीमा संस्करण, स्रोत और समय के अनुसार विभाजित करें।
मरम्मत के बाद सत्यापन को छोड़ देना → पैच एक दूसरा दोष ला सकता है → रिप्ले को पूरी सत्यापन श्रृंखला निष्पादित करनी चाहिए।

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

क्वारंटाइन दर 0.2% से बढ़कर 8% हो जाती है। क्या आप प्रकाशन जारी रखते हैं?

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

आप रिप्ले को किसी तय (settled) ऑर्डर को बदलने से कैसे रोकते हैं?

मूल और सुधार इवेंट्स को अलग करें, और फ़ैक्ट टेबल में संस्करण या प्रभावी-समय कॉलम बनाए रखें। एक सेटलमेंट स्नैपशॉट अपनी इनपुट पीढ़ी को पिन करता है। एक सुधारा हुआ इवेंट एक क्षतिपूर्ति वर्कफ़्लो से होकर गुजरता है जहाँ वित्तीय नियम यह तय करते हैं कि तय की गई राशि को चुपचाप अधिलेखित करने के बजाय एक समायोजन (adjustment) बनाया जाए या नहीं।

क्वारंटाइन क्षेत्र में PII शामिल है। सहायता टीम कैसे जांच कर सकती है?

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

एक वर्कर लक्ष्य राइट के बाद लेकिन क्वारंटाइन स्थिति बदलने से पहले क्रैश हो जाता है। क्या होता है?

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

रिकॉर्ड को बनाए रखने के बजाय कब छोड़ा (drop किया) जाना चाहिए?

केवल तभी जब यह पुनर्प्राप्ति योग्य न हो, कोई अनुपालन नियम प्रतिधारण की मांग न करता हो, और बिज़नेस स्वामी स्पष्ट रूप से नुकसान को स्वीकार करता हो। तब भी, एक ऑडिट योग्य गणना, कारण, बैच और नीति संस्करण बनाए रखें, और गुणवत्ता रिपोर्टों में ड्रॉप को उजागर करें।