Looker mit Ihrer Datenbank verbinden

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

Sie erstellen eine Datenbankverbindung in Looker auf der Seite Datenbank mit Looker verbinden. Es gibt zwei Möglichkeiten, die Seite Datenbank mit Looker verbinden zu öffnen:

  • Klicken Sie auf das Hauptmenü-Symbol , wählen Sie Admin aus und klicken Sie dann im Bereich Datenbank des Admin-Bereichs auf Verbindungen. Klicken Sie auf der Seite Verbindungen auf den Button Verbindung hinzufügen.
  • Klicken Sie im Hauptnavigationsmenü auf den Button Erstellen und wählen Sie dann den Menüpunkt Verbindung aus.

Auf dieser Seite werden gängige Felder beschrieben, die Looker auf der Seite Datenbank mit Looker verbinden anzeigt. Die auf der Seite angezeigten Felder richten sich nach Ihrer Dialekt-Einstellung.

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

Die Einrichtung der Datenbankverbindung umfasst die folgenden vier Abschnitte:

Allgemeine Einstellungen

Name

Der gewünschte Name für die Verbindung. Sie benötigen diesen Datenbankverbindungsnamen für den Parameter connection Ihres LookML-Modells. Der Name der Datenbankverbindung ist auch der Name, unter dem die Verbindung auf der Admin-Seite Verbindungen von Looker aufgeführt wird. Verwenden Sie für diese Einstellung nicht den Namen eines Ordners. Dieser Wert muss keine Übereinstimmung in Ihrer Datenbank haben. Name ist ein Label, das diese Verbindung in der Looker-Benutzeroberfläche identifiziert.

SQL-Dialekt

Der SQL-Dialekt, der Ihrer Verbindung entspricht. Hierbei ist es wichtig, den richtigen Wert zu wählen, damit Ihnen die richtigen Verbindungsoptionen angezeigt werden und Looker Ihre LookML richtig in SQL übersetzen kann.

Neueste Treiberversion verwenden

Standardmäßig stellt Looker immer über die aktuelle Version des JDBC-Treibers für Ihren Datenbankdialekt eine Verbindung zu Ihrer Datenbank her. Wenn für den ausgewählten Datenbankdialekt mehr als eine JDBC-Treiberversion verfügbar ist, die von Looker unterstützt wird, können Sie die Option Neueste Treiberversion verwenden deaktivieren, um eine frühere JDBC-Treiberversion für die Verbindung auszuwählen. Wenn Sie eine frühere Version des JDBC-Treibers auswählen möchten, können Sie die Option Neueste Treiberversion verwenden für Ihre Verbindung deaktivieren und dann die Treiberversion aus dem Drop-down-Menü Treiberversion auswählen.

Wenn Sie eine frühere JDBC-Treiberversion auswählen, verwendet Looker diese frühere Version so lange, wie sie von Looker unterstützt wird.

Looker stellt die Unterstützung einer Treiberversion in den folgenden beiden Szenarien ein:

  • Die Treiberversion wird nicht mehr von Looker unterstützt. In diesem Fall wird für die Verbindung die früheste Treiberversion verwendet, die Looker für den Dialekt unterstützt.
  • Die Treiberversion ist aufgrund eines Looker-Rollbacks noch nicht vorhanden. In diesem Fall wird für die Verbindung die neueste Treiberversion verwendet, die vom zurückgesetzten Release unterstützt wird.

Wenn die von Ihnen ausgewählte Treiberversion von Looker nicht mehr unterstützt wird, wird auf der Seite Datenbankverbindung bearbeiten unter dem Feld Treiberversion eine entsprechende Warnung angezeigt. In der Benachrichtigung wird auch angegeben, welche Treiberversion Looker für die Verbindung verwendet. Um diese Warnung zu löschen, wählen Sie entweder im Drop-down-Menü Treiberversion eine unterstützte JDBC-Treiberversion aus oder aktivieren Sie die Option Neueste Treiberversion verwenden, um die neueste Treiberversion zu verwenden.

Projektbereich

Wählen Sie aus, ob die Verbindung mit allen Projekten oder nur mit einem Projekt verwendet werden soll:

  • Alle Projekte: Alle LookML-Projekte auf der Instanz können auf die Verbindung zugreifen. Der Verbindungsname kann also im Parameter connection von Modelldateien in diesem Projekt angegeben werden.
  • Selected Project: Nur ein LookML-Projekt auf der Instanz kann auf die Verbindung zugreifen. Wenn Sie diese Option auswählen, wird auf dem Bildschirm „Verbindung“ ein Drop-down-Menü mit den Projekten auf der Instanz angezeigt. Wählen Sie das Projekt aus, das Zugriff auf diese Verbindung haben soll.

Verwenden Sie diese Option zusammen mit den folgenden Berechtigungen, um die Verbindungsverwaltung und Modellkonfiguration zu delegieren:

Statusdetails

Maximieren Sie den Bereich Statusdetails, um die Einstellungen für Ihre Verbindung zu testen.

Datenbankeinstellungen

SSH-Server aktivieren

Die Option SSH-Server ist nur dann verfügbar, wenn die Instanz in einer Kubernetes-Infrastruktur bereitgestellt wird und wenn die Fähigkeit aktiviert wurde, Ihrer Looker-Instanz Informationen zur SSH-Serverkonfiguration hinzuzufügen. Wenn diese Option in Ihrer Looker-Instanz nicht aktiviert ist und Sie sie aktivieren möchten, wenden Sie sich an einen Vertriebsspezialisten von Google Cloud oder stellen Sie eine Supportanfrage. Wenn Sie die Option SSH-Server aktivieren aktivieren, zeigt Looker die Felder SSH-Server und SSH-Tunnel an.

SSH-Server

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

Wählen Sie in der Drop-down-Liste eine SSH-Serverkonfiguration aus. Ein SSH-Server ist erforderlich, um einen geeigneten SSH-Tunnel auszuwählen oder zu erstellen. Sie können im Bereich Verbindungen auf dem Tab SSH-Server einen neuen SSH-Server erstellen.

SSH-Tunnel

Wählen Sie einen vorhandenen SSH-Tunnel aus der Drop-down-Liste aus oder klicken Sie auf das Symbol Neuen Tunnel erstellen, wenn Sie einen neuen SSH-Tunnel mit einem Hostnamen und einem Port oder einem lokalen Port erstellen möchten.

Hostname

Der Hostname Ihrer Datenbank, mit dem Looker eine Verbindung zu Ihrem Datenbankhost herstellen soll.

Wenn Sie mit einem Looker-Analysten zusammengearbeitet haben, um einen SSH-Tunnel zu Ihrer Datenbank zu konfigurieren, geben Sie im Feld Host den Wert "localhost" ein. Wenn Sie ein Nutzerattribut auf das Feld Host anwenden, darf die Nutzerzugriffsebene des Nutzerattributs nicht auf Bearbeitbar festgelegt sein. Wenn Sie für die Verbindung mit Ihrer Datenbank einen SSH-Tunnel konfiguriert haben, können Sie dem Feld Remote Host:Port kein Benutzerattribut zuweisen.

Port

Der Port Ihrer Datenbank, mit dem Looker eine Verbindung zu Ihrem Datenbankhost herstellen soll.

Wenn Sie mit einem Looker-Analysten zusammengearbeitet haben, um einen SSH-Tunnel zu Ihrer Datenbank zu konfigurieren, geben Sie im Feld Port die Portnummer ein, die zu Ihrer Datenbank weiterleitet. Diese sollte Ihnen Ihr Looker-Analyst mitgeteilt haben.

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 eine Portnummer in das Feld Benutzerdefinierter lokaler Port ein. Achten Sie darauf, dass der lokale Port auf Ihrer Instanz verfügbar ist.

Abrechnungsprojekt-ID (nur Google BigQuery)

Die Abrechnungsprojekt-ID ist die Google Cloud -Projekt-ID. Weitere Informationen finden Sie auf der Dokumentationsseite zu Google BigQuery.

Storage-Projekt-ID (nur Google BigQuery)

Der Name Ihrer Storage-Projekt-ID, wenn Sie Rechenleistung und Speicher in separaten Projekten trennen. Sie können Datasets in einem anderen Google Cloud -Projekt abfragen, wenn Ihre LookML-Entwickler im Parameter sql_table_name Ihrer LookML-Ansichten, Explores oder Joins Tabellennamen mit vollständigem Umfang angeben. Weitere Informationen finden Sie auf der Dokumentationsseite zu Google BigQuery.

Primäres Dataset (nur Google BigQuery)

Der Name des Datasets, das Looker standardmäßig verwenden soll, wenn es Ihre Datenbank abfragt. Weitere Informationen finden Sie auf der Dokumentationsseite zu Google BigQuery.

Datenbankname

Der Name der Datenbank auf Ihrem Host. Beispiel: Sie haben den Hostnamen my-instance.us-east-1.redshift.amazonaws.com, auf dem sich die Datenbank sales_info befindet. In dieses Feld geben Sie sales_info ein. Wenn Sie über mehrere Datenbanken auf einem Host verfügen, müssen Sie möglicherweise mehrere Verbindungen herstellen, um sie zu verwenden. (Mit Ausnahme von MySQL. Hier bedeutet das Wort Database etwas geringfügig anderes als in den meisten SQL-Dialekten.)

Standardschema

Das von Looker verwendete Standardschema, wenn kein Schema angegeben ist. Dies wird bei der Verwendung von SQL-Runner, bei der LookML-Projekterstellung und bei der Abfrage von Tabellen verwendet.

Authentifizierungseinstellungen

Wählen Sie für Google BigQuery-, Snowflake-, Trino- und Databricks-Verbindungen den Authentifizierungstyp aus, den Looker für den Zugriff auf Ihre Datenbank verwenden soll:

  • Bei Google BigQuery-Verbindungen haben Sie die Möglichkeit, OAuth oder ein Dienstkonto zu konfigurieren, mit dem sich Looker bei Ihrer Datenbank authentifiziert.
  • Bei Snowflake-, Trino- und Databricks-Verbindungen haben Sie die Möglichkeit, OAuth oder ein Datenbankkonto zu konfigurieren, mit dem sich Looker bei Ihrer Datenbank authentifizieren kann.

Wenn Sie OAuth verwenden, müssen sich Ihre Nutzer in Ihrer Datenbank anmelden, um Abfragen über Looker auszuführen. Wenn Nutzer einen OAuth-Autorisierungsablauf in Looker starten, zeigt Looker das Dialogfeld OAuth-Verbindung autorisieren an. Darin werden sie darüber informiert, dass die Looker-Instanz durch die Autorisierung der Verbindung in ihrem Namen auf Daten zugreifen kann und dass privilegierte Looker-Nutzer wie Administratoren oder Entwickler möglicherweise Einblick in ihre Daten haben. Nutzer müssen Autorisieren auswählen, um zur OAuth-Anmeldeseite zu gelangen. Die Einwilligungsinformationen werden im lokalen Speicher des Browsers gespeichert. Wenn der lokale Speicher gelöscht wird, wird das Dialogfeld beim nächsten Start eines OAuth-Autorisierungsablaufs wieder angezeigt. Weitere Informationen zum Konfigurieren von OAuth für eine Verbindung zu Looker finden Sie in den Verfahren für Google BigQuery, Snowflake, Trino oder Databricks.

Nutzername

Der Nutzername eines Nutzerkontos in Ihrer Datenbank, mit dem Looker eine Verbindung zu Ihrer Datenbank herstellen kann.

Passwort

Das Passwort eines Nutzerkontos in Ihrer Datenbank, mit dem Looker eine Verbindung zu Ihrer Datenbank herstellen kann.

Maximieren Sie den Bereich Statusdetails, um die Einstellungen für Ihre Verbindung zu testen.

Optionale Einstellungen

Max. Verbindungen pro Knoten

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. Falls Ihre Datenbankkonfiguration Verbindungen beschränkt, stellen Sie sicher, dass Ihr Wert für Max Connections per node gleich oder kleiner dem Grenzwert Ihrer Datenbank ist.

Zeitlimit für Verbindungspool

Fordern Nutzer mehr Verbindungen an, als mit der Einstellung Max Connections per node festgelegt sind, werden diese Anforderungen erst nach Abschluss der anderen ausgeführt. Hier wird die maximale Wartezeit für eine Anforderung festgelegt. Die Standardeinstellung ist 120 Sekunden.

Wählen Sie diesen Wert mit Bedacht. Ist er zu niedrig, werden die Anfragen von Nutzern abgebrochen, da die Zeit zum Abschluss der Anfragen anderer Nutzer nicht ausreicht. 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.

Maximale Anzahl gleichzeitiger Abfragen für diese Verbindung

Durch diesen optionalen Wert wird die Anzahl gleichzeitiger Abfragen begrenzt, die Looker zur gleichen Zeit an diese Datenbankverbindung senden kann. Wenn mehrere gleichzeitige Anfragen eingehen, die dieselbe Verbindung erfordern, stellt Looker sie intern in eine Warteschlange und verarbeitet sie der Reihe nach. Wenn Sie diesen Wert festlegen, wird ein vorhandener Wert für Maximale Anzahl von Verbindungen pro Knoten überschrieben.

Maximale Anzahl gleichzeitiger Abfragen pro Nutzer für diese Verbindung

Durch diesen optionalen Wert wird die Anzahl gleichzeitiger Abfragen eines Nutzers begrenzt, die Looker zur gleichen Zeit an diese Datenbankverbindung senden kann. Wenn mehrere gleichzeitige Anfragen eingehen, die dieselbe Verbindung erfordern, stellt Looker sie intern in eine Warteschlange und verarbeitet sie der Reihe nach. Der Standardwert wird durch Ihren Datenbankdialekt festgelegt und ist in der Regel 25.

Die Einstellung Maximale Anzahl gleichzeitiger Abfragen pro Nutzer für diese Verbindung gilt für die einzelne Verbindung, für die sie festgelegt ist. Diese Einstellung überschreibt die Startoption per-user-query-limit auf Instanzebene für die Verbindung.

