Looker mit Ihrer Datenbank verbinden

Nachdem Sie die Datenbank gesicherte und konfiguriert haben, können Sie sie mit Looker verbinden.

Eine neue Datenbankverbindung erstellen

Wählen Sie im Bereich Admin unter Datenbank die Option Verbindungen aus. Klicken Sie auf der Seite Verbindungen auf die Schaltfläche Verbindung hinzufügen. Looker zeigt die Seite Verbindungseinstellungen an.

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

Auf dieser Seite werden gängige Felder beschrieben, die in Looker auf der Seite Verbindungseinstellungen angezeigt werden. Welche Felder auf der Seite Verbindungseinstellungen genau angezeigt werden, hängt von Ihrem Dialekt ab.

Name

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

Dialekt

Der SQL-Dialekt, der Ihrer Verbindung entspricht. Es ist wichtig, dass Sie den richtigen Wert auswählen, damit Ihnen die entsprechenden Verbindungsoptionen angezeigt werden und Looker Ihr LookML korrekt in SQL übersetzen kann.

ID des Abrechnungsprojekts

Bei Google BigQuery-Verbindungen ist die Abrechnungsprojekt-ID die Google Cloud-Projekt-ID.

SSH-Server

Die Option SSH-Server ist nur verfügbar, wenn die Instanz in der Kubernetes-Infrastruktur bereitgestellt wird und nur die Möglichkeit, SSH-Serverkonfigurationsinformationen zu Ihrer Looker-Instanz hinzuzufügen, aktiviert ist. Wenn diese Option für Ihre Looker-Instanz nicht aktiviert ist und Sie sie aktivieren möchten, wenden Sie sich an einen Google Cloud-Vertriebsexperten oder beantragen Sie eine Supportanfrage.

Der SSH-Server wählt automatisch den localhost-Port für Sie aus und Sie können den localhost-Port nicht angeben. Wenn Sie eine SSH-Verbindung erstellen müssen, für die Sie einen localhost-Port angeben müssen, öffnen Sie eine Supportanfrage.

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

Lokaler Port

Standardmäßig wählt Looker automatisch einen verfügbaren lokalen Port für den SSH-Tunnel aus. Wenn Sie einen lokalen Port manuell auswählen möchten, wählen Sie Manuelle Eingabe aus und geben Sie in das Feld Benutzerdefinierter lokaler Port eine Portnummer ein. Achten Sie darauf, dass der lokale Port auf Ihrer Instanz verfügbar ist.

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 einen SSH-Tunnel für Ihre Datenbank konfiguriert haben, geben Sie im Feld Host "localhost" ein und geben Sie im Feld Port die Portnummer ein, die auf Ihre Datenbank weiterleitet.

Datenbank

Der Name der Datenbank auf Ihrem Host. Sie haben beispielsweise den Hostnamen my-instance.us-east-1.redshift.amazonaws.com, auf dem die Datenbank sales_info vorhanden ist. In dieses Feld würden Sie sales_info eingeben. Wenn sich mehrere Datenbanken auf demselben Host befinden, müssen Sie möglicherweise mehrere Verbindungen erstellen. Diese sind mit Ausnahme von MySQL gemeint, in 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. Das vollständige Verfahren finden Sie auf der Dokumentationsseite, die die OAuth-Konfiguration von Snowflake oder die OAuth-Konfiguration von Google BigQuery beschreibt.

Nutzername

Der Benutzername, den Looker zur Verbindungsherstellung mit Ihrer Datenbank verwenden soll. Sie sollten den Nutzer gemäß unserer Anleitung zur Datenbankkonfiguration im Voraus konfigurieren.

Passwort

Das Passwort, mit dem Looker eine Verbindung zu Ihrer Datenbank herstellen soll. Bitte konfigurieren Sie das Passwort vorab gemäß unserer Anleitung zur Datenbankkonfiguration.

E‑Mail-Adresse des Dienstkontos

