डेटा इंजीनियरिंग इंटरव्यू: आप बड़े पैमाने पर ऐतिहासिक डेटा को सुरक्षित रूप से बैकफ़िल कैसे करते हैं?

प्रॉम्प्ट और लागू संदर्भ

एक ऑर्डर डेटा पाइपलाइन प्रत्येक दिन ऑब्जेक्ट स्टोरेज से 2 TB इम्यूटिएबल रॉ डेटा पढ़ती है और business_date द्वारा पार्टिशन की गई एक orders_daily टेबल तैयार करती है। टीम को एक टैक्स ट्रांसफ़ॉर्मेशन डिफ़ेक्ट मिलता है जो 90 पार्टिशन्स को प्रभावित करता है। इसलिए इसे 5 दिनों के भीतर 180 TB को फिर से प्रोसेस करना होगा। दैनिक इंक्रीमेंटल पाइपलाइन बंद नहीं हो सकती; इसकी P95 फ्रेशनेस 45 मिनट या उससे कम रहनी चाहिए। देर से आने वाले रिफ़ंड और ऑर्डर सुधार भी उन्हीं बिजनेस कीज को अपडेट कर सकते हैं जिन्हें बैकफ़िल किया जा रहा है।

एक ऐसा बैकफ़िल डिज़ाइन करें जो दोहराने योग्य (repeatable) हो, रुकने के बाद पुनः आरंभ करने योग्य (resumable) हो, ऑडिट करने योग्य (auditable) हो और प्रतिवर्ती (reversible) हो। बताएं कि इनपुट और कोड वर्जन्स को कैसे पिन किया जाए, पार्टिशन्स को कैसे विभाजित और शेड्यूल किया जाए, ऐतिहासिक काम को प्रोडक्शन क्षमता लेने से कैसे रोका जाए, बैकफ़िल और लाइव इंक्रीमेंट्स के बीच ओवरलैप को कैसे हल किया जाए, पब्लिकेशन-ब्लॉकिंग वैलिडेशन को कैसे परिभाषित किया जाए, और विफलता के बाद अंतिम विश्वसनीय वर्जन को कैसे पुनर्स्थापित किया जाए।

हाल ही में सार्वजनिक डेटा इंजीनियरिंग इंटरव्यू सामग्री स्पष्ट रूप से ऐतिहासिक बैकफ़िल्स, आइडम्पोटेंट री-रन्स (idempotent reruns) और रीयल-टाइम प्रोसेसिंग को बनाए रखने को पाइपलाइन रिलायबिलिटी प्रश्नों के रूप में मानती है। सार्वजनिक परिदृश्य उम्मीदवारों से टेराबाइट-स्केल इनपुट, पार्टिशन रीप्रोसेसिंग, वैलिडेशन और रोलबैक को संभालने के लिए भी कहते हैं। आधिकारिक पाइपलाइन दस्तावेज़ीकरण ऐतिहासिक रन, रीप्रोसेसिंग नीतियां और अलग समवर्ती सीमाएं (concurrency limits) प्रदर्शित करते हैं। खोज का उद्देश्य विशिष्ट है: एक उम्मीदवार को एक निष्पादन योग्य प्रोडक्शन योजना की आवश्यकता होती है जो Airflow में “पिछले 90 दिनों को फिर से चलाएं” के शेड्यूलिंग प्रवेश बिंदु से कहीं आगे जाती है।

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

पहला संकेत यह है कि क्या उम्मीदवार एक पुनरुत्पादनीय (reproducible) डेटा वर्जन को परिभाषित करता है। एक मजबूत उत्तर बैकफ़िल अंतराल, लॉजिकल डेट, सोर्स स्नैपशॉट या सोर्स वर्जन, ट्रांसफ़ॉर्मेशन कोड, निर्भर डाइमेंशन वर्जन्स और टारगेट स्कीमा को पिन करता है। यदि दो प्रयास अलग-अलग इनपुट पढ़ते हैं, या यदि कोड now(), रैंडम वैल्यूज, या म्यूटेबल बाहरी लुकअप पर निर्भर करता है, तो “दोबारा चलाने के लिए सुरक्षित” का कोई परीक्षण योग्य अर्थ नहीं है।

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