Da die Einstellung Maximale Anzahl gleichzeitiger Abfragen pro Nutzer für diese Verbindung die Einstellung per-user-query-limit überschreibt, ist es wichtig, die Unterschiede zwischen diesen Einstellungen zu kennen:

  • Die Einstellung Maximale Anzahl gleichzeitiger Abfragen pro Nutzer für diese Verbindung gilt pro Nutzer und pro Verbindung, aber NICHT pro Knoten. Die Einstellung Maximale Anzahl gleichzeitiger Abfragen pro Nutzer für diese Verbindung gilt für die gleichzeitigen Abfragen des Nutzers für die Verbindung in der gesamten Looker-Instanz. Bei geclusterten Looker-Instanzen wird der Wert, den Sie für Maximale Anzahl gleichzeitiger Abfragen pro Nutzer für diese Verbindung festlegen, durch die Anzahl der Knoten in Ihrem Looker-Cluster geteilt, um die Anzahl der gleichzeitigen Abfragen zu bestimmen, die ein Nutzer auf jedem Knoten ausführen kann.

    Wenn Sie beispielsweise einen Cluster mit 5 Knoten haben und diesen Wert auf 15 festlegen, lässt jeder Knoten 3 gleichzeitige Abfragen pro Nutzer für diese Verbindung zu (15 / 5 = 3), was insgesamt 15 Abfragen über alle Knoten hinweg ergibt.

  • Die Startoption per-user-query-limit gilt pro Nutzer, pro Verbindung und pro Knoten.

    Wenn Sie beispielsweise einen Cluster mit 5 Knoten und einem per-user-query-limit-Wert von 15 haben, lässt jeder Knoten 15 gleichzeitige Abfragen pro Nutzer für diese Verbindung zu. Das ergibt insgesamt 75 Abfragen über alle Knoten hinweg (15 * 5 = 75).

Daher kann die Anwendung eines Werts für Maximale Anzahl gleichzeitiger Abfragen pro Nutzer für diese Verbindung bei geclusterten Looker-Instanzen die Abfrageleistung für Ihre Nutzer beeinträchtigen.

Zusätzliche JDBC-Parameter

Ein JDBC-Treiber (Java Database Connectivity) ist eine Softwarekomponente, die die Verbindung zwischen Looker und Ihrer Datenbank verwaltet.

Wenn der JDBC-Treiber für Ihre Datenbank eine Verbindung von Looker zu Ihrer Datenbank herstellt, erstellt der Treiber eine URL mit einer Reihe von Parametern, z. B. Host, Port, Datenbank oder Warehouse, sowie zusätzlichen dialektspezifischen Parametern. Wenn Sie die Verbindung für Ihre Datenbank einrichten, können Sie zusätzliche JDBC-Parameter angeben, die Looker bei der Kommunikation mit Ihrem Datenbanktreiber verwenden soll. Je nach Dialekt und spezifischem Parameter werden JDBC-Parameter möglicherweise vom JDBC-Treiber verarbeitet oder an Ihre Datenbank weitergegeben.

Damit Ihre Verbindung sicher bleibt, gibt es in Looker eine Zulassungsliste für die JDBC-Parameter, die für jeden Datenbankdialekt unterstützt werden.

  • Wenn Sie versuchen, eine Verbindung mit nicht unterstützten JDBC-Parametern zu erstellen oder zu aktualisieren, zeigt Looker eine Fehlermeldung mit den nicht zulässigen Parametern an.
  • Wenn Sie eine bestehende Verbindung mit nicht unterstützten JDBC-Parametern haben, entfernt Looker die Parameter und stellt dann eine Verbindung zu Ihrer Datenbank her.

Eine Liste der unterstützten JDBC-Parameter für Ihren Dialekt finden Sie im Abschnitt „Unterstützte JDBC-Parameter“ auf der Seite mit der Anleitung zur Datenbankkonfiguration für Ihren Dialekt.

Wenn Sie in einem JDBC-Parameter auf ein Nutzerattribut verweisen möchten, verwenden Sie die Liquid-Vorlagensyntax: _user_attributes['name_of_attribute']. Sehen Sie sich folgendes Beispiel an:

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

Wartungszeitplan

Der Looker-Regenerator prüft Datengruppen und persistente Tabellen (sowohl zusammengefasste Tabellen als auch persistente abgeleitete Tabellen), die auf sql_trigger_value basieren. Anhand dieser Prüfungen erstellt der Looker-Regenerator persistente Tabellen aus dem Scratch-Schema Ihrer Datenbank neu oder löscht sie.

Der Wert für Wartungsplan legt das cron-Intervall für den Looker-Regenerator fest. Der Looker-Regenerator initiiert einen Regeneratorzyklus, um Datengruppen und persistente Tabellen im Intervall cron zu prüfen. Wenn ein Looker-Regenerator-Zyklus im nächsten cron-Intervall noch läuft, schließt der Looker-Regenerator den laufenden Regenerator-Zyklus ab und wartet dann bis zum nächsten cron-Intervall, um den nächsten Regenerator-Zyklus zu starten.

Die Einstellung Wartungsplan akzeptiert einen cron-Ausdruck. Der Standardwert ist */5 * * * *. Das bedeutet, dass der Regenerator-Zyklus von Looker alle fünf Minuten einen Zyklus startet, wenn der vorherige Regenerator-Zyklus abgeschlossen ist. Wenn der vorherige Regeneratorzyklus noch nicht abgeschlossen ist, wird der Looker-Regenerator im nächsten Fünf-Minuten-Intervall nach Abschluss des Zyklus gestartet.

