Databricks के जवाब,बिना नोटबुक और बिना एक भी लाइन SQL के।

Connector Agent को बताएँ कि आपको Databricks चाहिए, या कैटलॉग में उसका कार्ड चुनें। अपने SQL warehouse की Connection details से server hostname और HTTP path डालें, फिर सुरक्षित फ़ॉर्म में access token चिपकाएँ। चाहें तो catalog और स्कीमा का नाम दें। फिर टेबल चुनें, तय करें कि वे कितनी बार रिफ़्रेश हों, और पहला लोड मंज़ूर करें।

आपके चुने हुए स्कीमा की टेबल और व्यू, या तो सारी या आपकी चुनी हुई सूची, उनके कॉलम और टाइप के साथ। यह Unity Catalog या Hive metastore के साथ, SQL warehouse या all-purpose cluster के ज़रिए काम करता है। Querri सिर्फ़ वही पढ़ सकता है जो टोकन का यूज़र या service principal पढ़ सकता है।

स्कीमा को पूरा दोबारा पढ़ना रोज़, हर हफ़्ते या हर महीने सेट किया जा सकता है। Incremental सिंक, updated_at जैसे cursor कॉलम के आधार पर, हर घंटे, रोज़ या हर हफ़्ते चलते हैं और सिर्फ़ आखिरी मान के बाद की पंक्तियाँ लाते हैं। किसी बड़ी मीटिंग से पहले एक सिंक हाथ से चला लें। Databricks में डिलीट की गई पंक्तियाँ अगले पूरे रिफ़्रेश तक Querri में बनी रहती हैं।

नहीं। Querri आपकी Databricks टेबल सिर्फ़ पढ़ता है और उनमें कभी कोई रिकॉर्ड नहीं बदलता। यह स्कीमा लुकअप और SELECT क्वेरी चलाता है, और कभी कोई टेबल या पंक्ति नहीं बनाता, अपडेट या डिलीट करता। ये क्वेरी आपके warehouse या cluster पर चलती हैं, इसलिए सिंक उसका कंप्यूट इस्तेमाल करता है।

Querri सिर्फ़ वही सिंक कर सकता है जिसकी अनुमति टोकन के यूज़र या service principal को है, इसलिए सबसे साफ़ सेटअप है एक service principal जिसके पास सिर्फ़ आपके चाहे गए स्कीमा का पढ़ने का एक्सेस हो। सिंक के बाद Unity Catalog की अनुमतियाँ हर व्यक्ति पर अलग से लागू नहीं होतीं: कौन क्या देखता है, यह Querri की शेयरिंग सेटिंग और हर व्यक्ति का रो फ़िल्टर तय करते हैं।

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

NetSuite भी कनेक्ट करें, और दोनों एक ही Library में आते हैं। Querri, lakehouse के इस्तेमाल, ऑर्डर या शिपमेंट को साझा ऑर्डर नंबर या ग्राहक के आधार पर NetSuite के इनवॉइस, sales orders और भुगतानों से मिला सकता है, और बताता है कि मिलान कैसे किया। एक बार तय करें कि कौन-सा इस्तेमाल बिल होने लायक है या ऑर्डर कब शिप माना जाए, और हर जवाब उसी का पालन करता है।

Databricks के साथ Salesforce कनेक्ट करें। Querri दोनों में अकाउंट का मिलान करता है, सबसे अच्छा दोनों में रखी किसी ID के आधार पर, ताकि आप प्रोडक्ट या ऑर्डर गतिविधि को पाइपलाइन, रिन्यूअल और खुले केस के साथ रख सकें। अगर मिलान ID के बजाय नाम पर टिका है, तो जवाब यह बताता है।

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

वह Delta टेबल सिंक करें जिसमें आपका मॉडल फ़ोरकास्ट लिखता है, साथ में ऑर्डर या सेल्स टेबल। फ़ोरकास्ट की गलती को एक बार KPI के रूप में तय करें, क्षेत्र या प्रोडक्ट के हिसाब से बाँटकर। Querri उस दिन से उसका इतिहास रखता है जब से आप शुरू करते हैं, और Nightly insights उस क्षेत्र को चिह्नित करता है जिसकी गलती भटकती है।

