Looker mit Ihrer Datenbank verbinden

Nachdem Sie Ihre Datenbank sichert und konfiguriert haben, können Sie Ihre Datenbank mit Looker verbinden.

Eine neue Datenbankverbindung erstellen

Wählen Sie im Bereich Datenbank im Steuerfeld Admin die Option Verbindungen aus. Klicken Sie auf der Seite Verbindungen auf die Schaltfläche Verbindung hinzufügen. Looker zeigt die Seite Verbindungseinstellungen an. Welche Felder auf der Seite Verbindungseinstellungen angezeigt werden, hängt von Ihrer Dialekteinstellung ab.

Weitere Informationen zum Anwenden von Nutzerattributen auf Verbindungseinstellungen finden Sie auf der Dokumentationsseite Nutzerattribute im Abschnitt Verbindungen.

Weitere Informationen zur Verwendung der Spalte PDT-Überschreibungen zum Konfigurieren separater Anmeldedaten für PDT-Prozesse finden Sie im Abschnitt Separate Anmeldedaten für PDT-Prozesse konfigurieren.

Die folgenden Optionen sind beispielsweise für die Konfiguration verfügbar, wenn Sie Looker mit Amazon Redshift verbinden.

Name

Der gewünschte Name für die Verbindung. Sie sollten den Namen von folders nicht verwenden. Dieser Wert muss keine Übereinstimmung in Ihrer Datenbank haben. Es handelt sich lediglich um eine von Ihnen zugewiesene Bezeichnung. Sie verwenden ihn im Parameter connection Ihres LookML-Modells.

Dialekt

Der entsprechende SQL-Dialekt Ihrer Verbindung. Es ist wichtig, den richtigen Wert auszuwählen, damit Ihnen die richtigen Verbindungsoptionen angezeigt werden und Looker Ihre LookML ordnungsgemäß in SQL übersetzen kann.

SSH-Server

Die Option SSH Server ist verfügbar, wenn die Instanz in der Kubernetes-Infrastruktur bereitgestellt wird, und wenn die Möglichkeit zum Hinzufügen von SSH-Serverkonfigurationsinformationen zu Ihrer Looker-Instanz aktiviert ist. Wenn diese Option für Ihre Looker-Instanz nicht aktiviert ist und Sie sie aktivieren möchten, wenden Sie sich an Ihren Looker-Account Manager oder öffnen Sie eine Supportanfrage in der Looker-Hilfe.

Der SSH-Server wählt den localhost-Port automatisch für Sie aus. Die Angabe des localhost-Ports ist derzeit nicht möglich. Wenn Sie eine SSH-Verbindung erstellen müssen, für die Sie einen Localport-Port angeben müssen, wenden Sie sich an Ihren Looker-Account Manager oder öffnen Sie eine Supportanfrage von Looker.

Wenn Sie eine Verbindung zu Ihrer Datenbank über einen SSH-Tunnel herstellen möchten, aktivieren Sie die Ein-/Aus-Schaltfläche und wählen Sie in der Drop-down-Liste eine SSH-Serverkonfiguration aus.

Remote Host:Port

Der Hostname Ihrer Datenbank und der Port, den Looker zur Verbindungsherstellung mit Ihrem Datenbank-Host verwenden soll.

Wenn Sie mit einem Looker-Analysten zusammen einen SSH-Tunnel für Ihre Datenbank konfiguriert haben, geben Sie in das Feld Host "localhost" und in das Feld Port die Portnummer ein, die zu Ihrer Datenbank weitergeleitet wird. Dies sollte Ihr Looker-Analyst angegeben haben.

Wenn Sie ein Nutzerattribut auf das Feld Host anwenden, darf für das Nutzerattribut die Nutzerzugriffsebene nicht auf Bearbeitbar festgelegt sein.

Wenn Sie einen SSH-Tunnel zur Verbindung mit Ihrer Datenbank konfiguriert haben, können Sie kein Nutzerattribut auf das Feld Remote-Host:Port anwenden.

Datenbanken

Der Name der Datenbank auf Ihrem Host. Beispiel: Sie haben den Hostnamen my-instance.us-east-1.redshift.amazonaws.com, für den es eine Datenbank namens sales_info gibt. In dieses Feld würden Sie sales_info eingeben. Wenn Sie mehrere Datenbanken auf demselben Host haben, müssen Sie möglicherweise mehrere Verbindungen zu diesen erstellen, mit Ausnahme von MySQL, bei dem das Wort Datenbank etwas anderes als in den meisten SQL-Dialekten bedeutet.

