Snowflake के साथ Perplexity कनेक्ट करना

Snowflake Connector के बारे में

Snowflake Connector आपको अपने Snowflake डेटा वेयरहाउस में संग्रहीत डेटा को सीधे Perplexity से क्वेरी करने की सुविधा देता है। यह Snowflake को Perplexity की प्रोडक्टिविटी सुविधाओं के साथ इंटीग्रेट करता है, जिससे आप अपने Snowflake डेटाबेस, ईमेल, कैलेंडर, अन्य कनेक्ट किए गए ऐप्स, और वेब में संबंधित जानकारी को तुरंत खोज और संयोजित कर सकते हैं — बिना मैन्युअल क्वेरी या संदर्भ बदलने के।

Snowflake Connector Perplexity Pro, Perplexity Max, Enterprise Pro, और Enterprise Max उपयोगकर्ताओं के लिए उपलब्ध है।

Snowflake Connector क्या करता है?

एक बार सक्षम होने पर, Snowflake Connector आपको अपने अधिकृत Snowflake डेटाबेस, स्कीमा, और टेबल्स में खोज करने की सुविधा देता है ताकि उसी डेटा के आधार पर उत्तर प्रदान किए जा सकें। यह connector आपके Snowflake अकाउंट से सुरक्षित रूप से कनेक्ट होकर काम करता है, और आपके वेयरहाउस की जानकारी को अन्य स्रोतों के साथ संयोजित करते हुए व्यापक खोज सक्षम करता है।

आप इस connector का उपयोग टेबल्स, व्यूज़, और स्कीमा में जानकारी जल्दी से ढूँढने के लिए कर सकते हैं — बिना SQL क्वेरी मैन्युअल रूप से लिखे या Snowflake कंसोल पर स्विच किए। जब आपका Snowflake डेटा अपडेट होता है, तो connector उन परिवर्तनों को बाद की क्वेरीज़ के दौरान स्वचालित रूप से दर्शाता है।

समर्थित डेटा ऑब्जेक्ट्स

Snowflake Connector का समर्थन करता है:

टेबल्स
व्यूज़ और मटीरियलाइज़्ड व्यूज़
स्कीमा
डेटाबेस
संरचित डेटा (CSV, JSON, Parquet-समर्थित टेबल्स)

फिलहाल, असंरचित डेटा (Snowflake स्टेजेस में संग्रहीत इमेज, ऑडियो, और वीडियो) समर्थित नहीं है।

प्रमाणीकरण के तरीके

Snowflake प्रमाणीकरण के दो स्वतंत्र आयाम हैं: कौन क्वेरीज़ चलाता है (पहचान), और कैसे वह पहचान खुद को सिद्ध करती है (क्रेडेंशियल)। Snowflake में अधिकांश संयोजन मान्य हैं — Snowflake Partner Authentication डॉक्स देखें।

पहचान (Snowflake उपयोगकर्ता प्रकार):

TYPE = PERSON — एक व्यक्तिगत Snowflake उपयोगकर्ता अकाउंट, प्रति Perplexity उपयोगकर्ता एक
TYPE = SERVICE — एक साझा सेवा अकाउंट (जैसे PERPLEXITY_USER) जिसके माध्यम से सभी Perplexity उपयोगकर्ता क्वेरी करते हैं

क्रेडेंशियल (वह उपयोगकर्ता कैसे प्रमाणीकरण करता है):

OAuth (ब्राउज़र-आधारित फ़्लो)
Key-pair (RSA निजी कुंजी)
Programmatic Access Token (PAT)

पहचान × क्रेडेंशियल मैट्रिक्स

	OAuth	Key-pair	PAT
`TYPE = PERSON` (व्यक्तिगत उपयोगकर्ता)	✅ अनुशंसित	✅ Snowflake में समर्थित	✅ Snowflake में समर्थित
`TYPE = SERVICE` (साझा अकाउंट)	❌ समर्थित नहीं (OAuth के लिए इंटरैक्टिव लॉगिन आवश्यक है)	✅ सेवा अकाउंट के लिए अनुशंसित	✅ समर्थित (केवल एकल भूमिका)

⚠️ Perplexity का connector UI आज क्या उजागर करता है:

Perplexity डायरेक्टरी में दो अलग connectors भेजता है:

"Snowflake (User OAuth)" — PERSON + OAuth के लिए (प्रति-उपयोगकर्ता पहचान, अनुशंसित)

"Snowflake" — SERVICE + key-pair, या SERVICE + PAT के लिए (साझा पहचान, फ़ॉलबैक)

प्रति-उपयोगकर्ता key-pair या PAT (PERSON + key-pair / PERSON + PAT) तकनीकी रूप से Snowflake द्वारा समर्थित है लेकिन वर्तमान में Perplexity के connector UI में उपलब्ध नहीं है। यदि आपके पास इसकी माँग करने वाला कोई ग्राहक है (जैसे OAuth के बिना उपयोगकर्ता-स्तरीय key-pair), तो connectors टीम से संपर्क करें — यह Snowflake द्वारा अवरुद्ध नहीं है।