Das Standardintervall von fünf Minuten ist auch das häufigste Intervall, das für den Wartungszeitplan unterstützt wird. Looker erzwingt kein maximales Intervall für den Wartungszeitplan. Das bedeutet, dass Sie das Intervall zwischen den Regeneratorzyklen von Looker so lange verlängern können, wie es durch einen cron-Ausdruck angegeben werden kann. Beachten Sie, dass sich längere Looker-Regenerator-Zyklen negativ auf die Aktualität der Daten in Ihrem Cache und in persistenten Tabellen auswirken können.

Nachdem der Looker-Regenerator alle Prüfungen und PDT-Neuerstellungen in einem Zyklus abgeschlossen hat, wartet er auf das nächste cron-Intervall, um den nächsten Zyklus zu starten. Wenn Sie PDT-Builds haben, die lange dauern, kann es sein, dass zwischen den Regenerator-Zyklen von Looker viel Zeit vergeht. Die Dauer der Neuerstellung Ihrer Tabellen kann allerdings von anderen Faktoren beeinflusst werden, wie im Abschnitt Wichtige Überlegungen zur Implementierung persistenter Tabellen auf der Seite Abgeleitete Tabellen in Looker beschrieben.

Falls Ihre Datenbank nicht rund um die Uhr verfügbar ist, empfiehlt sich die Einschränkung der Prüfungen auf die Zeiten der Datenbankverfügbarkeit. 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, das ? in cron-Ausdrücken nicht unterstützt.
  • Der Ausdruck cron verwendet die Anwendungszeitzone von Looker, um zu bestimmen, wann Prüfungen durchgeführt werden.
  • Werden keine PDTs erstellt, setzen Sie die cron-Zeichenfolge auf den Standardwert */5 * * * * zurück.

Hier sind einige Ressourcen, die Ihnen beim Erstellen von cron-Strings helfen:

Verbindung deaktivieren

Mit der Option Verbindung deaktivieren können Looker-Administratoren eine Verbindung vorübergehend beenden, wenn es nachgelagerte Probleme mit der Datenbank gibt, anstatt Abfragen manuell zu beenden oder Abfragen in der Abfragewarteschlange zu belassen.

Wenn die Option Verbindung deaktivieren aktiviert ist, sendet Looker keine Abfragen an die Datenbank. Stattdessen wird dem Nutzer eine Fehlermeldung angezeigt, dass die Verbindung deaktiviert ist.

Nachdem die Datenbankprobleme behoben wurden, kann ein Looker-Administrator die Option Verbindung deaktivieren deaktivieren. Sobald die Verbindung wieder aktiviert ist, funktionieren alle Abfragen wieder wie erwartet.

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 Option zum Schutz Ihrer Daten. Weitere sichere Optionen werden auf der Dokumentationsseite Sicheren Datenbankzugriff ermöglichen beschrieben.

SSL überprüfen

Geben Sie an, ob die Verifizierung des von der Verbindung verwendeten SSL-Zertifikats angefordert werden soll. Wird Verifizierung verlangt, muss die SSL-Zertifizierungsstelle, die das SSL-Zertifikat signiert hat, in der Liste der vertrauenswürdigen Quellen des Client aufgeführt sein. Handelt es sich bei der Zertifizierungsstelle um keine vertrauenswürdige Quelle, wird die Datenbankverbindung nicht hergestellt.

Ist diese Option nicht ausgewählt, wird die SSL-Verschlüsselung weiter auf die Verbindung angewendet, es wird jedoch keine Verifizierung der SSL-Verbindung verlangt. Es kann also auch dann eine Verbindung hergestellt werden, wenn die Zertifizierungsstelle nicht in der Liste der vertrauenswürdigen Quellen des Clients aufgeführt ist.

Tabellen und Spalten vorab im Cache speichern

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.

Soll SQL-Runner Tabelleninformationen nur nach Auswahl einer Tabelle laden, können Sie die Option Tabellen und Spalten vorab im Cache speichern deaktivieren, um das Vorabladen für die Verbindung durch SQL-Runner zu deaktivieren.

Schema abrufen und im Cache speichern

Für einige SQL-Schreibfunktionen wie Aggregat-Awareness 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 abrufen zu können. Bei Denodo-Dialekten oder Dialekten, die das Hadoop Distributed File System (HDFS) verwenden, kann das Abrufen des Informationsschemas so lange dauern, dass die Leistung Ihrer Looker-Abfragen erheblich beeinträchtigt wird. Wenn Sie wissen, dass Ihr Informationsschema langsam ist, können Sie die Option Schema abrufen und im Cache speichern für die Verbindung deaktivieren. Wenn Sie diese Funktion deaktivieren, werden einige der Looker-SQL-Optimierungen für bestimmte Funktionen verhindert. Sie sollten die Option Fetch and cache schema also aktivieren, es sei denn, Sie wissen, dass das Informationsschema Ihrer Verbindung besonders langsam ist.

