प्रॉम्प्ट और दायरा
व्यवसाय चाहता है कि BigQuery में लिखा गया डेटा तुरंत अलर्ट ट्रिगर करे और परिणामों को किसी टेबल, Pub/Sub, Bigtable या Spanner में भेजे। स्पष्ट करें कि क्या BigQuery continuous queries का उपयोग करना चाहिए और आप इनपुट सिमेंटिक्स, ऑथराइजेशन, रनटाइम, क्षेत्रों (regions), लागत और रिकवरी को कैसे संभालेंगे। उत्तर को केवल SQL सिंटैक्स तक सीमित न रखें।
साक्षात्कारकर्ता क्या जांच रहा है
- क्या आप continuous query को निश्चित अंतराल पर होने वाली पोलिंग के बजाय निरंतर चलने वाले SQL के रूप में समझते हैं।
- क्या आप लेटेंसी और डेटा सिमेंटिक्स के आधार पर इसे Dataflow, Pub/Sub और सामान्य प्रश्नों की तुलना में सही स्थान पर रख सकते हैं।
- क्या आप Enterprise संस्करण,
CONTINUOUSरिज़र्वेशन, सर्विस अकाउंट और क्षेत्रीय सीमाओं की पुष्टि करते हैं। - क्या आप डुप्लिकेट आउटपुट, बैकप्रेशर, मॉनिटरिंग, रीस्टार्ट व्यवहार और लागत का समाधान करते हैं।
स्पष्टीकरण के लिए प्रश्न
- क्या इनपुट केवल अपेंड-ओनली (append-only) है, या मौजूदा पंक्तियों को अपडेट और डिलीट किया जा सकता है? क्या डुप्लिकेट स्वीकार्य हैं?
- क्या गंतव्य BigQuery, Pub/Sub, Bigtable या Spanner है, और क्या उपभोक्ता सुरक्षित रूप से पुनः प्रयास (retry) कर सकते हैं?
- किन लेटेंसी, रनटाइम और डेटा-क्षेत्र गारंटियों की आवश्यकता है? क्या प्रोजेक्ट उनके लिए प्रोविज़न किया गया है?
- विफलता के बाद, प्रोसेसिंग कहाँ से फिर से शुरू होती है, और लैग (lag), त्रुटियों और आउटपुट वॉल्यूम की निगरानी कैसे की जाती है?
30-सेकंड का उत्तर
मैं पहले यह सत्यापित करूँगा कि आवश्यकता वास्तव में निरंतर प्रोसेसिंग की है या नहीं। Continuous queries आने वाले BigQuery डेटा का विश्लेषण करती हैं और परिणाम लिखती या निर्यात करती हैं, लेकिन उनके संस्करण, क्षमता, ऑथराइजेशन और क्षेत्रीय सीमाएं होती हैं। आइडमपोटेंसी (idempotency) कुंजियाँ परिभाषित करें, गंतव्य चुनें, और एक सर्विस अकाउंट, एक CONTINUOUS रिज़र्वेशन और मॉनिटरिंग तैयार करें। नियंत्रित ट्रैफ़िक के साथ लेटेंसी, डुप्लिकेट, लागत, स्टॉप और रिकवरी को सत्यापित करें; इस सुविधा को Cron के असीमित, मुफ़्त विकल्प के रूप में न समझें।
चरण-दर-चरण डिज़ाइन
1. पहले डेटा सिमेंटिक्स को परिभाषित करें
एक continuous query BigQuery तालिकाओं में लिखे जा रहे डेटा को प्रोसेस करना जारी रखती है। अपेंड्स, लेट इवेंट्स, अपडेट्स और डिलीट्स के अलग-अलग अर्थ होते हैं। यदि व्यवसाय को जटिल स्थिति (state), इवेंट-टाइम विंडो या सख्त क्रमबद्धता की आवश्यकता है, तो समर्थित SQL व्यवहार की पुष्टि करें और Dataflow जैसे स्ट्रीम प्रोसेसर से तुलना करें।
2. आउटपुट पथ चुनें
दस्तावेज़ीकरण परिणामों को BigQuery तालिका में सम्मिलित करने या Pub/Sub, Bigtable या Spanner में EXPORT DATA का उपयोग करने का समर्थन करता है। डाउनस्ट्रीम थ्रूपुट, ऑर्डरिंग, आइडमपोटेंसी और क्षेत्र के आधार पर चयन करें। Pub/Sub अन्य इवेंट-प्रोसेसिंग चरण के लिए उपयोगी है; सीधे तालिका में लिखने के लिए डीडुप्लिकेशन और रिटेंशन कुंजियों की आवश्यकता होती है।
3. रनटाइम और ऑथराइजेशन सीमाओं को सत्यापित करें
आप उपयोगकर्ता खाते या सर्विस अकाउंट के साथ continuous query बना और चला सकते हैं; Pub/Sub पर निर्यात करने के लिए सर्विस अकाउंट की आवश्यकता होती है। उपयोगकर्ता-खाते का जॉब दो दिनों तक चल सकता है, जबकि सर्विस-अकाउंट जॉब 150 दिनों तक चल सकता है। Continuous queries के लिए Enterprise या Enterprise Plus संस्करण और CONTINUOUS प्रकार का रिज़र्वेशन असाइनमेंट आवश्यक है।
4. बजट, मॉनिटर और रिकवर करें
Continuous queries BigQuery क्षमता कंप्यूट मूल्य निर्धारण का उपयोग करती हैं, जबकि प्राप्त करने वाली सेवाओं की लागत अलग होती है। क्वेरी-विशिष्ट मेट्रिक्स, इनपुट-टू-आउटपुट लेटेंसी, त्रुटियों, रीस्टार्ट और आउटपुट वॉल्यूम की निगरानी करें; स्टॉप, पुनर्निर्माण और अलर्ट प्रक्रियाओं को परिभाषित करें। एक आइडमपोटेंसी कुंजी या वॉटरमार्क से पुनर्प्राप्त करें और केवल एक स्वीकार्य सीमा को रीप्ले करें, ताकि रीस्टार्ट होने पर साइड इफेक्ट्स की पुनरावृत्ति न हो।
मॉडल उच्च-गुणवत्ता वाला उत्तर
मैं एक continuous query का मूल्यांकन डेटा-उत्पाद संचालन बाधा के रूप में करूँगा। यह BigQuery में लिखे गए डेटा का लगातार विश्लेषण कर सकता है और परिणामों को BigQuery, Pub/Sub, Bigtable या Spanner में लिख या निर्यात कर सकता है, लेकिन अपेंड-बनाम-परिवर्तन सिमेंटिक्स और डुप्लिकेट सहनशीलता यह निर्धारित करती है कि यह उपयुक्त है या नहीं। मैं Enterprise संस्करण, CONTINUOUS रिज़र्वेशन, सर्विस अकाउंट, अधिकतम रनटाइम और क्षेत्रीय सीमा की पुष्टि करूँगा। आउटपुट अनुबंध आइडमपोटेंसी, रीट्राई और डेड-लेटर हैंडलिंग को परिभाषित करेगा; टेलीमेट्री में लैग, बैकलॉग, त्रुटियां और लागत शामिल होगी। लॉन्च से पहले, नियंत्रित ट्रैफ़िक लेटेंसी और रीस्टार्ट व्यवहार का परीक्षण करेगा, जिसमें स्पष्ट पॉज़, रिज़्यूमे और बैकफ़िल प्रक्रियाएं होंगी। यदि वर्कलोड को समृद्ध इवेंट-टाइम स्थिति, सख्त क्रमबद्धता या लंबे समय तक चलने वाले टोपोलॉजी की आवश्यकता है, तो मैं प्रत्येक रीयल-टाइम आवश्यकता को BigQuery में जबरन लागू करने के बजाय एक समर्पित स्ट्रीम प्रोसेसर की तुलना करूँगा।
सामान्य गलतियाँ
- continuous query को ऐसी क्वेरी मानना जो प्रति मिनट एक बार चलती है।
- Enterprise या Enterprise Plus,
CONTINUOUSरिज़र्वेशन, या सर्विस-अकाउंट आवश्यकताओं की अनदेखी करना। - यह मान लेना कि प्रत्येक गंतव्य में समान ऑर्डरिंग और डुप्लिकेट सिमेंटिक्स हैं।
- रीस्टार्ट, डुप्लिकेट और देर से आने वाले डेटा के लिए वॉटरमार्क या आइडमपोटेंसी कुंजियों को छोड़ देना।
- BigQuery क्षमता और डाउनस्ट्रीम सेवाओं की लागत तय किए बिना केवल SQL लेटेंसी को मापना।
- दो-दिन या 150-दिन की रनटाइम सीमाओं को स्थायी निष्पादन के वादे के रूप में मानना।
अनुवर्ती प्रश्न और उत्तर
आप Dataflow को कब चुनेंगे?
जब वर्कलोड को जटिल इवेंट-टाइम विंडो, स्टेट मैनेजमेंट, सख्त ऑर्डरिंग, समृद्ध कनेक्टर या लंबे समय तक चलने वाली टोपोलॉजी की आवश्यकता हो, तो Dataflow या किसी अन्य स्ट्रीम प्रोसेसर से तुलना करें। यह सीमा सिमेंटिक और ऑपरेशनल है, SQL लाइनों की संख्या नहीं।
रीस्टार्ट के बाद आप डुप्लिकेट अलर्ट से कैसे बचते हैं?
प्रत्येक आउटपुट में एक इवेंट या व्यावसायिक आइडमपोटेंसी कुंजी डालें, डाउनस्ट्रीम को डीडुप्लिकेट या ट्रांसैक्ट करें, और एक वॉटरमार्क और प्रोसेसिंग बैच रिकॉर्ड करें। एक सुरक्षित रीप्ले सीमा से फिर से शुरू करें और उपभोक्ताओं के लिए किसी भी अपरिहार्य डुप्लिकेट व्यवहार को दस्तावेजित करें।
आप कैसे तय करते हैं कि लागत स्वीकार्य है या नहीं?
क्षमता स्लॉट, अंतर्ग्रहण (ingestion) और स्टोरेज, साथ ही Pub/Sub, Bigtable या Spanner शुल्क का अलग से अनुमान लगाएं। स्थिर स्थिति, निष्क्रिय अवधि और पीक लोड का परीक्षण करें, फिर देखी गई लेटेंसी और स्लॉट खपत के साथ बजट को कैलिब्रेट करें।