डेटा इंजीनियरिंग इंटरव्यू: आप Delta Lake Liquid Clustering का मूल्यांकन और माइग्रेशन कैसे करेंगे?

प्रॉम्प्ट और परिदृश्य

आपके पास tenant_id और order_date द्वारा पार्टिशन की गई और Z-Ordering के साथ मेंटेन की जाने वाली एक Delta Lake ऑर्डर फैक्ट टेबल है। जैसे-जैसे टेनेंट बढ़ते हैं, छोटे-टेनेंट की क्वेरीज़ अभी भी कई फाइलों को स्कैन करती हैं, इसलिए टीम Liquid Clustering का प्रस्ताव करती है। बताएं कि आप किन मेट्रिक्स पर नज़र रखेंगे, उनके साथ इस बदलाव का मूल्यांकन, माइग्रेशन, वैलिडेशन और रोलबैक कैसे करेंगे।

इंटरव्यूअर क्या जांच रहा है

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

पहले पूछे जाने वाले स्पष्टीकरण प्रश्न

1. क्या मुख्य क्वेरीज़ लगातार tenant_id, समय सीमा, या customer_id को फ़िल्टर करती हैं, और वे प्रेडिकेट्स कितने चयनात्मक (selective) हैं?
2. कौन से Delta Lake, Spark/Databricks रनटाइम, और रीडर/राइटर क्लाइंट वर्ज़न उपयोग में हैं, और क्या वे Liquid Clustering का समर्थन करते हैं?
3. पिछले दो हफ्तों में वर्तमान पार्टिशन और Z-Ordering मेंटेनेंस कैडेंस, फाइल साइज़, स्कैन किए गए बाइट्स और p95 लेटेंसी क्या हैं?
4. क्या प्लेटफ़ॉर्म बैकग्राउंड OPTIMIZE कंप्यूट को संभाल सकता है, और क्या कम ट्रैफ़िक वाली विंडो के साथ रोलबैक कॉपी उपलब्ध है?

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

मैं सबसे लगातार और चयनात्मक फ़िल्टरों की पुष्टि करने के लिए क्वेरी लॉग से शुरुआत करूंगा, फिर शैडो टेबल पर दो सप्ताह की तुलना चलाऊंगा। Liquid Clustering मौजूदा सभी डेटा को फिर से लिखे बिना भविष्य के राइट्स और ऑप्टिमाइज़ेशन द्वारा उपयोग किए जाने वाले लेआउट को बदल सकता है, लेकिन यह पारंपरिक पार्टिशनिंग और Z-Ordering का एक विकल्प है, इसलिए मैं पहले वर्ज़न, प्रोटोकॉल परिवर्तन और डाउनस्ट्रीम क्लाइंट्स को सत्यापित करूंगा। माइग्रेशन के बाद मैं इंक्रीमेंटल OPTIMIZE चलाऊंगा, और OPTIMIZE FULL का उपयोग केवल तभी करूंगा जब ऐतिहासिक डेटा अभी भी स्कैन पर हावी हो। मैं स्कैन किए गए बाइट्स, फाइल काउंट, p95, विफलता दर और लागत के आधार पर समकक्ष क्वेरीज़ की तुलना करूंगा। मैं राइट्स, समवर्तीता (concurrency) और रोलबैक के भी पास होने के बाद ही विस्तार करूंगा।

विस्तृत विश्लेषण

1. पहले एक वर्कलोड प्रोफाइल बनाएं

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

2. क्लस्टरिंग कॉलम चुनें और सेट को छोटा रखें

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

3. माइग्रेशन सीमाएं और कम्पैटिबिलिटी जांच परिभाषित करें

आधिकारिक दस्तावेज़ Liquid Clustering को समर्थित Delta Lake वर्ज़न से जोड़ता है, और मौजूदा टेबल के लिए सक्षमीकरण पथ वर्ज़न के अनुसार भिन्न होता है। इसे सक्षम करने से पहले, इंजन, प्रोटोकॉल अपग्रेड प्रभाव, स्ट्रीमिंग राइट्स, इंक्रीमेंटल रीड्स, बैकअप टूल और पुराने क्लाइंट्स की जांच करें। Liquid Clustering को पारंपरिक पार्टिशनिंग या Z-Ordering के साथ संयोजित नहीं किया जाता है, इसलिए माइग्रेशन योजना को पुराने मेंटेनेंस जॉब्स को रोकना चाहिए और शैडो टेबल के विरुद्ध लीगेसी उपभोक्ताओं को मान्य करना चाहिए।

4. इंक्रीमेंटल मेंटेनेंस से शुरुआत करें, फिर फुल रीराइट पर निर्णय लें

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

CREATE TABLE fact_orders (
  tenant_id STRING,
  order_date DATE,
  customer_id STRING,
  amount DECIMAL(18, 2)
) USING DELTA
CLUSTER BY (tenant_id, order_date);

OPTIMIZE fact_orders;

ALTER TABLE fact_orders CLUSTER BY (tenant_id, customer_id);
OPTIMIZE fact_orders FULL;

5. एक पुनरुत्पादक बेसलाइन के विरुद्ध लाभों को मान्य करें