Kostenschätzung

Die Ein-/Aus-Schaltfläche Kostenschätzung ist nur für die folgenden Datenbankverbindungen anwendbar:

Mit dem Schalter Kostenschätzung werden die folgenden Funktionen für die Verbindung aktiviert:

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

Datenbankverbindungs-Pooling

Bei Dialekten, die das Pooling von Datenbankverbindungen unterstützen, kann Looker mit dieser Funktion Pools von Verbindungen über den JDBC-Treiber verwenden. Das Datenbankverbindungs-Pooling ermöglicht eine schnellere Abfrageleistung. Für eine neue Abfrage muss keine neue Datenbankverbindung erstellt werden, sondern es kann eine vorhandene Verbindung aus dem Verbindungspool verwendet werden. Die Funktion für das Verbindungs-Pooling sorgt dafür, dass eine Verbindung nach der Ausführung einer Abfrage bereinigt wird und nach dem Ende der Abfrageausführung wiederverwendet werden kann. Weitere Informationen finden Sie auf der Dokumentationsseite Datenbankverbindungs-Pooling.

Einstellungen für persistente abgeleitete Tabellen (PDTs)

Die folgenden Einstellungen werden angezeigt, wenn PDTs aktiviert sind.

PDTs aktivieren

Aktivieren Sie die Option PDTs aktivieren, um persistente abgeleitete Tabellen zu aktivieren. Wenn PATs aktiviert sind, werden im Fenster Verbindung zusätzliche PAT-Felder und der Abschnitt PAT-Überschreibungen angezeigt. Looker zeigt die Ein/Aus-Schaltfläche PDTs aktivieren nur dann an, wenn der Datenbankdialekt PDTs unterstützt.

Beachten Sie Folgendes zu PDTs:

  • PDTs werden für Snowflake-Verbindungen, die OAuth verwenden, nicht unterstützt.
  • Wenn Sie PDTs für eine Verbindung deaktivieren, werden die Datengruppen, die mit Ihren PDTs verknüpft sind, nicht deaktiviert. Auch 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 ihre sql_trigger-Abfrage für Ihre Datenbank ausführt, müssen Sie den Parameter datagroup aus Ihrem LookML-Projekt löschen oder auskommentieren. Alternativ können Sie die Einstellung Wartungsplan für die Verbindung so aktualisieren, dass Looker PDTs und Datengruppen sehr selten oder nie prüft.
  • Bei Snowflake-Verbindungen legt Looker den Wert für den Parameter AUTOCOMMIT auf TRUE (den Standardwert von Snowflake) fest. AUTOCOMMIT ist für SQL-Befehle erforderlich, die Looker zur Verwaltung des PDT-Registrierungssystems ausführt.

Temporäre Datenbank

Obwohl dieses Label Temporäre Datenbank lautet, geben Sie je nach Ihrem 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 Anweisungen zur Datenbankkonfiguration Ihren Datenbankdialekt aus, um die entsprechenden Anweisungen für diesen Dialekt einzublenden.

Jede Verbindung muss eine eigene temporäre Datenbank oder ein eigenes temporäres Schema haben. Mehrere Verbindungen können sich diese nicht teilen.

Maximale Anzahl von PAT-Builder-Verbindungen

Mit der Einstellung Maximale Anzahl von PAT-Builder-Verbindungen können Sie angeben, wie viele gleichzeitige Tabellen-Builds der Looker-Regenerator für Ihre Datenbankverbindung initiieren kann. Die Einstellung Maximale Anzahl von PAT-Builder-Verbindungen gilt nur für die Tabellentypen, für die der Looker-Regenerator Neuerstellungen initiiert:

  • Tabellen mit triggerbasierter Aufbewahrungsstrategie (persistente abgeleitete Tabellen und zusammengefasste Tabellen, die die Persistenzstrategie datagroup_trigger oder sql_trigger_value verwenden).
  • Persistente Tabellen, die die Strategie persist_for verwenden, aber nur, wenn die persist_for-Tabelle Teil einer Kaskade abgeleiteter Tabellen ist, in der sie von einer Tabelle abhängt, die die Persistenzstrategie datagroup_trigger oder sql_trigger_value verwendet. In diesem Fall erstellt der Looker-Regenerator eine persist_for-Tabelle neu, da die Tabelle für die Neuerstellung einer anderen Tabelle in der Kaskade benötigt wird. Andernfalls initiiert der Regenerator keine Erstellungen für persist_for-Tabellen.

Die Einstellung Maximale Anzahl von PAT-Builder-Verbindungen ist standardmäßig auf 1 festgelegt, kann aber auf bis zu 100 erhöht werden. Der Wert darf jedoch nicht höher sein als der Wert, der im Feld Max. Verbindungen pro Knoten oder in der per-user-query-limit-Einstellung in den Startoptionen von Looker festgelegt ist.

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 mehrere Mandanten unterstützen, wie BigQuery, Snowflake und Redshift, können eine bessere Leistung bei der Verarbeitung paralleler Abfrageerstellungen zeigen.