Die E-Mail-Adresse des Dienstkontos, das für den Zugriff auf Ihre Datenbank verwendet wird. Das Dienstkonto wird über Ihre Datenbank verwaltet. Informationen zum Herstellen einer Verbindung zu BigQuery mit einem Dienstkonto finden Sie in der Google BigQuery-Verbindungsdokumentation zu Looker.

JSON-/P12-Datei des Dienstkontos

Die Zertifikatsdatei für das Dienstkonto. Laden Sie diese Datei aus Ihrer Datenbank herunter. Informationen zum Herstellen einer Verbindung zu BigQuery mit einem Dienstkonto finden Sie in der Google BigQuery-Verbindungsdokumentation zu Looker.

Schema

Das von Looker verwendete Standardschema, wenn kein Schema angegeben ist. Dies gilt, wenn Sie SQL Runner verwenden, bei der Erstellung eines LookML-Projekts und beim Abfragen von Tabellen.

Persistente abgeleitete Tabellen

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

Beachten Sie Folgendes zu PDTs:

  • PATs werden für Snowflake-Verbindungen, die OAuth verwenden, nicht unterstützt.
  • Durch das Deaktivieren von PATs für eine Verbindung werden die mit Ihren PATs verknüpften Datengruppen nicht deaktiviert. Auch wenn Sie PATs deaktivieren, führen vorhandene Datengruppen weiterhin ihre sql_trigger-Abfragen für die Datenbank aus. Wenn Sie verhindern möchten, dass eine Datengruppe ihre sql_trigger-Abfrage für Ihre Datenbank ausführt, müssen Sie den Parameter datagroup aus Ihrem LookML-Projekt löschen oder auskommentieren. Sie können auch die PDT- und Datagroup-Wartungspläne für die Verbindung aktualisieren, damit 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 Snowflake). AUTOCOMMIT ist für SQL-Befehle erforderlich, die von Looker ausgeführt werden, um sein PAT-Registrierungssystem aufrechtzuerhalten.

Temp Database

Obwohl dieses Feld mit dem Label Temp Database versehen ist, geben Sie je nach Ihrem SQL-Dialekt entweder den Datenbank- oder den Schemanamen ein, den Looker zum Erstellen von persistenten abgeleiteten Tabellen verwenden soll. Diese Datenbank oder dieses Schema sollten Sie im Voraus mit den entsprechenden Schreibberechtigungen konfigurieren. Wählen Sie auf der Dokumentationsseite zur Datenbankkonfigurationsanleitung den Datenbankdialekt für die Konfigurationsanleitung aus.

Jede Verbindung muss eine eigene Temp Database oder Temp haben. Sie kann nicht für mehrere Verbindungen verwendet werden.

Max PDT Builder Connections

Mit der Einstellung Max PDT Builder Connections können Sie festlegen, 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 Neuerstellungen startet:

  • Persistenzbasierte 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, wenn die Tabelle persist_for zu einer Kaskade abgeleiteter Tabellen gehört, für die eine Tabelle mit der Persistenzstrategie datagroup_trigger oder sql_trigger_value erforderlich ist. In diesem Fall erstellt der Looker-Regenerator eine persist_for-Tabelle, da sie zum Erstellen einer anderen Tabelle im Wasserfall erforderlich ist. Andernfalls initiiert der Regenerator keine Builds für persist_for-Tabellen.

Die Einstellung für Max PDT Builder Connections ist standardmäßig auf 1 eingestellt, kann aber auch auf 10 festgelegt werden. Der Wert darf jedoch nicht höher als der Wert sein, der im Feld Max. Verbindungen oder per-user-query-limit festgelegt wurde, wie er 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 die Mehrinstanzenfähigkeit unterstützen – wie BigQuery, Snowflake und Redshift – können bei der Verarbeitung paralleler Abfrage-Builds eine bessere Leistung erzielen.

Wenn Sie die Einstellung Max PDT Builder Connections erhöhen möchten, bietet es sich an, sie um 1 zu erhöhen. Wenn ein unerwartetes Verhalten auftritt, setzen Sie es auf die Standardeinstellung 1 zurück. Wenn die Abfrageleistung nicht beeinträchtigt ist, können Sie sie schrittweise um 1 erhöhen und die Leistung bei jeder Steigerung erhöhen, bevor Sie die Einstellung weiter erhöhen.

