डेटा इंजीनियरिंग साक्षात्कार: आप कैसे साबित करेंगे कि DataFusion नेस्टेड-फील्ड पुशडाउन स्कैन लागत को कम करता है?

सवाल

DataFusion 53 get_field जैसे एक्सप्रेशन्स को डेटा सोर्स में पुश कर सकता है। परिणामों को बदले बिना कम I/O और डिकोडिंग लागत को साबित करने के लिए आप क्वेरी, प्लान और बेंचमार्क कैसे डिजाइन करेंगे?

संदर्भ और सीमाएं

मान लें कि एक Parquet टेबल में एक विस्तृत struct कॉलम s है, जबकि क्वेरी को केवल s['label'] की आवश्यकता है और यह s['value'] पर फ़िल्टर करती है। बैच स्कैन, स्टैटिस्टिक्स, नल (nulls), स्कीमा इवोल्यूशन, और पुशडाउन लागू न होने पर सुरक्षित फ़ॉलबैक को कवर करें। "प्लान में प्रोजेक्शन दिखाई देता है" को एंड-टू-एंड प्रमाण न मानें।

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

कौशल सिमेंटिक शुद्धता, प्लान रीराइटिंग, डेटा-सोर्स क्षमता और मापने योग्य लाभ को अलग-अलग समझने में है। DataFusion 53 नेस्टेड-फील्ड एक्सेस को स्कैन के करीब ले जाता है ताकि पूरा struct पढ़ने की आवश्यकता न पड़े; इसके कॉन्फ़िगरेशन डॉक्स बताते हैं कि enable_leaf_expression_pushdown फ़िल्टर, सॉर्ट या जॉइन एक्सप्रेशन्स से get_field निकालता है और इसे लीफ़ नोड्स की ओर पुश करता है।

पहले इन बिंदुओं को स्पष्ट करें:

• क्या सोर्स फ़ील्ड-लेवल प्रोजेक्शन का समर्थन करता है, और क्या फ़ाइल फ़ॉर्मेट Parquet है?
• s['label'] और s['value'] के लिए प्रकार (types), नल सिमेंटिक्स, और मिसिंग-फ़ील्ड नियम क्या हैं?
• क्या बेसलाइन डिसेबल्ड ऑप्टिमाइजेशन है, कोई पुराना DataFusion संस्करण है, या ऐसी क्वेरी है जो पूरे struct को पढ़ती है?
• क्या तुलना को स्कैन बाइट्स, डिकोडिंग CPU, पीक मेमोरी, लेटेंसी, या ऑब्जेक्ट-स्टोर अनुरोधों पर केंद्रित होना चाहिए?

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

नेस्टेड प्रोजेक्शन और फ़िल्टरिंग वाले SQL से शुरुआत करें। फिर ऑप्टिमाइजेशन से पहले और बाद में लॉजिकल और फिजिकल प्लान तथा Parquet रीडर प्रोजेक्शन की तुलना करें। अंत में, स्कैन बाइट्स, डिकोड समय, पीक मेमोरी और परिणाम जांच को मापने के लिए समान डेटा, कैश स्थिति और समवर्तीता (concurrency) का उपयोग करें, साथ ही यह भी बताएं कि फ़ॉलबैक कब करना है।

चरण-दर-चरण विस्तृत विश्लेषण

