प्रॉम्प्ट और संदर्भ
BigQuery चेंज डेटा कैप्चर (CDC) टेबल के कॉन्फ़िगर किए गए max_staleness के भीतर, एक डैशबोर्ड सामान्य लेटेंसी पर अनुमत पुरानी बेसलाइन को पढ़ सकता है। एक बार जब लंबित परिवर्तन उस विंडो से अधिक पुराने हो जाते हैं, तो क्वेरी-टाइम मर्ज उच्च लेटेंसी पर वर्तमान परिणाम लौटा सकता है। कार्य इन स्थितियों और बैकग्राउंड अप्लाई बैकलॉग को प्लेटफ़ॉर्म के अपने वॉटरमार्क और जॉब मेट्रिक्स के साथ अलग करना है।
इंटरव्यूअर क्या मूल्यांकन करता है
upsert_stream_apply_watermarkके साथ लागू की गई प्रगति को मापना।- अनुमत पुरानेपन (staleness), बैकग्राउंड अप्लाई बैकलॉग और रनटाइम मर्ज को अलग करना।
- अपर्याप्त बैकग्राउंड क्षमता को उपयोगकर्ता क्वेरी लेटेंसी से जोड़ना।
- केवल एक नॉइज़ी सैंपल के बजाय व्यावसायिक थ्रेशोल्ड और अवधि पर अलर्ट करना।
उत्तर देने से पहले स्पष्टीकरण
व्यावसायिक सहनशीलता, प्रत्येक टेबल का max_staleness, राइट पीक्स, बैकग्राउंड रिज़र्वेशन और डैशबोर्ड फ़्रीक्वेंसी स्थापित करें। इसमें एक विलोपन (deletion) उद्देश्य शामिल करें क्योंकि CDC डिलीट केवल तभी लागू होता है जब वॉटरमार्क इसके राइट टाइम को पार कर जाता है।
30-सेकंड का उत्तर ढांचा
INFORMATION_SCHEMA.TABLES.upsert_stream_apply_watermark को पोल करें और टेबल कॉन्फ़िगरेशन और व्यावसायिक थ्रेशोल्ड दोनों के साथ now - watermark की तुलना करें। इसे बैकग्राउंड अप्लाई P95, कतारबद्ध होने (queueing) और विफलता के साथ-साथ रनटाइम-मर्ज काउंट और क्वेरी लेटेंसी के साथ सहसंबंधित करें। केवल तभी पेज करें जब निरंतर वॉटरमार्क उल्लंघन संसाधन संतृप्ति (saturation) या उपयोगकर्ता प्रभाव के साथ जुड़ता है।
चरण-दर-चरण विस्तृत विश्लेषण
प्रति डेटा उत्पाद निम्न-कार्डिनैलिटी मेट्रिक्स बनाएं: वॉटरमार्क आयु, max_staleness, बैकग्राउंड अप्लाई P95, विफलताएं, और रनटाइम-मर्ज क्वेरी। कॉन्फ़िगर की गई विंडो के भीतर, एक क्वेरी बेसलाइन पढ़ सकती है। इसके बाहर, BigQuery क्वेरी समय पर लंबित परिवर्तनों को मर्ज कर सकता है, जिससे लेटेंसी बढ़ जाती है; वह रनटाइम मर्ज वॉटरमार्क को आगे नहीं बढ़ाता है।
दो द्वारों (gates) का उपयोग करें: लगातार दो व्यावसायिक-थ्रेशोल्ड उल्लंघन एक चेतावनी बनाते हैं; रिज़र्वेशन संतृप्ति, अप्लाई टाइमआउट, या डैशबोर्ड लेटेंसी इसे पेज में पदोन्नत करती है। एक स्रोत हार्टबीट बिना किसी नए डेटा को अप्लाई बैकलॉग से अलग करती है।
क्रमशः राइट्स, बैकग्राउंड जॉब्स, क्षमता और रनटाइम मर्ज का निदान करें। फिर बैकग्राउंड क्षमता जोड़ें, इनपुट को सुचारू करें, या विंडो पर फिर से विचार करें। केवल अलर्ट को शांत करने के लिए व्यावसायिक उद्देश्य को कमजोर न करें।
मजबूत नमूना उत्तर
लागू किया गया वॉटरमार्क मेरा प्राथमिक सिग्नल है; अप्लाई जॉब्स और क्वेरी मर्ज इसे स्पष्ट करते हैं। प्रत्येक मिनट मैं वॉटरमार्क आयु की तुलना SLO और टेबल विकल्प से करता हूँ, फिर अप्लाई P95, क्षमता और क्वेरी टेल लेटेंसी को सहसंबंधित करता हूँ।
पुनर्प्राप्ति के लिए वॉटरमार्क को पकड़ने (catch up), रनटाइम मर्ज के गिरने और डैशबोर्ड लेटेंसी को सामान्य होने की आवश्यकता होती है। एक पीक-लोड रीप्ले अतिरिक्त हेडरूम को साबित करता है।
सामान्य गलतियाँ
- केवल सफल राइट्स या ग्रीन पाइपलाइन जॉब्स की निगरानी करना।
- इवेंट टाइम को BigQuery के लागू वॉटरमार्क के रूप में मानना।
- यह मान लेना कि रनटाइम मर्ज वॉटरमार्क को आगे बढ़ाता है।
- केवल अलर्ट हटाने के लिए
max_stalenessबढ़ाना। - स्रोत हार्टबीट की कमी होना।
फॉलो-अप प्रश्न
रनटाइम मर्ज किसी क्वेरी को धीमा क्यों कर सकता है?
क्वेरी वर्तमान परिणाम वापस करने के लिए बेसलाइन डेटा को लंबित संशोधनों के साथ मर्ज करती है, जिससे अतिरिक्त समय और कंप्यूट की खपत होती है।
क्या होगा यदि वॉटरमार्क शून्य (null) है?
CDC कॉन्फ़िगरेशन, हाल के म्यूटेशन और बैकग्राउंड जॉब्स की जाँच करें। अज्ञात को उसकी अपनी स्थिति के रूप में मानें, न कि शून्य अंतराल (lag) के रूप में।
CDC डिलीट कब लागू किया जाता है?
केवल तभी जब upsert_stream_apply_watermark उस टाइमस्टैम्प को पार कर जाता है जिस पर डिलीट को स्ट्रीम किया गया था।
आप कैसे साबित करते हैं कि स्केलिंग ने काम किया?
प्रतिनिधि पीक लोड के तहत, बेहतर अप्लाई P95, वॉटरमार्क आयु, रनटाइम-मर्ज काउंट और डैशबोर्ड टेल लेटेंसी की एक साथ आवश्यकता होती है।