डेटा इंजीनियरिंग इंटरव्यू: पार्टिशनिंग रणनीति कैसे चुनें और यह कैसे साबित करें कि पार्टिशन प्रूनिंग काम कर रही है?

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

एक Apache Iceberg इवेंट टेबल में लगभग 1 PiB डेटा है और यह प्रतिदिन 6 TiB जोड़ती है। यह 180 दिनों का डेटा रखती है। प्रत्येक क्वेरी में एक event_time रेंज होती है, जो आमतौर पर एक से सात दिनों की होती है; 35% क्वेरीज़ में 12,000 tenant_id वैल्यूज़ में से किसी एक पर इक्वलिटी फ़िल्टर भी होता है। इवेंट्स 48 घंटे तक देर से आ सकते हैं, और ऐतिहासिक बैकफ़िल की संभावना है। वर्तमान अनपार्टिशन्ड टेबल बहुत अधिक डेटा स्कैन करती है।

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

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

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

पहला संकेत वर्कलोड-फर्स्ट रीजनिंग (workload-first reasoning) है। पार्टिशन कॉलम तब उपयोगी होता है जब सामान्य प्रेडिकेट्स इंजन को फिजिकल डेटा को बाहर करने (exclude) की अनुमति देते हैं। केवल कार्डिनैलिटी अकेले एक अच्छी पार्टिशन की नहीं बनाती है।

दूसरा संकेत ग्रैन्युलैरिटी अनुशासन (granularity discipline) है। मोटे (coarse) पार्टिशन अनावश्यक बाइट्स पढ़ते हैं; बारीक या हाई-कार्डिनैलिटी वाले पार्टिशन मेटाडेटा, छोटी फ़ाइलें और महंगी राइट्स (writes) बनाते हैं। एक मजबूत उत्तर स्पेसिफिकेशन चुनने से पहले बाइट्स और पार्टिशन काउंट का अनुमान लगाता है।

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

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

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

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

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

“मैं कॉलम कार्डिनैलिटी से नहीं, बल्कि प्रेडिकेट लॉग से शुरुआत करूंगा। प्रत्येक क्वेरी event_time को फ़िल्टर करती है, इसलिए मैं day(event_time) को कैनरी करूंगा। छह TiB प्रतिदिन एक बड़ा आकार है; टेनेंट इक्वलिटी वाली 35% क्वेरीज़ के लिए, मैं एक फिक्स्ड bucket(64, tenant_id) ट्रांसफ़ॉर्म जोड़ने का बेंचमार्क करूंगा। यह 12,000 टेनेंट पार्टिशन्स के बजाय प्रति दिन अधिकतम 64 फिजिकल ग्रुप्स बनाता है।

मैं हाफ-ओपन इवेंट-टाइम रेंज का उपयोग करूंगा, प्लान और प्लान की गई फ़ाइलों का निरीक्षण करूंगा, और समान परिणामों को सत्यापित करते हुए अनपार्टिशन्ड कंट्रोल के विरुद्ध स्कैन किए गए बाइट्स की तुलना करूंगा। मैं tenant_id/hour को अस्वीकार कर दूंगा क्योंकि यह प्रति दिन सैकड़ों-हजारों ग्रुप्स बना सकता है और राइटर्स के संसाधनों को समाप्त कर सकता है। लेट इवेंट्स संबंधित इवेंट-डे पार्टिशन को अपडेट करते हैं। मैं वर्कलोड क्लास के अनुसार रोल आउट करूंगा और प्रूनिंग लाभ, फ़ाइल साइज़, राइट कॉस्ट और मेटाडेटा स्वीकार्य सीमाओं के भीतर रहने के बाद ही Iceberg स्पेसिफिकेशन को इवॉल्व करूंगा।”

चरण-दर-चरण गहन विश्लेषण

चरण 1: क्वेरी लॉग को प्रेडिकेट मैट्रिक्स में बदलें

लेआउट चुनने से पहले प्रोडक्शन क्वेरीज़ का सैंपल लें। प्रत्येक वर्कलोड क्लास के लिए, फ़्रीक्वेंसी, लेटेंसी या कॉस्ट वेट, टाइम-रेंज की चौड़ाई, टेनेंट सेलेक्टिविटी, जॉइन्स, और क्या प्रेडिकेट फ़ैक्ट टेबल को स्कैन करने से पहले उपलब्ध है, इसे रिकॉर्ड करें। केवल फ़्रीक्वेंसी के आधार पर वेटेज देने से सस्ते डैशबोर्ड ऑप्टिमाइज़ हो सकते हैं, जबकि उस दुर्लभ दैनिक जॉब की अनदेखी हो सकती है जो अधिकांश टेबल को पढ़ता है।

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