तीसरा संकेत क्षमता और आइसोलेशन है। 5 दिनों में 180 TB को पूरा करने के लिए, न्यूनतम औसत रॉ रीड दर है:

180 TB / (5 × 24 h) = 1.5 TB/h ≈ 417 MB/s

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

चौथा संकेत पब्लिकेशन और रिकवरी की सीमा है। नब्बे सफल कार्य एक नए वर्जन को उपभोक्ताओं के लिए सुरक्षित नहीं बनाते हैं। पब्लिकेशन से पहले, सिस्टम को पार्टिशन की पूर्णता, की विशिष्टता (key uniqueness), बिजनेस इनवेरिएंट्स, सोर्स समाधान (reconciliation), और डिफ़ेक्ट के अनुरूप अंतर साबित करने होंगे। पब्लिकेशन एक नियंत्रित वर्जन कटओवर होना चाहिए। अवलोकन अवधि (observation period) के दौरान पुराने वर्जन को बनाए रखें ताकि रोलबैक का अर्थ केवल एक पॉइंटर बदलना हो, न कि 180 TB की फिर से गणना करना।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• क्या रॉ इनपुट वास्तव में इम्यूटिएबल है? ऑब्जेक्ट वर्जन्स, एक स्नैपशॉट ID, या एक रीप्ले करने योग्य लॉग स्थिति प्राप्त करें। यदि सोर्स डेटा को इन-प्लेस म्यूटेट करता है, तो पहले एक संदर्भ योग्य (referencable) इनपुट वर्जन बनाएं।
• कौन सी घड़ी 90-दिवसीय अंतराल को परिभाषित करती है? business_date, इवेंट टाइम, इनजेशन टाइम और टाइम ज़ोन को संरेखित करें। यह भी परिभाषित करें कि देर से आए रिफ़ंड का स्वामी कौन सा पार्टिशन है।
• टारगेट ग्रेन और स्थिर की (stable key) क्या हैं? स्थापित करें कि क्या कोई पंक्ति एक ऑर्डर, ऑर्डर आइटम, या दैनिक योग (aggregate) है और क्या order_id, source_version, और एक डिटर्मिनिस्टिक कॉन्फ़्लिक्ट क्रम मौजूद है।
• ट्रांसफ़ॉर्मेशन किस म्यूटेबल डेटा पर निर्भर करता है? विनिमय दरें, टैक्स नियम, SCD डाइमेंशन्स, और डिलीशन रिकॉर्ड्स को ऐतिहासिक घटना समय के अनुसार पढ़ा जाना चाहिए, न कि आज के मूल्यों के साथ चुपचाप बदल दिया जाना चाहिए।
• लाइव इंक्रीमेंट किन पार्टिशन्स को अपडेट कर सकता है? यदि यह केवल सबसे हाल के 7 दिनों में लिखता है, तो बैकफ़िल पुराने पार्टिशन्स का स्वामित्व ले सकता है। यदि कोई ऐतिहासिक ऑर्डर बदल सकता है, तो वर्जन ऑर्डरिंग या डेल्टा कैच-अप आवश्यक है।
• कौन से आइसोलेशन और एटॉमिक पब्लिकेशन फीचर्स मौजूद हैं? एक अलग वेयरहाउस, रिसोर्स पूल, प्राथमिकता कतार, पार्टिशन ट्रांजेक्शन, टेबल क्लोन, व्यू कटओवर, या कैटलॉग पॉइंटर डिज़ाइन को बदल देता है।
• क्या 5 दिन एक सख्त समय सीमा है या एक लक्ष्य? लाइव P95 फ्रेशनेस लक्ष्य, सोर्स रीड कोटा, लागत सीमा और किसी भी अनुमत छोटे कटओवर विंडो को प्राप्त करें।
• कौन साइन ऑफ़ करता है? तकनीकी दावे (assertions), वित्तीय समाधान (financial reconciliation), डाउनस्ट्रीम सैंपलिंग, और अवलोकन अवधि में से प्रत्येक के लिए एक मालिक और ब्लॉकिंग सीमा की आवश्यकता होती है।