अनुशंसित मार्ग: User OAuth

हम User OAuth की अनुशंसा करते हैं (PERSON + OAuth)। प्रत्येक Perplexity उपयोगकर्ता अपने स्वयं के Snowflake क्रेडेंशियल्स से प्रमाणीकरण करता है, क्वेरीज़ उस उपयोगकर्ता की मूल Snowflake अनुमतियों के अंतर्गत चलती हैं, और आपको Snowflake में एक स्पष्ट प्रति-उपयोगकर्ता ऑडिट ट्रेल मिलता है — कोई साझा सेवा अकाउंट नहीं, Perplexity में RBAC तर्क को फिर से बनाने की आवश्यकता नहीं। यह Snowflake की अपनी दिशा से भी मेल खाता है: Snowflake के अनुसार, "Key-pair and PAT are fallback options for service accounts that can't use OAuth", और Snowflake का प्रबंधित MCP सर्वर आज केवल OAuth 2.0 का समर्थन करता है।

नोट: OAuth के साथ, एक्सेस टोकन प्रमाणीकरण के समय एक विशिष्ट Snowflake भूमिका — विशेष रूप से, उपयोगकर्ता के DEFAULT_ROLE — से क्रिप्टोग्राफ़िक रूप से बंधा होता है। यह सुनिश्चित करने के लिए कि उपयोगकर्ताओं को सत्र के भीतर उन्हें दी गई सभी भूमिकाओं तक एक्सेस मिले, द्वितीयक भूमिकाओं को सही ढंग से कॉन्फ़िगर करें (नीचे User OAuth Role Configuration देखें)।

फ़ॉलबैक मार्ग: सेवा अकाउंट

सेवा अकाउंट (SERVICE + key-pair, या SERVICE + PAT) तब उपयुक्त है जब:

अंतिम उपयोगकर्ताओं के पास व्यक्तिगत Snowflake अकाउंट नहीं हैं (उदाहरण के लिए, ऐसे व्यावसायिक उपयोगकर्ता जो Perplexity के माध्यम से क्वेरी करते हैं लेकिन उनके पास Snowflake तक प्रत्यक्ष एक्सेस नहीं है)
आप स्पष्ट रूप से चाहते हैं कि सरलता या ऑडिटिंग कारणों के लिए सभी Perplexity क्वेरीज़ एक साझा पहचान के अंतर्गत चलें
आप एक आंतरिक/परीक्षण वातावरण सेट कर रहे हैं जहाँ प्रति-उपयोगकर्ता पहचान की आवश्यकता नहीं है

सेवा अकाउंट का उपयोग करते समय, हम PAT की तुलना में key-pair की अनुशंसा करते हैं — PATs की समाप्ति अवधि छोटी होती है और निर्माण के समय एक ही भूमिका से बंधे होते हैं (नीचे Service Account Role Configuration देखें)।

भूमिका कॉन्फ़िगरेशन

User OAuth Role Configuration (अनुशंसित)

Snowflake में OAuth प्रमाणीकरण एक्सेस टोकन को एक प्राथमिक भूमिका — उपयोगकर्ता के DEFAULT_ROLE — से बाँधता है, और सक्रिय सत्र के भीतर भूमिका स्विच करना समर्थित नहीं है। Perplexity कोई भूमिका-चयनकर्ता प्रस्तुत नहीं करता। जो भी उपयोगकर्ता ने पहले से Snowflake में DEFAULT_ROLE और DEFAULT_SECONDARY_ROLES के लिए कॉन्फ़िगर किया है, वही OAuth सत्र उपयोग करता है।

सुरक्षा इंटीग्रेशन स्तर पर अनुशंसित:

OAUTH_USE_SECONDARY_ROLES = IMPLICIT

Snowflake का इस पैरामीटर के लिए डिफ़ॉल्ट NONE है, जिसका मतलब है कि OAuth सत्र केवल उपयोगकर्ता की प्राथमिक भूमिका सक्रिय करके खुलते हैं — उन्हें दी गई कोई भी द्वितीयक भूमिकाएँ सक्रिय नहीं होतीं। इसे IMPLICIT पर सेट करना Snowflake को बताता है कि OAuth सत्र खुलने पर प्रत्येक उपयोगकर्ता के DEFAULT_SECONDARY_ROLES को भी स्वचालित रूप से सक्रिय करे। इंटीग्रेशन किसी भी तरह काम करेगा, लेकिन IMPLICIT के बिना उपयोगकर्ता केवल अपने DEFAULT_ROLE के माध्यम से एक्सेस योग्य डेटा देखेंगे, चाहे उन्हें कोई भी अन्य भूमिकाएँ दी गई हों — जो शायद ही कभी आप चाहते हैं और यही इस मार्गदर्शिका के बाकी हिस्से को काम करने योग्य बनाता है।

