डेटा इंजीनियरिंग इंटरव्यू: आप एक गवर्न करने योग्य Arrow Flight SQL सर्विस को कैसे डिज़ाइन करेंगे?

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

कई एनालिटिक्स क्लाइंट्स को अलग-अलग SQL इंजनों तक पहुँचने की आवश्यकता होती है। मौजूदा JDBC/ODBC पाथ बड़े परिणामों के लिए रो-कॉलम कन्वर्जन और कनेक्शन-पूल पर दबाव डालते हैं, इसलिए टीम कॉलमर ट्रांसफर के लिए Arrow Flight SQL पर विचार कर रही है। SQL रिक्वेस्ट से लेकर Flight डेटा स्ट्रीम तक सर्विस को डिज़ाइन करें, जिसमें मेटाडेटा, रिजल्ट एंडपॉइंट्स, ऑथेंटिकेशन, बैकप्रेशर, कैंसिलेशन, ऑडिट और आइसोलेशन शामिल हों।

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

• क्या आप Flight RPC और Arrow मेमोरी फॉर्मेट के ऊपर Flight SQL की बाउंड्री को समझते हैं।
• क्या आप GetFlightInfo, GetSchema, DoGet, DoPut और DoAction के बीच अंतर कर सकते हैं।
• क्या आप क्वेरी हैंडल, रिजल्ट पार्टिशन, फ्लो कंट्रोल, कैंसिलेशन और री-ट्राई डिज़ाइन करते हैं।
• क्या आप SQL ऑथराइजेशन, टेनेंट रिसोर्सेज, संवेदनशील कॉलम और ऑडिट को संभालते हैं।
• क्या आप JDBC/ODBC एडॉप्टर्स, कैपेबिलिटी नेगोशिएशन और ऑब्ज़र्वेबिलिटी को समझा सकते हैं।

पहले स्पष्ट करने योग्य प्रश्न

1. क्या क्लाइंट मुख्य रूप से इंटरैक्टिव क्वेरीज़, बैच एक्सपोर्ट्स या स्ट्रीमिंग राइट्स हैं?
2. रिजल्ट साइज, कॉनकरेंट क्वेरीज़, टाइम-टू-फर्स्ट-बाइट और टेनेंट कोटा क्या हैं?
3. क्या सभी बैकएंड Arrow को नेटिव रूप से निष्पादित करते हैं, या गेटवे को परिणामों को कनवर्ट करना होगा?
4. क्या OAuth, mTLS, रो और कॉलम नीतियां, या क्रॉस-रीजन एक्सेस की आवश्यकता है?
5. कैंसिलेशन को किन डेटाबेस, मेमोरी और ऑब्जेक्ट-स्टोरेज रिसोर्सेज को वापस रिक्लेम करना चाहिए?

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

“मैं सर्विस को ऑथेंटिकेशन और टेनेंट पॉलिसी, SQL प्लानिंग, Flight SQL प्रोटोकॉल अडैप्टेशन और एक रिजल्ट-स्ट्रीम गेटवे में विभाजित करूँगा। क्लाइंट एक क्वेरी हैंडल और एंडपॉइंट्स के लिए GetFlightInfo को कॉल करता है, फिर Arrow RecordBatches को खींचने के लिए DoGet का उपयोग करता है; मेटाडेटा GetSchema का उपयोग करता है, जबकि राइट्स या पैरामीटराइज्ड एक्शन्स DoPut या Action सेमेंटिक्स का उपयोग करते हैं। गेटवे स्कैन्स, कॉनकरेंसी और रिटेंशन को सीमित करता है, डाउनस्ट्रीम बैकप्रेशर को एक्ज़ीक्यूशन तक पहुंचाता है, और कैंसिलेशन का समर्थन करता है। प्रत्येक हैंडल में पहचान, नीति, प्लान वर्ज़न और ऑडिट डेटा होता है; प्लानिंग के दौरान संवेदनशील कॉलम हटा दिए जाते हैं और कैपेबिलिटी नेगोशिएशन के माध्यम से इंजन के अंतर को उजागर किया जाता है।”

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

1. प्रोटोकॉल और निष्पादन सीमाओं को अलग करें