चरण 2: उम्मीदवार पार्टिशन साइज़ और काउंट का अनुमान लगाएं

दैनिक इवेंट-टाइम पार्टिशन्स को लगभग 6 TiB प्राप्त होता है। इसलिए एक सात-दिवसीय क्वेरी फ़ाइल- और रो-ग्रुप-लेवल स्किपिंग से पहले लगभग 42 TiB के साथ शुरू हो सकती है। प्रति घंटे के पार्टिशन्स को औसतन लगभग 256 GiB प्राप्त होता है:

6 TiB / 24 = 0.25 TiB = 256 GiB per hour

दोनों सामान्य कॉलमर फ़ाइलों को भरने के लिए पर्याप्त बड़े हैं। दैनिक पार्टिशन्स लगभग 180 सक्रिय टाइम ग्रुप्स बनाते हैं; प्रति घंटे के पार्टिशन्स लगभग 4,320 बनाते हैं। बारीक विकल्प तभी उचित है जब कई क्वेरीज़ कुछ घंटों को कवर करती हों और अतिरिक्त मेटाडेटा व राइट फ़ैन-आउट मापी गई लागत में सुधार करते हों।

tenant_id और घंटे द्वारा सीधे पार्टिशन करने की एक खतरनाक ऊपरी सीमा (upper bound) है:

12,000 tenants * 24 hours = 288,000 tenant-hour groups per day

स्पार्स ग्रुप्स और स्क्यू वास्तविक संख्या को कम कर देते हैं, लेकिन ऊपरी सीमा विफलता मोड को उजागर करती है। राइटर्स प्रति बैच कई ग्रुप्स को छू सकते हैं और छोटी फ़ाइलों को बंद कर सकते हैं। एक फिक्स्ड bucket(64, tenant_id) ट्रांसफ़ॉर्म टेनेंट डायमेंशन को प्रति टाइम पार्टिशन 64 ग्रुप्स तक सीमित करता है। एकसमान डेटा के साथ, प्रत्येक दैनिक बकेट को लगभग 96 GiB प्राप्त होता है; वास्तविक स्क्यू को मापा जाना चाहिए।

चरण 3: वर्कलोड को पूरा करने वाला सबसे सरल स्पेसिफिकेशन चुनें

day(event_time) से शुरुआत करें। यह प्रत्येक क्वेरी को सर्व करता है और इसका मेटाडेटा सतह सबसे छोटा है। फिर टेनेंट-भारी वर्कलोड के लिए इस विकल्प को बेंचमार्क करें:

PARTITIONED BY (day(event_time), bucket(64, tenant_id))

बकेट काउंट एक इंटरव्यू उम्मीदवार है, कोई यूनिवर्सल डिफ़ॉल्ट नहीं। वास्तविक टेनेंट डिस्ट्रीब्यूशन, फ़ाइल टार्गेट्स, राइटर पैरेललिज्म और क्वेरी कंकरेंसी का उपयोग करके 16, 32, 64 और 128 की तुलना करें। बकेट्स जोड़ना केवल तभी मदद करता है जब इंजन टेनेंट इक्वलिटी प्रेडिकेट से बकेट प्राप्त कर सके और प्लान की गई फ़ाइलों में कमी मेटाडेटा और राइट फ़ैन-आउट से अधिक हो।

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

चरण 4: ऐसे प्रेडिकेट्स लिखें जिन्हें प्लानर प्रून कर सके

UTC सीमाओं में परिवर्तित व्यावसायिक समय क्षेत्र में एक स्पष्ट हाफ-ओपन रेंज का उपयोग करें:

SELECT tenant_id, event_type, COUNT(*)
FROM analytics.events
WHERE event_time >= TIMESTAMP '2026-07-01 00:00:00 UTC'
  AND event_time <  TIMESTAMP '2026-07-08 00:00:00 UTC'
  AND tenant_id = 'tenant-42'
GROUP BY tenant_id, event_type;

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

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

