Wenn Sie Snowflake oder Databricks mit Perplexity verbinden, erstellt Computer eine Datenkarte Ihres Data Warehouses oder Lakehouses. Die Datenkarte erfasst wichtige Informationen zu Ihrem Datenmodell – relevante Tabellen und Spalten, gängige Abfragemuster und Beziehungen zwischen Objekten –, damit Computer Fragen in natürlicher Sprache in präzise Abfragen übersetzen kann.
Stellen Sie es sich als eine Karte Ihrer Datenumgebung vor, die Computer dabei hilft zu verstehen, was sich wo befindet und wie es typischerweise verwendet wird. Nach der Erstellung wird die Datenkarte fortlaufend weiter verbessert: Sie lernt aus Nutzerfeedback, kann direkt von Administratoren bearbeitet werden und wird versioniert, sodass Änderungen jederzeit überprüft und zurückgesetzt werden können.
Sobald die Generierung der Datenkarte gestartet wurde, erkundet Computer mithilfe der Berechtigungen Ihres verbundenen Kontos Ihr Datenmodell. Dieser Prozess untersucht Ihre Schemas, Tabellen, Views und historischen Nutzungsmuster, um ein umfassendes Verständnis Ihrer Daten zu erstellen.
Die Datenkarte wird sicher in einem organisationsweiten, versionierten Repository gespeichert, auf das nur Mitglieder Ihrer Organisation zugreifen können. Jede Änderung — sei es durch Neu-Generierung, Bearbeitungen durch Administratoren oder selbstlernende Aktualisierungen — wird protokolliert, damit sie überprüft und zurückgesetzt werden kann.
Es gibt eine Datenkarte pro Organisation, die von allen Mitgliedern dieser Organisation gemeinsam genutzt wird. Wenn ein Administrator die Generierung ausführt, geschieht dies im Namen der gesamten Organisation und nicht für einen einzelnen Nutzer.
Die Erstellung der Datenkarte für Snowflake wird von einem Organisationsadministrator über die Einstellungen des Snowflake-Connectors gestartet. Perplexity stellt zwei Snowflake-Connectoren bereit, und Administratoren erstellen die Datenkarte über den Konnektor, den ihre Organisation konfiguriert hat:
Snowflake (Schlüsselpaar oder PAT) — Abfragen werden als das konfigurierte Dienstkonto ausgeführt.
Snowflake (User OAuth) — Abfragen werden unter der Snowflake-Identität des Administrators ausgeführt, der die Generierung initiiert.
Welche Identität auch immer verwendet wird, sie muss die Account-Usage-Views von Snowflake lesen können (siehe unten Anforderungen). Wenn diese Berechtigungen fehlen, schlägt die Generierung unmittelbar mit einem klaren Berechtigungsfehler fehl, statt eine unvollständige Datenkarte zu erstellen.
Bei Databricks wird die Generierung über die Konnektor-Einstellungen mit der Databricks-OAuth-Identität des Initiators gestartet. Computer listet die Kataloge, Schemata und Tabellen auf, die der Nutzer in Unity Catalog sehen kann, und liest die Databricks-Systemtabellen, um Nutzungssignale zu erfassen. Alles, was der Initiator in Unity Catalog sehen kann, bestimmt, was letztendlich in der Datenkarte angezeigt wird.
Sie können ergänzenden Kontext hinzufügen — laden Sie Dateien hoch oder fügen Sie Notizen hinzu, die Ihre Daten beschreiben (z. B. wofür wichtige Tabellen stehen, geschäftliche Definitionen, gängige Abfragemuster) — damit Computer Ihre Daten genauer interpretieren kann. Der ergänzende Kontext wird in jeden Generierungslauf eingespeist und ist von der Regenerierung nicht betroffen, sodass Sie ihn im Laufe der Zeit weiter ergänzen können, ohne befürchten zu müssen, dass er verloren geht.
Nachdem die Generierung abgeschlossen ist, wird die Schaltfläche Datenkarte generieren im Konnektor-Dialog zu Wissen anzeigen. Wenn Sie auf Wissen anzeigen klicken, öffnet sich der Datenkarte-Editor, in dem Admins alles durchsuchen, bearbeiten und verwalten können, was Computer über Ihre Daten gelernt hat. Datenkarte neu generieren ist außerdem im Konnektor-Dialog verfügbar, sobald eine erste Datenkarte vorhanden ist — siehe Datenkarte neu generieren, um zu erfahren, was die Funktion bewirkt und was erhalten bleibt.
Das Erstellen einer Datenkarte kann je nach Größe und Komplexität Ihres Data Warehouse oder Lakehouse bis zu 90 Minuten dauern. Sie müssen die Seite nicht geöffnet lassen — der Vorgang läuft im Hintergrund, und die Schaltfläche Wissen anzeigen wird im Konnektor-Dialog angezeigt, sobald er abgeschlossen ist.
Der Datenkarte-Editor ist die Administratoransicht Ihrer Datenkarte und über die Admin-Tools der Organisation zugänglich. Er trennt Snowflake- und Databricks-Wissen in eigene Abschnitte, und der zugrunde liegende Geschäftskontext, die Tabellencluster und die Abfragemuster sind als Dateien organisiert, die Sie direkt lesen und bearbeiten können.
Im Editor können Administratoren:
Durchsuchen Sie die vollständige Datenkarte — geschäftlicher Kontext, Tabellencluster und gängige Abfragemuster.
Bearbeiten Sie Dateien direkt. Gespeicherte Änderungen werden sofort auf die aktive Datenkarte angewendet und werden zur neuen verlässlichen Quelle; sie müssen nicht den Review-Workflow durchlaufen.
Prüfen und handeln Sie auf KI-vorgeschlagene Änderungen aus der selbstlernenden Pipeline. Admins können den Vorschlag genehmigen (die Änderungen werden auf die Datenkarte angewendet) oder ablehnen (der Vorschlag wird verworfen). Eine direkte Anpassung eines Vorschlags vor der Genehmigung wird derzeit nicht unterstützt — Admins, die ein anderes Ergebnis wünschen, können den Vorschlag ablehnen und die Änderung anschließend selbst vornehmen.
Zeigen Sie den Versionsverlauf jeder Datei an und setzen Sie sie bei Bedarf zurück.
Direkte Bearbeitungen im Editor sind für die normale Nutzung dauerhaft, existieren jedoch parallel zum automatisch generierten Inhalt und werden nicht beibehalten, wenn Sie die Datenkarte für dieses Warehouse neu generieren — siehe unten Datenkarte neu generieren.
Die Datenkarte wird umso besser, je mehr Ihr Team sie nutzt. Wenn ein Nutzer den Daten-Agenten in einer Sitzung korrigiert — zum Beispiel: "verwende fct\_queries statt query\_events für Abfrageanzahlen" oder "schließe type = 'internal' aus den Metriken zum Abfragevolumen aus" — erfasst Computer dieses Feedback und nutzt es, um die Datenkarte für alle zu verbessern.
Die Pipeline ist darauf ausgelegt, sicher, prüfbar und organisationseinheitlich gemeinsam nutzbar zu sein:
Wenn ein Nutzer in einer Data Scientist-Sitzung Feedback gibt, protokolliert Computer eine strukturierte Korrektur — die Datei, die betroffen sein soll, den Abschnitt, die vorgeschlagene Änderung und den Sitzungskontext, aus dem sie hervorgegangen ist. Die Datenkarte selbst wird niemals direkt aus einer Nutzersitzung live bearbeitet; Feedback landet zunächst immer nur in diesem Protokoll.
Einmal täglich überprüft Computer die in den letzten 24 Stunden für jede Organisation erfassten Korrekturen und erstellt eine einzelne, konsolidierte vorgeschlagene Aktualisierung für die Datenkarte:
Mehrere Korrekturen am selben Bereich werden zu einer zusammengeführt.
Widersprüchliche Korrekturen (z. B. eine sagt „Cron-Jobs immer einschließen“, eine andere „Cron-Jobs immer ausschließen“) werden zur manuellen Prüfung zurückgestellt statt automatisch aufgelöst.
Jede Korrektur wird dem richtigen Warehouse zugewiesen — eine Snowflake-spezifische Korrektur fließt nicht in die Databricks Datenkarte ein und umgekehrt.
Korrekturen, die nicht zuverlässig zusammengeführt oder zugewiesen werden können, werden zur Prüfung durch einen Administrator markiert, anstatt stillschweigend übernommen zu werden.
Das Ergebnis wird im Datenkarte-Editor als ein einzelner Vorschlag angezeigt, den Admins überprüfen können.
Admins genehmigen den Vorschlag (die Änderungen werden auf die Datenkarte angewendet) oder lehnen ihn ab (der Vorschlag wird verworfen). Die Genehmigung ist das, was die Änderungen „bereitstellt“ — die nächste Datenfrage, die Ihr Team stellt, verwendet die aktualisierte Datenkarte. Es gibt keinen separaten Veröffentlichungsschritt.
Dieses Human-in-the-loop-Muster ist beabsichtigt: Es ermöglicht Computer, kontinuierlich aus der realen Nutzung zu lernen, während Administratoren die Kontrolle darüber behalten, was als verlässliche Ground Truth gilt.
Wer kann was tun?
Jeder Nutzer in einer Data Scientist-Sitzung kann Feedback geben, das in den vorgeschlagenen Update-Vorschlag des nächsten Tages einfließt.
Organisationsadmins können Datenkarte-Dateien direkt durchsuchen und bearbeiten sowie die täglichen vorgeschlagenen Updates im Datenkarte-Editor genehmigen oder ablehnen.
Es gibt eine Datenkarte pro Organisation — jedes Mitglied der Organisation führt Abfragen gegen dieselbe gemeinsam genutzte Datenkarte aus. Es gibt keine Datenkarte pro Nutzer.
Admins können Datenkarte neu generieren jederzeit über das Konnektor-Dialog ausführen. Derzeit ist die Neuerstellung ein Neubau von Grund auf für das Warehouse, das Sie neu generieren:
Die Datenkarte für dieses Warehouse wird vollständig durch ein neues Ergebnis ersetzt. Manuelle Admin-Bearbeitungen an der Datenkarte dieses Warehouses werden nicht beibehalten.
Die Datenkarte des anderen Warehouses bleibt unverändert — die Neuerstellung für Snowflake hat keine Auswirkungen auf Databricks und umgekehrt.
Zusätzlicher Kontext wird beibehalten und für den neuen Durchlauf erneut angewendet.
Ausstehendes Feedback (Korrekturen, die an diesem Tag protokolliert, aber noch nicht in ein vorgeschlagenes Update übernommen wurden) wird beibehalten. Feedback, das bereits genehmigt und auf die Datenkarte angewendet wurde, gehört zu dem, was ersetzt wird.
Die vollständige Versionshistorie bleibt erhalten, sodass frühere Versionen der Datenkarte weiterhin geprüft werden können.
Da die Neuerstellung die Datenkarte eines Warehouses und alle daran vorgenommenen Admin-Bearbeitungen ersetzt, sollte sie gezielt ausgeführt werden. Eine sicherere Neuerstellung, die Admin-Bearbeitungen beibehält — sowie ein separater expliziter "full reset" — sind für die Roadmap vorgesehen, sind aber derzeit noch nicht im Produkt verfügbar.
Die Identität, die zum Erstellen der Datenkarte verwendet wird — das Servicekonto für die Schlüsselpaar- / PAT-Authentifizierung oder der Snowflake-Nutzer des initiierenden Administrators für die OAuth-Authentifizierung — muss beide dieser Ansichten im Schema SNOWFLAKE.ACCOUNT\_USAGE lesen können:
SNOWFLAKE.ACCOUNT\_USAGE.QUERY\_HISTORY
SNOWFLAKE.ACCOUNT\_USAGE.ACCESS\_HISTORY (Snowflake Enterprise Edition oder höher)
Wichtig: ACCOUNT\_USAGE ist standardmäßig nur für Administratoren verfügbar. Die häufigste Ursache für das Fehlschlagen der Generierung ist eine Rolle, die Ihre regulären Datenbanken lesen kann, aber keinen Zugriff auf ACCOUNT\_USAGE hat. Die Lösung besteht darin, IMPORTED PRIVILEGES für die Datenbank SNOWFLAKE zu gewähren.
Falls Sie diesen Zugriff nicht bereits während der Ersteinrichtung gewährt haben, führen Sie Folgendes als ACCOUNTADMIN aus: