प्रॉम्प्ट और दायरा
टेबल को Parquet के रूप में प्रतिदिन लिखा जाता है, जिसमें प्रत्येक row group के अंदर कई डेटा पेज होते हैं। क्वेरी आमतौर पर customer_id और एक समय सीमा (time range) द्वारा फ़िल्टर करती हैं, जो लगभग पूरी टेबल को स्कैन करते हुए 1% से कम पंक्तियों से मेल खाती हैं। बताएं कि वैकल्पिक Page Index पुराने रीडर्स को सही रखते हुए, मेटाडेटा लागत को नियंत्रित करते हुए और यह साबित करते हुए कि लाभ कैश या संसाधन परिवर्तनों के बजाय पेज प्रूनिंग (page pruning) से आते हैं, अप्रासंगिक पेज रीड्स को कैसे कम कर सकता है।
क्षमता, चयनात्मकता (selectivity), और स्कैन अनुपात इंटरव्यू की मान्यताएं हैं, सार्वभौमिक बेंचमार्क नहीं। यह प्रश्न डेटा इंजीनियरिंग, लेकहाउस इंजन, क्वेरी ऑप्टिमाइज़ेशन और स्टोरेज इन्फ्रास्ट्रक्चर भूमिकाओं के लिए उपयुक्त है। इसका मुख्य कौशल कॉलमर फ़ाइल लेआउट और प्रेडिकेट पुशडाउन (predicate pushdown) है, इसलिए यह data से संबंधित है।
इंटरव्यूअर्स क्या मूल्यांकन करते हैं
पहला, क्या आप ColumnIndex और OffsetIndex में अंतर कर सकते हैं? पहला यह तय करने के लिए प्रति-पेज सीमा सांख्यिकी (per-page boundary statistics) का उपयोग करता है कि कौन से पेज मेल खा सकते हैं; दूसरा मैचिंग रो रेंज को प्रोजेक्टेड कॉलम में ऑफ़सेट पर मैप करता है।
दूसरा, क्या आप ऑर्डर्ड (ordered) बनाम अनऑर्डर्ड (unordered) कॉलम की व्याख्या कर सकते हैं? ऑर्डर्ड कॉलम बाउंड्री बाइनरी सर्च का उपयोग कर सकते हैं; अनऑर्डर्ड कॉलम को अक्सर पेज सीमाओं को क्रमिक रूप से जांचने की आवश्यकता होती है। Page Index कोई सामान्य सेकेंडरी इंडेक्स नहीं है।
तीसरा, क्या आप शुद्धता (correctness) की रक्षा कर सकते हैं? ट्रंकेटेड (truncated) min/max मान कैंडिडेट सेट को बढ़ा सकते हैं लेकिन ऐसे पेज को बाहर नहीं करना चाहिए जो मेल खा सकता है। Nulls, NaNs, कॉलम क्रम और column_orders फ़ॉर्मैट परिभाषा का पालन करते हैं।
चौथा, क्या आप ट्रेड-ऑफ़ को माप सकते हैं? इंडेक्स मेटाडेटा फ़ुटर-एरिया I/O और राइट कार्य को जोड़ता है, जबकि चयनात्मक स्कैन डेटा-पेज I/O को कम कर सकते हैं। एक निश्चित गति का वादा करने के बजाय वास्तविक वर्कलोड के साथ मापें।
पांचवां, क्या आप फ़ॉलबैक प्रदान कर सकते हैं? एक पुराना रीडर Page Index को अनदेखा कर सकता है और फिर भी सामान्य row-group या पेज सांख्यिकी के साथ सही ढंग से पढ़ सकता है। इंडेक्स को सक्षम करने से परिणाम सिमेंटिक्स नहीं बदलना चाहिए।
पहले स्पष्ट करने योग्य प्रश्न
- क्या इंजन और रीडर ColumnIndex और OffsetIndex को लागू करते हैं, और क्या वे उन्हें डिफ़ॉल्ट रूप से पढ़ते हैं?
- क्या
customer_idराइट समय पर रेंज-क्लस्टर्ड (range-clustered) या सॉर्टेड है, या यह अनऑर्डर्ड है? - क्या प्रेडिकेट्स समानता, रेंज, प्रीफ़िक्स या जटिल एक्सप्रेशन्स हैं?
- क्या मौजूदा फ़ाइलों में पेज-लेवल सांख्यिकी शामिल है, और एन्कोडिंग व पेज साइज़ क्या हैं?
- न्यूनतम पुराना-रीडर वर्शन और क्रॉस-लैंग्वेज कम्पैटिबिलिटी मैट्रिक्स क्या है?
- क्या हम पॉइंट लुकअप, रेंज स्कैन या फ़ुल-टेबल एग्रीगेट्स को ऑप्टिमाइज़ कर रहे हैं?
30-सेकंड उत्तर फ्रेमवर्क
“मैं पहले रीडर सपोर्ट को सत्यापित करूंगा और पेज काउंट, ColumnIndex साइज़, ऑर्डरिंग और प्रेडिकेट सेलेक्टिविटी के लिए फ़ाइल फ़ूटर्स का सैंपल लूंगा। सॉर्टेड customer_id के लिए, मैं कैंडिडेट्स का पता लगाने के लिए पेज min/max सीमाओं का उपयोग करूंगा; अन्य कॉलमों के लिए, मैं सीमाओं का परीक्षण करूंगा और मैचिंग पंक्तियों को प्रोजेक्टेड कॉलमों में मैप करने के लिए OffsetIndex का उपयोग करूंगा। मैं ऑर्डरिंग या पेज साइज़ तभी बदलूंगा जब कोई बेंचमार्क वैल्यू दिखाए, क्योंकि Page Index एक सेकेंडरी इंडेक्स नहीं है। पुराने रीडर्स को इसे अनदेखा करते हुए वही परिणाम देना चाहिए। अंत में, कोल्ड-कैश और निश्चित संसाधनों के तहत, मैं इंडेक्स-डिसेबल्ड कंट्रोल के मुकाबले स्कैन किए गए बाइट्स, पढ़े गए पेजेस, प्लानिंग समय, एंड-टू-एंड p95 और फ़ूटर/इंडेक्स ओवरहेड की तुलना करूंगा।”
चरण-दर-चरण उत्तर
चरण 1: फ़ॉर्मैट और रीडर सपोर्ट सत्यापित करें
Page Index वैकल्पिक ColumnChunk मेटाडेटा है जिसमें ColumnIndex और OffsetIndex शामिल हैं। इंडेक्स लोकेशन और लंबाई, कॉलम क्रम और column_orders के लिए फ़ाइल मेटाडेटा का निरीक्षण करें; फिर टार्गेट इंजन में स्पष्ट पेज-प्रूनिंग मेट्रिक्स सक्षम करें। यदि कोई रीडर केवल इंडेक्स लिखता है लेकिन उसका उपभोग नहीं करता है, तो इसे लिखने से स्कैन कम नहीं होंगे।
for each row_group:
read ColumnIndex for predicate columns
select pages whose min/max may match predicate
use OffsetIndex to map selected row ranges to projected columns
read only those page rangesचरण 2: ऑर्डर्ड और अनऑर्डर्ड कॉलम को अलग करें
Parquet प्रलेखन बताता है कि ऑर्डर्ड कॉलम के लिए सीमाएं बाइनरी सर्च का समर्थन करती हैं, जबकि अनऑर्डर्ड कॉलम के लिए आमतौर पर क्रमिक min/max जांच की आवश्यकता होती है। ऑर्डरिंग फ़ॉर्मैट-व्यापी आवश्यकता नहीं है। केवल टेबल कार्डिनैलिटी का उपयोग करने के बजाय प्रति row group मान-रेंज ओवरलैप रिकॉर्ड करें।
चरण 3: min/max की व्याख्या रूढ़िवादी (conservatively) तरीके से करें
राइटर्स लंबी स्ट्रिंग्स को ट्रंकेट कर सकते हैं या वास्तविक मान रेंज को कवर करने वाली सीमाओं का उपयोग कर सकते हैं। ऐसी सीमाएं अतिरिक्त कैंडिडेट पेजेस का कारण बन सकती हैं लेकिन संभावित मैच को बाहर नहीं करना चाहिए। column_orders के अनुसार nulls, NaNs और तुलनाओं की व्याख्या करें; जब सांख्यिकी अधूरी हो, तो पेज को सुरक्षित रूप से पढ़ें।
चरण 4: कॉलमों के बीच रीड्स को कनेक्ट करें
ColumnIndex केवल प्रेडिकेट कॉलम के लिए कैंडिडेट पेजेस की पहचान करता है। प्रोजेक्शन को अभी भी अन्य कॉलमों की आवश्यकता होती है, इसलिए OffsetIndex मैचिंग रो रेंज को उनके पेज ऑफ़सेट पर मैप करता है। पेज सीमाएं कॉलमों में भिन्न हो सकती हैं; किसी एक कॉलम के पेज नंबर को दूसरे के लिए कभी पुन: उपयोग न करें। OffsetIndex के बिना, एक रीडर क्रमिक रूप से अधिक कॉलम डिकोड कर सकता है।
चरण 5: राइट और मेटाडेटा लागत को मापें
अधिक पेजेस पेज हेडर और इंडेक्स प्रविष्टियों को जोड़ते हैं; बड़े पेजेस प्रूनिंग ग्रैन्युलैरिटी को कम करते हैं। क्वेरी सेलेक्टिविटी, रो की चौड़ाई, कम्प्रेशन और पेज साइज़ के मैट्रिक्स का बेंचमार्क करें। पॉइंट लुकअप अधिक मेटाडेटा को सही ठहरा सकते हैं, जबकि व्यापक स्कैन और पूर्ण एग्रीगेट्स केवल अतिरिक्त फ़ूटर I/O का भुगतान कर सकते हैं।
चरण 6: कम्पैटिबिलिटी और रोलआउट डिज़ाइन करें
राइट्स सक्षम करने से पहले, सभी कंज़्यूमर्स की सूची बनाएं। एक पुराना रीडर जो Page Index को अनदेखा करता है, उसे row-group सांख्यिकी या सामान्य पेज रीड्स का उपयोग करना चाहिए और समान परिणाम देना चाहिए। इंडेक्स-डिसेबल्ड कंट्रोल रखते हुए, पहले नई फ़ाइलों और एक निश्चित पार्टीशन पर रोल आउट करें। सपोर्ट करने वाले और न करने वाले रीडर्स के लिए रिजल्ट हैश, स्कैन किए गए बाइट्स और एरर्स रिकॉर्ड करें।
चरण 7: दोहराने योग्य स्वीकृति (repeatable acceptance) को परिभाषित करें
कोल्ड कैश, फिक्स्ड कॉनकरेन्सी और बार-बार परीक्षणों के साथ समान स्नैपशॉट पर समकक्ष क्वेरी चलाएं। स्कैन किए गए बाइट्स, पढ़े गए पेजेस, स्किप रेशियो, फ़ूटर/इंडेक्स बाइट्स, डिकोड सीपीयू, एंड-टू-एंड लेटेंसी और परिणाम सत्यापन रिकॉर्ड करें। नकारात्मक नियंत्रण (negative control) के रूप में एक उच्च-ओवरलैप अनऑर्डर्ड पार्टीशन रखें; यदि इंडेक्स केवल कम-सेलेक्टिविटी वाले वर्कलोड के लिए लागत जोड़ता है तो रोलआउट रोक दें।
मॉडल उत्तर
“मैं पहले सत्यापित करूंगा कि रीडर ColumnIndex और OffsetIndex का उपभोग करता है, फिर पेज काउंट, इंडेक्स लंबाई, column_orders और राइट ऑर्डरिंग के लिए फ़ूटर्स का सैंपल लूंगा। Page Index वैकल्पिक मेटाडेटा है, सेकेंडरी इंडेक्स नहीं; यह बताता है कि कौन से पेज मेल खा सकते हैं।
सॉर्टेड customer_id के लिए, मैं पेज min/max सीमाओं पर बाइनरी-सर्च करूंगा; अनऑर्डर्ड कॉलमों के लिए, मैं सीमाओं की क्रमिक रूप से जांच करूंगा। मैं मैचिंग प्रेडिकेट पंक्तियों को प्रोजेक्टेड कॉलमों में मैप करने के लिए OffsetIndex का उपयोग करूंगा, कभी भी एक कॉलम के पेज नंबर को दूसरे के लिए दोबारा उपयोग नहीं करूंगा। ट्रंकेटेड सांख्यिकी कैंडिडेट्स को विस्तृत कर सकती है; गायब सांख्यिकी, nulls, या अनिश्चित ऑर्डरिंग के लिए सुरक्षित रीड की आवश्यकता होती है।
राइट्स पर, मैं सेलेक्टिविटी, पेज साइज़, कम्प्रेशन और फ़ूटर वृद्धि का बेंचमार्क करूंगा। रोलआउट के दौरान मैं एक पुराने-रीडर और इंडेक्स-डिसेबल्ड कंट्रोल को बनाए रखूंगा, और समान परिणामों की मांग करूंगा। कोल्ड कैश और निश्चित संसाधनों के साथ, मैं विस्तार करने से पहले स्कैन किए गए बाइट्स, स्किप रेशियो, इंडेक्स I/O, सीपीयू, p95 और रिजल्ट हैश की तुलना करूंगा।”
सामान्य गलतियां
- Page Index को सेकेंडरी इंडेक्स की तरह मानना → अनऑर्डर्ड कॉलम में अभी भी कई कैंडिडेट्स हो सकते हैं → मान-रेंज ओवरलैप और सेलेक्टिविटी को मापें।
- केवल ColumnIndex लिखना → प्रोजेक्टेड कॉलम मैचिंग पंक्तियों द्वारा जंप नहीं कर सकते → OffsetIndex मैपिंग को मान्य करें।
- ट्रंकेटेड min/max को सटीक मानना → वास्तविक मैच बाहर हो सकते हैं → केवल कंज़र्वेटिव कैंडिडेट विस्तार की अनुमति दें।
- केवल वॉर्म कैश का परीक्षण करना → कैश I/O को छुपाता है → कोल्ड-कैश कंट्रोल रन को दोहराएं।
- कॉलमों में पेज नंबरों का पुन: उपयोग करना → पेज सीमाएं भिन्न होती हैं → रो रेंज और ऑफ़सेट का उपयोग करें।
- पुराने रीडर्स को अनदेखा करना → रोलआउट कम्पैटिबिलिटी रिग्रेशन पेश करता है → रीडर मैट्रिक्स और फ़ॉलबैक बनाए रखें।
- परिणामों के बिना केवल लेटेंसी की जांच करना → प्रूनिंग बग्स पंक्तियों को खो सकते हैं → हैश और व्यावसायिक एग्रीगेट्स की तुलना करें।
- डिफ़ॉल्ट रूप से हर जगह सक्षम करना → कम-सेलेक्टिविटी स्कैन मेटाडेटा लागत का भुगतान करते हैं → प्रति टेबल या पार्टीशन रोल आउट करें।
फॉलो-अप प्रश्न
फॉलो-अप 1: ऑर्डर्ड कॉलम को अधिक लाभ क्यों होता है?
ऑर्डरिंग मानों को पड़ोसी पेजेस में केंद्रित करती है, इसलिए एक रेंज अक्सर एक सन्निहित (contiguous) पेज अंतराल पर मैप होती है जो बाइनरी सर्च का समर्थन करती है। अनऑर्डर्ड मान अधिक ओवरलैप करते हैं और अधिक कैंडिडेट्स उत्पन्न करते हैं। पेज साइज़ और प्रेडिकेट सेलेक्टिविटी अभी भी परिणाम निर्धारित करते हैं।
फॉलो-अप 2: क्या OffsetIndex के बिना पेजेस को स्किप किया जा सकता है?
प्रेडिकेट कॉलम कैंडिडेट्स की पहचान कर सकता है, लेकिन प्रोजेक्टेड कॉलम सीधे समान रो रेंज का पता नहीं लगा सकते हैं, इसलिए रीडर को अधिक क्रमिक रीड्स की आवश्यकता हो सकती है। केवल फ़ाइल मेटाडेटा से समर्थन का अनुमान लगाने के बजाय टार्गेट रीडर को मान्य करें।
फॉलो-अप 3: क्या ट्रंकेटेड सांख्यिकी सुरक्षित है?
एक सही राइटर वास्तविक सीमा को कवर करने वाली कंज़र्वेटिव सीमाएं प्रस्तुत करता है। यह गलत सकारात्मक (false positives) और अतिरिक्त रीड्स बना सकता है, लेकिन गलत नकारात्मक (false negatives) नहीं। यदि वह गारंटी उपलब्ध नहीं है, तो सामान्य रीड्स पर वापस आएं।
फॉलो-अप 4: आप कैसे साबित करते हैं कि कोई पंक्ति नहीं खोई है?
Page Index सक्षम और अक्षम के साथ समान स्नैपशॉट चलाएं, पूर्ण परिणामों, काउंट्स, एग्रीगेट्स और प्रमुख सैंपल्स की तुलना करें, फिर सिंथेटिक डेटा के साथ बाउंड्री वैल्यूज, nulls, डुप्लिकेट्स और लंबी स्ट्रिंग्स का परीक्षण करें।
फॉलो-अप 5: Page Index कब लिखने लायक नहीं है?
पूर्ण स्कैन, कम-सेलेक्टिविटी प्रेडिकेट्स, कम पेजेस, या फ़ूटर-प्रधान लेटेंसी को लाभ नहीं हो सकता है। इंडेक्स बाइट्स, राइट सीपीयू और रखरखाव लागत की तुलना करें, और प्रति-टेबल या प्रति-पार्टीशन स्विच रखें।
फॉलो-अप 6: स्कीमा या ऑर्डरिंग परिवर्तनों के बारे में क्या?
नई फ़ाइलों की व्याख्या उनके अपने स्कीमा और column_orders के साथ की जानी चाहिए; टेबल एक वैश्विक ऑर्डरिंग नहीं मान सकती है। मिश्रित ऐतिहासिक फ़ाइलों को क्षमता-जागरूक हैंडलिंग और गायब इंडेक्स की निगरानी की आवश्यकता होती है।