Beachte Folgendes zur Einstellung Max PDT Builder Connections:

  • Die Einstellung Max. PDT-Builder-Verbindungen gilt nur für Verbindungen, die für den Neuaufbau von Tabellen erforderlich sind, und 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 Triggerprüfungsabfragen immer nacheinander ausgeführt werden, wird die Einstellung Max PDT Builder Connections nicht angewendet.
  • 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 somit das Limit für den gesamten Cluster fest.
  • Die Einstellung Max PDT Builder Connections 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 den Tabellen mit den Strategien datagroup_trigger oder sql_trigger_value abhängig).
    • Tabellen im Entwicklungsmodus:
    • Tabellen, die mit der Option Abgeleitete Tabellen & Ausführung neu erstellen neu erstellt wurden
    • Tabellen, von denen eine in einer Abhängigkeit Kaskade abhängig ist. 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 die Neuerstellung abschließen, bevor table_B mit der Neuerstellung beginnen kann.

Always Retry Failed PDT Builds

Mit der Einstellung Immer fehlgeschlagene PAT-Builds wiederholen wird konfiguriert, wie der Looker-Regenerator versucht, persistenzbasierte Tabellen wiederherzustellen, die im vorherigen Regeneratorzyklus fehlgeschlagen sind. Bei dem Looker-Regenerator werden die per Trigger beibehaltenen Tabellen (PDTs und zusammengefasste Tabellen) gemäß dem Intervall neu erstellt, das in der Verbindungseinstellung für PDT und Datagroup-Wartungszeitplan konfiguriert ist. Wenn die Einstellung Fehlgeschlagene PAT-Builds immer wiederholen aktiviert ist, versucht der Looker-Regenerator, eine PAT zu erstellen, die im vorherigen Regenerator-Zyklus fehlgeschlagen ist, auch wenn die Triggerbedingung des PATs nicht erfüllt ist. Wenn diese Einstellung deaktiviert ist, versucht der Looker-Regenerator eine Neuerstellung einer zuvor fehlgeschlagenen PDT nur dann, wenn die Triggerbedingung der PDT erfüllt ist. Fehlgeschlagene PAT-Builds immer wiederholen ist standardmäßig deaktiviert.

Weitere Informationen zum Looker-Regenerator finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker.

Enable PDT API Control

Die Einstellung PDT API-Steuerung aktivieren bestimmt, 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.

Zusätzliche Parameter

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

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

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

PDT and Datagroup Maintenance Schedule

Diese Einstellung akzeptiert einen cron-Ausdruck, der angibt, wann der Looker-Regenerator die Datengruppen und persistente Tabellen (sowohl zusammengefasste Tabellen als auch persistente abgeleitete Tabellen) prüfen soll, die auf sql_trigger_value basieren. Auf der Grundlage dieser Prüfungen werden die beibehaltenen Tabellen aus dem Scratch-Schema Ihrer Datenbank von Looker neu erstellt oder gelöscht.

Der Wert für PDT und Datagroup-Wartungsplan legt das Intervall cron für den Looker-Regenerator fest. Der Looker-Regenerator löst einen Regenerator-Zyklus aus, um Datengruppen und persistente Tabellen im Intervall cron zu prüfen. Wenn ein Looker-Regenerator-Zyklus bei dem nächsten cron-Intervall noch nicht abgeschlossen ist, wird dieser abgeschlossen. Erst dann beginnt der nächste cron-Intervall, um mit dem nächsten Regenerator-Zyklus zu beginnen.

Für die Einstellung PDT und Datagroup-Wartungsplan ist ein cron-Ausdruck zulässig. Der Standardwert ist */5 * * * *. Dies bedeutet, dass der Looker-Regenerator-Zyklus einen Zyklus von fünf Minuten startet, wenn der vorherige Regenerator-Zyklus abgeschlossen ist. Wenn der vorherige Regeneratorzyklus nicht abgeschlossen ist, wird der Looker-Regenerator in den nächsten fünf Minuten nach seinem Abschluss gestartet.

