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

डेटा इंजीनियरिंग साक्षात्कार: आप Parquet Variant Shredding को कैसे डिज़ाइन करेंगे?

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

प्रश्न

एक डेटा लेक को JSON इवेंट प्राप्त होते हैं जिनका आकार (shape) बार-बार बदलता है, लेकिन सामान्य फ़ील्ड Parquet में कॉलम-प्रून करने योग्य (column-prunable) होने चाहिए। Variant एन्कोडिंग और Variant Shredding को समझाएं, फिर इन्जेशन, रीड, इवोल्यूशन और फ़ॉलबैक डिज़ाइन करें।

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

एक डेटा लेक को ऐसे JSON इवेंट प्राप्त होते हैं जिनका आकार बार-बार बदलता है। टीम मनमाने फ़ील्ड्स को बनाए रखना चाहती है और साथ ही अक्सर पूछे जाने वाले फ़ील्ड्स को कॉलम-रीडेबल और प्रून करने योग्य बनाना चाहती है। Parquet Variant के value और metadata घटकों, Variant Shredding के typedvalue और fieldoffset को समझाएं, और कम्पैटिबिलिटी, इवोल्यूशन और सत्यापन डिज़ाइन करें।

Apache Parquet विनिर्देश Variant को बाइनरी value और metadata फ़ील्ड्स के साथ दर्शाता है; Variant Shredding आंशिक रूप से समरूप (partially homogeneous) फ़ील्ड्स को अलग-अलग कॉलमों में निकाल सकता है और ऑफ़सेट द्वारा मूल मान को पुनर्गठित कर सकता है। यह साक्षात्कार JSON को एक अपारदर्शी स्ट्रिंग कॉलम में रखने के बजाय प्रारूप इनवेरिएंट्स, रीड सिमेंटिक्स और वर्कलोड साक्ष्यों का परीक्षण करता है।

साक्षात्कारकर्ता क्या जांच रहा है

साक्षात्कारकर्ता यह देखना चाहता है कि क्या आप स्व-वर्णनात्मक मेटाडेटा को Variant मानों से अलग कर सकते हैं और typedvalue, fieldid और field_offset के बीच के संबंध को समझा सकते हैं। आपको अनुपलब्ध फ़ील्ड्स, मिश्रित प्रकारों, फ़ील्ड क्रम और संस्करण विकास (version evolution) को संभालना आना चाहिए; यह समझाना चाहिए कि श्रेडिंग प्रोजेक्शन, प्रेडिकेट पुशडाउन, कम्प्रेशन और फ़ॉलबैक को कैसे सक्षम बनाती है; और तुल्यता, प्रदर्शन और अनुकूलता मैट्रिक्स के साथ डिज़ाइन को साबित करना चाहिए।

पहले स्पष्ट करने वाले प्रश्न

फ़ील्ड्स और क्वेरीज़

अक्सर पूछे जाने वाले पाथ्स, प्रकार की स्थिरता, मनमाने अज्ञात फ़ील्ड्स को बनाए रखने की आवश्यकता, और क्या क्वेरी इंजन Variant और श्रेडेड कॉलमों का समर्थन करता है, इसकी पुष्टि करें।

अनुकूलता और गवर्नेंस

पुष्टि करें कि किन पुराने पाठकों (readers) को फ़ाइलें खोलनी होंगी, क्या कोई स्कीमा रजिस्ट्री मौजूद है, विलोपन और नाम बदलने को कैसे परिभाषित किया गया है, और क्या विकृत रिकॉर्ड कच्चे Variant कॉलम में प्रवेश कर सकते हैं।

प्रदर्शन लक्ष्य

स्कैन अंश, ऑब्जेक्ट-स्टोर अनुरोध लागत, राइट लेटेंसी, कम्प्रेशन अनुपात, कैश बजट और पुनर्निर्माण CPU बजट की पुष्टि करें। एक एकल JSON नमूने से मान का अनुमान न लगाएं।

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