1. डेटा तैयार करें: struct चौड़ाई, नल दर और फ़ील्ड चयनात्मकता (selectivity) को नियंत्रित करते हुए समान पार्टिशन्स, रो ग्रुप्स और स्टैटिस्टिक्स के साथ Parquet फ़ाइलें बनाएं।
2. बेसलाइन परिभाषित करें: पूर्ण-struct रीड, डिसेबल्ड पुशडाउन और लीफ़-फ़ील्ड रीड के लिए DataFusion संस्करण, थ्रेड काउंट, ऑब्जेक्ट-स्टोर लेटेंसी और कैश स्थिति को स्थिर रखें।
3. प्लान का निरीक्षण करें: पुष्टि करें कि get_field स्कैन के निकट है और प्रोजेक्शन में केवल id, s.label, और फ़िल्टर फ़ील्ड s.value शामिल हैं; केवल SQL टेक्स्ट पर्याप्त नहीं है।
4. सोर्स का अवलोकन करें: पढ़े गए Parquet कॉलम, रो-ग्रुप प्रूनिंग, फेच किए गए बाइट्स और डिकोड बैच रिकॉर्ड करें, जिससे प्रोजेक्शन लाभ को प्रेडिकेट लाभ से अलग किया जा सके।
5. परिणामों की जांच करें: सॉर्ट किए गए हैश या पंक्तियों की तुलना करें, जिसमें मिसिंग फ़ील्ड, नल, प्रकार परिवर्तन, खाली struct और डुप्लिकेट पंक्तियां शामिल हों।
6. फ़ॉलबैक परिभाषित करें: यदि सोर्स में फ़ील्ड पुशडाउन का अभाव है, रीराइट असुरक्षित है, या लाभ थ्रेशोल्ड से कम है, तो सही पूर्ण-रीड पाथ बनाए रखें और कारण रिकॉर्ड करें।

मॉडल उत्तर

मैं एक निश्चित Parquet डेटासेट से तीन बेसलाइन बनाऊंगा: पूर्ण s पढ़ें, enable_leaf_expression_pushdown को डिसेबल करें, और लीफ़ फ़ील्ड का चयन करते समय ऑप्टिमाइजेशन को सक्षम करें। क्वेरी है:

SELECT id, s['label']
FROM events
WHERE s['value'] > 150;

मैं लॉजिकल और फिजिकल प्लान को सेव करूंगा और सत्यापित करूंगा कि get_field स्कैन के करीब स्थित है और स्कैन प्रोजेक्शन में अब s का पूरा भाग शामिल नहीं है। मैं कोल्ड-कैश और वार्म-कैश के कई इटरेशन चलाऊंगा, जिसमें पढ़े गए बाइट्स, ऑब्जेक्ट-स्टोर अनुरोध, Parquet डिकोड CPU, पीक मेमोरी, एंड-टू-एंड लेटेंसी और आउटपुट पंक्तियों को रिकॉर्ड किया जाएगा। मैं पूर्ण-struct बेसलाइन के साथ एक स्थिर सॉर्ट किए गए हैश की तुलना करूंगा, जिसमें स्पष्ट रूप से नल, मिसिंग फ़ील्ड, और पुराने व नए स्कीमा शामिल होंगे। यदि सोर्स फ़ील्ड को प्रोजेक्ट नहीं कर सकता है, तो मैं सुंदर दिखने वाले प्लान के लिए शुद्धता का त्याग करने के बजाय पूर्ण रीड को बनाए रखूंगा और एक मेट्रिक उत्सर्जित (emit) करूंगा। रोलआउट से पहले, स्कैन बाइट्स और परिणाम हैश रिग्रेशन गेट बन जाएंगे।

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

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

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

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

लीफ़-फ़ील्ड रीड्स अभी भी कोई लाभ क्यों नहीं दिखा सकते हैं?

फ़ाइल रो-ओरिएंटेड हो सकती है, struct भौतिक रूप से अलग करने योग्य नहीं हो सकता है, ऑब्जेक्ट-स्टोर अनुरोध हावी हो सकते हैं, या सोर्स फ़ील्ड प्रोजेक्शन लागू नहीं कर सकता है। केवल प्लान के बजाय वास्तविक बाइट्स और डिकोड समय का निरीक्षण करें।

यदि s['value'] अधिकांशतः नल है, तो आप परिणामों को कैसे सुरक्षित रखते हैं?

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

नेस्टेड फ़ील्ड जोड़े जाने के बाद पुरानी फ़ाइलों का क्या होता है?

रीडर को नाम से फ़ील्ड को हल (resolve) करना चाहिए और पुरानी फ़ाइलों पर परिभाषित नल या डिफ़ॉल्ट सिमेंटिक्स लागू करना चाहिए। बेंचमार्क में पुरानी और नई फ़ाइलें शामिल होनी चाहिए और संयुक्त स्कैन को मान्य करना चाहिए।

साक्षात्कार चेकलिस्ट

एक-वाक्य का निष्कर्ष

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