OAuth verwenden

Bei Snowflake- und Google BigQuery-Verbindungen haben Sie nun die Möglichkeit, OAuth zu verwenden. Dies bedeutet, dass Ihre Benutzer sich bei Snowflake bzw. Google anmelden müssen, um Abfragen von Looker ausgeben zu können.

Wenn Sie OAuth verwenden auswählen, sehen Sie die Felder OAuth-Client-ID und OAuth-Clientschlüssel:

Diese Werte werden von der Snowflake-Datenbank oder von Google generiert. Die vollständige Anleitung finden Sie auf der Dokumentationsseite, auf der die OAuth-Konfiguration für Schneeflocken oder OAuth-Konfiguration für Google BigQuery beschrieben wird.

Nutzername

Der Benutzername, den Looker zur Verbindungsherstellung mit Ihrer Datenbank verwenden soll. Konfigurieren Sie den Nutzer vorab gemäß unserer Anleitung zur Datenbankkonfiguration.

Passwort

Das Passwort, das Looker zur Verbindungsherstellung mit Ihrer Datenbank verwenden soll. Konfigurieren Sie das Passwort vorab gemäß unserer Anleitung zur Datenbankkonfiguration.

Schema

Das von Looker verwendete Standardschema, wenn kein Schema angegeben ist. Das gilt, wenn Sie SQL Runner, während der LookML-Projektgenerierung und beim Abfragen von Tabellen verwenden.

Persistente abgeleitete Tabellen

Klicken Sie dieses Kästchen an, um persistente abgeleitete Tabellen zu aktivieren. Dadurch werden zusätzliche PDT-Felder und die Spalte PDT-Überschreibungen eingeblendet. Looker zeigt diese Option nur an, wenn der Datenbankdialekt die Verwendung von PDTs unterstützt.

Beachten Sie Folgendes zu PDTs:

  • PDTs werden für Snowflake-Verbindungen, die OAuth verwenden, nicht unterstützt.
  • Durch das Deaktivieren von PDTs für eine Verbindung werden die mit Ihren PDTs verbundenen Datengruppen nicht deaktiviert. Selbst wenn Sie PDTs deaktivieren, führen vorhandene Datengruppen weiterhin ihre sql_trigger-Abfragen für die Datenbank aus. Wenn Sie verhindern möchten, dass eine Datengruppe „sql_trigger“ für Ihre Datenbank ausgeführt wird, müssen Sie den Parameter datagroup aus Ihrem LookML-Projekt löschen oder auskommentieren. Alternativ können Sie die Einstellung PDT- und Datagroup-Wartungsplan für die Verbindung aktualisieren, sodass Looker PDTs und Datengruppen selten oder nie prüft.
  • Bei Snowflake-Verbindungen setzt Looker den Wert für den Parameter AUTOCOMMIT auf TRUE (Standardwert von Schneeflake). AUTOCOMMIT ist für SQL-Befehle erforderlich, die Looker ausführt, um sein PDT-Registrierungssystem aufrechtzuerhalten.

Temp Database

Obwohl diese mit Temp Database gekennzeichnet ist, geben Sie je nach SQL-Dialekt entweder den Datenbank- oder Schemanamen ein, den Looker zum Erstellen persistenter abgeleiteter Tabellen verwenden soll. Diese Datenbank oder dieses Schema sollten Sie im Voraus mit den entsprechenden Schreibberechtigungen konfigurieren. Wählen Sie auf der Dokumentationsseite zur Datenbankkonfiguration den Datenbankdialekt aus, um die Anleitungen für diesen Dialekt aufzurufen.

Jede Verbindung muss eine eigene Temp-Datenbank oder ein Schema haben. Sie können nicht verbindungsübergreifend genutzt werden.

Max PDT Builder Connections

