प्रतिनिधि इंटरव्यू विषय

आप लेकहाउस के लिए एंड-टू-एंड डेटा इंटीग्रिटी चेक कैसे डिज़ाइन करेंगे?

डेटाकठिन
Offer.cc संपादकीय टीमप्रकाशित अपडेट किया गया

प्रश्न

एक ऐसा लेकहाउस इंटीग्रिटी प्लान डिज़ाइन करें जो ट्रंकेटेड अपलोड, स्टोरेज करप्शन, फ़ाइल रिप्लेसमेंट और डुप्लिकेट पाइपलाइन राइट्स का पता लगाए। चेक लेयर्स, एल्गोरिदम के चयन, मेटाडेटा, सैंपलिंग बनाम फुल स्कैन, अलर्ट्स और रिपेयर के बारे में बताएं।

1. प्रॉम्प्ट और संदर्भ

एक डेटा लेक हर दिन ऑब्जेक्ट-स्टोरेज फ़ाइलें प्राप्त करता है, उन्हें Parquet के रूप में लिखता है, और डैशबोर्ड तथा मॉडलों के लिए टेबल स्नैपशॉट कमिट करता है। टीम ट्रंकेटेड ट्रांसफर, बदले गए ऑब्जेक्ट्स, मेटाडेटा जो अब कंटेंट से मेल नहीं खाता, और पुनः प्रयासों (retries) के बाद डुप्लिकेट राइट्स को लेकर चिंतित है। ऐसे चेक डिज़ाइन करें जो केवल एक अंतिम पंक्ति गणना (row count) की तुलना करने के बजाय विफलता की सीमा (failure boundary) का पता लगाएं।

2. इंटरव्यूअर क्या परख रहा है

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

3. पहले स्पष्ट करने योग्य प्रश्न

  • क्या हम ट्रांसफर त्रुटियों को रोक रहे हैं, साइलेंट करप्शन का पता लगा रहे हैं, या कंप्लायंस साक्ष्य बना रहे हैं? प्रत्येक लक्ष्य एल्गोरिदम और रिटेंशन को बदल देता है।
  • क्या फ़ाइलें इम्यूटिएबल (immutable) हैं? यदि इन-प्लेस रिप्लेसमेंट की अनुमति है, तो ऑब्जेक्ट वर्शन या कंटेंट डाइजेस्ट को टेबल स्नैपशॉट का हिस्सा होना चाहिए।
  • कौन सा डिटेक्शन डिले और फॉल्स-पॉजिटिव रेट स्वीकार्य है? रियल-टाइम चेक और दैनिक फुल स्कैन के बजट अलग-अलग होते हैं।
  • क्या एकाधिक फॉर्मेट, स्टोर या क्रॉस-रीजन कॉपियां मौजूद हैं? प्रत्येक सीमा को एक नए सत्यापन की आवश्यकता होती है।

4. तीस सेकंड का उत्तर ढांचा

“मैं चार लेयर्स का उपयोग करूंगा: अपलोड के दौरान ऑब्जेक्ट चेकसम सत्यापित करना, रीड के दौरान Parquet पेज CRC सत्यापित करना, स्नैपशॉट कमिट करते समय फ़ाइल मैनिफ़ेस्ट और मेटाडेटा सत्यापित करना, और बिज़नेस लेयर पर पंक्ति गणना, पार्टीशन रेंज और महत्वपूर्ण मेट्रिक्स का मिलान (reconcile) करना। प्रत्येक चेक के लिए एल्गोरिदम, डाइजेस्ट, ऑब्जेक्ट वर्शन, जॉब ID और टाइमस्टैम्प स्टोर करें। विफल फ़ाइलों को क्वारंटाइन करें और उन्हें अपस्ट्रीम सोर्स या विश्वसनीय रेप्लिकेट से फिर से बनाएं। फुल स्कैन के साथ जोखिम-आधारित सैंपलिंग को मिलाएं, और डेटासेट तथा ब्लास्ट रेडियस द्वारा अलर्ट को श्रेणीबद्ध करें। अंत में, विफलताओं को केवल लॉग में छोड़ने के बजाय परिणामों को एक ऑडिट करने योग्य टेबल में लिखें।”

5. चरण-दर-चरण तर्क