दो मामले

मामला A — उपयोगकर्ताओं के पास पहले से भूमिका डिफ़ॉल्ट्स कॉन्फ़िगर हैं। यदि आपके उपयोगकर्ताओं के DEFAULT_ROLE और DEFAULT_SECONDARY_ROLES पहले से उसी तरह सेट हैं जैसे आप चाहते हैं (प्रति-उपयोगकर्ता RBAC, कस्टम डिफ़ॉल्ट भूमिकाएँ, विशिष्ट द्वितीयक भूमिका सूचियाँ, आदि), तो कुछ और न करें। IMPLICIT सुरक्षा इंटीग्रेशन सेटिंग पर्याप्त है — प्रत्येक उपयोगकर्ता के मौजूदा डिफ़ॉल्ट्स ही उनके Perplexity सत्र में उपयोग होंगे।

मामला B — उपयोगकर्ताओं के पास अभी तक भूमिका डिफ़ॉल्ट्स नहीं हैं। यदि आपने प्रति-उपयोगकर्ता भूमिका डिफ़ॉल्ट्स कॉन्फ़िगर नहीं किए हैं, तो अनुशंसित पैटर्न यह है कि हर उपयोगकर्ता के DEFAULT_ROLE को PUBLIC और DEFAULT_SECONDARY_ROLES को ALL पर सेट करें। इंटीग्रेशन पर OAUTH_USE_SECONDARY_ROLES = IMPLICIT के साथ संयुक्त, यह प्रत्येक सत्र को उस उपयोगकर्ता को दी गई सभी भूमिकाओं का संघ देता है:

ALTER USER <username> SET
  DEFAULT_ROLE = PUBLIC,
  DEFAULT_SECONDARY_ROLES = ('ALL');

नोट: Snowflake के अगस्त 2024 के व्यवहार परिवर्तन के अनुसार, नए-निर्मित उपयोगकर्ताओं के लिए DEFAULT_SECONDARY_ROLES = ('ALL') नया अकाउंट-स्तरीय डिफ़ॉल्ट है। कई संगठनों के पास यह बिना किसी स्पष्ट कार्रवाई के पहले से सेट है। कुछ भी बदलने से पहले जाँचने के लिए DESC USER <username> चलाएँ।

सर्विस अकाउंट रोल कॉन्फ़िगरेशन

OAuth के विपरीत, सेवा अकाउंट एक समर्पित उपयोगकर्ता होता है जो connector के लिए बनाई गई एक विशिष्ट भूमिका के अंतर्गत चलता है — आमतौर पर PERPLEXITY_ROLE। OAuth के लिए उपयोग किया जाने वाला DEFAULT_ROLE = PUBLIC + DEFAULT_SECONDARY_ROLES = ('ALL') पैटर्न यहाँ लागू नहीं होता। इसके बजाय, सेवा उपयोगकर्ता के DEFAULT_ROLE को समर्पित PERPLEXITY_ROLE पर सेट करें, और उस भूमिका को केवल वही अनुमतियाँ दें जिनकी Perplexity को आवश्यकता है।

सेवा अकाउंट उपयोगकर्ता बनाते समय इसे लागू करें (key-pair प्रमाणीकरण का उपयोग करते हुए, जिसे हम PAT के बजाय अनुशंसित करते हैं):

CREATE USER PERPLEXITY_USER
  TYPE = SERVICE
  DEFAULT_ROLE = PERPLEXITY_ROLE
  DEFAULT_WAREHOUSE = PERPLEXITY_WAREHOUSE
  COMMENT = 'Service account for Perplexity'
  RSA_PUBLIC_KEY = 'MIIBIjANBgkqhki...your_public_key_here...IDAQAB';

यह Snowflake की सेवा अकाउंट सर्वोत्तम प्रथाओं का पालन करता है: सेवा उपयोगकर्ता को एक संकीर्ण-अनुमति वाली एकल भूमिका तक सीमित रखा जाता है, न कि उसे दी गई हर भूमिका के संघ को विरासत में लेने दिया जाता है।

PAT के साथ सेवा अकाउंट

यदि आप key-pair के बजाय Programmatic Access Token का उपयोग करते हैं, तो Snowflake को टोकन निर्माण के समय ROLE_RESTRICTION सेट करना आवश्यक है। टोकन ROLE_RESTRICTION में निर्दिष्ट एकल भूमिका से कठोरता से बंधा होता है और टोकन के जीवनकाल में इसे बदला नहीं जा सकता।

यहाँ वही समर्पित PERPLEXITY_ROLE उपयोग करें:

ALTER USER PERPLEXITY_USER ADD PROGRAMMATIC ACCESS TOKEN PERPLEXITY_PAT
  ROLE_RESTRICTION = 'PERPLEXITY_ROLE'
  DAYS_TO_EXPIRY = 90;

इसी कारण से — छोटी समाप्ति अवधियों के साथ — हम सेवा अकाउंट सेटअप के लिए PAT की तुलना में key-pair की अनुशंसा करते हैं।

(वैकल्पिक) OAuth के माध्यम से किन भूमिकाओं का उपयोग किया जा सकता है, उसे प्रतिबंधित करना

यदि आप यह सीमित करना चाहते हैं कि उपयोगकर्ता Perplexity OAuth इंटीग्रेशन के माध्यम से किन Snowflake भूमिकाओं में प्रमाणीकरण कर सकते हैं, तो आप सुरक्षा इंटीग्रेशन स्तर पर इनमें से किसी एक का उपयोग करके इसे सीमित कर सकते हैं:

PRE_AUTHORIZED_ROLES_LIST — उन भूमिकाओं की स्पष्ट अनुमति सूची जिनका उपयोग इस OAuth इंटीग्रेशन के माध्यम से किया जा सकता है
BLOCKED_ROLES_LIST — उन भूमिकाओं की अस्वीकृति सूची जिनका उपयोग इस OAuth इंटीग्रेशन के माध्यम से नहीं किया जा सकता

उदाहरण के लिए:

ALTER SECURITY INTEGRATION PERPLEXITY_OAUTH   SET PRE_AUTHORIZED_ROLES_LIST = ('ANALYST_ROLE', 'READ_ONLY_ROLE');

इसका उपयोग करें यदि आप संवेदनशील भूमिकाओं (जैसे ACCOUNTADMIN) को OAuth फ़्लो से पूरी तरह बाहर रखना चाहते हैं।

Snowflake में Perplexity क्या कर सकता है, इसे नियंत्रित करना

Snowflake Connector SQL को एक टूल सरफ़ेस (Merge Snowflake connector से प्राप्त) के माध्यम से निष्पादित करता है जिसमें एक सामान्य execute_sql टूल शामिल है। चूँकि execute_sql मनमाना SQL — DDL और DML सहित — स्वीकार करता है, इसलिए केवल-पठनीय प्रवर्तित करने या Perplexity के कार्यों को प्रतिबंधित करने का एकमात्र विश्वसनीय तरीका Snowflake RBAC परत पर है, Perplexity UI में नहीं।

अनुशंसित पैटर्न: Snowflake भूमिका स्तर पर केवल-पठनीय प्रवर्तित करें।

एक समर्पित केवल-पठनीय भूमिका (जैसे PERPLEXITY_READ_ONLY) प्रावधान करें, जो उन डेटाबेस, स्कीमा, और टेबल्स पर केवल USAGE और SELECT देती है जिन्हें आप Perplexity को क्वेरी करने देना चाहते हैं — और स्पष्ट रूप से INSERT, UPDATE, DELETE, CREATE, DROP, OWNERSHIP, या वेयरहाउस MODIFY नहीं देती। फिर सुनिश्चित करें कि उपयोगकर्ता उस भूमिका में प्रमाणीकरण करें:

इसे उपयोगकर्ता के DEFAULT_ROLE के रूप में सेट करें, या
OAuth इंटीग्रेशन को PRE_AUTHORIZED_ROLES_LIST = ('PERPLEXITY_READ_ONLY', …) से सीमित करें और/या BLOCKED_ROLES_LIST के माध्यम से लिखने-सक्षम भूमिकाओं को बाहर करें (ऊपर (वैकल्पिक) OAuth के माध्यम से किन भूमिकाओं का उपयोग किया जा सकता है, उसे प्रतिबंधित करना देखें)।

RBAC को इस तरह कॉन्फ़िगर करने पर, Snowflake Perplexity द्वारा किए जाने वाले किसी भी लेखन प्रयास को अस्वीकार कर देगा, चाहे कोई भी टूल कॉल किया जाए।

नोट: Perplexity Snowflake connector सेटिंग्स में एक Tool permissions पैनल प्रस्तुत करता है जो उपलब्ध टूल्स की सूची देता है। आज, यह पैनल विश्वसनीय रीड/राइट/एडिट प्रवर्तन प्रदान नहीं करता — Snowflake भूमिका स्तर पर एक्सेस को नियंत्रित करना (ऊपर) Perplexity के कार्यों को नियंत्रित करने का सही तरीका है।

गोपनीयता और डेटा सुरक्षा

Perplexity से कनेक्ट होने पर, Snowflake Connector आपकी ओर से निम्नलिखित कार्रवाइयाँ कर सकता है:

Snowflake डेटा पर SQL क्वेरीज़ निष्पादित करें
Cortex Search और Analyst क्वेरी करें
कस्टम UDFs और स्टोर्ड प्रोसीजर चलाएँ

यदि आप Snowflake में एक्सेस रद्द करते हैं या कोई भूमिका हटाते हैं, तो वह डेटा Perplexity से तुरंत अप्राप्य हो जाता है। यदि आप Perplexity में अपना Snowflake अकाउंट डिस्कनेक्ट करते हैं, तो आप चुन सकते हैं कि कैश्ड डेटा रखना है या डिलीट करना है।

Enterprise-grade सुरक्षा और नियंत्रण

Enterprise संगठनों के लिए, Perplexity SOC 2 Type II प्रमाणन, एंड-टू-एंड एन्क्रिप्शन, सख्त डेटा गोपनीयता उपाय, और बारीक उपयोगकर्ता एक्सेस नियंत्रण प्रदान करता है। आपके Snowflake डेटा का उपयोग AI प्रशिक्षण के लिए कभी नहीं किया जाता।

Perplexity को Snowflake से जोड़ना व्यक्तिगत स्तर पर किया जाता है — आपके संगठन में कोई और आपके Snowflake डेटा को क्वेरी नहीं कर सकता। हालाँकि, यदि आप किसी साझा Space में डेटा सिंक करते हैं, तो उस Space तक एक्सेस वाला कोई भी व्यक्ति उसे खोज पाएगा।

संगठन एडमिन Organization Settings में Permissions स्क्रीन से सभी उपयोगकर्ताओं के लिए Snowflake Connector को सक्षम या अक्षम कर सकते हैं। रीड/राइट प्रवर्तन Snowflake भूमिका स्तर पर किया जाता है (ऊपर Snowflake में Perplexity क्या कर सकता है, इसे नियंत्रित करना देखें)।

इसे कैसे सक्रिय करें

नोट: हम अधिकांश संगठनों के लिए User OAuth की अनुशंसा करते हैं — यह प्रति-उपयोगकर्ता पहचान प्रदान करता है और Snowflake की अपनी दिशा से मेल खाता है। जब व्यक्तिगत Snowflake अकाउंट उपलब्ध नहीं होते, तो सेवा अकाउंट (key-pair) फ़ॉलबैक के रूप में प्रस्तुत किया जाता है। यदि आप User OAuth का उपयोग कर रहे हैं, तो केवल-एडमिन OAuth सेटअप के लिए Step 7: Connect Snowflake to Perplexity देखें। नीचे दिए गए SQL सेटअप चरण 1–6 केवल सेवा अकाउंट / key-pair सेटअप पर लागू होते हैं।

पूर्वापेक्षाएँ

ACCOUNTADMIN भूमिका (या CREATE USER और GRANT विशेषाधिकारों वाली कोई भूमिका)
आपकी लोकल मशीन पर OpenSSL इंस्टॉल है (macOS पर पहले से इंस्टॉल)

Step 1: एक Key Pair जनरेट करें

अपने टर्मिनल से, एक RSA निजी कुंजी जनरेट करें:

openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out snowflake_computer_key.p8 -nocrypt

इसके बाद, संबंधित सार्वजनिक कुंजी जनरेट करें:

openssl rsa -in snowflake_computer_key.p8 -pubout -out snowflake_computer_key.pub

Step 2: एक भूमिका और वेयरहाउस बनाएँ

USE ROLE ACCOUNTADMIN;

-- Create a dedicated role
CREATE ROLE IF NOT EXISTS PERPLEXITY_ROLE
  COMMENT = 'Role for Perplexity service account';

-- Create a warehouse (or use an existing one)
CREATE WAREHOUSE IF NOT EXISTS PERPLEXITY_WAREHOUSE
  WAREHOUSE_SIZE = 'XLARGE'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE
  COMMENT = 'Warehouse for Perplexity queries';

-- Grant warehouse usage to the role
GRANT USAGE ON WAREHOUSE PERPLEXITY_WAREHOUSE TO ROLE PERPLEXITY_ROLE;

Step 3: सेवा अकाउंट उपयोगकर्ता बनाएँ

Snowflake वर्कशीट में ACCOUNTADMIN भूमिका का उपयोग करते हुए निम्नलिखित चलाएँ। RSA_PUBLIC_KEY मान को अपनी snowflake_computer_key.pub फ़ाइल की सामग्री से बदलें, बिना हैडर और फ़ुटर के।

USE ROLE ACCOUNTADMIN;

CREATE USER PERPLEXITY_USER
  TYPE = SERVICE
  DEFAULT_ROLE = PERPLEXITY_ROLE
  DEFAULT_WAREHOUSE = PERPLEXITY_WAREHOUSE
  COMMENT = 'Service account for Perplexity'
  RSA_PUBLIC_KEY = 'MIIBIjANBgkqhki...your_public_key_here...IDAQAB';