हाँ। आम शब्दों में डैशबोर्ड माँगें, या आपकी टीम जो पहले से इस्तेमाल करती है उसके स्क्रीनशॉट से शुरू करें, और पूछकर उसे बदलें। एक ही डैशबोर्ड में lakehouse टेबल के साथ ERP, CRM या स्प्रेडशीट डेटा मिल सकता है, हर देखने वाले को उसकी पंक्तियों तक सीमित रखा जा सकता है, और उसे आपके अपने ऐप में एम्बेड किया जा सकता है।

हाँ। Claude या ChatGPT में एक बार सेटअप के बाद, lakehouse टेबल के सवाल आपकी Querri Library से जवाब लेते हैं, आपकी परिभाषाओं और नियमों का पालन करते हैं, और Querri में उस व्यक्ति को जो दिखने की अनुमति है उसी के अंदर रहते हैं, इसलिए असिस्टेंट और आपके डैशबोर्ड एक ही बात कहते हैं।

नहीं। कनेक्टर को access token चाहिए, या तो personal access token या किसी service principal का। OAuth ब्राउज़र साइन-इन पर निर्भर होता, जो शेड्यूल किए गए सिंक के दौरान सर्वर पर पूरा नहीं हो सकता। Service principal का टोकन कनेक्शन को किसी एक कर्मचारी से अलग रखता है।

एक कनेक्शन एक catalog और एक स्कीमा को कवर करता है। कस्टम SQL क्वेरी सपोर्टेड नहीं हैं, इसलिए उनकी जगह टेबल या व्यू चुनें। न OAuth है, न वापस लिखना, और incremental सिंक अगले पूरे रिफ़्रेश तक डिलीट हुई पंक्तियाँ नहीं पकड़ते। कई catalog या स्कीमा का मतलब बस कई कनेक्शन है।

हाँ, कनेक्शन की एडवांस्ड सेटिंग में मौजूद वैकल्पिक VPN टनल के ज़रिए। इसके बिना Querri प्राइवेट पते अस्वीकार करता है और सिर्फ़ पोर्ट 443 पर HTTPS से कनेक्ट होता है। अगर warehouse बंद है या host गलत है, तो कनेक्शन अटकने के बजाय कुछ मिनटों में हार मान लेता है।

हाँ। पंक्तियाँ एक बड़े पुल के बजाय 50,000 के टुकड़ों में typed Parquet फ़ाइलों में स्ट्रीम होती हैं, और पंक्तियाँ आते ही प्रगति दिखती है। रोज़ बढ़ने वाली टेबल पर, cursor कॉलम की मदद से हर रन सिर्फ़ पिछली बार के बाद की पंक्तियाँ पढ़ता है। आप हर टेबल के लिए पंक्तियों की सीमा भी रख सकते हैं।

नहीं। टेबल सिंक होने के बाद, एक्सेस वाला कोई भी व्यक्ति आम भाषा में पूछता है। Querri हर जवाब के पीछे के चरण दिखाता है, ताकि डेटा टीम का कोई व्यक्ति लॉजिक जाँच सके, और अच्छा जवाब एक प्रोजेक्ट के रूप में सेव किया जा सकता है जो ताज़ा डेटा पर दोबारा चलता है।

Querri, SOC 2 Type II, HIPAA और ISO 27001:2022 प्रमाणित है, और आपका डेटा कभी किसी मॉडल को ट्रेन करने में इस्तेमाल नहीं होता। आपका access token स्टोरेज में एन्क्रिप्टेड रहता है, एरर मैसेज से हटा दिया जाता है और Connector Agent को कभी नहीं दिखाया जाता, और कनेक्शन सिर्फ़ HTTPS इस्तेमाल करता है।