30-सेकंड का उत्तर फ़्रेमवर्क

“मैं 90 बिजनेस डेट्स, इनपुट स्नैपशॉट और कोड वर्जन को पिन करूँगा, फिर प्रत्येक लॉजिकल-डेट पार्टिशन को एक मैनिफ़ेस्ट के साथ आइसोलेटेड स्टेजिंग में लिखूँगा। 5 दिनों में 180 TB को प्रोसेस करने के लिए कम से कम लगभग 417 MB/s की आवश्यकता होती है, इसलिए मैं पहले बेंचमार्क करूँगा और लाइव P95 के 45 मिनट के करीब पहुँचने पर थ्रॉटल करूँगा। W0 को बैकफ़िल करने के बाद, मैं W1 के माध्यम से कैच-अप करूँगा और 90/90 पार्टिशन्स, समाधान (reconciliation), और बिजनेस चेक पास होने के बाद ही कटओवर करूँगा। पुराना वर्जन रोलबैक के लिए उपलब्ध रहेगा।”

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

चरण 1: बैकफ़िल को एक इम्यूटिएबल रन विनिर्देश के रूप में परिभाषित करें

एक backfill_id बनाएं और निम्नलिखित रिकॉर्ड करें:

प्रत्येक पार्टिशन रन में business_date पास करें। ट्रांसफ़ॉर्मेशन के अंदर लॉजिकल समय के स्थान पर वॉल-क्लॉक समय का उपयोग न करें। जब ऐतिहासिक विनिमय दरें या SCD डाइमेंशन्स निर्भरताएं हों, तो घटना समय (event time) पर एक as-of जॉइन निष्पादित करें। इनपुट, कोड या किसी भी निर्भरता वर्जन में बदलाव एक नया backfill_id बनाता है; एक रन के अंदर दो परिणाम वर्जन्स को न मिलाएं।

प्रोडक्शन टारगेट को लिखे बिना एक योजना तैयार करें। सभी 90 पार्टिशन्स, निर्भरता क्रम, अनुमानित इनपुट बाइट्स, प्रस्तावित कन्करेंसी और गंतव्य पाथ्स की सूची बनाएं। अंतराल (gaps), डुप्लिकेट तिथियां, सोर्स रिटेंशन से बाहर के पार्टिशन्स और डाउनस्ट्रीम दुष्प्रभावों का पता लगाएं। गैर-डेटा प्रभावों जैसे ईमेल, बिलिंग और बाहरी API कॉल्स को अक्षम करें या उन्हें ऑडिट मोड पर रीडायरेक्ट करें, ताकि ऐतिहासिक रीप्ले वास्तविक व्यावसायिक कार्यों को फिर से ट्रिगर न कर सके।

चरण 2: पॉज़, रिज़्यूमे और ऑडिट के लिए पार्टिशन मैनिफ़ेस्ट का उपयोग करें

प्रत्येक business_date को एक सीमित कार्य इकाई (bounded work unit) के रूप में मानें। मैनिफ़ेस्ट में कम से कम निम्नलिखित रिकॉर्ड होना चाहिए:

backfill_id, business_date, input_snapshot, code_sha,
state, attempt, input_rows, output_rows, output_checksum,
staging_location, published_version, started_at, completed_at

एक उपयोगी स्थिति मॉडल PENDING → RUNNING → VALIDATED → PUBLISHED है, जिसमें विफलताएं FAILED में जाती हैं। एक सशर्त अपडेट (conditional update) या लीज के माध्यम से एक इकाई का दावा करें ताकि किसी पार्टिशन का केवल एक ही सक्रिय स्वामी हो। समाप्त हो चुकी लीज को पुनः प्राप्त किया जा सकता है। केवल विफल पार्टिशन का पुन: प्रयास करें और उस पार्टिशन के लिए एक अन्य आइसोलेटेड स्टेजिंग प्रयास लिखें; अंतिम टेबल में कभी भी आंख मूंदकर न जोड़ें (append)।

यदि एक तिथि पार्टिशन पूरी तरह से बंद है, तो सबसे सरल आइडम्पोटेंट राइट पूरे पार्टिशन का निर्माण करना और फिर उस पार्टिशन को ट्रांजेक्शनल रूप से बदलना है। यदि किसी ऑर्डर को विभिन्न तिथियों में सुधारा जा सकता है, तो MERGE में एक स्थिर बिजनेस की और सोर्स वर्जन का उपयोग करें। एक स्पष्ट विजेता को परिभाषित करें, जैसे कि source_updated_at और उसके बाद टाई होने पर मोनोटोनिक source_sequence। एक MERGE एक पुराने ऐतिहासिक रिकॉर्ड को एक नए सुधार को बदलने से केवल तभी रोकता है जब प्राइमरी की, वर्जन और डिलीशन सेमेंटिक्स सभी विश्वसनीय हों।

चरण 3: थ्रेड काउंट का अनुमान लगाने के बजाय मापों से कन्करेंसी प्राप्त करें

180 TB/5-दिन की आवश्यकता लगभग 417 MB/s की रॉ-रीड निचली सीमा देती है। 1 प्रतिनिधि पार्टिशन पर एक कैनरी चलाएं और पढ़ने, डीकंप्रेशन, शफ़ल, ट्रांसफ़ॉर्मेशन, राइटिंग और वैलिडेशन के लिए बाइट्स, अवधि, CPU, मेमोरी, वेयरहाउस कतार समय और अस्थायी स्थान को मापें। यदि एक पार्टिशन प्रभावी थ्रूपुट का r MB/s प्रदान करता है, तो सैद्धांतिक कन्करेंसी निचली सीमा लगभग ceil(417/r) है। सोर्स कोटा, शफ़ल पीक, टारगेट कमिट क्षमता और लागत सीमाएं वास्तविक मूल्य को और अधिक सीमित करती हैं।

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

कैनरी पास होने के बाद, बैचों में स्केल करें: उदाहरण के लिए, पहले 1 पार्टिशन, फिर 3, फिर मापी गई सुरक्षित कन्करेंसी। प्रत्येक स्तर पर एक पूर्ण लाइव इंक्रीमेंटल चक्र का निरीक्षण करें। यदि क्षमता समय सीमा को पूरा नहीं कर सकती है, तो समय सीमा, अस्थायी क्षमता, या दायरे को जल्दी बदलें। लाइव फ्रेशनेस का त्याग करके अनुमान संबंधी त्रुटि को न छिपाएं।

चरण 4: ऐतिहासिक और लाइव पाइपलाइनों के बीच राइट ओनरशिप को परिभाषित करें

पहले सोर्स स्नैपशॉट या लॉग वॉटरमार्क W0 से ऐतिहासिक अंतराल को एक नए वर्जन में पुनर्गणना करें। यदि लाइव पाइपलाइन केवल सबसे हाल के 7 दिनों को ठीक करती है, तो बैकफ़िल को विशेष रूप से पुराने 83 दिनों का स्वामित्व लेने दें। नवीनतम 7 को लाइव स्वामित्व के तहत रखें, फिर अंत में उस ओवरलैप विंडो को नए वर्जन में पुनर्गणना करें या मर्ज करें।

यदि लाइव सुधार किसी भी ऐतिहासिक ऑर्डर को छू सकते हैं, तो स्नैपशॉट-प्लस-डेल्टा-कैच-अप फ़्लो का उपयोग करें:

1. W0 रिकॉर्ड करें; बैकफ़िल केवल W0 से पहले के डिटर्मिनिस्टिक इनपुट को पढ़ता है।
2. लाइव पाइपलाइन पुराने वर्जन की सेवा जारी रखती है, जबकि W0 के बाद के परिवर्तन एक रीप्ले करने योग्य लॉग में रहते हैं।
3. सभी 90 ऐतिहासिक पार्टिशन्स के मान्य होने के बाद, W1 रिकॉर्ड करें और उसी वर्जन नियम के साथ नए वर्जन में (W0, W1] में परिवर्तन लागू करें।
4. एक बार जब लैग कटओवर बजट के भीतर आ जाए, तो पब्लिकेशन पॉइंटर को संक्षेप में फ्रीज करें या एक राइट फेंस (write fence) प्राप्त करें और अंतिम डेल्टा लागू करें।
5. उपभोक्ताओं को एटॉमिक रूप से नए वर्जन पर ले जाएं, फिर इसे लाइव पाइपलाइन का राइट टारगेट बनाएं।

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

चरण 5: स्तरों में मान्य करें और पब्लिकेशन से पहले कड़े गेट्स लगाएं

प्रत्येक स्टेजिंग पार्टिशन पूरा होने के बाद चेक की तीन परतें चलाएं:

• संरचना और पूर्णता: संगत स्कीमा, आवश्यक फ़ील्ड्स मौजूद हैं, विशिष्ट बिजनेस कीज, सही तिथि सीमाएं, और 90 में से कोई भी पार्टिशन गायब या डुप्लिकेट नहीं है।
• सोर्स समाधान (Source reconciliation): इनपुट और आउटपुट पंक्ति गणना, विशिष्ट ऑर्डर, कर-पूर्व राशि, कर, और तिथि, क्षेत्र, मुद्रा और राज्य द्वारा शुद्ध राशि की तुलना करें। योग (aggregates) के लिए, रिकॉर्ड-स्तरीय अंतर बनाए रखें जिसकी जांच की जा सकती है।
• व्यावसायिक नियम और अंतर: राशि संरक्षण, रिफ़ंडेबल राशि के भीतर रिफ़ंड, और वैध स्थिति संक्रमण। नए-बनाम-पुराने अंतर उन ऑर्डर्स पर केंद्रित होने चाहिए जो डिफ़ेक्ट से प्रभावित हुए थे; अप्रभावित स्लाइस बिना किसी स्पष्टीकरण के नहीं बदलने चाहिए।

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

वैश्विक पब्लिकेशन गेट के लिए कम से कम आवश्यकता होनी चाहिए: मैनिफ़ेस्ट में 90/90 VALIDATED; कोई सक्रिय या विफल पार्टिशन नहीं; सुसंगत इनपुट स्नैपशॉट, कोड और निर्भरता वर्जन्स; W1 के माध्यम से कैच-अप; सभी कड़े दावों (hard assertions) का पास होना; बैकफ़िल के दौरान दैनिक पाइपलाइन द्वारा 45 मिनट की P95 फ्रेशनेस बनाए रखना; और मालिक की मंजूरी। कोई भी विफलता पुराने वर्जन को दृश्यमान बनाए रखती है।

चरण 6: एक बार कटओवर करें, लगातार निरीक्षण करें और जल्दी से रोल बैक करें

पब्लिकेशन से पहले पुराना रीड पॉइंटर और आउटपुट वर्जन सहेजें। कटओवर केवल एक स्थिर दृश्य (stable view) या कैटलॉग पॉइंटर को बदलता है; यह कटओवर के दौरान 180 TB को स्थानांतरित नहीं करता है। तुरंत महत्वपूर्ण डैशबोर्ड और डाउनस्ट्रीम जॉब्स के खिलाफ एक उपभोक्ता-क्वेरी सुइट चलाएं, और क्वेरी लेटेंसी और सबसे हालिया इंक्रीमेंटल राइट की जांच करें। अवलोकन अवधि के दौरान पुराने और नए वर्जन्स के बीच महत्वपूर्ण मैट्रिक्स की तुलना करना जारी रखें।

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