क्वेरी सेट, डेटा स्नैपशॉट, समवर्तीता और कैश स्थितियों को स्थिर रखें। माइग्रेशन से पहले और बाद में स्कैन की गई फाइलों, स्कैन किए गए बाइट्स, p50/p95 लेटेंसी, विफलता दर, राइट थ्रूपुट और प्रति-क्वेरी लागत की तुलना करें। एक उदाहरण स्वीकृति मानदंड में 30% कम स्कैन किए गए बाइट्स, 20% कम p95, और 10% से अधिक राइट लागत में वृद्धि न होना शामिल हो सकता है; ये प्रोजेक्ट उदाहरण हैं और इन्हें बेसलाइन के अनुसार ट्यून किया जाना चाहिए। समय-सीमा क्वेरीज़, क्रॉस-टेनेंट क्वेरीज़, बैकफ़िल और समवर्ती ऑप्टिमाइज़ेशन का भी परीक्षण करें ताकि कोई एक पथ रिग्रेशन को न छिपाए।

6. रोलबैक, गवर्नेंस और निरंतर निगरानी जोड़ें

एक मूल स्नैपशॉट या शैडो टेबल रखें, पहले कम ट्रैफ़िक पर रीड्स को स्विच करें, और धीरे-धीरे विस्तार करें। क्लस्टरिंग कॉलम, वर्ज़न, ऑप्टिमाइज़ेशन बैच और मेट्रिक्स रिकॉर्ड करें, और पुराने क्लाइंट्स के लिए कम्पैटिबिलिटी जांच लागू करें। यदि p95, राइट लेटेंसी, या लागत बार-बार एक सीमा को पार करती है, तो विस्तार रोकें, रीड रूट को पुनर्स्थापित करें, और नए-लेआउट मेंटेनेंस को रोकें। रोलबैक के बाद, तुरंत दूसरा कॉलम सेट आज़माने के बजाय प्रेडिकेट्स और तिरछेपन (skew) पर फिर से विचार करें।

एक संपूर्ण और सशक्त उत्तर

मैं क्वेरी-लॉग बेसलाइन स्थापित करूंगा और सत्यापित करूंगा कि tenant_id और समय फ़िल्टर वास्तव में स्कैनिंग पर हावी हैं, फिर शैडो टेबल पर दो या तीन क्लस्टरिंग-कॉलम संयोजनों को रीप्ले करूंगा। रोलआउट से पहले मैं Delta/Spark वर्ज़न, प्रोटोकॉल व्यवहार, स्ट्रीमिंग रीड्स और राइट्स, और पुराने क्लाइंट्स की जांच करूंगा क्योंकि Liquid Clustering पार्टिशनिंग और Z-Ordering के साथ जुड़ने के बजाय उन्हें रिप्लेस करता है और अधिकतम चार कॉलम का समर्थन करता है। मैं पहले नए डेटा को माइग्रेट करूंगा और इंक्रीमेंटल OPTIMIZE चलाऊंगा; यदि ऐतिहासिक फाइलें अभी भी स्कैन बढ़ाती हैं, तो मैं कम ट्रैफ़िक विंडो के दौरान OPTIMIZE FULL शेड्यूल करूंगा। मैं स्नैपशॉट, एक पॉज़ स्विच और रीड-रूट फ़ॉलबैक बनाए रखते हुए स्कैन किए गए बाइट्स, फाइल काउंट, p95, लागत, राइट थ्रूपुट और विफलता दर पर रोलआउट को नियंत्रित करूंगा। मैं दो अवलोकन विंडो बीतने के बाद ही विस्तार करूंगा, किसी भी उल्लंघन पर रोक लगाऊंगा और समीक्षा करूंगा।

सामान्य विफलता मोड

• बिना किसी क्वेरी बेसलाइन या नियंत्रण समूह के केवल यह रटना कि "Liquid Clustering तेज़ है"।
• पार्टिशनिंग और Z-Ordering के साथ इसकी असंगति की अनदेखी करना जबकि पुराने जॉब्स चलते रहते हैं।
• यह मान लेना कि क्लस्टरिंग-कॉलम परिवर्तन तुरंत सभी ऐतिहासिक डेटा को फिर से लिख देता है, जिसमें कोई इंक्रीमेंटल या पूर्ण ऑप्टिमाइज़ेशन योजना नहीं होती है।
• स्कैन किए गए बाइट्स, p95, राइट लागत और डेटा के तिरछेपन की अनदेखी करते हुए केवल औसत लेटेंसी की रिपोर्ट करना।
• वर्ज़न, प्रोटोकॉल, पुराने क्लाइंट और रोलबैक जांच के बिना इसे प्रोडक्शन टेबल पर सक्षम करना।

फॉलो-अप और विस्तार

फॉलो-अप 1: परिभाषा में सभी चार सामान्य कॉलम क्यों नहीं शामिल किए जाते?

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

फॉलो-अप 2: मौजूदा डेटा में सुधार होने में कितना समय लगेगा?

एक निश्चित समय का वादा न करें। कॉलम बदलने पर मौजूदा डेटा अपने आप फिर से नहीं लिखा जाता है; इसका उत्तर इंक्रीमेंटल OPTIMIZE कवरेज पर निर्भर करता है। यदि ऐतिहासिक डेटा हावी है, तो OPTIMIZE FULL की विंडो और लागत का मूल्यांकन करें।

फॉलो-अप 3: आप अत्यधिक टेनेंट तिरछेपन (skew) को कैसे संभालते हैं?

टेनेंट टियर द्वारा वर्कलोड को रीप्ले करें और बड़े-टेनेंट, छोटे-टेनेंट और क्रॉस-टेनेंट क्वेरीज़ की अलग-अलग तुलना करें। आवश्यकता पड़ने पर कॉलम सेट या क्वेरी रूटिंग को समायोजित करें, और समग्र औसत के बजाय सबसे खराब पर्सेंटाइल को मानदंड के रूप में उपयोग करें।

फॉलो-अप 4: कौन से संकेत आपको माइग्रेशन रोकने के लिए कहते हैं?

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