Snowflake कनेक्टर आपको अपने Snowflake डेटा वेयरहाउस के डेटा को सीधे Perplexity से क्वेरी करने की सुविधा देता है। आप अपने Snowflake डेटाबेसेज़, अपने अन्य कनेक्ट किए गए ऐप्स, और वेब में जानकारी खोज और संयोजित कर सकते हैं — बिना SQL मैन्युअल रूप से लिखे या Snowflake कंसोल पर स्विच किए।
यह Perplexity Pro, Perplexity Max, Enterprise Pro, और Enterprise Max पर उपलब्ध है। Snowflake को कनेक्ट करना प्रति-उपयोगकर्ता किया जाता है — जब तक आप डेटा को किसी साझा प्रोजेक्ट में सिंक नहीं करते, आपके संगठन में कोई और आपका डेटा क्वेरी नहीं कर सकता।
यह मार्गदर्शिका बताती है कि कनेक्टर कैसे काम करता है, प्रमाणीकरण विधि कैसे चुनें, रोल्स और केवल-पठनीय एक्सेस कैसे कॉन्फ़िगर करें, और चरण-दर-चरण सेटअप कैसे करें। यदि आप बस सबसे तेज़ रास्ता चाहते हैं: अधिकांश संगठनों को User OAuth का उपयोग करना चाहिए — सीधे सेटअप गाइड पर जाएँ।
एक बार सक्षम होने पर, कनेक्टर आपके Snowflake अकाउंट से सुरक्षित रूप से कनेक्ट होता है और आपको उन डेटाबेसेज़, स्कीमाज़, टेबल्स, और व्यूज़ में खोज करने की सुविधा देता है जिन्हें देखने के लिए आप अधिकृत हैं। जब आपका Snowflake डेटा बदलता है, तो कनेक्टर आपकी अगली क्वेरी पर उन परिवर्तनों को स्वचालित रूप से दर्शाता है।
समर्थित डेटा ऑब्जेक्ट्स:
टेबल्स
व्यूज़ और मटीरियलाइज़्ड व्यूज़
स्कीमाज़
डेटाबेसेज़
संरचित डेटा (CSV-, JSON-, और Parquet-समर्थित टेबल्स)
असंरचित डेटा (Snowflake स्टेजेस में संग्रहीत इमेज, ऑडियो, और वीडियो) समर्थित नहीं है।
Snowflake प्रमाणीकरण के दो स्वतंत्र आयाम हैं: क्वेरीज़ किसके रूप में चलती हैं (पहचान) और वह पहचान कैसे खुद को सिद्ध करती है (क्रेडेंशियल)। Perplexity डायरेक्टरी में दो कनेक्टर उपलब्ध कराता है, जिनमें से प्रत्येक एक अनुशंसित संयोजन से मेल खाता है:
Snowflake (User OAuth) — प्रत्येक Perplexity उपयोगकर्ता OAuth के माध्यम से अपने स्वयं के Snowflake अकाउंट (TYPE = PERSON) से साइन इन करता है। अधिकांश संगठनों के लिए अनुशंसित।
Snowflake — सभी Perplexity उपयोगकर्ता एक key pair का उपयोग करके एक साझा सेवा अकाउंट (TYPE = SERVICE) के माध्यम से क्वेरी करते हैं। इसका उपयोग तब करें जब आपके अंतिम उपयोगकर्ताओं के पास व्यक्तिगत Snowflake अकाउंट न हों।
User OAuth के साथ, प्रत्येक व्यक्ति अपने स्वयं के क्रेडेंशियल्स से प्रमाणीकरण करता है, क्वेरीज़ उनकी मूल Snowflake अनुमतियों के अंतर्गत चलती हैं, और आपको एक स्पष्ट प्रति-उपयोगकर्ता ऑडिट ट्रेल मिलता है — कोई साझा सेवा अकाउंट नहीं और Perplexity के भीतर अपने रोल-आधारित एक्सेस नियंत्रण (RBAC) को फिर से बनाने की आवश्यकता नहीं। यह Snowflake की अपनी दिशा से भी मेल खाता है: इसका प्रबंधित MCP सर्वर आज केवल OAuth 2.0 का समर्थन करता है।
नोट: OAuth के साथ, एक्सेस टोकन साइन-इन के समय एक ही प्राथमिक रोल — उपयोगकर्ता के DEFAULT\_ROLE — से बंधा होता है। यह सुनिश्चित करने के लिए कि उपयोगकर्ता उन्हें दी गई हर चीज़ तक पहुँच सकें, द्वितीयक रोल्स कॉन्फ़िगर करें (User OAuth रोल कॉन्फ़िगरेशन देखें)।
एक साझा सेवा अकाउंट (TYPE = SERVICE + key pair) तब उपयुक्त है जब:
आपके अंतिम उपयोगकर्ताओं के पास व्यक्तिगत Snowflake अकाउंट नहीं हैं (उदाहरण के लिए, ऐसे व्यावसायिक उपयोगकर्ता जो Perplexity के माध्यम से क्वेरी करते हैं लेकिन जिनके पास Snowflake तक प्रत्यक्ष एक्सेस नहीं है)।
आप चाहते हैं कि सरल ऑडिटिंग के लिए सभी Perplexity क्वेरीज़ एक ही साझा पहचान के अंतर्गत चलें।
आप एक आंतरिक या परीक्षण वातावरण सेट कर रहे हैं जहाँ प्रति-उपयोगकर्ता पहचान की आवश्यकता नहीं है।
सेवा अकाउंट को एक समर्पित, संकीर्ण दायरे वाली रोल के साथ कॉन्फ़िगर करें — सेवा अकाउंट रोल कॉन्फ़िगरेशन देखें।
Programmatic Access Tokens (PATs) पर एक नोट: Snowflake PAT क्रेडेंशियल्स का भी समर्थन करता है, और कनेक्टर उन्हें स्वीकार करता है। हम नए सेटअप के लिए PAT की अनुशंसा नहीं करते — टोकन छोटी अवधि में समाप्त हो जाते हैं और निर्माण के समय एक ही रोल से कठोरता से बंधे होते हैं, इसलिए इस मार्गदर्शिका के सभी उदाहरणों में हम key pair का उपयोग करते हैं। यदि आपको PAT का उपयोग करना ही है, तो निर्माण के समय ROLE\_RESTRICTION को अपनी समर्पित Perplexity रोल पर सेट करें।
OAuth सत्र उपयोगकर्ता के DEFAULT\_ROLE को प्राथमिक रोल के रूप में लेकर खुलता है; सत्र के भीतर रोल बदलना समर्थित नहीं है और Perplexity कोई रोल चयनकर्ता नहीं दिखाता। इसलिए प्रत्येक उपयोगकर्ता ने DEFAULT\_ROLE और DEFAULT\_SECONDARY\_ROLES के लिए जो भी सेट किया है, ठीक वही उनका Perplexity सत्र उपयोग करता है।
इसे एक बार, सुरक्षा इंटीग्रेशन स्तर पर सेट करें:
OAUTH\_USE\_SECONDARY\_ROLES = IMPLICIT
Snowflake का इस पैरामीटर के लिए डिफ़ॉल्ट NONE है, जिसका अर्थ है कि OAuth सत्र केवल प्राथमिक रोल सक्रिय करके खुलते हैं। इसे IMPLICIT पर सेट करना Snowflake को बताता है कि प्रत्येक उपयोगकर्ता के DEFAULT\_SECONDARY\_ROLES को भी स्वचालित रूप से सक्रिय करे। इसके बिना, उपयोगकर्ता केवल वही डेटा देखते हैं जो उनके DEFAULT\_ROLE के माध्यम से पहुँच योग्य है — जो शायद ही कभी आप चाहते हैं।
इसके बाद दो मामलों में से एक को संभालें:
मामला A — उपयोगकर्ताओं के पास पहले से रोल डिफ़ॉल्ट्स हैं। यदि आपके उपयोगकर्ताओं के DEFAULT\_ROLE और DEFAULT\_SECONDARY\_ROLES पहले से वैसे ही सेट हैं जैसे आप चाहते हैं, तो कुछ और न करें। IMPLICIT सेटिंग पर्याप्त है — प्रत्येक उपयोगकर्ता के मौजूदा डिफ़ॉल्ट्स ही उनके Perplexity सत्र में उपयोग होते हैं।
मामला B — उपयोगकर्ताओं के पास अभी तक रोल डिफ़ॉल्ट्स नहीं हैं। DEFAULT\_ROLE को PUBLIC और DEFAULT\_SECONDARY\_ROLES को ALL पर सेट करके प्रत्येक सत्र को उस उपयोगकर्ता को दी गई सभी रोल्स का संघ दें:
ALTER USER \SET DEFAULT\_ROLE = PUBLIC, DEFAULT\_SECONDARY\_ROLES = ('ALL');
नोट: Snowflake के अगस्त 2024 के परिवर्तन के बाद से, नए बनाए गए उपयोगकर्ताओं के लिए DEFAULT\_SECONDARY\_ROLES = ('ALL') डिफ़ॉल्ट है, इसलिए कई संगठनों में यह पहले से सेट है। कुछ भी बदलने से पहले जाँचने के लिए DESC USER \ चलाएँ।
सेवा अकाउंट एक एकल समर्पित उपयोगकर्ता होता है जो एक विशिष्ट रोल के अंतर्गत चलता है — आमतौर पर PERPLEXITY\_ROLE। OAuth के लिए उपयोग किया जाने वाला PUBLIC + ('ALL') पैटर्न यहाँ लागू नहीं होता। इसके बजाय, सेवा उपयोगकर्ता के DEFAULT\_ROLE को अपनी समर्पित रोल पर सेट करें और उस रोल को केवल वही विशेषाधिकार दें जिनकी Perplexity को आवश्यकता है। यह Snowflake की सेवा अकाउंट सर्वोत्तम प्रथाओं का पालन करता है।
इस उपयोगकर्ता को बनाने का पूरा SQL नीचे सेटअप गाइड में दिया गया है।
यह सीमित करने के लिए कि उपयोगकर्ता Perplexity OAuth इंटीग्रेशन के माध्यम से किन Snowflake रोल्स में प्रमाणीकरण कर सकते हैं, इसे सुरक्षा इंटीग्रेशन स्तर पर सीमित करें:
PRE\_AUTHORIZED\_ROLES\_LIST — इस इंटीग्रेशन के माध्यम से अनुमत रोल्स की अनुमति सूची।
BLOCKED\_ROLES\_LIST — इस इंटीग्रेशन से अवरुद्ध रोल्स की अस्वीकृति सूची।
ALTER SECURITY INTEGRATION PERPLEXITY\_OAUTH
SET PRE\_AUTHORIZED\_ROLES\_LIST = ('ANALYST\_ROLE', 'READ\_ONLY\_ROLE');
संवेदनशील रोल्स (उदाहरण के लिए ACCOUNTADMIN) को OAuth फ़्लो से पूरी तरह बाहर रखने के लिए इसका उपयोग करें।
कनेक्टर SQL को एक टूल सरफ़ेस (Merge Snowflake कनेक्टर से प्राप्त) के माध्यम से निष्पादित करता है। Snowflake (User OAuth) कनेक्टर बारीक, नामित टूल्स प्रस्तुत करता है — जिसमें एक समर्पित केवल-पठनीय क्वेरी टूल (execute\_sql\_readonly) शामिल है, जो केवल SELECT, WITH, SHOW, DESCRIBE, EXPLAIN, VALUES, और LIST स्वीकार करता है, और DDL/DML तथा बहु-कथन इनपुट को अस्वीकार करता है। सेवा-अकाउंट Snowflake कनेक्टर एक सामान्य execute\_sql टूल प्रस्तुत करता है जो DDL और DML सहित मनमाना SQL स्वीकार करता है।
आधिकारिक नियंत्रण Snowflake RBAC है। चाहे कोई भी टूल कॉल किया जाए, क्वेरीज़ उसी रोल के अंतर्गत चलती हैं जिसकी आपका कॉन्फ़िगरेशन अनुमति देता है, इसलिए Snowflake रोल स्तर पर केवल-पठनीय प्रवर्तित करना ही विश्वसनीय बैकस्टॉप है — और सेवा-अकाउंट कनेक्टर पर यही एकमात्र प्रवर्तन सीमा है।
अनुशंसित पैटर्न — एक समर्पित रोल के साथ केवल-पठनीय प्रवर्तित करें। एक ऐसी रोल (जैसे PERPLEXITY\_READ\_ONLY) प्रावधान करें जो उन डेटाबेसेज़, स्कीमाज़, और टेबल्स पर केवल USAGE और SELECT देती है जिन्हें आप Perplexity को क्वेरी करने देना चाहते हैं, और INSERT, UPDATE, DELETE, CREATE, DROP, OWNERSHIP, या वेयरहाउस MODIFY नहीं देती। फिर सुनिश्चित करें कि उपयोगकर्ता उसी रोल में प्रमाणीकरण करें:
इसे उपयोगकर्ता के DEFAULT\_ROLE के रूप में सेट करें, या
OAuth इंटीग्रेशन को PRE\_AUTHORIZED\_ROLES\_LIST से सीमित करें और/या BLOCKED\_ROLES\_LIST के माध्यम से लिखने-सक्षम रोल्स को बाहर करें (OAuth के माध्यम से किन रोल्स का उपयोग किया जा सकता है, उसे प्रतिबंधित करना देखें)।
RBAC को इस तरह कॉन्फ़िगर करने पर, Snowflake Perplexity के किसी भी लेखन प्रयास को अस्वीकार कर देता है, चाहे कोई भी टूल कॉल किया जाए।
नोट: कनेक्टर सेटिंग्स में एक Tool permissions पैनल शामिल है जो उपलब्ध टूल्स की सूची देता है। Snowflake (User OAuth) कनेक्टर पर आप सीमित कर सकते हैं कि कौन से टूल्स प्रस्तुत किए जाएँ — केवल-पठनीय सेटअप के लिए, केवल रीड टूल्स सक्षम करें (उदाहरण के लिए execute\_sql\_readonly, list\_\*, describe\_\*, get\_\*) ताकि राइट/DDL टूल्स सरफ़ेस से बाहर रहें। इसे गहराई-में-सुरक्षा (defense-in-depth) मानें, आधिकारिक सीमा नहीं: Snowflake RBAC (ऊपर) ही वह है जो एक्सेस को विश्वसनीय रूप से प्रवर्तित करता है।
कनेक्ट होने पर, Snowflake कनेक्टर आपकी ओर से निम्नलिखित कार्रवाइयाँ कर सकता है:
आपके Snowflake डेटा पर SQL क्वेरीज़ निष्पादित करना
Cortex Search और Cortex Analyst क्वेरी करना
कस्टम UDFs और स्टोर्ड प्रोसीजर चलाना
यदि आप Snowflake में एक्सेस रद्द करते हैं या कोई रोल हटाते हैं, तो वह डेटा Perplexity से तुरंत अप्राप्य हो जाता है। यदि आप Perplexity में Snowflake को डिस्कनेक्ट करते हैं, तो आप चुन सकते हैं कि कैश्ड डेटा रखना है या डिलीट करना है।
Enterprise संगठनों के लिए, Perplexity SOC 2 Type II प्रमाणन, एंड-टू-एंड एन्क्रिप्शन, सख्त डेटा गोपनीयता उपाय, और बारीक उपयोगकर्ता एक्सेस नियंत्रण प्रदान करता है। आपके Snowflake डेटा का उपयोग AI प्रशिक्षण के लिए कभी नहीं किया जाता।
Snowflake को कनेक्ट करना प्रति-उपयोगकर्ता किया जाता है — आपके संगठन में कोई और आपका डेटा क्वेरी नहीं कर सकता। हालाँकि, यदि आप किसी साझा प्रोजेक्ट में डेटा सिंक करते हैं, तो उस प्रोजेक्ट तक एक्सेस वाला कोई भी व्यक्ति उसे खोज सकता है।
संगठन एडमिन Organization Settings में Permissions स्क्रीन से सभी उपयोगकर्ताओं के लिए कनेक्टर को सक्षम या अक्षम कर सकते हैं। रीड/राइट प्रवर्तन Snowflake रोल स्तर पर किया जाता है (Perplexity क्या कर सकता है, इसे नियंत्रित करना देखें)।
अपनी प्रमाणीकरण विधि से मेल खाने वाला मार्ग चुनें:
User OAuth (अनुशंसित): एक संगठन एडमिन OAuth ऐप को एक बार कॉन्फ़िगर करता है, फिर उपयोगकर्ता व्यक्तिगत रूप से साइन इन करते हैं। सीधे Snowflake को Perplexity से कनेक्ट करें पर जाएँ — चरण 1–6 का SQL केवल सेवा-अकाउंट सेटअप के लिए है।
सेवा अकाउंट (key pair): चरण 1–6 में SQL सेटअप चलाएँ, फिर चरण 7 में कनेक्ट करें।
ACCOUNTADMIN रोल (या CREATE USER और GRANT विशेषाधिकारों वाली कोई रोल)
लोकल मशीन पर OpenSSL इंस्टॉल हो (macOS पर पहले से इंस्टॉल) — केवल सेवा-अकाउंट सेटअप के लिए
अपने टर्मिनल से, एक 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
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 = 'XSMALL'
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;
इसे 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 को आवश्यकता है।
-- 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 डॉक्यूमेंटेशन देखें।
Perplexity सटीक क्वेरी निर्माण के लिए Data Map बनाने हेतु SNOWFLAKE.ACCOUNT\_USAGE स्कीमा के दो व्यूज़ का उपयोग करता है:
|
View |
उद्देश्य |
|
|
क्वेरी मेटाडेटा, प्रदर्शन, और उपयोग पैटर्न |
|
|
ऑब्जेक्ट-स्तरीय ऑडिट ट्रेल (केवल Enterprise Edition) |
USE ROLE ACCOUNTADMIN;
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE PERPLEXITY\_ROLE;
नोट: ACCESS\_HISTORY केवल Snowflake Enterprise Edition या उच्चतर पर उपलब्ध है; Standard Edition पर Perplexity स्वचालित रूप से QUERY\_HISTORY पर वापस आ जाता है। इस चरण को छोड़ने से क्वेरी सटीकता कम हो जाती है। Perplexity इन व्यूज़ का उपयोग कैसे करता है, इसके लिए Data Map को समझना देखें।