Der Standardwert von 5 Minuten ist auch das Intervall, das für den Wartungszeitplan für PAT und die Datengruppe am häufigsten unterstützt wird. Looker erzwingt kein maximales Intervall für PDT und Datagroup-Wartungszeitplan. Das heißt, Sie können das Intervall zwischen Looker-Regenerator-Zyklen so lange verlängern, wie durch einen cron-Ausdruck angegeben werden kann. Beachten Sie, dass längere Recycling-Zyklen von Looker die Aktualität der Daten im Cache und in den persistenten Tabellen beeinträchtigen können.

Nachdem der Looker-Regenerator alle Prüfungen und PAT-Neuerstellungen in einem Zyklus abgeschlossen hat, wird auf das nächste cron-Intervall gewartet, um den nächsten Zyklus zu initiieren. Wenn Sie langfristige PAT-Builds haben, kann es zwischen den Looker-Regenerator-Zyklen zu langen Zeiträumen kommen. Andere Faktoren können sich auf den Zeitaufwand für die Neuerstellung Ihrer Tabellen auswirken. Weitere Informationen dazu finden Sie im Abschnitt Wichtige Hinweise zum Implementieren persistenter Tabellen auf der Seite Abgeleitete Tabellen in Looker.

Wenn die Datenbank nicht rund um die Uhr verfügbar ist, sollten Sie Prüfungen auf Zeiten beschränken, zu denen die Datenbank aktiv ist. Hier 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, das ? in cron-Ausdrücken nicht unterstützt.
  • Der Ausdruck cron verwendet die Anwendungszeitzone von Looker, um festzustellen, wann Prüfungen durchgeführt werden.
  • Wenn PATs nicht erstellt werden, setzen Sie den Cron-String auf den Standardwert */5 * * * * zurück.

Hier sind einige Ressourcen mit nützlichen Informationen 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 der Möglichkeiten, mit denen Sie Ihre Daten schützen können. Andere sichere Optionen werden auf der Dokumentationsseite Sicheren Datenbankzugriff aktivieren beschrieben.

Verify SSL Cert

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

Wenn dieses Kästchen nicht angeklickt ist, wird die Verbindung zwar trotzdem mit einer SSL-Verschlüsselung hergestellt, es ist jedoch keine Bestätigung der SSL-Verbindung erforderlich. Daher kann eine Verbindung hergestellt werden, wenn sich die Zertifizierungsstelle nicht in der Liste der vertrauenswürdigen Quellen des Clients befindet.

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 die Datenbankkonfiguration Verbindungen begrenzt, achten Sie darauf, dass der Wert für Max. Verbindungen dem Limit Ihrer Datenbank entspricht oder darunter liegt.

Connection Pool Timeout

Wenn Ihre Nutzer mehr Verbindungen anfordern, als in der Einstellung Max. Verbindungen angegeben sind, warten die Anfragen, bis andere abgeschlossen sind, bevor sie ausgeführt werden. Hier wird die maximale Wartezeit für eine Anforderung festgelegt. Diesen Wert sollten Sie mit Bedacht wählen. Ein zu kurzer Zeitraum kann dazu führen, dass die Abfragen der Nutzer abgebrochen werden, weil sie nicht genug Zeit haben, um die anderen Abfragen abzuschließen. 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:

Durch das Kästchen Kostenschätzung werden die folgenden Funktionen für die Verbindung aktiviert:

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

SQL-Runner-Precache

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 Tabelleninformationen nur dann laden soll, wenn eine Tabelle ausgewählt ist, können Sie die Option SQL Runner Precache deaktivieren, um das SQL Runner-Laden für die Verbindung zu deaktivieren.

Fetch Information Schema For SQL Writing