"मैं Variant को दो बाइनरी घटकों, value और metadata के रूप में मानता हूं, जहां metadata ऑब्जेक्ट कुंजियों या प्रकार की जानकारी का वर्णन करता है। मैं अज्ञात फ़ील्ड्स के लिए कच्चे Variant को बनाए रखते हुए स्थिर, उच्च-मात्रा वाले सब-फ़ील्ड्स को typedvalue और fieldoffset कॉलमों में श्रेड करता हूं। रीड्स स्पष्ट null या प्रकार-बेमेल व्यवहार के साथ, field_id और ऑफ़सेट द्वारा सिमेंटिक्स का पुनर्निर्माण करते हैं। रोलआउट से पहले मैं पुराने/नए रीडर मैट्रिक्स, रैंडमाइज्ड नेस्टेड-डेटा तुल्यता परीक्षण, कॉलम-प्रूनिंग जांच और वास्तविक स्कैन-लागत मापों का उपयोग करता हूं; यदि वे विफल होते हैं, तो मैं अनश्रेडेड कॉलम पर फ़ॉलबैक करता हूं।"

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

चरण 1: Variant इनवेरिएंट्स को परिभाषित करें

प्रत्येक रिकॉर्ड के लिए value और metadata संग्रहीत करें। Metadata को value के अंदर प्रकारों, कुंजियों और ऑफ़सेट की व्याख्या करनी चाहिए, और फ़ाइल के भीतर एक field_id की स्थिर व्याख्या होनी चाहिए। null, अनुपलब्ध मानों, सरणियों (arrays), ऑब्जेक्ट्स और संख्यात्मक प्रकारों के लिए एन्कोडिंग परिभाषित करें।

चरण 2: श्रेड उम्मीदवारों का चयन करें

केवल स्थिर प्रकारों, लगातार प्रश्नों और मापने योग्य लाभ वाले पाथ्स को निकालें। कम घनत्व वाले कॉलम विस्फोट और राइट प्रवर्धन (write amplification) से बचने के लिए Variant में विरल (sparse) या अत्यधिक बहुरूपी (polymorphic) पाथ्स रखें। नियम को संस्करणित कॉन्फ़िगरेशन से संचालित करें।

चरण 3: typed_value और ऑफ़सेट डिज़ाइन करें

कॉलमर प्रोसेसिंग के लिए उपयुक्त पाथ्स के लिए typedvalue लिखें। नेस्टेड संरचनाओं के लिए fieldid, field_offset, या समकक्ष स्थान डेटा को सुरक्षित रखें ताकि पाठक एक Variant को फिर से जोड़ सकें। कभी भी यह न मानें कि ऑब्जेक्ट फ़ील्ड क्रम में सिमेंटिक्स शामिल हैं।

चरण 4: स्कीमा इवोल्यूशन को संभालें

पहले एक नए फ़ील्ड को Variant में रखें, फिर उसका क्वेरी पैटर्न स्थिर होने के बाद एक श्रेडिंग नियम जोड़ें। जब कोई प्रकार बदलता है, तो भौतिक कॉलम प्रकार को चुपचाप बदलने के बजाय एक नया field_id या संस्करण बनाएं। विलोपन के बाद पुराने स्नैपशॉट को पढ़ने के लिए आवश्यक मेटाडेटा व्याख्याओं को बनाए रखें।

चरण 5: रीड्स और प्रूनिंग की योजना बनाएं

ऐसी क्वेरी के लिए जिसे केवल श्रेडेड पाथ्स की आवश्यकता होती है, typed_value को प्रोजेक्ट करें और सांख्यिकी (statistics) का उपयोग करें। अज्ञात पाथ्स के लिए, value और metadata पढ़ें। जब मान null, अनुपलब्ध या बहुरूपी हों, तो प्रेडिकेट पुशडाउन को सुरक्षित साबित किया जाना चाहिए।

text
read(record, path):
  if path has shredded column:
    value = typed_value[row]
    if value is present: return value
  variant = decode(value[row], metadata[row])
  return lookup_path(variant, path)

चरण 6: संगति (consistency) जांच जोड़ें

प्रकारों, सरणी क्रम, अनुपलब्ध फ़ील्ड्स और null सिमेंटिक्स की तुलना करते हुए, प्रति रिकॉर्ड पुनर्निर्माण तुल्यता जांच चलाएं। field_offset सीमाओं, मेटाडेटा संदर्भों और क्रॉस-रो-ग्रुप रीड्स का नमूना लें; किसी भी बेमेल पर प्रकाशन को रोकें।