Wenn Sie die Einstellung Maximale Anzahl von PAT-Builder-Verbindungen erhöhen möchten, sollten Sie sie zuerst um 1 erhöhen. Wenn ein unerwartetes Verhalten auftritt, setzen Sie den Wert wieder auf den Standardwert 1 zurück. Wenn die Abfrageleistung nicht beeinträchtigt wird, können Sie den Wert schrittweise um 1 erhöhen und die Leistung bei jedem Schritt überprüfen, bevor Sie die Einstellung weiter erhöhen.

Hinweise zur Einstellung Maximale Anzahl von PAT-Builder-Verbindungen:

  • Die Einstellung Maximale Anzahl von 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 benötigt werden. Eine Auslöserprüfung ist die Abfrage zum Prüfen, ob die Persistenzstrategie der Tabelle ausgelöst wird. Diese Auslöserprüfungsabfragen werden immer nacheinander ausgeführt. Daher gilt die Einstellung Maximale Anzahl von PAT-Builder-Verbindungen für sie nicht.
  • In einer geclusterten Looker-Instanz wird der Regenerator nur für den Hauptknoten ausgeführt. Die Einstellung Maximale Anzahl von PAT-Builder-Verbindungen gilt nur für den Hauptknoten und legt daher den Grenzwert für den gesamten Cluster fest.
  • Die Einstellung Maximale Anzahl von PAT-Builder-Verbindungen gilt nicht für die nachfolgend aufgeführten Tabellentypen. Diese Tabellentypen werden nacheinander erstellt:
    • Tabellen, die über den Parameter persist_for beibehalten werden (es sei denn, die Tabelle ist von Tabellen abhängig, die die Strategien datagroup_trigger oder sql_trigger_value verwenden).
    • Tabellen im Entwicklungsmodus
    • Tabellen, die mit der Option Abgeleitete Tabellen neu erstellen und ausführen neu erstellt wurden.
    • Tabellen, die in einer Abhängigkeitskaskade voneinander abhängen. Eine Tabelle kann nicht gleichzeitig mit einer Tabelle erstellt werden, von der sie abhängt. Wenn beispielsweise table_B von table_A abhängt, muss die Neuerstellung von table_A abgeschlossen sein, bevor die Neuerstellung von table_B beginnen kann.

Fehlgeschlagene PAT-Builds wiederholen

Mit der Ein/Aus-Schaltfläche Fehlgeschlagene PDT-Builds wiederholen wird konfiguriert, wie der Looker-Regenerator versucht, Tabellen mit triggerbasierter Aufbewahrungsstrategie neu zu erstellen, die im vorherigen Regenerator-Zyklus fehlgeschlagen sind. Der Looker-Regenerator ist der Prozess, der Tabellen mit triggerbasierter Aufbewahrungsstrategie (PDTs und zusammengefasste Tabellen) gemäß dem Intervall neu erstellt, das in der Verbindungseinstellung Wartungszeitplan konfiguriert ist. Wenn die Option Fehlgeschlagene PDT-Builds wiederholen aktiviert ist, versucht der Looker-Regenerator, eine PDT neu zu erstellen, die im vorherigen Regenerator-Zyklus fehlgeschlagen ist, auch wenn die Auslösebedingung der PDT nicht erfüllt ist. Wenn diese Einstellung deaktiviert ist, versucht der Looker-Regenerator nur dann, eine zuvor fehlgeschlagene PDT neu zu erstellen, wenn die Auslösebedingung der PDT erfüllt ist. Fehlgeschlagene PAT-Builds wiederholen ist standardmäßig deaktiviert.

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

API-Steuerung für PAT

Mit der Ein/Aus-Schaltfläche API-Steuerung für PAT wird festgelegt, ob die API-Aufrufe start_pdt_build, check_pdt_build und stop_pdt_build für diese Verbindung verwendet werden können. Wenn die Option PDT API Control deaktiviert ist, schlagen diese API-Aufrufe fehl, wenn sie auf PDTs für diese Verbindung verweisen. Die Ein/Aus-Schaltfläche PDT API Control ist standardmäßig deaktiviert.

PAT-Überschreibungen aktivieren

Wenn Ihre Datenbank persistente abgeleitete Tabellen unterstützt und Sie in den Verbindungseinstellungen die Option PDTs aktivieren aktiviert haben, zeigt Looker die Option PDT-Überschreibungen an. Aktivieren Sie die Option PDT Overrides, um den Abschnitt PDT Overrides einzublenden. Dort können Sie separate JDBC-Parameter (Host, Port, Datenbank, Nutzername, Passwort, Schema, zusätzliche Parameter und Anweisungen nach der Verbindung) 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 Looker-Projekt verwenden, auch wenn Sie Ihren Datenbank-Anmeldedaten 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 PDT-Prozesse an leistungsfähigere 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.

Bei einer Verbindung, bei der die Felder für Nutzername und Passwort auf Nutzerattribute festgelegt sind, kann im Abschnitt PDT-Überschreibungen beispielsweise ein separater Nutzer (pdt_user) mit einem eigenen Passwort erstellt werden. Bei dieser Konfiguration geschieht Folgendes:

  • Jeder Benutzer kann mit seinen eigenen Anmeldedaten, die ihm über seine Benutzerattribute zugewiesen wurden, auf die Datenbank zugreifen.
  • Das Konto pdt_user wird für alle PDT-Prozesse verwendet. Dabei finden entsprechende Zugriffsebenen für die Erstellung und Aktualisierung von PDTs Anwendung.
  • Der Traffic von Nutzerabfragen und der Traffic von PDT-Prozessen können schnell unterschieden werden, z. B. für das Monitoring mit Systemaktivität.

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 dazu finden Sie auf der Dokumentationsseite Zeitzoneneinstellungen verwenden.

Zeitzone der Abfrage

Die Option Zeitzone der Abfrage ist nur sichtbar, wenn Sie Nutzerspezifische Zeitzonen deaktiviert haben.

Wenn nutzerspezifische Zeitzonen deaktiviert sind, ist die Zeitzone der Abfrage die Zeitzone, die Ihren Nutzern angezeigt wird, wenn sie zeitbasierte Daten abfragen. Außerdem ist es die Zeitzone, in die Looker zeitbasierte Daten aus der Zeitzone der Datenbank konvertiert.

Weitere Informationen dazu finden Sie auf der Dokumentationsseite Zeitzoneneinstellungen verwenden.

Maximieren Sie den Bereich Statusdetails, um die Einstellungen für Ihre Verbindung zu testen.

Überprüfen

Nachdem Sie alle Einstellungen für die Datenbankverbindung eingegeben haben, können Sie die Verbindung prüfen und testen, um sicherzustellen, dass sie richtig konfiguriert ist.

Ihre Verbindungseinstellungen testen

Sie können Ihre Verbindungseinstellungen testen, indem Sie unten auf der Seite Verbindungseinstellungen im Bereich Statusdetails auf die Schaltfläche Verbindung testen klicken.

Wenn Looker Can Connect anzeigt, klicken Sie auf Connect, um die Verbindung zu erstellen. Ihre Datenbankverbindung wird dann der Liste auf der Looker-Seite Verbindungen Verwaltung hinzugefügt.

Administratoren können die Verbindung jederzeit testen, indem sie auf der Seite Verbindungen verwalten neben dem Eintrag der Verbindung auf den Button Testen klicken, wie auf der Dokumentationsseite Verbindungen beschrieben.

Wenn Sie einen oder mehrere Verbindungsparameterwerte auf ein Nutzerattribut festgelegt haben, wird die Option Als Nutzer testen angezeigt. Wählen Sie einen Nutzer aus und klicken Sie dann auf Testen, um zu prüfen, ob die Datenbank eine Verbindung herstellen und Abfragen als dieser Nutzer ausführen kann.

Fehlerbehebung

Sollte Ihre Verbindung einen oder zwei Tests nicht bestehen, beachten Sie Folgendes:

  • Wenn Sie Mongo Version 3.6 oder früher in Atlas ausführen und ein Kommunikationsverbindungsfehler 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. Entsprechende Anweisungen finden Sie auf der Dokumentationsseite Anweisungen zur Datenbankkonfiguration.
  • Für Datenbankverbindungen, die OAuth verwenden, z. B. Snowflake, Google BigQuery, Trino und Databricks, ist eine Nutzeranmeldung erforderlich. Wenn Sie nicht bei Ihrem OAuth-Nutzerkonto angemeldet sind, wenn Sie eine dieser Verbindungen testen, zeigt Looker eine Warnung und den Link Anmelden an. Klicken Sie auf den Link, wählen Sie im Dialogfeld OAuth-Verbindung autorisieren die Option Autorisieren aus, wenn Sie dazu aufgefordert werden, und geben Sie Ihre OAuth-Anmeldedaten ein, damit Looker auf Ihre OAuth-Kontoinformationen zugreifen kann.
  • Wenn Looker keine Verbindung zur Datenbank herstellen kann, enthalten die Testergebnisse eine Netzwerkdiagnose, die zeigt, ob Looker den Hostnamen auflösen und eine TCP-Verbindung zu jeder IP-Adresse herstellen kann. Weitere Informationen und Informationen zum Testen der Erreichbarkeit ohne Verbindung finden Sie auf der Seite Administratoreinstellungen – Verbindungen.
  • Tipps zur Fehlerbehebung für vom Kunden gehostete Looker-Instanzen finden Sie auf der Dokumentationsseite Datenbankverbindung für vom Kunden gehostete Instanzen testen.

Nächste Schritte

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