Mit der Einstellung Max PDT Builder Connections (Max. PDT-Builder-Verbindungen) können Sie angeben, wie viele gleichzeitige Tabellen-Builds der Looker-Regenerator für Ihre Datenbankverbindung initiieren kann. Die Einstellung Max PDT Builder Connections gilt nur für die Tabellentypen, für die der Looker-Regenerator neue Builds initiiert:

  • Andauernde Trigger-Tabellen (persistente abgeleitete Tabellen und zusammengefasste Tabellen, die die Persistenzstrategie datagroup_trigger oder sql_trigger_value verwenden)
  • Vorhandene Tabellen, die die Strategie persist_for verwenden, aber nur dann, wenn die Tabelle persist_for Teil einer Kaskade abgeleiteter Tabellen ist, von denen eine Tabelle mit der Persistenzstrategie datagroup_trigger oder sql_trigger_value abhängt. In diesem Fall erstellt der Looker-Regenerator eine persist_for-Tabelle, da die Tabelle zum Erstellen einer anderen Tabelle im Kaskaden benötigt wird. Andernfalls initiiert der Regenerator keine Builds für persist_for-Tabellen.

Die Einstellung Max PDT Builder Connections ist standardmäßig auf 1 eingestellt, kann jedoch auf 10 festgelegt werden. Der Wert darf jedoch nicht höher als der Wert sein, der im Feld Max. Verbindungen oder in der per-user-query-limit festgelegt ist, die in den Startoptionen von Looker festgelegt wurde.

Wählen Sie diesen Wert mit Bedacht. Ist der Wert zu hoch, überlastet dies möglicherweise Ihre Datenbank. Wenn der Wert niedrig ist, können PDTs oder aggregierte Tabellen mit langer Ausführungszeit die Erstellung anderer persistenter Tabellen verzögern oder andere Abfragen für die Verbindung verlangsamen. Datenbanken, die Mehrinstanzenfähigkeit unterstützen – z. B. BigQuery, Snowflake und Redshift – können bei der Verarbeitung paralleler Abfrage-Builds möglicherweise leistungsfähiger sein.

Wenn Sie die Einstellung Max PDT Builder Connections erhöhen möchten, ist es eine gute Faustregel, die Zahl um 1 zu erhöhen. Sollte ein unerwartetes Verhalten auftreten, setzen Sie es auf den Standardwert 1 zurück. Wenn die Abfrageleistung nicht beeinträchtigt wird, können Sie sie weiterhin schrittweise um 1 erhöhen und die Leistung bei jeder einzelnen Steigerung prüfen, bevor Sie die Einstellung weiter erhöhen.

Beachten Sie Folgendes zur Einstellung Max. PDT Builder-Verbindungen:

  • Die Einstellung Max. PDT-Builder-Verbindungen gilt nur für Verbindungen, die für die Neuerstellung von Tabellen erforderlich sind, nicht für die Verbindungen, die für Triggerprüfungen erforderlich sind. Eine Triggerprüfung ist eine Abfrage, mit der geprüft wird, ob die Persistenzstrategie der Tabelle ausgelöst wird. Da diese Trigger-Abfrageabfragen immer nacheinander ausgeführt werden, gilt die Einstellung Max PDT Builder Connections nicht.
  • In einer geclusterten Looker-Instanz wird der Regenerator nur auf dem Hauptknoten ausgeführt. Die Einstellung Max PDT Builder Connections gilt nur für den Hauptknoten und legt damit das Limit für den gesamten Cluster fest.
  • Die Einstellung Max PDT Builder Connections (Max. PDT-Builder-Verbindungen) gilt nicht für die folgenden Tabellentypen. Diese Arten von Tabellen werden nacheinander erstellt:
    • Tabellen, die über den Parameter persist_for beibehalten werden (es sei denn, die Tabelle ist von Tabellen mit der Strategie datagroup_trigger oder sql_trigger_value abhängig).
    • Tabellen im Entwicklungsmodus:
    • Mit der Option Abgeleitete Tabellen &Ausführen erstellen erstellte Tabellen.
    • Tabellen, in denen eine Abhängigkeit von einer anderen Kaskade abhängt. Eine Tabelle kann nicht gleichzeitig mit einer Tabelle erstellt werden, von der sie abhängt. Wenn table_B beispielsweise von table_A abhängt, muss table_A den Neuerstellungsvorgang abschließen, bevor table_B ihn neu erstellen kann.

Always Retry Failed PDT Builds