चरण 7: लागत और फ़ॉलबैक को मापें

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

मॉडल उत्तर

मैं Variant value/metadata को सत्य के पूर्ण स्रोत (source of truth) के रूप में रखूंगा और केवल स्थिर, उच्च-मात्रा वाले पाथ्स को श्रेड करूंगा। typedvalue कॉलम-अनुकूल मानों को संग्रहीत करता है; fieldid और fieldoffset पाठकों को विनिर्देश के अनुसार नेस्टेड सिमेंटिक्स का पुनर्निर्माण करने की अनुमति देते हैं, जबकि अज्ञात फ़ील्ड कच्चे Variant से क्वेरी करने योग्य रहते हैं। संस्करणित नियम और नए fieldids भौतिक प्रकारों को चुपचाप बदले बिना इवोल्यूशन का प्रबंधन करते हैं। रिलीज से पहले मैं पुराने और नए पाठकों, अनुपलब्ध/null मानों, बहुरूपी सरणियों, प्रूनिंग सुरक्षा और पुनर्निर्माण तुल्यता का परीक्षण करूंगा, फिर स्कैन किए गए बाइट्स, अनुरोध गणनाओं और CPU के आधार पर सुविधा को सक्षम करूंगा।

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

  • गलती: Variant को एक एकल JSON स्ट्रिंग कॉलम के रूप में मानना। → यह क्यों विफल होता है: यह स्व-वर्णनात्मक मेटाडेटा और कॉलमर निष्कर्षण को खो देता है। → सुधार: value, metadata, field_id और ऑफ़सेट की भूमिकाएं बताएं।
  • गलती: हर पाथ को श्रेड करना। → यह क्यों विफल होता है: विरल पाथ्स कॉलम विस्फोट और राइट प्रवर्धन पैदा करते हैं। → सुधार: क्वेरी आवृत्ति, प्रकार स्थिरता और घनत्व के आधार पर पाथ्स का चयन करें।
  • गलती: field_id को फ़ील्ड क्रम से बदलना। → यह क्यों विफल होता है: ऑब्जेक्ट क्रम में बदलाव से अर्थ नहीं बदलना चाहिए। → सुधार: निर्दिष्ट पहचानकर्ताओं और ऑफ़सेट के साथ पुनर्निर्माण करें।
  • गलती: केवल क्वेरी परिणामों की तुलना करना और पुराने पाठकों को छोड़ देना। → यह क्यों विफल होता है: प्रारूप समर्थन और फ़ॉलबैक जोखिम उत्पादन में दिखाई देते हैं। → सुधार: एक फ़ाइल-संस्करण, पाठक-संस्करण और क्षमता मैट्रिक्स बनाएं।

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

आपको श्रेडिंग से कब बचना चाहिए?

जब पाथ अत्यधिक विरल हों, प्रकार लगातार बदलते हों, क्वेरी दुर्लभ हों, या पाठकों में समर्थन की कमी हो, तो Variant को बरकरार रखें। मापे गए स्कैन और पुनर्निर्माण सीमाओं के साथ निर्णय लें।

आप असुरक्षित प्रेडिकेट प्रूनिंग को कैसे रोकते हैं?

प्रेडिकेट्स को केवल तभी पुश डाउन करें जब आंकड़े पाथ को कवर करते हों और अनुपलब्ध, null और प्रकार के बेमेल में अंतर करते हों; अन्यथा उम्मीदवार पंक्तियों को पढ़ें और Variant की व्याख्या करें।

आप पुनर्निर्माण तुल्यता का परीक्षण कैसे करते हैं?

नेस्टेड ऑब्जेक्ट्स, सरणियां, डुप्लिकेट कुंजियां, nulls, अनुपलब्ध फ़ील्ड्स और कई संख्यात्मक प्रकार उत्पन्न करें। फ़ाइल संस्करणों में सामान्यीकृत मूल और पुनर्निर्मित Variants की तुलना करें।

यदि कोई पुराना पाठक Variant को पढ़ने में असमर्थ है तो क्या होगा?

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

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

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