चरण 5: प्रूनिंग और शुद्धता साबित करें

एक घंटे की रेंज, एक दिन, सात दिन, टेनेंट और गैर-टेनेंट वेरिएंट, एक खाली रेंज, एक लेट इवेंट और एक डेलाइट-सेविंग सीमा के साथ एक टेस्ट मैट्रिक्स बनाएं। प्रत्येक क्वेरी के लिए, कैप्चर करें:

• लॉजिकल और फिजिकल प्लान्स, जिसमें पार्टिशन या फ़ाइल फ़िल्टर शामिल हैं;
• प्लान किए गए पार्टिशन और फ़ाइल काउंट्स;
• अनुमानित और वास्तविक स्कैन किए गए बाइट्स;
• प्लानिंग समय, निष्पादन p50/p95, और टास्क काउंट;
• आउटपुट रो काउंट, एग्रीगेट्स, और कंट्रोल के विरुद्ध एक चेकसम।

एक अनपार्टिशन्ड स्नैपशॉट कंट्रोल है। 180 समान आकार के दिनों में एक दिन की क्वेरी के लिए, एक मोटा अनुमान यह है कि टाइम प्रूनिंग मेटाडेटा, स्क्यू और फ़ाइल आंकड़ों से पहले सक्रिय बाइट्स के लगभग 1/180 पर विचार करती है। यह एक ऑर्डर-ऑफ़-मैग्नीट्यूड जांच है, कोई वादा किया गया अनुपात नहीं। एक प्लान जो फ़िल्टर का नाम देता है लेकिन फिर भी सभी फ़ाइलों को स्कैन करता है, वह पास नहीं हुआ है।

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

चरण 6: राइट्स, लेट डेटा और मेंटेनेंस का ध्यान रखें

पार्टिशनिंग राइट पाथ को बदल देती है। प्रति टास्क ओपन राइटर्स, प्रति कमिट बनाई गई फ़ाइलें, p50/p90 फ़ाइल साइज़, कमिट लेटेंसी, मेटाडेटा वृद्धि और पुनः प्रयास संघर्षों (retry conflicts) को ट्रैक करें। लिखने से पहले पार्टिशन ट्रांसफ़ॉर्म द्वारा पंक्तियों को वितरित करें और प्रति ग्रुप बाइट्स से राइटर काउंट का आकार तय करें। पार्टिशन प्रूनिंग लाखों छोटी फ़ाइलों की भरपाई नहीं कर सकती है।

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

चरण 7: बिना बिग-बैंग रीराइट के इवॉल्व करें

Iceberg हिडन पार्टिशनिंग के साथ, एक नया स्पेसिफिकेशन नई फ़ाइलों पर लागू होता है जबकि पुरानी फ़ाइलें अपने पिछले स्पेसिफिकेशन को बनाए रखती हैं। प्लानर दोनों को पढ़ सकता है, लेकिन लाभ तब तक मिश्रित रहता है जब तक कि हॉट या अक्सर क्वेरी किए जाने वाले पुराने डेटा को दोबारा नहीं लिखा जाता। एक बेसलाइन स्नैपशॉट रिकॉर्ड करें, हालिया रेंज को कैनरी करें, और केवल तभी विस्तार करें जब पुराने और नए-स्पेसिफिकेशन दोनों क्वेरीज़ सही रहें।

रोलबैक का अर्थ है नए स्पेसिफिकेशन पर नए राइटर्स को रोकना और पिछले राइट कॉन्फ़िगरेशन या टेबल स्नैपशॉट को पुनर्स्थापित करना जहां समर्थित हो। यह पहले से हटाई गई फ़ाइलों को स्वचालित रूप से पूर्ववत नहीं करता है। स्नैपशॉट रिटेंशन और फिजिकल क्लीनअप को कैनरी विंडो से बाहर रखें। ऐतिहासिक डेटा को केवल तभी दोबारा लिखें जब मापी गई बचत I/O और संघर्ष के जोखिम को उचित ठहराती हो।

स्वीकृति मानदंडों में समान व्यावसायिक परिणाम, प्रत्येक वर्कलोड क्लास के लिए अपेक्षित पार्टिशन एलिमिनेशन, कम स्कैन बाइट्स या लेटेंसी, स्वस्थ फ़ाइल-साइज़ परसेंटाइल्स, सीमित प्लानिंग समय, इनजेशन-SLA में कोई गिरावट नहीं, और स्थिर मेटाडेटा वृद्धि शामिल होनी चाहिए।

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