Mit der Einstellung Immer fehlgeschlagene PDT-Builds wiederholen wird konfiguriert, wie mit dem Looker-Regenerator versucht wird, triggerbasierte Abfragen zu erstellen, die im vorherigen Regeneratorzyklus fehlgeschlagen sind. Mit dem Looker-Regenerator werden die per Trigger beibehaltenen Tabellen (PDTs und zusammengefasste Tabellen) gemäß dem Intervall neu erstellt, das in der Verbindungseinstellung PDT und Datagroup-Wartungsplan konfiguriert ist. Wenn die Einstellung Fehlgeschlagene PDT-Builds immer wiederholen aktiviert ist, versucht der Looker-Regenerator einen PDT, der im vorherigen Regeneratorzyklus fehlgeschlagen ist, neu zu erstellen, auch wenn die PDT-Triggerbedingung nicht erfüllt ist. Wenn diese Einstellung deaktiviert ist, versucht der Looker-Regenerator, eine zuvor fehlgeschlagene PDT nur dann neu zu erstellen, wenn die Triggerbedingung der PDT erfüllt ist. Builds wiederholt fehlgeschlagener Builds immer wiederholen ist standardmäßig deaktiviert.

Weitere Informationen zum Looker-Regenerator finden Sie in der Dokumentation zur abgeleiteten Tabelle in Looker.

Enable PDT API Control

Mit der Einstellung PDT API-Steuerung aktivieren wird festgelegt, ob die API-Aufrufe start_pdt_build, check_pdt_build und stop_pdt_build für diese Verbindung verwendet werden können. Ist diese Einstellung aktiviert, schlagen diese API-Aufrufe fehl, wenn sie auf PDTs für diese Verbindung verweisen. Die Option PDT API-Steuerung aktivieren ist standardmäßig deaktiviert.

Additional Params

Sie können hier gegebenenfalls zusätzliche Java Database Connectivity (JDBC)-Parameter für Ihre Abfragen angeben.

Wenn Sie in einem JDBC-Parameter auf ein Nutzerattribut verweisen möchten, verwenden Sie die Syntax Flüssigkeitsvorlagen: _user_attributes['name_of_attribute']. Beispiel:

my_jdbc_param={{ _user_attributes['name_of_attribute'] }}

So könnte es in Looker im Feld Zusätzliche Parameter aussehen:

Zusätzliche JDBC-Parameter wurden nicht von Looker getestet und können zu unbeabsichtigtem Verhalten führen.

PDT and Datagroup Maintenance Schedule

Für diese Einstellung kann ein cron-Ausdruck verwendet werden, der angibt, wann die Looker-Regenerator Datengruppen und persistente Tabellen (sowohl zusammengefasste Tabellen als auch persistente abgeleitete Tabellen) prüfen sollen, die auf sql_trigger_value basieren, und sehen, welche Tabellen neu generiert oder gelöscht werden sollten.

Der Standardwert von */5 * * * * gibt an, dass alle fünf Minuten eine Vorabprüfung durchgeführt werden soll. Ein cron-Ausdruck, der auf häufigere Prüfungen hindeutet, führt alle fünf Minuten zu Prüfungen.

Während der PDT-Erstellung führt Looker keine zusätzlichen Auslöserprüfungen durch. Nachdem alle PDTs aus der letzten Auslöserprüfung erstellt wurden, setzt Looker die Prüfung von Datengruppen- und PDT-Auslösern entsprechend dem Wartungszeitplan für PDTs und Datengruppen (PDT and Datagroup Maintenance Schedule) fort.

Wenn Ihre Datenbank nicht rund um die Uhr aktiv ist, können Sie die Überprüfung auf Zeiten beschränken, zu denen sie verfügbar ist. Hier sind einige zusätzliche cron-Ausdrücke:

cron-Ausdruck Definition
*/5 8-17 * * MON-FRI Datengruppen und PDTs während der Geschäftszeiten alle 5 Minuten prüfen, montags bis freitags
*/5 8-17 * * * Datengruppen und PDTs während der Geschäftszeiten alle 5 Minuten prüfen, täglich
0 8-17 * * MON-FRI Datengruppen und PDTs während der Geschäftszeiten stündlich prüfen, montags bis freitags
1 3 * * * Datengruppen und PDTs täglich um 3:01 prüfen

Beachten Sie beim Erstellen eines cron-Ausdrucks Folgendes:

  • Looker verwendet parse-cron v0.1.3, die ? in cron-Ausdrücken nicht unterstützt.
  • Der Ausdruck cron verwendet die Anwendungszeitzone von Looker, um zu bestimmen, wann Prüfungen ausgeführt werden.
  • Wenn PDTs nicht erstellt werden, setzen Sie den Cron-String auf den Standardwert */5 * * * * zurück.