-- Grant the dedicated role to the service account
GRANT ROLE PERPLEXITY_ROLE TO USER PERPLEXITY_USER;

नोट: TYPE = SERVICE इसे एक गैर-मानवीय सेवा अकाउंट के रूप में नामित करता है। पासवर्ड सेट न करें। DEFAULT_ROLE = PERPLEXITY_ROLE सेवा अकाउंट को केवल उन्हीं अनुमतियों वाली एक समर्पित भूमिका तक सीमित करता है जिनकी Perplexity को आवश्यकता है।

Step 4: अपने डेटा तक एक्सेस दें

-- Grant access to a specific database
GRANT USAGE ON DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;

-- Grant access to all schemas in a database (current and future)
GRANT USAGE ON ALL SCHEMAS IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;
GRANT USAGE ON FUTURE SCHEMAS IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;

-- Grant read access to all tables and views (current and future)
GRANT SELECT ON ALL TABLES IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;
GRANT SELECT ON FUTURE TABLES IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;
GRANT SELECT ON ALL VIEWS IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;
GRANT SELECT ON FUTURE VIEWS IN DATABASE MY_DATABASE TO ROLE PERPLEXITY_ROLE;

अधिक चयनात्मक एक्सेस के लिए, Snowflake GRANT डॉक्यूमेंटेशन देखें।

Step 5: Query History और Access History तक एक्सेस दें

Perplexity सटीक क्वेरी निर्माण के लिए डेटा मैप बनाने हेतु SNOWFLAKE.ACCOUNT_USAGE स्कीमा में दो व्यूज़ पर निर्भर करता है:

View	उद्देश्य
QUERY_HISTORY	क्वेरी मेटाडेटा, प्रदर्शन, और उपयोग पैटर्न
ACCESS_HISTORY	ऑब्जेक्ट-स्तरीय ऑडिट ट्रेल (केवल Enterprise Edition)

USE ROLE ACCOUNTADMIN;

GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE PERPLEXITY_ROLE;

नोट: ACCESS_HISTORY केवल Snowflake Enterprise Edition या उच्चतर पर उपलब्ध है। Perplexity Standard Edition पर स्वचालित रूप से QUERY_HISTORY पर वापस आ जाएगा। इस चरण को छोड़ने से क्वेरी सटीकता कम हो जाएगी। Perplexity इन व्यूज़ का उपयोग आपके डेटा के लिए डेटा मैप बनाने में कैसे करता है, इस पर अधिक विवरण के लिए Understanding the Data Map देखें।

एक्सेस सत्यापित करें:

USE ROLE ACCOUNTADMIN;
GRANT ROLE PERPLEXITY_ROLE TO USER <your_username>;

USE ROLE PERPLEXITY_ROLE;
USE WAREHOUSE PERPLEXITY_WAREHOUSE;

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY LIMIT 5;
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY LIMIT 5;

Step 6: (वैकल्पिक) IP पतों को अनुमति सूची में डालें

यदि आपके Snowflake अकाउंट की कोई नेटवर्क नीति है जो आने वाले कनेक्शनों को IP पते के अनुसार प्रतिबंधित करती है, तो इस पेज से IP को अनुमति सूची में डालें:

USE ROLE ACCOUNTADMIN;

CREATE NETWORK POLICY PERPLEXITY_COMPUTER_POLICY
    ALLOWED_IP_LIST = (...US IPs from the link above...);

ALTER USER PERPLEXITY_USER
    SET NETWORK_POLICY = PERPLEXITY_COMPUTER_POLICY;

Step 7: Snowflake को Perplexity से कनेक्ट करें

OAuth के लिए: पहले Admin Setup (Snowflake (User OAuth) connector)

यदि आपका संगठन OAuth (व्यक्तिगत उपयोगकर्ता) प्रमाणीकरण का उपयोग कर रहा है, तो व्यक्तिगत उपयोगकर्ताओं द्वारा प्रमाणीकरण करने से पहले एक संगठन एडमिन को संगठन के लिए Snowflake (User OAuth) connector को एक बार कॉन्फ़िगर करना होगा।

Organization Settings → Connectors → Snowflake (User OAuth) में, एडमिन को एक तीन-चरणीय सेटअप पेन दिखाई देगा:

Step 1: Manage OAuth app — अपने Snowflake अकाउंट के विरुद्ध Perplexity को OAuth क्लाइंट के रूप में पंजीकृत करने के लिए Manage OAuth app पर क्लिक करें। यह आपको एक कस्टम Snowflake SECURITY INTEGRATION बनाने और परिणामी Client ID और Client Secret को Perplexity में वापस पेस्ट करने के माध्यम से ले जाएगा।
Step 2: Authenticate with Snowflake (User OAuth) — एडमिन यह सत्यापित करने के लिए एक बार प्रमाणीकरण करता है कि इंटीग्रेशन एंड-टू-एंड काम करता है।
Step 3: Generate a data map (वैकल्पिक) — संगठन के लिए वैकल्पिक रूप से एक डेटा मैप जनरेट करें (Understanding the Data Map देखें) और क्वेरी सटीकता में सुधार के लिए पूरक संदर्भ जोड़ें।