Flight SQL, SQL मेटाडेटा, क्वेरीज़ और प्रिपेयर्ड स्टेटमेंट्स के लिए Protobuf कमांड्स को परिभाषित करता है, जो GetFlightInfo, GetSchema और DoGet जैसे Flight RPCs का पुन: उपयोग करते हैं। गेटवे पहचान, नीति, लाइफसाइकिल और फ्लो कंट्रोल को संभालता है; एडॉप्टर्स एक लॉजिकल प्लान को इंजन SQL और Arrow बैचेस में ट्रांसलेट करते हैं।

2. क्वेरी लाइफसाइकिल डिज़ाइन करें

एक अनगुएसेबल (unguessable) क्वेरी हैंडल बनाने से पहले ऑथेंटिकेट करें और टेनेंट क्षमताओं का समाधान करें। GetFlightInfo स्कीमा, एंडपॉइंट्स और समाप्ति समय लौटाता है; DoGet उन एंडपॉइंट्स से RecordBatches को रीड करता है। प्लान्ड, रनिंग, ड्रेनिंग, कैंसल्ड, फेल्ड और एक्सपायर्ड स्टेट्स को ट्रैक करें ताकि री-ट्राई से डुप्लिकेट एक्ज़ीक्यूशन न बने।

{
  "queryHandle": "q_7f2a",
  "schemaVersion": 3,
  "endpoints": [{"ticket": "t_01", "location": "grpc://flight-2"}],
  "expiresAt": "2026-08-01T13:00:00Z",
  "cancelToken": "c_7f2a"
}

3. कॉलमर परिणाम और बैकप्रेशर को संभालें

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

4. कैंसिलेशन, विफलता और री-ट्राई डिज़ाइन करें

एक कैंसिलेशन टोकन को डेटाबेस कैंसिल, वर्कर स्ट्रीम्स और अस्थायी ऑब्जेक्ट-स्टोरेज फ़ाइलों से मैप करें। डिस्कनेक्ट होने के बाद, केवल हैंडल वाले इडेम्पोटेंट (idempotent) रीड्स ही अपुष्ट बैचेस का री-ट्राई कर सकते हैं; राइट्स के लिए स्पष्ट ट्रांजैक्शन या Action सेमेंटिक्स की आवश्यकता होती है, न कि अनुमानित दोहराए गए DoPut की। विफलता प्रतिक्रियाएं SQL या संवेदनशील डेटा के बिना वर्गीकृत स्थिति और ट्रेस आईडी को उजागर करती हैं।

5. ऑथराइजेशन और टेनेंट गवर्नेंस लागू करें

ऑथेंटिकेशन mTLS, OAuth या Flight ऑथराइजेशन हेडर का उपयोग कर सकता है, जिसमें क्रेडेंशियल्स केवल TLS पर भेजे जाते हैं। यूज़र्स, रोल्स और टेनेंट्स को डेटाबेस पहचान, अनुमत कैटलॉग, स्कीमा, टेबल्स, रो फिल्टर्स, कॉलम मास्क और रिसोर्स सीमाओं में मैप करें। प्लानिंग के दौरान कॉलम प्रूनिंग और पैरामीटर बाइंडिंग लागू करें; कभी भी यूजर SQL को एडमिनिस्ट्रेटर कनेक्शन में कॉन्केटनेटर न करें।

6. ऑब्ज़र्वेबिलिटी और कम्पैटिबिलिटी का निर्माण करें

क्वेरी हैंडल, टेनेंट, डेटाबेस, प्लान वर्ज़न, बैच काउंट, बाइट्स, फर्स्ट-बैच लेटेंसी, कैंसिल का कारण और पीक रिसोर्सेज को रिकॉर्ड करें। टेनेंट और इंजन द्वारा मेट्रिक्स को विभाजित करें, और कच्चे डेटा को लॉग से बाहर रखें। सेमेंटिक अंतरों का दस्तावेजीकरण करते हुए JDBC/ODBC ड्राइवर एडॉप्टर्स प्रदान करें; GetSqlInfo, GetCatalogs और संबंधित मेटाडेटा कॉल्स के माध्यम से समर्थन को उजागर करें।

एक मजबूत उत्तर का उदाहरण