मॉनिटरिंग व्यू को प्रोसेस किए गए और शेष TB, स्थिति के अनुसार पार्टिशन गणना, थ्रूपुट, अनुमानित पूर्णता समय, पुन: प्रयास और वैलिडेशन विफलताएं, सोर्स थ्रॉटलिंग, कंप्यूट-पूल कतार, टारगेट कमिट लेटेंसी और लाइव-पाइपलाइन P50/P95 फ्रेशनेस दिखाना चाहिए। अलर्ट में backfill_id, पार्टिशन, कोड वर्जन, विफल गेट और मालिक शामिल होना चाहिए ताकि एक ऑपरेटर यह तय कर सके कि कन्करेंसी को कम करना है, पार्टिशन का पुन: प्रयास करना है, या पूरे पब्लिकेशन को रोकना है।

उच्च गुणवत्ता वाला नमूना उत्तर

“मैं पहले इस बैकफ़िल को एक वर्जन्ड रन के रूप में फ्रीज करूँगा: 90 business_date मान, रॉ स्नैपशॉट और वॉटरमार्क W0, कोड SHA, टैक्स-डाइमेंशन वर्जन, टारगेट-टेबल वर्जन और स्वीकृति सीमाएं। प्रत्येक दिन एक कार्य है जो आइसोलेटेड स्टेजिंग आउटपुट लिखता है। एक मैनिफ़ेस्ट PENDING/RUNNING/VALIDATED/PUBLISHED और प्रत्येक प्रयास को रिकॉर्ड करता है। ट्रांसफ़ॉर्मेशन केवल लॉजिकल समय का उपयोग करते हैं। बंद पार्टिशन्स पूरी तरह से निर्मित और बदले जाते हैं; जिन ऑर्डर्स में देर से सुधार प्राप्त हो सकते हैं वे MERGE में एक स्थिर प्राइमरी की और सोर्स वर्जन का उपयोग करते हैं, इसलिए एक पुराना वर्जन एक नए वर्जन को अधिलेखित (overwrite) नहीं कर सकता है।”

“5 दिनों में 180 TB को प्रोसेस करने के लिए, पुन: प्रयासों और वैलिडेशन से पहले, कम से कम लगभग 417 MB/s के औसत रॉ रीड्स की आवश्यकता होती है। मैं एक प्रतिनिधि पार्टिशन का बेंचमार्क करूँगा, एंड-टू-एंड थ्रूपुट और प्रत्येक चरण के पीक को मापूंगा, और फिर चरणों में कन्करेंसी बढ़ाऊंगा। बैकफ़िल को सोर्स रीड्स, टारगेट राइट्स और शेड्यूलर कन्करेंसी पर सीमाओं के साथ एक आइसोलेटेड कम प्राथमिकता वाला रिसोर्स पूल मिलता है। कंट्रोलर लाइव P95 फ्रेशनेस की सुरक्षा करता है: जैसे ही लैग 45 मिनट के करीब पहुंचता है, यह नए पार्टिशन्स का दावा करना बंद कर देता है और रिकवरी के बाद धीरे-धीरे वापस गति बढ़ाता है।”

“समवर्ती शुद्धता (concurrent correctness) के लिए, मैं स्नैपशॉट W0 से नया वर्जन बनाता हूँ जबकि लाइव पाइपलाइन पुराने वर्जन की सेवा जारी रखती है। ऐतिहासिक पार्टिशन्स समाप्त होने के बाद, मैं W1 रिकॉर्ड करता हूँ, (W0, W1] सुधारों को नए वर्जन में रीप्ले करता हूँ, फिर अंतिम कैच-अप के लिए एक छोटे फेंस का उपयोग करता हूँ और एटॉमिक रूप से पॉइंटर को स्थानांतरित करता हूँ। पब्लिकेशन के लिए 90/90 पार्टिशन्स, अद्वितीय कीज, सोर्स राशि समाधान, व्यावसायिक इनवेरिएंट्स, स्पष्टीकरण योग्य पुराने/नए अंतर और स्वस्थ प्रोडक्शन फ्रेशनेस की आवश्यकता होती है। मैं अवलोकन के दौरान पुराने वर्जन को बनाए रखता हूँ। एक विफल हार्ड गेट या उपभोक्ता क्वेरी पॉइंटर को वापस ले जाती है और जांच के लिए विफल वर्जन को सुरक्षित रखती है।”

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

