डेटा इंजीनियरिंग साक्षात्कार: BigQuery Graph को Recursive SQL की जगह कब लेना चाहिए?

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

एक रिलेशनल डेटासेट में ग्राहक, खाते और ट्रांसफ़र शामिल हैं। साक्षात्कारकर्ता पूछता है कि BigQuery Graph बनाम रिकर्सिव SQL का उपयोग कब किया जाए और एक ऐसा माइग्रेशन और रोलबैक प्लान कैसे डिज़ाइन किया जाए जिसे सत्यापित किया जा सके।

यह डेटा इंजीनियरिंग, एनालिटिक्स इंजीनियरिंग और डेटा प्लेटफ़ॉर्म भूमिकाओं के लिए लक्षित है। मान लें कि डेटा पहले से ही BigQuery में मौजूद है और ग्राफ़ क्षमता अभी भी प्रिव्यू (Preview) में है; Preview को बिना शर्त प्रोडक्शन का वादा न मानें। कार्य संबंध अभिव्यक्ति (relationship expression), गवर्नेंस, लागत और कम्पैटिबिलिटी की तुलना करना है, न कि यह दावा करना कि एक क्वेरी लैंग्वेज हमेशा तेज़ होती है।

साक्षात्कारकर्ता क्या मूल्यांकन करता है

साक्षात्कारकर्ता यह देखना चाहता है कि क्या आप ग्राफ़ या रिलेशनल मॉडल चुनने से पहले क्वेरी के आकार (query shape) को वर्गीकृत करते हैं, और क्या आप व्यावसायिक सिमेंटिक्स (business semantics), निष्पादन योजनाओं (execution plans) और प्लेटफ़ॉर्म लाइफ़साइकिल को अलग करते हैं। एक मजबूत उत्तर यह बताता है कि एक ग्राफ़ मॉडल मौजूदा तालिकाओं के साथ कैसे सह-अस्तित्व में रहता है, रिकर्सिव SQL कब सरल होता है, और एक ही बेंचमार्क डेटा माइग्रेशन को कैसे मान्य करता है।

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

क्या ट्रैवर्सल निश्चित गहराई (fixed-depth) का है, या गहराई और पाथ प्रेडिकेट्स बार-बार बदलते हैं?
क्या परिणाम में नोड्स, एजेस और पाथ्स लौटने चाहिए, या केवल एग्रीगेटेड मेट्रिक्स?
क्या यह बैच एनालिटिक्स है या कम विलंबता वाला (low-latency) ऑनलाइन ट्रैवर्सल?
क्या परिणामों का मौजूदा SQL रिपोर्टों से पंक्ति-दर-पंक्ति मिलान होना चाहिए, और Preview कम्पैटिबिलिटी विंडो कब तक है?
बजट, स्कैन वॉल्यूम, कॉनक्रेन्सी, फ्रेशनेस और डाउनस्ट्रीम-क्लाइंट की सीमाएं क्या हैं?

तीस-सेकंड उत्तर ढांचा

“मैं पहले क्वेरी के आकार और डिलीवरी लक्ष्य के आधार पर रूट तय करता हूं। मैं निश्चित एक या दो-हॉप ट्रैवर्सल, सरल एग्रीगेट्स और मूल्यवान मौजूदा SQL संपत्तियों के लिए SQL रखता हूं; जब मल्टी-हॉप पैटर्न, पाथ प्रेडिकेट्स और रिलेशनशिप का पुन: उपयोग बार-बार होता है, तो मैं BigQuery Graph का मूल्यांकन करता हूं। मैं नोड्स, एजेस, लेबल्स और कीज़ को परिभाषित करता हूं, फिर परिणामों, बाइट्स, लेटेंसी और लागत के लिए समान स्नैपशॉट पर GQL और रिकर्सिव SQL की तुलना करता हूं। चूंकि Graph अभी Preview में है, इसलिए SQL प्राथमिक पथ बना रहता है जबकि Graph शैडो मोड में चलता है जब तक कि गेट्स पास न हो जाएं।”

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

1. रिलेशनल प्रश्न को ग्राफ़ में अनुवाद करें