जब आप Step 1 में Manage OAuth app पर क्लिक करते हैं, तो आपको Snowflake पक्ष पर सुरक्षा इंटीग्रेशन बनाना होगा। निम्नलिखित को ACCOUNTADMIN के रूप में चलाएँ:

USE ROLE ACCOUNTADMIN;

CREATE SECURITY INTEGRATION PERPLEXITY_OAUTH
  TYPE = OAUTH
  ENABLED = TRUE
  OAUTH_CLIENT = CUSTOM
  OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
  OAUTH_REDIRECT_URI = 'https://ah.merge.dev/oauth/callback'
  OAUTH_ISSUE_REFRESH_TOKENS = TRUE
  OAUTH_REFRESH_TOKEN_VALIDITY = 7776000
  OAUTH_USE_SECONDARY_ROLES = IMPLICIT
  COMMENT = 'OAuth security integration for Perplexity';

Perplexity में वापस पेस्ट करने के लिए Client ID और Client Secret प्राप्त करें:

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('PERPLEXITY_OAUTH');

एडमिन सेटअप पूरा होने के बाद, व्यक्तिगत उपयोगकर्ता नीचे दिए गए चरणों का उपयोग करके प्रमाणीकरण कर सकते हैं।

उपयोगकर्ता कनेक्शन चरण

उपयोगकर्ता केवल वही प्रमाणीकरण विधि देखेंगे जो उनके एडमिन द्वारा कॉन्फ़िगर किए गए connector से मेल खाती है — Snowflake connector के अंतर्गत Key-pair या PAT, Snowflake (User OAuth) connector के अंतर्गत OAuth।

Settings में Connectors पर जाएँ और Snowflake या Snowflake (User OAuth) connector ढूँढें।
Enable → Add Connector पर क्लिक करें।
उस विधि का उपयोग करके प्रमाणीकरण करें जिसके लिए आपका connector कॉन्फ़िगर किया गया है:

Key-pair प्रमाणीकरण (Snowflake connector)

अपना Snowflake अकाउंट पहचानकर्ता, उपयोगकर्ता नाम, और निजी कुंजी (snowflake_computer_key.p8) दर्ज करें।

Programmatic Access Token (PAT) (Snowflake connector)

अपना Snowflake अकाउंट पहचानकर्ता और Snowflake में Governance & Security से एक PAT दर्ज करें।

OAuth (व्यक्तिगत उपयोगकर्ता) (Snowflake (User OAuth) connector)

आपको प्रमाणीकरण के लिए Snowflake पर भेज दिया जाएगा। Perplexity कोई भूमिका-चयनकर्ता प्रस्तुत नहीं करता — आपका OAuth सत्र आपके Snowflake DEFAULT_ROLE को प्राथमिक भूमिका के रूप में उपयोग करता है, और OAUTH_USE_SECONDARY_ROLES = IMPLICIT के माध्यम से आपके DEFAULT_SECONDARY_ROLES स्वचालित रूप से सक्रिय होते हैं। यदि आपकी भूमिका डिफ़ॉल्ट्स पहले से ही आपके एडमिन द्वारा कॉन्फ़िगर हैं, तो किसी कार्रवाई की आवश्यकता नहीं है।

यदि आप पाते हैं कि आपके सत्र में आपको अपेक्षित डेटा तक एक्सेस नहीं है, तो अपने Snowflake एडमिन से अपने DEFAULT_ROLE और DEFAULT_SECONDARY_ROLES को सत्यापित करने के लिए कहें (ऊपर User OAuth Role Configuration देखें)।

सेटअप पूरा करने के लिए Allow पर क्लिक करें।

कनेक्ट किए गए डेटा का उपयोग करना

एक बार कनेक्ट हो जाने पर, आप Computer कार्यों में अपने Snowflake डेटा का संदर्भ दे सकते हैं। डेटाबेस, स्कीमा, या टेबल्स का उल्लेख करें और Perplexity उन्हें बहु-चरणीय वर्कफ़्लो के हिस्से के रूप में क्वेरी करेगा — सब कुछ एक सुरक्षित क्लाउड sandbox में अतुल्यकालिक रूप से।

इसे आज़माना

एक बार कनेक्ट हो जाने पर, इस तरह की क्वेरी चलाकर देखें:

"Summarize the revenue trends from the Q4 sales table and highlight key metrics"
"Find all customer records updated in the last 30 days"
"What are the top-performing products based on the analytics schema?"
"Compare this quarter's pipeline data against the previous quarter's figures"