• शेड्यूलर कन्करेंसी को अधिकतम पर सेट करना → सोर्स, शफ़ल, टारगेट कमिट, या दैनिक जॉब्स वास्तविक बाधा (bottleneck) बन जाते हैं → एक-पार्टिशन बेंचमार्क, थ्रूपुट निचली सीमा और प्रोडक्शन SLO से कन्करेंसी प्राप्त करें, फिर गतिशील रूप से थ्रॉटल करें।
• टास्क पुन: प्रयास को आइडम्पोटेंसी मानना → ऑर्केस्ट्रेटर केवल कार्य को फिर से निष्पादित करता है; ब्लाइंड अपेंड अभी भी डेटा की नकल (duplicate) करते हैं → डिटर्मिनिस्टिक इनपुट और लॉजिकल समय का उपयोग करें, फिर एक पार्टिशन को बदलें या स्थिर की और वर्जन द्वारा मर्ज करें।
• ऐतिहासिक और लाइव जॉब्स को एक ही पार्टिशन लिखने देना → देर से समाप्त होने वाली पुरानी गणना एक नए सुधार को अधिलेखित कर सकती है → पार्टिशन स्वामित्व असाइन करें या W0/W1 डेल्टा कैच-अप और स्पष्ट वर्जन ऑर्डरिंग का उपयोग करें।
• 90 कार्यों के सफल होने के बाद प्रकाशित करना → सफलता की स्थितियां पूर्ण रिकॉर्ड, सही राशि, या समझदारी भरे अंतर को साबित नहीं करती हैं → पार्टिशन, सोर्स, बिजनेस, अंतर और उपभोक्ता जांच पर गेट लगाएं।
• वैलिडेशन से पहले ऑनलाइन टेबल को अधिलेखित करना → एक विफल वैलिडेशन रिकवरी पाथ के रूप में एक और बड़ी पुनर्गणना छोड़ता है → एक वर्जन्ड आउटपुट लिखें, इसे मान्य करें, एक बार कटओवर करें, और पुराना पॉइंटर बनाए रखें।
• केवल कुल पंक्ति गणना की तुलना करना → डुप्लिकेट और चूक एक दूसरे को रद्द कर सकते हैं → अद्वितीय कीज, बकेटेड चेकसम, राशि, स्थिति वितरण और रिकॉर्ड अंतर की भी तुलना करें।
• एक ऐतिहासिक ट्रांसफ़ॉर्मेशन में now() को कॉल करना → दो प्रयास अलग-अलग पार्टिशन सेमेंटिक्स उत्पन्न करते हैं → लॉजिकल डेट, इनपुट स्नैपशॉट और निर्भरता वर्जन्स को रन पैरामीटर के रूप में पास करें।
• विफलता के बाद सभी 180 TB को फिर से चलाना → यह लागत और जोखिम का विस्तार करता है और मान्य प्रगति को छोड़ देता है → पार्टिशन मैनिफ़ेस्ट से विफल इकाइयों को फिर से शुरू करें; केवल तभी प्रभावित पार्टिशन्स की पुनर्गणना करें जब कोई वर्जन बदलता है।

अनुवर्ती प्रश्न और उत्तर

अनुवर्ती 1: यदि सोर्स के पास कोई इम्यूटिएबल स्नैपशॉट नहीं है, तो बैकफ़िल कैसे दोहराने योग्य हो सकता है?