Im Folgenden finden Sie einige Ressourcen zum Erstellen von cron-Strings:

SSL

Wählen Sie aus, ob Ihre Daten bei der Übergabe zwischen Looker und Ihrer Datenbank mit SSL-Verschlüsselung geschützt werden sollen. SSL ist nur eine von mehreren Optionen, die zum Schutz Ihrer Daten eingesetzt werden können. Andere sichere Optionen finden Sie auf der Dokumentationsseite Sicheren Datenbankzugriff aktivieren.

Verify SSL Cert

Geben Sie an, ob die Verifizierung des von der Verbindung verwendeten SSL-Zertifikats angefordert werden soll. Wenn eine Bestätigung erforderlich ist, muss die SSL-Zertifizierungsstelle, die das SSL-Zertifikat signiert hat, aus der Liste der vertrauenswürdigen Quellen des Clients stammen. Handelt es sich bei der Zertifizierungsstelle um keine vertrauenswürdige Quelle, wird die Datenbankverbindung nicht hergestellt.

Wenn dieses Kästchen nicht ausgewählt ist, wird für die Verbindung weiterhin die SSL-Verschlüsselung verwendet. Eine Bestätigung der SSL-Verbindung ist jedoch nicht erforderlich, sodass eine Verbindung hergestellt werden kann, wenn die Zertifizierungsstelle nicht auf der Clientliste der vertrauenswürdigen Quellen steht.

Max Connections

Hier können Sie die Anzahl der Verbindungen festlegen, die Looker höchstens mit Ihrer Datenbank herstellen kann. Dabei legen Sie überwiegend die Anzahl der Abfragen fest, die Looker gleichzeitig für Ihre Datenbank ausführen kann. Looker reserviert zudem bis zu drei Verbindungen für das Beenden von Abfragen. Ist der Verbindungspool sehr klein, reserviert Looker weniger Verbindungen.

Wählen Sie diesen Wert mit Bedacht. Ist der Wert zu hoch, überlastet dies möglicherweise Ihre Datenbank. Ist er zu niedrig, müssen sich Abfragen eine kleine Anzahl an Verbindungen teilen. Das bedeutet, dass viele Abfragen Benutzern langsam erscheinen, da die Abfragen warten müssen, bis andere, frühere Abfragen beantwortet wurden.

Der Standardwert (der je nach verwendetem SQL-Dialekt unterschiedlich ausfällt) ist in der Regel ein guter Ausgangspunkt. Die meisten Datenbanken verfügen außerdem über ihre eigenen Einstellungen für die von ihnen maximal akzeptierte Anzahl Verbindungen. Wenn in Ihrer Datenbankkonfiguration Verbindungen begrenzt sind, muss der Wert für Max Connections (Verbindungen maximal) dem Grenzwert Ihrer Datenbank entsprechen oder niedriger sein.

Connection Pool Timeout

Wenn Ihre Nutzer mehr Verbindungen anfordern als die Einstellung Max. Verbindungen, wird die Ausführung anderer Anfragen erst nach Abschluss abgeschlossen. Hier wird die maximale Wartezeit für eine Anforderung festgelegt. Diesen Wert sollten Sie mit Bedacht wählen. Wenn er zu niedrig ist, werden die Abfragen möglicherweise abgebrochen, weil nicht genug Zeit für andere Suchanfragen zur Verfügung steht. Ist er zu hoch, entsteht möglicherweise eine große Warteschlange mit Benutzeranfragen und lange Wartezeiten für Benutzer. Der Standardwert ist in der Regel ein guter Ausgangspunkt.

Kostenschätzung

Das Kästchen Kostenschätzung gilt nur für die folgenden Datenbankverbindungen:

Das Kästchen Kostenschätzung aktiviert die folgenden Funktionen für die Verbindung:

BigQuery- und MySQL-Verbindungen unterstützen auch die Kostenschätzung. Da diese Funktion jedoch immer aktiviert ist, gibt es kein Häkchen bei Kostenschätzung für BigQuery- und MySQL-Verbindungen.

Weitere Informationen finden Sie auf der Dokumentationsseite Daten in Looker untersuchen.

Vorabzwischenspeicherung durch SQL-Runner