समस्या निवारण

आपके संगठन के लिए Snowflake सक्षम नहीं है

यदि आप किसी Enterprise संगठन के सदस्य हैं और Snowflake Connector सक्षम नहीं कर पा रहे हैं, तो एडमिन ने उसे अक्षम किया हो सकता है। पुष्टि करने के लिए अपने संगठन एडमिन से संपर्क करें, या Perplexity सहायता से संपर्क करें।

कनेक्शन और प्रमाणीकरण समस्याएँ

सत्यापित करें कि Perplexity के IP पते आपकी Snowflake नेटवर्क नीति में अनुमति सूची में हैं
पुष्टि करें कि भूमिका के पास आवश्यक वेयरहाउस, डेटाबेस, और स्कीमा पर USAGE विशेषाधिकार हैं
किसी भी नीति परिवर्तन के बाद उपयोगकर्ताओं को Snowflake Connector को फिर से कनेक्ट करने के लिए कहें

"Invalid private key" त्रुटि

सुनिश्चित करें कि आप निजी कुंजी (snowflake_computer_key.p8) पेस्ट कर रहे हैं, सार्वजनिक कुंजी नहीं। फ़ाइल -----BEGIN PRIVATE KEY----- से शुरू होनी चाहिए।

वर्तमान प्रमाणीकरण नीति द्वारा प्रमाणीकरण अस्वीकृत

ACCOUNTADMIN के रूप में SHOW AUTHENTICATION POLICIES चलाएँ। सुनिश्चित करें कि PERPLEXITY_USER ऐसी नीति के अंतर्गत आता है जिसकी अनुमत विधियों में KEYPAIR शामिल है। यदि आवश्यक हो:

CREATE AUTHENTICATION POLICY PERPLEXITY_AUTH_POLICY
  AUTHENTICATION_METHODS = ('KEYPAIR')
  CLIENT_TYPES = ('DRIVERS');

ALTER USER PERPLEXITY_USER SET AUTHENTICATION POLICY PERPLEXITY_AUTH_POLICY;

OAuth: कनेक्ट करने के बाद उपयोगकर्ता को सीमित डेटा दिखता है

OAuth सत्र उपयोगकर्ता के Snowflake DEFAULT_ROLE को प्राथमिक भूमिका के रूप में उपयोग करता है, और OAUTH_USE_SECONDARY_ROLES = IMPLICIT के माध्यम से द्वितीयक भूमिकाएँ सक्रिय होती हैं। यदि किसी उपयोगकर्ता को अपेक्षित डेटा तक एक्सेस नहीं है:

पुष्टि करें कि सुरक्षा इंटीग्रेशन में OAUTH_USE_SECONDARY_ROLES = IMPLICIT है।
DESC USER <username> चलाएँ और DEFAULT_ROLE और DEFAULT_SECONDARY_ROLES जाँचें। सत्र ठीक उसी का उपयोग करेगा जो वहाँ कॉन्फ़िगर है।
यदि उपयोगकर्ता के पास कोई प्रति-उपयोगकर्ता भूमिका कॉन्फ़िगरेशन नहीं है और आप चाहते हैं कि उन्हें दिए गए सब कुछ तक एक्सेस मिले, तो DEFAULT_ROLE = PUBLIC और DEFAULT_SECONDARY_ROLES = ('ALL') सेट करें।
इनमें से किसी भी सेटिंग के बदलने के बाद नया टोकन जारी करने के लिए उनसे Snowflake Connector को डिस्कनेक्ट और फिर से कनेक्ट करवाएँ।

`ACCESS_HISTORY` व्यू त्रुटि लौटाता है

पुष्टि करें कि आपका Snowflake अकाउंट Enterprise Edition या उच्चतर है।

`ACCOUNT_USAGE` व्यूज़ पर अपर्याप्त विशेषाधिकार

सत्यापित करें कि GRANT IMPORTED PRIVILEGES को ACCOUNTADMIN के रूप में चलाया गया और PERPLEXITY_ROLE उपयोगकर्ता को दी गई है।

Key-pair प्रमाणीकरण विफल

सार्वजनिक कुंजी फ़िंगरप्रिंट भरा हुआ है, इसकी पुष्टि के लिए DESC USER PERPLEXITY_USER फिर से चलाएँ।

यदि इन सेटिंग्स को अपडेट करने के बाद भी समस्याएँ बनी रहती हैं, तो सहायता के लिए Perplexity सहायता से संपर्क करें।

संबंधित आर्टिकल्स

Outlook.com के साथ Perplexity कनेक्ट करना

Confluence के साथ Perplexity कनेक्ट करना

Google Drive के साथ Perplexity कनेक्ट करना

Data Map को समझना

Databricks के साथ Perplexity कनेक्ट करना