“एक Flight SQL सर्विस SQL सेमेंटिक्स को Arrow कॉलमर स्ट्रीम्स के साथ जोड़ती है। क्लाइंट GetFlightInfo से स्कीमा, टिकट, एंडपॉइंट्स और एक्सपायरी प्राप्त करता है, फिर DoGet के साथ RecordBatches को पुल करता है। प्लानिंग के दौरान, गेटवे पहचान, टेनेंट, रो और कॉलम नीति, और रिसोर्स बजट लागू करता है। परिणाम स्ट्रीमिंग बने रहते हैं, और डाउनस्ट्रीम बैकप्रेशर एक्ज़ीक्यूशन तक पहुंचता है; धीमे क्लाइंट्स पॉज़ या स्पिल कर सकते हैं। कैंसिलेशन को डेटाबेस, वर्कर और अस्थायी फ़ाइलों को समाप्त करना चाहिए। इडेम्पोटेंट रीड हैंडल्स री-ट्राई कर सकते हैं, जबकि राइट्स के लिए स्पष्ट ट्रांजैक्शन सेमेंटिक्स की आवश्यकता होती है। प्रत्येक क्वेरी में ऑडिट और ट्रेस आईडी होते हैं, और कैपेबिलिटी नेगोशिएशन इंजन और JDBC/ODBC अंतरों को संभालता है।”

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

• Flight SQL को JSON HTTP API के रूप में देखना → कॉलमर बैचेस और एंडपॉइंट सेमेंटिक्स खो जाते हैं → Flight SQL RPC लाइफसाइकिल के इर्द-गिर्द डिज़ाइन करें।
• गेटवे पर पूरे परिणाम को कैश करना → बड़ी क्वेरीज़ मेमोरी को समाप्त कर देती हैं → बैचेस को स्ट्रीम करें और बैकप्रेशर को प्रोपेगेट करें।
• केवल कनेक्शन सेटअप पर ऑथेंटिकेट करना → रो, कॉलम और टेनेंट नीतियां छूट जाती हैं → प्लानिंग के दौरान नीति लागू करें।
• डिस्कनेक्ट होने के बाद हर क्वेरी को रीस्टार्ट करना → डेटाबेस लोड और डुप्लिकेट राइट्स बढ़ते हैं → हैंडल द्वारा रीड्स और ट्रांजैक्शन या Action सेमेंटिक्स द्वारा राइट्स का री-ट्राई करें।
• क्षमताओं (capabilities) को अनदेखा करना → क्लाइंट्स मान लेते हैं कि हर SQL फीचर मौजूद है → GetSqlInfo जैसे मेटाडेटा के साथ नेगोशिएट करें।

फॉलो-अप और उत्तर

GetFlightInfo को DoGet से अलग क्यों करें?

GetFlightInfo स्कीमा, टिकट, एंडपॉइंट्स और एक्ज़ीक्यूशन जानकारी लौटाता है; DoGet डेटा स्ट्रीम को ले जाता है। यह अलग-अलग वर्कर्स पर रिजल्ट पार्टिशन्स की अनुमति देता है और क्लाइंट्स को एंडपॉइंट्स को समानांतर (parallel) या लेज़ी रूप से पढ़ने देता है।

आप एक धीमे टेनेंट की क्वेरी को कैसे सीमित करते हैं?

प्लानिंग के दौरान स्कैन-बाइट, कॉनकरेंसी, मेमोरी और वॉल-क्लॉक कोटा सेट करें, फिर एक्ज़ीक्यूशन का नमूना लें और सीमा पार होने पर रद्द या डिग्रेड करें। टेनेंट और इंजन द्वारा कोटा मापें ताकि एक बड़ा टेनेंट साझा वर्कर्स के संसाधनों को समाप्त न कर दे।

क्या एक DoPut डुप्लिकेट राइट्स का री-ट्राई कर सकता है?

हाँ। राइट्स के लिए एक स्पष्ट कमिट पॉइंट और री-ट्राई रिजल्ट के साथ एक ट्रांजैक्शन आईडी, बैच सीक्वेंस और इडेम्पोटेंसी कंस्ट्रेंट की आवश्यकता होती है। यदि कमिट स्थिति अज्ञात है, तो आँख बंद करके रीप्ले करने के बजाय एक सुलह (reconciliation) स्थिति लौटाएं।

क्लाइंट्स को सीधे डेटाबेस से कनेक्ट क्यों नहीं होने दिया जाए?

सीधा एक्सेस साझा ऑथराइजेशन, ऑडिटिंग, थ्रॉटलिंग और क्रॉस-इंजन व्यवहार को कठिन बनाता है, और डेटाबेस नेटवर्क बाउंड्री को उजागर करता है। एक Flight SQL गेटवे Arrow-नेटिव ट्रांसपोर्ट दक्षता को बनाए रखते हुए उन नियंत्रणों को केंद्रीकृत करता है।