In SQL-Runner werden alle Tabelleninformationen unmittelbar nach der Auswahl einer Verbindung und eines Schemas vorab geladen. Somit kann SQL-Runner Tabellenspalten schnell anzeigen, nachdem Sie auf einen Tabellennamen geklickt haben. Für Verbindungen und Schemata mit vielen Tabellen oder sehr großen Tabellen soll SQL-Runner jedoch möglicherweise nicht alle Informationen vorab laden.

Wenn der SQL Runner die Tabelleninformationen nur laden soll, wenn eine Tabelle ausgewählt ist, können Sie die Option SQL-Runner Precache deaktivieren, um das Vorabladen des SQL Runners für die Verbindung zu deaktivieren.

Fetch Information Schema For SQL Writing

Für einige SQL-Schreibfunktionen wie zusammengefasste Bekanntheit verwendet Looker das Informationsschema Ihrer Datenbank, um SQL-Schreibvorgänge zu optimieren. Falls das Informationsschema nicht zwischengespeichert ist, muss Looker das Schreiben von SQL in die Datenbank möglicherweise gelegentlich blockieren, um das Informationsschema abzurufen. Bei Dialekten, die Hadoop Distributed File System (HDFS) verwenden, kann das Abrufen des Informationsschemas lange dauern, um die Leistung Ihrer Looker-Abfragen erheblich zu beeinträchtigen. Wenn Sie wissen, dass Ihr Informationsschema langsam ist, können Sie die Option Schema für SQL-Schreibvorgang abrufen deaktivieren. Wenn Sie diese Funktion deaktivieren, werden einige SQL-Optimierungen von Looker für bestimmte Funktionen verhindert. Sie sollten daher die Option Schema für Informationen zum SQL-Schreiben abrufen aktivieren, es sei denn, Sie wissen, dass Ihr Informationsschema besonders langsam ist.

Disable Context Comment

Die Option Kontextkommentar deaktivieren gilt nur für BigQuery-Verbindungen. Kontextkommentare in Google BigQuery-Verbindungen sind standardmäßig deaktiviert, da Kontextkommentare die Cache-Funktion von Google ungültig machen und sich negativ auf die Cache-Leistung auswirken können. Sie können Kontextkommentare für eine BigQuery-Verbindung aktivieren, indem Sie die Einstellung Kontextkommentar deaktivieren auf der Seite Verbindungseinstellungen für die Verbindung deaktivieren. Weitere Informationen finden Sie auf der Dokumentationsseite von Google BigQuery.

Zeitzone der Datenbank

Die Zeitzone, in der Ihre Datenbank zeitbasierte Informationen speichert. Looker muss diese kennen, damit Zeitwerte für Benutzer konvertiert werden können. Dies erleichtert das Verständnis und die Nutzung zeitbasierter Daten. Weitere Informationen finden Sie auf der Dokumentationsseite Einstellungen für die Zeitzone verwenden.

Zeitzone der Abfrage

Die Option Abfragezeitzone ist nur sichtbar, wenn Sie Nutzerspezifische Zeitzonen deaktiviert haben.

Wenn benutzerdefinierte Zeitzonen deaktiviert sind, wird die Abfragezeitzone als Zeitzone angezeigt, die Ihren Nutzern beim Abfragen zeitbasierter Daten angezeigt wird, sowie in der Zeitzone, in die Looker zeitbasierte Daten aus der Datenbankzeitzone konvertiert.

Weitere Informationen finden Sie auf der Dokumentationsseite Einstellungen für die Zeitzone verwenden.

Eigene Anmeldedaten für PDT-Prozesse konfigurieren

Wenn Ihre Datenbank nichtflüchtige, abgeleitete Tabellen unterstützt und Sie das Kästchen Persistente abgeleitete Tabellen in den Verbindungseinstellungen angeklickt haben, zeigt Looker die Spalte PDT-Überschreibungen an. In der Spalte PDT-Überschreibungen können Sie separate JDBC-Parameter (Host, Port, Datenbank, Nutzername, Passwort, Schema und zusätzliche Parameter) eingeben, die für PDT-Prozesse spezifisch sind. Dies kann aus verschiedenen Gründen hilfreich sein:

  • Wenn Sie einen separaten Datenbanknutzer für PDT-Prozesse erstellen, können Sie PDTs in Ihrem Modell verwenden, auch wenn Sie Ihren Anmeldedaten für die Datenbank Nutzerattribute zuweisen.
  • PDT-Prozesse können durch einen eigenen Datenbankbenutzer authentifiziert werden, der über eine höhere Priorität verfügt. Somit kann die Datenbank PDT-Jobs eine höhere Priorität einräumen als weniger wichtigen Benutzerabfragen.
  • Der Schreibzugriff kann für die Standard-Looker-Datenbankverbindung entzogen und nur einem bestimmten Benutzer zugewiesen werden, den PDT-Prozesse zur Authentifizierung verwenden. Dies ist für die meisten Unternehmen eine bessere Sicherheitsstrategie.
  • Für Datenbanken wie Snowflake können PDT-Prozesse an leistungsstärkere Hardware weitergeleitet werden, die nicht mit den anderen Looker-Nutzern geteilt wird. Auf diese Weise können PDTs schnell erstellt werden, ohne dass die Notwendigkeit entsteht, jederzeit kostenintensive Hardware vorzuhalten.