रन से पहले बनाए गए वर्जन्ड ऐतिहासिक निर्यात को प्राथमिकता दें, या डेटाबेस स्नैपशॉट स्थिति, CDC लॉग स्थिति और ऑब्जेक्ट वर्जन IDs रिकॉर्ड करें। यदि एकमात्र सोर्स एक म्यूटेबल टेबल है, तो मैनिफ़ेस्ट में रीड टाइम, वॉटरमार्क और प्रति-पार्टिशन चेकसम रिकॉर्ड करें और बाद में कैच-अप के लिए रन के दौरान परिवर्तनों को लगातार कैप्चर करें। जब मूल इनपुट का पुनर्निर्माण नहीं किया जा सकता है, तो पुनरुत्पादकता अंतर (reproducibility gap) का खुलासा करें; यह दावा न करें कि दो प्रयास समान होने चाहिए।

अनुवर्ती 2: एक सही किया गया SCD डाइमेंशन फैक्ट टेबल को फीड करता है। पहले किसको बैकफ़िल किया जाना चाहिए?

प्रभावित वंशावली सबग्राफ (lineage subgraph) बनाएं और इसे टोपोलॉजिकल क्रम में प्रोसेस करें। पहले नया डाइमेंशन वर्जन बनाएं, फिर घटना समय के अनुसार फैक्ट टेबल को उस वर्जन से जोड़ें, और अंत में एग्रीगेट्स और मार्ट्स का पुनर्निर्माण करें। प्रत्येक परत एक बैकफ़िल वर्जन पहचानकर्ता साझा करती है; एक नई फैक्ट टेबल के साथ एक पुराना डाइमेंशन प्रकाशित न करें। डाइमेंशन बिजनेस कीज, गैर-ओवरलैपिंग प्रभावी अंतराल, फैक्ट फॉरेन-की मैच दर और महत्वपूर्ण एग्रीगेट्स को मान्य करें।

अनुवर्ती 3: यदि प्लेटफ़ॉर्म में कोई एटॉमिक टेबल स्वैप नहीं है, तो आप कैसे प्रकाशित करते हैं?

एक स्वतंत्र वर्जन टेबल लिखने और उपभोक्ताओं को एक स्थिर दृश्य (stable view) के माध्यम से रूट करने को प्राथमिकता दें। यदि दृश्य परिभाषा को एटॉमिक रूप से बदला जा सकता है, तो केवल दृश्य को स्विच करें। यदि वह भी अनुपलब्ध है, तो पुराने-पार्टिशन बैकअप या एक स्पष्ट रखरखाव विंडो (maintenance window) के साथ ट्रांजेक्शनल छोटे-बैच प्रतिस्थापन का उपयोग करें जो कटओवर और स्वीकृति के लिए संबंधित रीड्स और राइट्स को रोकती है। दिखाई देने वाली मध्यवर्ती स्थितियों और रोलबैक समय का उल्लेख करें; बहु-चरणीय अधिलेखन (multi-step overwrite) को एटॉमिक न कहें।

अनुवर्ती 4: पुराने और नए वर्जन्स में समान पंक्ति गणना और कुल राशि है। और क्या जांचा जाना चाहिए?

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

अनुवर्ती 5: क्या रन सबसे पुरानी या सबसे नई तारीख से शुरू होना चाहिए?

यह निर्भरता और व्यावसायिक मूल्य पर निर्भर करता है। यदि बाद का पार्टिशन पहले वाले की स्थिति पर निर्भर करता है, तो आगे की ओर (forward) रन करें। यदि पार्टिशन स्वतंत्र हैं और हाल की रिपोर्टों में अधिक तात्कालिकता है, तो विपरीत क्रम मदद कर सकता है। दोनों ही मामलों में, पब्लिकेशन गेट अभी भी पूरे अंतराल को कवर करता है जब तक कि उत्पाद स्वामी स्पष्ट रूप से प्रत्येक चरण के लिए एक अलग वर्जन, उपभोक्ता दायरे और रोलबैक सीमा के साथ चरणबद्ध पब्लिकेशन को मंजूरी नहीं देता है।