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

डेटा इंटरव्यू: आप ClickHouse Refreshable Materialized View को कैसे डिज़ाइन करेंगे?

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

प्रश्न

एक एनालिटिक्स प्लेटफॉर्म को जटिल जॉइन्स और एग्रीगेट्स को समय-समय पर एक क्वेरी टेबल में मटेरियलाइज़ करना होगा। ClickHouse के इंक्रीमेंटल और Refreshable Materialized Views की तुलना करें, फिर कैडेंस, रिकवरी, डिपेंडेंसी, एटॉमिक अपडेट्स, APPEND स्नैपशॉट्स और मॉनिटरिंग को डिज़ाइन करें।

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

एक एनालिटिक्स प्लेटफॉर्म लगातार डिटेल टेबल्स को अपडेट करता है, जबकि क्वेरीज़ को जटिल जॉइन्स, डीनॉर्मलाइज़ेशन और आवधिक एग्रीगेट्स की आवश्यकता होती है। टीम हर घंटे या मिनट में परिणामों की पुनर्गणना करना चाहती है और क्वेरीज़ को टारगेट टेबल पढ़ने देना चाहती है; कुछ कंज्यूमर्स को प्रत्येक रीफ्रेश एक स्नैपशॉट के रूप में भी चाहिए। ClickHouse Refreshable Materialized Views, उनकी सीमाओं और परिचालन गारंटियों की व्याख्या करें।

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

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

एक मजबूत उत्तर यह समझाता है कि Refreshable View समय-समय पर पूरे डेटासेट पर एक क्वेरी चलाता है और अपने परिणाम को टारगेट टेबल में लिखता है। यह जटिल जॉइन्स या गैर-रीयल-टाइम अपडेट्स के लिए उपयुक्त है, जबकि इंक्रीमेंटल व्यूज आमतौर पर ब्लॉक-लेवल एग्रीगेशन के लिए उपयुक्त होते हैं। एटॉमिक रिप्लेसमेंट, APPEND स्नैपशॉट्स, डिपेंडेंसी क्रम, मैन्युअल रीफ्रेश, system.view_refreshes, रिसोर्स आइसोलेशन और फ्रेशनेस अलर्ट्स को कवर करें।

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

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

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

"मैं पहले यह परीक्षण करूँगा कि क्या क्वेरी इंक्रीमेंटल रूप से मेंटेन करने योग्य है: सिंगल-टेबल एग्रीगेट के लिए एक इंक्रीमेंटल व्यू का उपयोग करें, और जटिल जॉइन्स, डीनॉर्मलाइज़ेशन या कम-आवृत्ति वाले अपडेट्स के लिए Refreshable View का उपयोग करें। एक निश्चित अंतराल पर टारगेट टेबल में रीफ्रेश करें, विफलता पर अंतिम सफल परिणाम बनाए रखें, और जब स्नैपशॉट की आवश्यकता हो तो APPEND का उपयोग करें। मैं केवल क्वेरी गति को मापने के बजाय डिपेंडेंसी, मैन्युअल रीफ्रेश, सिस्टम-टेबल मॉनिटरिंग, रिसोर्स आइसोलेशन और फ्रेशनेस अलर्ट्स जोड़ूँगा।"

चरण-दर-चरण समाधान

चरण 1: इंक्रीमेंटल और फुल-रीफ्रेश मॉडल को अलग करें

एक इंक्रीमेंटल व्यू आंशिक परिणामों की गणना करता है जैसे ही इन्सर्ट किए गए ब्लॉक्स आते हैं और यह मर्ज करने योग्य एग्रीगेट्स के लिए उपयुक्त है। एक Refreshable View समय-समय पर पूरे डेटासेट को स्कैन करता है और जटिल जॉइन्स, डीनॉर्मलाइज़ेशन या गैर-रीयल-टाइम रीबिल्ड के लिए उपयुक्त है। इसकी लागत सोर्स साइज़ के साथ बढ़ती है, इसलिए पहले इसका बजट तय करें।

चरण 2: रीफ्रेश और टारगेट टेबल को परिभाषित करें

कैडेंस और टारगेट सेट करने के लिए क्रिएशन के समय REFRESH EVERY का उपयोग करें। क्वेरी तुरंत चलती है और फिर शेड्यूल पर; टारगेट में पढ़ने और क्लीनअप के लिए एक स्पष्ट सॉर्ट की, पार्टिशनिंग और वर्ज़न कॉलम होना चाहिए।

