प्रॉम्प्ट और संदर्भ
एक भुगतान प्रणाली कल 1,000 ऑर्डर्स की रिपोर्ट करती है, लेकिन वेयरहाउस रिपोर्ट में 998 हैं। एक ऐसी पाइपलाइन डिज़ाइन करें जो सोर्स, लैंडिंग लेयर, ट्रांसफ़ॉर्मेशन मॉडल और रिपोर्ट में अंतर (differences) का पता लगाती हो।
उत्तर को dbt, Airflow या किसी विशिष्ट वेयरहाउस तक सीमित न रखें। लक्ष्य एक ऐसा दोहराने योग्य एविडेंस चेन बनाना है जो छूटे हुए (missing), डुप्लिकेट, मिसमैच, देर से आए (late) और अलग-अलग परिभाषित रिकॉर्ड्स में अंतर कर सके।
इंटरव्यूअर क्या टेस्ट कर रहा है
रिकॉन्सिलिएशन ग्रेन (Reconciliation grain)
ऑर्डर, मर्चेंट, दिन या बैच ग्रेन चुनने से पहले बिज़नेस की (business key), समय सिमेंटिक्स (time semantics) और मौद्रिक सटीकता (monetary precision) को परिभाषित करें। केवल काउंट की जांच करने से ऑफसेटिंग त्रुटियां छिप सकती हैं।
व्याख्या योग्य चेक्स (Explainable checks)
काउंट, अमाउंट, स्टेटस वितरण, की (key) की विशिष्टता (uniqueness) और सैंपल किए गए विवरणों की जांच करें। नियम का वर्ज़न और इनपुट स्नैपशॉट को सुरक्षित (persist) रखें ताकि प्रत्येक परिणाम को दोबारा रीप्रोड्यूस किया जा सके।
क्लोज्ड-लूप इंसिडेंट्स (Closed-loop incidents)
अंतरों को वर्गीकृत करें, एक ओनर नियुक्त करें, साक्ष्य सुरक्षित रखें, रीप्ले का समर्थन करें और समाधान (closure) दर्ज करें। बिना किसी ट्रैक करने योग्य केस वाला ईमेल कोई ऑपरेशनल लूप नहीं है।
सुरक्षित ऑपरेशन्स (Safe operations)
लेट डेटा, इडेम्पोटेंट री-रन, पार्टिशन्स, स्कीमा परिवर्तन, फ्रेशनेस और ऑडिट इतिहास को इस तरह संभालें कि सुधार से नई विसंगतियां पैदा न हों।
पूछने योग्य स्पष्टीकरण प्रश्न
- "कल" के लिए कौन सा टाइमज़ोन और इवेंट-टाइम परिभाषा का उपयोग किया जाता है?
- ऑर्डर बिज़नेस की क्या है, और रिफ़ंड तथा कैंसलेशन की गणना कैसे की जाती है?
- क्या सोर्स देर से अपडेट या डिलीट भेज सकता है?
- क्या वेयरहाउस बैच, स्ट्रीमिंग या हाइब्रिड है?
- कौन सी करेंसी और दशमलव सटीकता लागू होती है?
- क्या समाधान स्वचालित होना चाहिए, रीप्ले किया जाना चाहिए या पहले मैन्युअल रूप से स्वीकृत होना चाहिए?
30-सेकंड का उत्तर ढांचा
"मैं एक टाइम विंडो और स्नैपशॉट को फ़्रीज़ करूंगा, ऑर्डर की के आधार पर काउंट, अमाउंट और स्टेटस का मिलान करूंगा, और फिर मिसिंग, डुप्लिकेट, अभी तक न पहुंचे और ट्रांसफ़ॉर्मेशन त्रुटियों की गहराई से जांच करूंगा। प्रत्येक विसंगति एक नियम वर्ज़न, सोर्स सारांश, वेयरहाउस सारांश और ओनर को स्टोर करती है। वॉटरमार्क और एक रीट्राई विंडो देर से आए डेटा को वास्तविक डेटा हानि से अलग करती है। एक इडेम्पोटेंट बैकफ़िल या रीप्ले स्वीकृत मामलों को ठीक करता है, फिर उसी स्नैपशॉट का दोबारा मिलान किया जाता है। इनपुट, आउटपुट, अलर्ट और मानवीय कार्रवाइयां एक ऑडिट टेबल में दर्ज की जाती हैं।"
चरण-दर-चरण गहन विश्लेषण
चरण 1: स्कोप और स्नैपशॉट को फ़्रीज़ करें
सोर्स बैच, इवेंट-टाइम रेंज, प्रोसेसिंग टाइम, टाइमज़ोन और स्नैपशॉट आईडी (snapshot ID) रिकॉर्ड करें। सोर्स में बदलाव के दौरान परिणामों में विचलन (drift) होने के बजाय उन्हें एक ही इनपुट सेट को इंगित करना चाहिए।
चरण 2: कीज़ को सामान्यीकृत (normalize) करें
ऑर्डर आईडी, मर्चेंट आईडी, स्टेटस मैपिंग, करेंसी और अमाउंट सटीकता को सामान्यीकृत करें। प्रत्येक पक्ष का हैश या सारांश बनाए रखें; निदान के लिए केवल आवश्यक न्यूनतम संवेदनशील डेटा ही रखें।
चरण 3: स्तरित (layered) जांच चलाएं
पहले काउंट और कुल अमाउंट की तुलना करें, फिर मर्चेंट, तारीख और स्टेटस के आधार पर समूहित (group) करें। इसके बाद की विशिष्टता, नल (null), डुप्लिकेट, टॉलरेंस और विस्तृत एंटी-जॉइन (anti-join) जांच करें। कुल योग समान होने का अर्थ यह नहीं है कि विवरण भी समान हैं।
चरण 4: देरी (lateness) को संशोधन से अलग करें
अभी तक न पहुंचे डेटा को छूटे हुए डेटा से अलग करने के लिए इवेंट टाइम और वॉटरमार्क का उपयोग करें। बैकफ़िल विंडो के भीतर रिकॉर्ड्स को पेंडिंग रखें; इसके बंद होने के बाद ही इसे एस्केलेट करें। वर्ज़न या परिवर्तन समय का उपयोग करके अपडेट, रिफ़ंड और डिलीट की पुनर्गणना करें।
चरण 5: वर्गीकृत और सुधार करें
अमाउंट, ऑर्डर काउंट, बिज़नेस प्रभाव और अवधि के आधार पर मामलों को रैंक करें। स्वचालित सुधार केवल इडेम्पोटेंट बैकफ़िल या रीप्ले तक सीमित है। वित्तीय-परिभाषा परिवर्तनों के लिए अनुमोदन और पहले/बाद के साक्ष्य की आवश्यकता होती है।
चरण 6: री-रन और ऑडिट
स्नैपशॉट आईडी, पार्टिशन और नियम वर्ज़न के आधार पर इडेम्पोटेंट तरीके से चलाएं। समीक्षा के लिए इनपुट स्कोप, क्वेरी वर्ज़न, मेट्रिक्स, विवरण अंतर, अलर्ट, ओनर, रीट्राई और क्लोज़र समय स्टोर करें।
मॉडल उच्च-गुणवत्ता वाला उत्तर
"मैं प्रत्येक सोर्स बैच के लिए एक snapshot_id जनरेट करूंगा और एक UTC इवेंट-टाइम विंडो फ़्रीज़ करूंगा। एक सामान्यीकरण लेयर ऑर्डर आईडी, स्टेटस, करेंसी और अमाउंट सटीकता को संरेखित करती है। हम काउंट, अमाउंट और स्टेटस वितरण की तुलना करते हैं, फिर सोर्स-ओनली, वेयरहाउस-ओनली, डुप्लिकेट और अमाउंट-मिसमैच रिकॉर्ड खोजने के लिए प्राइमरी-की एंटी-जॉइन का उपयोग करते हैं।
एक वॉटरमार्क और दो घंटे की बैकफ़िल विंडो लेट इवेंट्स को पेंडिंग के रूप में वर्गीकृत करती है; विंडो के बाद केवल अनसुलझे अंतर ही एस्केलेट होते हैं। डिफरेंस टेबल नियम वर्ज़न, दोनों रिकॉर्ड सारांश, अमाउंट डेल्टा, ओनर और साक्ष्य को स्टोर करती है। एक स्वीकृत रीप्ले snapshot_id और बिज़नेस की पर इडेम्पोटेंट होता है। सुधार के बाद मैं उसी स्नैपशॉट को दोबारा चलाता हूं और इनपुट रेंज, कोड वर्ज़न, अलर्ट और क्लोज़र समय को ऑडिट टेबल में लिखता हूं।"
सामान्य गलतियां
- केवल कुल काउंट की तुलना करना → ऑफसेटिंग त्रुटियां छिपी रहती हैं → बिज़नेस-की एंटी-जॉइन का उपयोग करें और विवरण के अंतरों को बनाए रखें।
- प्रोसेसिंग टाइम को इवेंट टाइम के रूप में उपयोग करना → लेट या क्रॉस-टाइमज़ोन रिकॉर्ड्स विंडो को बदल देते हैं → इवेंट टाइम, प्रोसेसिंग टाइम और टाइमज़ोन को अलग से परिभाषित करें।
- रिफ़ंड, कैंसल, अपडेट और डिलीट सिमेंटिक्स को छोड़ देना → प्रत्येक लेयर एक अलग संख्या की व्याख्या करती है → स्टेटस मैपिंग और ट्रीटमेंट नियमों का वर्ज़न बनाएं।
- फ़्लोटिंग-पॉइंट मुद्रा की तुलना → दशमलव का मामूली अंतर एक गलत इंसिडेंट बन जाता है → पूर्णांक माइनर यूनिट्स, करेंसी और स्पष्ट टॉलरेंस का उपयोग करें।
- प्रत्येक लेट रिकॉर्ड पर तुरंत अलर्ट जारी करना → अत्यधिक अलर्ट गलत सुधारों को ट्रिगर करते हैं → वॉटरमार्क और पेंडिंग स्थिति वाली बैकफ़िल विंडो का उपयोग करें।
- नॉन-इडेम्पोटेंट सुधार → री-रन डुप्लिकेट पंक्तियां बनाते हैं → स्नैपशॉट और बिज़नेस की द्वारा इडेम्पोटेंट तरीके से अपसर्ट (upsert) करें।
- कोई ओनर, साक्ष्य या क्लोज़र स्थिति न होना → इंसिडेंट्स को असाइन या रिव्यू नहीं किया जा सकता → एक केस और ऑडिट रिकॉर्ड जोड़ें।
- केवल अंतिम संख्याएं बनाए रखना → परिणाम को दोबारा रीप्रोड्यूस नहीं किया जा सकता → इनपुट स्नैपशॉट, नियम वर्ज़न और कोड वर्ज़न स्टोर करें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: क्या होगा यदि योग मेल खाते हैं लेकिन रिकॉर्ड भिन्न हैं?
ऑफसेटिंग जोड़ और हटाव को खोजने के लिए बिज़नेस-की एंटी-जॉइन, डुप्लिकेट-की जांच और समूहीकृत वितरण का उपयोग करें। समीक्षा के लिए विवरण के अंतरों को सुरक्षित रखें।
फॉलो-अप 2: आप लेट-डेटा के गलत अलर्ट से कैसे बचते हैं?
इवेंट टाइम, एक वॉटरमार्क और एक स्पष्ट बैकफ़िल विंडो का उपयोग करें। विंडो के भीतर मामलों को पेंडिंग के रूप में चिह्नित करें और इसके बाद अनसुलझे मामलों को एस्केलेट करें, साथ ही विंडो वर्ज़न को रिकॉर्ड करें।
फॉलो-अप 3: सुधार को सुरक्षित रूप से कैसे री-रन किया जा सकता है?
स्नैपशॉट आईडी, पार्टिशन और बिज़नेस की को इडेम्पोटेन्सी कीज़ के रूप में उपयोग करें; राइट्स (writes) को अपसर्ट या डीडुप्लिकेट करें; प्रत्येक रीट्राई से पहले और बाद में काउंट और अमाउंट की तुलना करें।
फॉलो-अप 4: आप रिकॉन्सिलिएशन नियमों का परीक्षण कैसे करते हैं?
मिसिंग, डुप्लिकेट, लेट, रिफ़ंड और करेंसी मामलों के लिए फ़िक्सचर्स बनाएं। नियम वर्ज़न, टॉलरेंस, बाउंड्री डेट्स और टाइमज़ोन का परीक्षण करें, फिर फ़ाल्स-पॉज़िटिव दरों की निगरानी करें।
फॉलो-अप 5: आप अलर्ट और ओनरशिप को कैसे रूट करते हैं?
अमाउंट, काउंट, अवधि और व्यावसायिक गंभीरता के आधार पर रूट करें। प्रत्येक अलर्ट को एक बैच, साक्ष्य और सुधार कार्रवाई से लिंक करें; क्लोज़र के लिए एक कारण की आवश्यकता होती है और यह ऑडिट योग्य रहता है।
स्रोत 1: dbt सोर्स और सोर्स टेस्ट
dbt Developer Hub सोर्स दस्तावेज़ सोर्सेस घोषित करने, वंशावली (lineage) बनाने, डेटा परीक्षण संलग्न करने और फ्रेशनेस को मापने का वर्णन करता है—जो रिकॉन्सिलिएशन इनपुट्स के लिए उपयोगी गवर्नेंस पैटर्न हैं।
स्रोत 2: फ्रेशनेस और SLA विंडोज़
dbt Developer Hub source-freshness गाइड फ्रेशनेस प्रबंधन के लिए loaded-at फ़ील्ड, चेतावनी/त्रुटि थ्रेशोल्ड और स्नैपशॉट परिणाम दिखाता है, जो लेट-डेटा विंडो और एस्केलेशन को सूचित करता है।
स्रोत 3: डेटा-क्वालिटी चेक्स
dbt Labs की डेटा-क्वालिटी गाइड विशिष्टता (uniqueness), संबंधों, नल चेक्स और फ्रेशनेस को कवर करती है, जो यह दर्शाती है कि स्वचालित चेक्स को वर्ज़न किए गए मॉडल और अलर्ट से कैसे जोड़ा जाना चाहिए।