Die folgende Konfiguration zeigt beispielsweise eine Verbindung, in die Felder für Benutzernamen und Passwort auf Benutzerattribute festgelegt sind. Somit kann jeder Benutzer mit seinen eigenen Anmeldedaten auf die Datenbank zugreifen. In der Spalte PDT-Überschreibung wird ein separater Nutzer (pdt_user) mit eigenem Passwort erstellt. Das Konto pdt_user wird für alle PDT-Prozesse mit Zugriffsebenen verwendet, die der Erstellung und Aktualisierung der PDT entsprechen:

In der Spalte PDT-Überschreibungen können Sie den Datenbanknutzer und andere Verbindungseigenschaften ändern. Eine PDT-Überschreibung muss jedoch dieselben Daten wie die Standardverbindung lesen und Daten an denselben Ort schreiben. Looker kann nicht Daten von einem Ort lesen und an einen anderen Ort schreiben.

Ihre Verbindungseinstellungen testen

Nachdem Sie die Anmeldedaten eingegeben haben, klicken Sie auf Diese Einstellungen testen, um zu prüfen, ob die Informationen korrekt sind und die Datenbank eine Verbindung herstellen kann.

Sollte Ihre Verbindung einen oder zwei Tests nicht bestehen:

  • Probieren Sie einige der Schritte zur Fehlerbehebung auf der Dokumentationsseite Datenbankverbindung testen aus.
  • Wenn Sie die Versa 3.6 oder älter auf Atlas ausführen und ein Fehler bei der Kommunikationsverknüpfung auftritt, lesen Sie die Dokumentation zum Mongo Connector.
  • Meldungen zu erfolgreichen Verbindungen für das Temp-Schema und PDTs erhalten Sie nur, wenn Sie diese Funktion bei der Konfiguration Ihrer Looker-Datenbank aktiviert haben. Eine Anleitung dazu finden Sie auf der Dokumentationsseite Datenbankkonfigurationsanleitung.

Für Datenbankverbindungen mit OAuth, z. B. Snowflake und Google BigQuery, ist eine Nutzeranmeldung erforderlich. Wenn Sie beim Testen einer dieser Verbindungen nicht in Ihrem OAuth-Nutzerkonto angemeldet sind, zeigt Looker eine Warnung mit dem Link Anmelden an. Klicken Sie auf den Link, um Ihre OAuth-Anmeldedaten einzugeben oder Looker den Zugriff auf Ihre OAuth-Kontoinformationen zu gestatten.

Sollten weiterhin Probleme auftreten, wenden Sie sich an den Support von Looker.

Als Nutzer testen

Wenn du einen oder mehrere Verbindungsparameterwerte für ein Nutzerattributfestgelegt hast, wird die Option Als Benutzer testenüber der Schaltfläche Diese Einstellungen testenangezeigt. Wählen Sie einen Nutzer aus und klicken Sie auf Diese Einstellungen testen, um zu prüfen, ob die Datenbank eine Verbindung herstellen und Abfragen als dieser Nutzer ausführen kann.

Ihre Datenbankverbindung hinzufügen

Nachdem Sie die Einstellungen für die Datenbankverbindung konfiguriert und getestet haben, klicken Sie auf Verbindung hinzufügen. Die Datenbankverbindung wird jetzt auf der Seite Verbindungen zur Liste hinzugefügt.

Nächste Schritte

Nachdem Sie Ihre Datenbank mit Looker verbunden haben, können Sie die Anmeldeoptionen für Ihre Nutzer konfigurieren.