Person और Account को नोड्स के रूप में और Owns और Transfers को निर्देशित किनारों (directed edges) के रूप में मॉडल करें, जिसमें प्रत्येक किनारे पर समय, राशि और स्थिर पहचानकर्ता (stable identifiers) हों। “तीन हॉप्स के भीतर पहुंचने योग्य खाते ढूंढें और जोखिम का एग्रीगेशन करें” स्वाभाविक रूप से एक पाथ क्वेरी है; “दिन के अनुसार ट्रांसफ़र राशियों का योग करें” को रिलेशनल एग्रीगेशन के रूप में ऑडिट करना आसान है। मॉडल को प्रश्न का अनुसरण करना चाहिए, न कि फीचर की नवीनता का।

2. क्वेरी के आकार से रूट चुनें

निश्चित गहराई, निश्चित कॉलम और केवल-मीट्रिक आउटपुट के लिए, रिकर्सिव SQL अक्सर पठनीयता और मौजूदा एक्सेस कंट्रोल के मामले में बेहतर साबित होता है। परिवर्तनीय गहराई, पुन: प्रयोज्य पाथ पैटर्न और नोड्स तथा एजेस वाले परिणामों के लिए, GQL निर्माण जैसे GRAPH, MATCH, NEXT, और RETURN संबंध के करीब के इरादे को व्यक्त करते हैं। यह निर्णय बदलाव की आवृत्ति और रखरखाव लागत के बारे में है, न कि SQL को पूरी तरह से बदलने के बारे में।

3. सिमेंटिक सीमाओं को मॉडल और लॉक करें

लेबल्स, दिशा, अशक्त होने योग्य गुण (nullable properties), वैधता समय और डुप्लिकेट-एज हैंडलिंग को परिभाषित करें। प्रत्येक व्यावसायिक संबंध को एक कुंजी (key) दें ताकि बार-बार लोड होने से पाथ की संख्या न बढ़े। असीमित चक्र (unbounded cycle) को रोकने के लिए परिभाषित करें कि क्या ट्रैवर्सल किसी नोड पर दोबारा जा सकता है। ग्राफ़ सिंटैक्स संबंधों को व्यक्त करता है; डेटासेट अनुमतियां, कॉलम नीतियां और ऑडिट अभी भी संवेदनशील फ़ील्ड की सुरक्षा करते हैं।

4. एक पुनरुत्पादक (reproducible) डुअल-रन बेंचमार्क बनाएं

प्रतिनिधि स्नैपशॉट और क्वेरी परिवारों का उपयोग करें: वन-हॉप नेबर्स, टू-हॉप ट्रांसफ़र, समय-बद्ध पाथ, डुप्लिकेट एजेस और खाली परिणाम। सेट्स और काउंट्स की तुलना करने से पहले रिकर्सिव SQL और GQL दोनों को नोड आईडी, एज आईडी, पाथ की लंबाई और एग्रीगेट्स में प्रोजेक्ट करें। प्रोसेस किए गए बाइट्स, स्लॉट उपयोग, p50/p95 लेटेंसी, विफलताओं और फ्रेशनेस को रिकॉर्ड करें; एक बार का वॉल-क्लॉक नमूना कोई प्रमाण नहीं है।

text

snapshot = freeze_partition(as_of)
expected = run_recursive_sql(snapshot, query_family)
candidate = run_gql_graph(snapshot, query_family)
assert canonicalize(expected) == canonicalize(candidate)
gate = error_rate < 0.01 and p95_ms <= budget and cost_per_query <= limit

5. Graph और SQL को इंटरऑपरेबल रखें

जब रिपोर्टों को अभी भी सारणीबद्ध (tabular) इनपुट की आवश्यकता होती है, तो ग्राफ़ परिणामों को एक तालिका में प्रोजेक्ट करें और उन्हें SQL एग्रीगेट्स या डायमेंशन्स के साथ जोड़ें। जब दोनों पथ समान संबंधों का उपयोग करते हैं, तो नोड्स और एजेस की नकल करने से बचें। Google के दस्तावेज़ GRAPH_TABLE के माध्यम से ग्राफ़ क्वेरीज़ को SQL के साथ संयोजित करने का वर्णन करते हैं, इसलिए प्रत्येक पाइपलाइन को फिर से लिखने के बजाय माइग्रेशन को क्वेरी परिवार द्वारा विभाजित किया जा सकता है।

6. Preview जोखिम और रोलबैक का मूल्य निर्धारण करें

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

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

मैं क्वेरी के आकार से शुरुआत करूंगा। निश्चित गहराई, निश्चित कॉलम और सरल एग्रीगेट्स वाली रिपोर्टें Preview निर्भरता और माइग्रेशन लागत को सीमित करने के लिए रिकर्सिव SQL पर ही रहेंगी। मैं परिवर्तनीय गहराई, पुन: प्रयोज्य पाथ पैटर्न और नोड-एंड-एज आउटपुट के साथ खोजपूर्ण विश्लेषण के लिए BigQuery Graph का मूल्यांकन करूंगा। मैं ग्राहकों और खातों को नोड्स के रूप में, स्वामित्व और ट्रांसफ़र को निर्देशित किनारों के रूप में मॉडल करूंगा, और कीज़, दिशा, वैधता समय और चक्र नियमों को लॉक करूंगा। माइग्रेशन समान स्नैपशॉट पर दोनों पथों को डुअल-रन करेगा, आउटपुट को समान नोड्स, एजेस, पाथ लंबाई और मेट्रिक्स में कैनोनिकलाइज़ करेगा, फिर परिणाम, बाइट्स, p95, विफलताओं और लागत की तुलना करेगा। Graph शैडो मोड में चलने के दौरान SQL प्राथमिक बना रहता है। कोई Preview क्षेत्र, कोटा, या संस्करण परिवर्तन—या कोई विफल गेट—वापस SQL पर रूट करता है। यह केवल यह दावा करने के बजाय कि ग्राफ़ क्वेरी तेज़ हैं, अभिव्यक्ति, गवर्नेंस, लागत और रोलबैक को कवर करता है।

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

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

अनुवर्ती प्रश्न और उत्तर

यदि गहराई दो हॉप्स से मनमानी गहराई (arbitrary depth) तक बढ़ जाती है तो क्या बदलता है?

निर्णय बदल सकता है। मनमानी गहराई और पाथ प्रेडिकेट्स रिकर्सिव SQL रखरखाव और संसाधन जोखिमों को बढ़ाते हैं, इसलिए Graph की पाथ अभिव्यक्ति अधिक आकर्षक हो जाती है। फिर भी एक अधिकतम गहराई, नोड-विज़िट सीमा और लागत गेट निर्धारित करें; कभी भी असीमित ट्रैवर्सल स्वीकार न करें।

यदि व्यवसाय को एक सेकंड के भीतर ऑनलाइन परिणाम की आवश्यकता हो तो क्या होगा?

पहले जांचें कि क्या बैच BigQuery एनालिटिक्स लेटेंसी लक्ष्य को पूरा करता है। यदि नहीं, तो एक ऑनलाइन ग्राफ़ स्टोर या प्रीकंप्यूटेड इंडेक्स बनाए रखें और बैच सत्यापन तथा इतिहास के लिए BigQuery Graph का उपयोग करें। भाषा की एकरूपता के लिए ऑनलाइन SLO का त्याग न करें।

आप कैसे साबित करते हैं कि GQL और रिकर्सिव SQL समकक्ष हैं?

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

SQL फ़ॉलबैक को कब हटाया जा सकता है?

केवल Preview स्थिति, क्षेत्रों और क्लाइंट कम्पैटिबिलिटी के स्थिर होने के बाद और डेटा स्वामी के अनुमोदन के साथ कई डेटा चक्र परिणाम, लागत, लेटेंसी, अनुमति और विफलता-अभ्यास (failure-drill) गेट्स को पास कर लेते हैं। अन्यथा SQL बनाए रखें।

जब ग्राफ़ संबंध संवेदनशील हों तो अनुमतियाँ कैसे काम करनी चाहिए?

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