“मैं पहले वास्तविक प्रेडिकेट डिस्ट्रीब्यूशन निकालूंगा। यहां, प्रत्येक क्वेरी में एक इवेंट-टाइम रेंज होती है, जबकि केवल 35% एक टेनेंट का चयन करती हैं, इसलिए समय प्राथमिक डायमेंशन है। एक दैनिक पार्टिशन में लगभग 6 TiB होता है और यह 180 सक्रिय टाइम ग्रुप्स देता है। प्रति घंटे के पार्टिशन्स में लगभग 256 GiB होता है लेकिन 4,320 सक्रिय टाइम ग्रुप्स बनते हैं; मैं उनका उपयोग केवल तभी करूंगा जब संकीर्ण-घंटे की क्वेरीज़ अतिरिक्त मेटाडेटा को उचित ठहराती हों।

मेरा बेसलाइन कैनरी day(event_time) है। टेनेंट-भारी क्वेरीज़ के लिए, मैं day(event_time), bucket(64, tenant_id) को बेंचमार्क करूंगा। चौंसठ केवल एक उम्मीदवार है: यह टेनेंट फ़ैन-आउट को सीमित करता है और एकसमान वितरण के तहत प्रति दैनिक बकेट लगभग 96 GiB देता है। मैं सीधे टेनेंट-आवर पार्टिशनिंग को अस्वीकार कर दूंगा क्योंकि इसकी ऊपरी सीमा प्रति दिन 288,000 ग्रुप्स है, जिससे छोटी फ़ाइलों और राइटर फ़ैन-आउट का जोखिम होता है।

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

लेट इवेंट्स अपने इवेंट-डे पार्टिशन्स में लिखते हैं, इसलिए कॉम्पैक्शन 48-घंटे की लेट-अराइवल विंडो से आगे प्रतीक्षा करता है। कैनरी के दौरान मैं फ़ाइल परसेंटाइल्स, प्रति टास्क राइटर्स, प्लानिंग p95, मेटाडेटा, राइट लैग और संघर्षों की निगरानी करता हूं। यदि Iceberg पार्टिशन इवोल्यूशन उपलब्ध है, तो नई फ़ाइलें नए स्पेक को अपनाती हैं जबकि पुरानी फ़ाइलें पठनीय बनी रहती हैं। मैं पुराने डेटा को केवल तभी दोबारा लिखता हूं जब मापी गई क्वेरी बचत रीराइट लागत से अधिक हो जाती है। किसी भी शुद्धता अंतर, ऑल-फ़ाइल स्कैन, छोटी फ़ाइलों में उछाल, या इनजेशन-SLA गिरावट पर रोलआउट को रोक दिया जाता है।”

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

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

फॉलो-अप प्रश्न और उत्तर

फॉलो-अप 1: यदि 95% क्वेरीज़ एक टेनेंट को फ़िल्टर करती हैं तो क्या बदलता है?

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

फॉलो-अप 2: यदि 256 GiB प्रति घंटा अभी भी बड़ा है तो प्रति घंटा पार्टिशन क्यों न करें?

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

फॉलो-अप 3: क्या होगा यदि कोई क्वेरी स्थानीय कैलेंडर दिन को फ़िल्टर करती है?

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

फॉलो-अप 4: क्या होगा यदि प्लान प्रूनिंग दिखाता है लेकिन बाइट्स कम नहीं होते हैं?

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

फॉलो-अप 5: आप दैनिक से प्रति घंटा पार्टिशन्स में सुरक्षित रूप से कैसे बदलाव करते हैं?

नई फ़ाइलों पर नए स्पेसिफिकेशन को कैनरी करें, पिछला स्नैपशॉट रखें, और पुराने व नए लेआउट को पार करने वाली श्रेणियों को क्वेरी करें। शुद्धता, प्लानिंग, फ़ाइल साइज़ और राइट लागत को मापें। केवल उन ऐतिहासिक श्रेणियों को दोबारा लिखें जिनका मापा गया लाभ I/O के लिए भुगतान करता है, और रोलबैक व रिटेंशन विंडो बंद होने तक फिजिकल क्लीनअप में देरी करें।