sql
CREATE MATERIALIZED VIEW actor_summary_mv
REFRESH EVERY 1 MINUTE TO actor_summary AS
SELECT actor_id, count() AS movies, max(updated_at) AS updated_at
FROM actor_movies
GROUP BY actor_id;

चरण 3: एटॉमिक अपडेट सिमेंटिक्स को परिभाषित करें

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

चरण 4: APPEND स्नैपशॉट चुनें

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

चरण 5: डिपेंडेंसी और विफलता को संभालें

एक Refreshable View दूसरे व्यू पर निर्भर हो सकता है और अपस्ट्रीम के पूरा होने के बाद ही चल सकता है। विफलता पर, अंतिम अच्छा परिणाम बनाए रखें, कारण रिकॉर्ड करें और पुनः प्रयास शेड्यूल करें; कभी भी एक धीमी क्वेरी को पूरे DAG को हमेशा के लिए ब्लॉक न करने दें या चुपचाप पुराना डेटा प्रकाशित न करने दें।

चरण 6: संसाधन और कॉनकरेंसी को नियंत्रित करें

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

चरण 7: मॉनिटरिंग और ऑपरेशन्स जोड़ें

स्थिति, अंतिम सफलता, अंतिम और अगला रीफ्रेश, पढ़ी और लिखी गई पंक्तियों और लेटेंसी के लिए system.view_refreshes को क्वेरी करें। नियंत्रित मैन्युअल रन के लिए SYSTEM REFRESH VIEW को प्रदर्शित करें, कैडेंस परिवर्तनों को सत्यापित करें, और बार-बार होने वाली विफलताओं, फ्रेशनेस उल्लंघनों और राइट एम्प्लीफिकेशन पर अलर्ट करें।

चरण 8: डेटा और विफलता के मामलों को मान्य करें

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

ट्रेड-ऑफ और सीमाएं

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

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

रोलआउट योजना और प्रमाण

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

कैडेंस, डिपेंडेंसी, टारगेट सॉर्टिंग, रिसोर्स पूल, रिटेंशन, मैन्युअल रीफ्रेश और अलर्ट थ्रेशोल्ड को दस्तावेज़ित करें। केवल टास्क स्थिति के बजाय system.view_refreshes और रिज़ल्ट वॉटरमार्क को रिलीज़ गेट्स के रूप में उपयोग करें।

सामान्य गलतियाँ और फॉलो-अप्स

प्रत्येक इंक्रीमेंटल व्यू को Refreshable View से बदलना

सिंगल-टेबल एग्रीगेट्स आमतौर पर इंक्रीमेंटल मेंटेनेंस के लिए उपयुक्त होते हैं। फुल स्कैन स्वीकार करने से पहले यह साबित करें कि लॉजिक को इंक्रीमेंटल रूप से मेंटेन नहीं किया जा सकता है।

रीफ्रेश विफल होने के बाद टारगेट को खाली करना

अंतिम सफल परिणाम को बनाए रखें और इसकी फ्रेशनेस को चिह्नित करें ताकि रीडर्स को खाली टेबल न दिखाई दे। कारण ठीक होने के बाद पुनः प्रयास करें।

बिना स्नैपशॉट की के APPEND का उपयोग करना

जनरेशन टाइम, वर्ज़न और डिडुप्लीकेशन के बिना, बार-बार रीफ्रेश अस्पष्ट होते हैं। स्नैपशॉट मेटाडेटा और रिटेंशन को टेबल डिज़ाइन का हिस्सा बनाएं।

शेड्यूल टाइम देखना लेकिन डेटा वॉटरमार्क को नहीं

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

क्या होगा यदि रीफ्रेश लगातार धीमा होता जाए?

जॉइन्स, पार्टिशन प्रूनिंग, सॉर्ट कीज़, रिसोर्स कन्टेन्शन और ग्रोथ का निरीक्षण करें; केवल अंतराल को छोटा करने के बजाय प्री-एग्रीगेशन, डिपेंडेंसी स्प्लिट्स या इंक्रीमेंटल व्यूज का मूल्यांकन करें।

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

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