पहला, ट्रांसफर को सुरक्षित करें। प्रोड्यूसर अपलोड करने से पहले एक डाइजेस्ट की गणना करता है और स्टोरेज सर्विस इसे मान्य करती है; बेमेल होने पर ऑब्जेक्ट अस्वीकार हो जाता है और रिट्री ट्रिगर होती है। Amazon S3 सिंगल-पार्ट और मल्टीपार्ट अपलोड के लिए चेकसम का समर्थन करता है और क्लाइंट्स को डाउनलोड के दौरान चेकसम का अनुरोध करने की अनुमति देता है। मल्टीपार्ट ETag को पूरे ऑब्जेक्ट के MD5 के रूप में नहीं माना जाना चाहिए।

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

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

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

पांचवां, पेट्रोलिंग और मरम्मत। रीड के समय हॉट डेटा को सत्यापित करें और जोखिम के अनुसार कोल्ड डेटा का सैंपल लें; उच्च-मूल्य या विनियमित (regulated) डेटासेट पर पूर्ण चेक चलाएं। Amazon S3 Batch Operations रेस्ट पर मौजूद ऑब्जेक्ट्स के बड़े सेट के लिए अतुल्यकालिक रूप से (asynchronously) पूर्ण-ऑब्जेक्ट या समग्र चेकसम रिपोर्ट तैयार कर सकता है। मूल डाइजेस्ट, डिटेक्शन समय और स्नैपशॉट संदर्भ के साथ विसंगतियों को क्वारंटाइन करें, एक विश्वसनीय रेप्लिकेट से फिर से बनाएं, और सत्यापन के बाद ही फिर से कमिट करें।

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

“मैं चेकसम को पूरी डेटा-गुणवत्ता योजना के रूप में नहीं मानूंगा। अपलोड लेयर एक ट्रांसपोर्ट डाइजेस्ट को सत्यापित करती है, Parquet रीडर पेज CRC को सक्षम करता है, स्नैपशॉट कमिट ऑब्जेक्ट वर्शन और राइटर ID के साथ एक इम्यूटिएबल मैनिफ़ेस्ट स्टोर करता है, और बिज़नेस लेयर महत्वपूर्ण पार्टीशन्स के लिए काउंट्स, कीज़ और राशियों का मिलान करती है। प्रत्येक चेक अपने एल्गोरिदम, डाइजेस्ट और समय को रिकॉर्ड करता है। एक रीड या पेट्रोल विफलता फ़ाइल को क्वारंटाइन करती है और एक नए स्नैपशॉट को इसे संदर्भित करने से रोकती है। मैं हॉट डेटा को समकालिक रूप से (synchronously) सत्यापित करूंगा, जोखिम-आधारित सैंपलिंग के साथ सामान्य डेटा को कवर करूंगा, और एक शेड्यूल पर विनियमित डेटा को पूरी तरह से स्कैन करूंगा। मरम्मत एक विश्वसनीय प्रतिकृति से पुनर्निर्माण करती है और मूल विफलता साक्ष्य को बनाए रखती है। ये लेयर्स ट्रांसफर, स्टोरेज, स्नैपशॉट और बिज़नेस-लॉजिक विफलताओं के बीच अंतर करती हैं, साथ ही उनकी लागत और अनदेखे क्षेत्रों को स्पष्ट करती हैं।”

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

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

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

क्या होगा यदि कोई हमलावर किसी फ़ाइल को बदल देता है और उसके डाइजेस्ट को भी अपडेट कर देता है?

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

आपके पास फुल स्कैन के लिए प्रतिदिन केवल एक घंटा है। आप इसे कैसे आवंटित करते हैं?

डेटा मूल्य, हाल के परिवर्तनों, ऐतिहासिक विफलताओं और प्रतिकृति पाथ द्वारा पार्टीशन्स को स्कोर करें। सबसे जोखिम भरे हिस्सों को पहले स्कैन करें, और बाकी को रीड-टाइम चेक, सैंपलिंग और रोलिंग विंडो के साथ कवर करें। पूरे लेक के सत्यापित होने का दावा करने के बजाय कवरेज और असत्यापित विंडो की रिपोर्ट करें।

आप रिपेयर जॉब को डेटा डुप्लिकेट करने से कैसे रोकते हैं?

मूल फ़ाइल ID, लक्ष्य स्नैपशॉट और एक इडेम्पोटेंट (idempotent) राइट कुंजी का उपयोग करें। कमिट करने से पहले, जांचें कि क्या मैनिफ़ेस्ट में पहले से ही वही कंटेंट डाइजेस्ट शामिल है, फिर स्नैपशॉट पॉइंटर को परमाणु रूप से (atomically) अपडेट करें। पुनः प्रयास केवल विफल फ़ाइलों का पुनर्निर्माण करते हैं और पहले से पुष्टि की गई फ़ाइलों को कभी नहीं जोड़ते हैं।

सार्वजनिक स्रोत

संबंधित प्रश्न