Bei einigen SQL-Schreibfunktionen wie Zusammenfassung der Bekanntheit verwendet Looker das Informationsschema Ihrer Datenbank, um das SQL-Schreiben 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 Informationen zum Schema für SQL-Schreibvorgänge abrufen für Ihre Verbindung deaktivieren. Wenn Sie dieses Feature deaktivieren, werden einige SQL-Optimierungen von Looker für bestimmte Features verhindert. Aktivieren Sie daher die Option Informationen zum Schema für SQL-Schreibvorgänge abrufen, es sei denn, Sie wissen, dass das Informationsschema Ihrer Verbindung 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 sie die Cache-Funktion von Google BigQuery unwirksam machen und sich negativ auf die Cache-Leistung auswirken können. Sie können Kontextkommentare für eine BigQuery-Verbindung aktivieren. Heben Sie dazu die Einstellung Kontextkommentar deaktivieren auf der Seite Verbindungseinstellungen auf. Weitere Informationen finden Sie auf der Dokumentationsseite zu 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 Zeitzoneneinstellungen verwenden.

Zeitzone der Abfrage

Die Option Zeitzone der Abfrage wird nur angezeigt, wenn Sie Nutzerspezifische Zeitzonen deaktiviert haben.

Wenn nutzerspezifische Zeitzonen deaktiviert sind, ist die Abfragezeitzone die Zeitzone, die Ihren Nutzern beim Abfragen zeitbasierter Daten angezeigt wird, und die Zeitzone, in die Looker zeitbasierte Daten aus der Datenbankzeitzone umwandelt.

Weitere Informationen finden Sie auf der Dokumentationsseite Zeitzoneneinstellungen verwenden.

Eigene Anmeldedaten für PDT-Prozesse konfigurieren

Wenn die Datenbank persistente abgeleitete Tabellen unterstützt und Sie das Kästchen Persistente abgeleitete Tabellen aktiviert haben, wird in Looker der Abschnitt PDT-Überschreibungen angezeigt. Im Abschnitt PDT-Überschreibungen können Sie separate JDBC-Parameter (Host, Port, Datenbank, Nutzername, Passwort, Schema und zusätzliche Parameter) angeben, die für PDT-Prozesse spezifisch sind. Dies kann aus verschiedenen Gründen hilfreich sein:

  • Wenn Sie einen separaten Datenbanknutzer für PAT-Prozesse erstellen, können Sie diese in Ihrem Looker-Projekt verwenden, auch wenn Sie Ihren Datenbankanmeldedaten Nutzerattribute zuweisen oder OAuth für Ihre Datenbankverbindung verwenden.
  • 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.
  • Bei Datenbanken wie Snowflake können PAT-Prozesse an leistungsstärkere Hardware weitergeleitet werden, die nicht mit anderen Looker-Nutzern geteilt wird. Auf diese Weise können PDTs schnell erstellt werden, ohne dass die Notwendigkeit entsteht, jederzeit kostenintensive Hardware vorzuhalten.

Sie können beispielsweise eine Verbindung konfigurieren und die Felder „Nutzername“ und „Passwort“ auf Nutzerattribute festlegen. Somit kann jeder Benutzer mit seinen eigenen Anmeldedaten auf die Datenbank zugreifen. Im Abschnitt PDT Overrides (PDT-Überschreibungen) wird ein separater Nutzer (pdt_user) mit eigenem Passwort erstellt. Das pdt_user-Konto wird für alle PAT-Prozesse mit Zugriffsebenen verwendet, die für die Erstellung und Aktualisierung von PAT erforderlich sind.

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:

  • Führen Sie einige der Schritte zur Fehlerbehebung auf der Dokumentationsseite zum Testen der Datenbankverbindung aus.
  • Wenn Sie Versa 3.6 oder niedriger auf Atlas verwenden und ein Fehler bei der Kommunikation 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.

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

Als Nutzer testen

Wenn Sie einen oder mehrere Verbindungsparameterwerte für ein Nutzerattribut festgelegt haben, wird die Option Als Nutzer testen über der Schaltfläche Diese Einstellungen testen angezeigt. Wählen Sie einen Nutzer aus und klicken Sie auf Diese Einstellungen testen, um zu prüfen, ob die Datenbank als dieser Nutzer eine Verbindung herstellen und Abfragen 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 in die Liste aufgenommen.

Nächste Schritte

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