Nachdem Sie Ihre Datenbank gesichert und konfiguriert haben, können Sie eine Verbindung zu Looker herstellen.
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:
- Wählen Sie im Bereich Verwaltung unter Datenbank die Option Verbindungen aus. Klicken Sie auf der Seite Verbindungen auf die Schaltfläche Verbindung hinzufügen.
- Klicken Sie im linken Navigationsbereich auf die Schaltfläche Erstellen und wählen Sie dann den Menüpunkt Verbindung aus.
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 Datenbank mit Looker verbinden angezeigt werden. Die genauen Felder, die auf der Seite angezeigt werden, richten sich nach Ihrer Dialekteinstellung.
Klicken Sie hier, um die Links zu den dialektspezifischen Anleitungen in der Looker-Dokumentation aufzurufen.
- Actian Avalanche
- AlloyDB for PostgreSQL
- Amazon Aurora PostgreSQL
- Amazon Athena
- Amazon Aurora MySQL
- Amazon RDS for MySQL
- Amazon RDS for PostgreSQL
- Amazon Redshift
- Apache Druid
- Apache Hive 2.3 und höher sowie 3.1.2 und höher
- Apache Spark 3 und höher
- ClickHouse
- Cloudera Impala 3.1 und höher
- Databricks
- DataVirtuality
- Denodo
- Dremio
- Exasol
- Firebolt
- Google BigQuery Legacy SQL
- Google BigQuery-Standard-SQL
- Google Cloud SQL for MySQL
- Google Cloud SQL for PostgreSQL
- Google Spanner
- Greenplum
- IBM DB2 auf AS400
- IBM DB2 on LUW
- MariaDB
- Microsoft Azure Synapse Analytics
- Microsoft Azure SQL-Datenbank
- Microsoft Azure PostgreSQL
- Microsoft SQL Server (MSSQL)
- MongoDB-Connector für BI
- MySQL
- Oracle
- Oracle ADWC
- PostgreSQL
- PrestoDB
- SAP HANA
- SingleStore (früher MemSQL)
- Snowflake
- Teradata
- Trino
- Vektor
- Vertica
Nachdem Sie die Einstellungen für die Datenbankverbindung eingegeben haben, können Sie auf der Seite Datenbank mit Looker verbinden die Schaltfläche Testen auswählen, um die Verbindung zu testen und sicherzustellen, dass sie richtig konfiguriert ist. Klicken Sie auf Testen, um zu prüfen, ob die Verbindung erfolgreich hergestellt wurde. Informationen zur Fehlerbehebung finden Sie auf der Dokumentationsseite Datenbankkonnektivität testen. Wenn in Looker Can Connect (Verbindung möglich) angezeigt wird, drücken Sie auf Connect (Verbinden), um die Verbindung herzustellen. Ihre Datenbankverbindung wird dann der Liste auf der Looker-Verwaltungsseite Verbindungen hinzugefügt.
Allgemeine Einstellungen
Name
Der gewünschte Name für die Verbindung. Sie benötigen diesen Datenbankverbindungsnamen für den Parameter connection
Ihres LookML-Modells. Anhand des Namens der Datenbankverbindung wird die Verbindung auch auf der Seite Verbindungen Verwaltung in Looker identifiziert. Verwenden Sie für diese Einstellung keinen Ordnernamen. Dieser Wert muss nicht mit einem Wert in Ihrer Datenbank übereinstimmen. Name
ist ein Label, das diese Verbindung in der Looker-Benutzeroberfläche identifiziert.
Zugehörigkeit zur Verbindung
Wählen Sie aus, ob die Verbindung für alle Projekte oder nur für ein Projekt verwendet werden soll:
- Alle Projekte: Alle LookML-Projekte in der Instanz können auf die Verbindung zugreifen. Der Verbindungsname kann daher im Parameter
connection
von Modelldateien in diesem Projekt angegeben werden. - Ausgewähltes Projekt: 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 in 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 die Modellkonfiguration zu delegieren:
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.
ID des Abrechnungsprojekts
Nur für Google BigQuery-Verbindungen ist die Abrechnungsprojekt-ID die Projekt-ID von Google Cloud .
Host
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 "localhost"
ein.
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 von Ihrem Looker-Analysten mitgeteilt worden sein.
Datenbank
Der Name der Datenbank auf Ihrem Host. Angenommen, Sie haben einen Hostnamen my-instance.us-east-1.redshift.amazonaws.com
, auf dem sich eine Datenbank namens sales_info
befindet. Geben Sie in dieses Feld 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 Datenbank etwas geringfügig anderes als in den meisten SQL-Dialekten.)
Schema
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.
Authentifizierung
Wählen Sie für Verbindungen zu Google BigQuery, Snowflake, Trino und Databricks die Authentifizierungsart aus, die Looker für den Zugriff auf Ihre Datenbank verwenden soll:
- Bei Google BigQuery-Verbindungen haben Sie die Möglichkeit, OAuth oder ein Dienstkonto für Looker zu konfigurieren, um sich bei Ihrer Datenbank zu authentifizieren.
- Bei Snowflake-, Trino- und Databricks-Verbindungen haben Sie die Möglichkeit, OAuth oder ein Datenbankkonto für Looker zu konfigurieren, um sich bei Ihrer Datenbank zu authentifizieren.
Wenn Sie OAuth verwenden, müssen sich Ihre Nutzer in Ihrer Datenbank anmelden, um Abfragen über Looker ausführen zu können. Weitere Informationen zum Konfigurieren von OAuth für eine Verbindung zu Looker finden Sie in den Anleitungen 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.
Optionale Einstellungen
SSH-Server
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 Google Cloud Vertriebsmitarbeiter oder senden Sie eine Supportanfrage.
Der SSH-Server wählt den localhost-Port automatisch für Sie aus. Die Angabe des localhost-Ports ist nicht möglich. Wenn Sie eine SSH-Verbindung erstellen müssen, für die Sie einen localhost-Port angeben müssen, senden Sie eine Supportanfrage.
Wenn Sie eine Verbindung zu Ihrer Datenbank über einen SSH-Tunnel herstellen möchten, aktivieren Sie die Option und wählen Sie in der Drop-down-Liste eine SSH-Serverkonfiguration 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 eine Portnummer in das Feld Benutzerdefinierter lokaler Port ein. Achten Sie darauf, dass der lokale Port auf Ihrer Instanz verfügbar ist.
Persistente abgeleitete Tabellen (PDTs)
PDTs aktivieren
Aktivieren Sie die Option PDTs aktivieren, um nichtflüchtige abgeleitete Tabellen zu aktivieren. Wenn PDTs aktiviert sind, werden im Fenster Verbindung zusätzliche PDT-Felder und der Bereich PDT-Überschreibungen angezeigt. In Looker wird die Ein/Aus-Schaltfläche PDTs aktivieren nur angezeigt, 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.
- 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, werden für vorhandene Datengruppen weiterhin
sql_trigger
-Abfragen in der Datenbank ausgeführt. Wenn Sie verhindern möchten, dass für eine Datengruppe diesql_trigger
-Abfrage in Ihrer Datenbank ausgeführt wird, müssen Sie den Parameterdatagroup
aus Ihrem LookML-Projekt löschen oder kommentieren. Sie können auch die Einstellung Wartungszeitplan für Datengruppen und PDTs für die Verbindung aktualisieren, damit Looker PDTs und Datengruppen sehr selten oder nie prüft. - Bei Snowflake-Verbindungen legt Looker den Wert für den Parameter
AUTOCOMMIT
aufTRUE
fest (Standardwert von Snowflake).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 Schema haben. Mehrere Verbindungen können sich diese nicht teilen.
Max. Anzahl der Verbindungen für PDT-Generator
Mit der Einstellung Max. Anzahl der Verbindungen für PDT-Generator können Sie angeben, wie viele Tabellenerstellungen der Looker-Regenerator für eine Datenbankverbindung gleichzeitig initiieren kann. Die Einstellung Maximale Anzahl von PAT-Builder-Verbindungen gilt nur für die Tabellentypen, für die der Looker-Regenerator Neuerstellungen initiiert:
- Trigger-persistente Tabellen (persistente abgeleitete Tabellen und Aggregattabellen, die die Persistenzstrategie
datagroup_trigger
odersql_trigger_value
verwenden) - Persistierte Tabellen, die die
persist_for
-Strategie verwenden, aber nur, wenn diepersist_for
-Tabelle Teil einer Abfolge abgeleiteter Tabellen ist, bei der sie von einer Tabelle abhängt, die die Persistenzstrategiedatagroup_trigger
odersql_trigger_value
verwendet. In diesem Fall erstellt der Looker-Regenerator einepersist_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ürpersist_for
-Tabellen.
Die Standardeinstellung für Maximale Anzahl von PAT-Builder-Verbindungen ist 1. Sie kann jedoch auf bis zu 10 erhöht werden. Der Wert darf jedoch nicht höher sein als der im Feld Maximale Verbindungen pro Knoten oder in per-user-query-limit
festgelegte Wert in den Startoptionen von Looker.
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, ist es empfehlenswert, sie um jeweils eins zu erhöhen. Wenn unerwartetes Verhalten auftritt, setzen Sie den Wert auf den Standardwert 1 zurück. Andernfalls, wenn die Abfrageleistung nicht beeinträchtigt wird, können Sie den Wert schrittweise um 1 erhöhen und die Leistung bei jedem Schritt prüfen, bevor Sie die Einstellung weiter erhöhen.
Beachten Sie Folgendes zur Einstellung Max. Anzahl der Verbindungen für PDT-Generator:
- Die Einstellung Maximale Anzahl von PAT-Builder-Verbindungen gilt nur für Verbindungen, die für die Neuerstellung von Tabellen erforderlich sind, nicht für Verbindungen, die für Triggerprüfungen erforderlich sind. 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 PDT-Builder-Verbindungen für sie nicht.
- In einer geclusterten Looker-Instanz wird der Regenerator nur auf dem Hauptknoten ausgeführt. Die Einstellung Max. Anzahl der Verbindungen für PDT-Generator gilt nur für den Hauptknoten und legt daher das Limit 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
gespeichert wurden, es sei denn, die Tabelle ist von Tabellen abhängig, die die Strategiendatagroup_trigger
odersql_trigger_value
verwenden. - Tabellen im Entwicklungsmodus
- Tabellen, die mit der Option Abgeleitete Tabellen neu erstellen und ausführen neu erstellt wurden.
- Tabellen, bei denen eine Tabelle in einer Abhängigkeitsabfolge von einer anderen abhängt. Eine Tabelle kann nicht gleichzeitig mit einer Tabelle erstellt werden, von der sie abhängt. Wenn
table_B
beispielsweise vontable_A
abhängt, musstable_A
neu erstellt werden, bevortable_B
neu erstellt werden kann.
- Tabellen, die über den Parameter
Wartungszeitplan für Datengruppe und PAT
Der Looker-Regenerator prüft Datengruppen und persistente Tabellen (sowohl zusammengefasste Tabellen als auch persistente abgeleitete Tabellen), die auf sql_trigger_value
basieren. Basierend auf diesen Prüfungen erstellt der Looker-Regenerator persistente Tabellen neu oder löscht sie aus dem Schema Ihrer Datenbank.
Mit dem Wert Wartungszeitplan für Datengruppe und PAT wird das Intervall cron
für den Looker-Regenerator festgelegt. Der Looker-Regenerator initiiert einen Regenerator-Zyklus, um Datengruppen und persistente Tabellen im Intervall cron
zu prüfen. Wenn zum nächsten cron
-Intervall noch ein Looker-Regeneratorzyklus läuft, schließt der Looker-Regenerator diesen Zyklus ab und wartet dann bis zum nächsten cron
-Intervall, um den nächsten Regeneratorzyklus zu starten.
Für die Einstellung Wartungszeitplan für Datengruppe und PAT ist ein cron
-Ausdruck zulässig. Der Standardwert ist */5 * * * *
. Das bedeutet, dass der Looker-Regenerator nach Ablauf des vorherigen Zyklus einen neuen Zyklus im Fünf-Minuten-Intervall startet. Wenn der vorherige Kreislauf des Regenerators noch nicht abgeschlossen ist, wird der Looker-Regenerator nach Abschluss des Kreislaufs im nächsten Fünf-Minuten-Intervall gestartet.
Der Standardwert von fünf Minuten ist auch das häufigste Intervall, das für den Wartungszeitplan für Datengruppe und PAT unterstützt wird. In Looker wird kein maximales Intervall für den Wartungszeitplan für Datengruppen und PDTs erzwungen. Das bedeutet, dass Sie das Intervall zwischen den Looker-Regeneratorzyklen so lange verlängern können, wie es mit einem cron
-Ausdruck angegeben werden kann. Längere Looker-Regenerator-Zyklen können sich negativ auf die Aktualität der Daten in Ihrem Cache und Ihren persistenten Tabellen auswirken.
Nachdem der Looker-Regenerator alle Prüfungen und die Neuerstellung der PDTs in einem Zyklus abgeschlossen hat, wartet er auf das nächste cron
-Intervall, um den nächsten Zyklus zu starten. Wenn die Erstellung von PDTs lange dauert, kann es zwischen den regeneratorischen Zyklen von Looker lange Zeiträume geben. Die Dauer der Neuerstellung Ihrer Tabellen kann allerdings von anderen Faktoren beeinflusst werden, wie im Abschnitt Wichtige Aspekte beim Implementieren persistenter Tabellen auf der Seite Abgeleitete Tabellen in Looker beschrieben.
Falls Ihre Datenbank nicht rund um die Uhr verfügbar ist, empfehlt sich die Einschränkung der Prüfungen auf die Zeiten der Datenbankverfügbarkeit. Hier sind einige weitere 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
?
incron
-Ausdrücken nicht unterstützt. - Beim Ausdruck
cron
wird die Zeitzone der Looker-Anwendung verwendet, um zu bestimmen, wann Prüfungen durchgeführt werden. - Werden keine PDTs erstellt, setzen Sie die cron-Zeichenfolge auf den Standardwert
*/5 * * * *
zurück.
Im Folgenden finden Sie einige Ressourcen, die Ihnen beim Erstellen von cron
-Strings helfen:
- https://crontab.guru: Hilfe zum Bearbeiten und Testen von
cron
-Strings. - http://www.crontab-generator.org: Wählen Sie die Zeiteinstellungen aus und der Generator erstellt den entsprechenden
cron
-String.
Fehlgeschlagene PAT-Builds wiederholen
Mit der Ein/Aus-Schaltfläche Fehlgeschlagene PDT-Builds noch einmal versuchen wird konfiguriert, wie der Looker-Regenerator versucht, Auslöser-persistente Tabellen neu zu erstellen, die im vorherigen Regenerator-Zyklus fehlgeschlagen sind. Der Looker-Regenerator ist der Prozess, bei dem per Trigger persistente Tabellen (PDTs und aggregierte Tabellen) gemäß dem Intervall neu erstellt werden, das in der Verbindungseinstellung Wartungszeitplan für Datengruppen und PDTs konfiguriert ist. Wenn die Option Fehlgeschlagene PAT-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 PDT-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 PDT API-Steuerung 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 Ein/Aus-Schaltfläche PDT API Control deaktiviert ist, schlagen diese API-Aufrufe fehl, wenn sie auf PDTs für diese Verbindung verweisen. Die Option PDT API Control ist standardmäßig deaktiviert.
PAT-Überschreibungen
Wenn Ihre Datenbank nichtflüchtige abgeleitete Tabellen unterstützt und Sie in den Verbindungseinstellungen die Option PDTs aktivieren aktiviert haben, wird in Looker der Bereich PDT-Überschreibungen angezeigt. Im Bereich PDT-Überschreibungen können Sie eigene JDBC-Parameter eingeben (Host, Port, Datenbank, Nutzername, Passwort, Schema, zusätzliche Parameter und After-Connect-Anweisungen), 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 Anmeldedaten für die Datenbank Nutzerattribute zuweisen oder OAuth für die 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 leistungsstärkere Hardware weitergeleitet werden, die nicht mit den übrigen 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. Im Abschnitt PDT-Überschreibungen wird ein separater Nutzer (pdt_user
) mit einem eigenen Passwort erstellt. Das Konto pdt_user
wird für alle PDT-Prozesse verwendet. Dabei finden entsprechende Zugriffsebenen für die Erstellung und Aktualisierung von PDTs Anwendung.
Zeitzone
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 ist nur sichtbar, wenn Sie Nutzerspezifische Zeitzonen deaktiviert haben.
Wenn Nutzerspezifische Zeitzonen deaktiviert sind, ist die Zeitzone der Abfrage die Zeitzone, die 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 finden Sie auf der Dokumentationsseite Zeitzoneneinstellungen verwenden.
Zusätzliche Einstellungen
Zusätzliche JDBC-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 Liquid-Vorlagensyntax: _user_attributes['name_of_attribute']
. Beispiel:
my_jdbc_param={{ _user_attributes['name_of_attribute'] }}
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. Verbindungen pro Knoten gleich oder kleiner dem Grenzwert Ihrer Datenbank ist.
Zeitlimit für Verbindungspool
Wenn Ihre Nutzer mehr Verbindungen anfordern als in der Einstellung Maximale Verbindungen pro Knoten festgelegt, warten die Anfragen, bis andere abgeschlossen sind, bevor sie ausgeführt werden. Hier wird die maximale Wartezeit für eine Anforderung festgelegt. Die Standardeinstellung beträgt 120 Sekunden.
Diesen Wert sollten Sie mit Bedacht wählen. 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.
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, mit der Sie Ihre Daten schützen können. 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 eine Überprüfung verlangt, muss die SSL-Zertifizierungsstelle, die das SSL-Zertifikat signiert hat, in der Liste der vertrauenswürdigen Quellen des Clients aufgeführt sein. Handelt es sich bei der Zertifizierungsstelle um keine vertrauenswürdige Quelle, wird die Datenbankverbindung nicht hergestellt.
Ist dieses Kästchen nicht angeklickt, 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.
SQL-Runner-Precache
In SQL-Runner werden alle Tabelleninformationen unmittelbar nach der Auswahl einer Verbindung und eines Schemas vorab geladen. So 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 SQL Runner Precache deaktivieren, um das Vorabladen für die Verbindung durch SQL-Runner zu deaktivieren.
Fetch Information Schema For SQL Writing
Für einige Funktionen zum Schreiben von SQL-Code, z. B. die Aggregationserkennung, verwendet Looker das Informationsschema Ihrer Datenbank, um das Schreiben von SQL-Code 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 das Hadoop Distributed File System (HDFS) verwenden, kann das Abrufen des Informationsschemas so lange dauern, dass sich die Leistung Ihrer Looker-Abfragen erheblich verschlechtert. Wenn Sie wissen, dass Ihr Informationsschema langsam ist, können Sie die Option Fetch Information Schema For SQL Writing für die Verbindung deaktivieren. Wenn Sie diese Funktion deaktivieren, wird die Looker-SQL-Optimierung für bestimmte Funktionen verhindert. Sie sollten die Option Informationsschema für SQL-Schreibvorgänge abrufen aktivieren, es sei denn, Sie wissen, dass das Informationsschema Ihrer Verbindung besonders langsam ist.
Kostenschätzung
Die Option Kostenschätzung gilt nur für die folgenden Datenbankverbindungen:
- Snowflake
- Amazon Redshift
- Amazon Aurora
- PostgreSQL, Google Cloud SQL for PostgreSQL und Microsoft Azure PostgreSQL
Mit der Ein/Aus-Schaltfläche Kostenschätzung werden die folgenden Funktionen für die Verbindung aktiviert:
- Kostenschätzungen für Explore-Abfragen
- Kostenschätzungen für SQL Runner-Abfragen
- Schätzungen der Recheneinsparungen für Abfragen zur geschätzten Markenbekanntheit
Weitere Informationen finden Sie auf der Dokumentationsseite Daten in Looker untersuchen.
Datenbankverbindungs-Pooling
Bei Dialekten, die das Pooling von Datenbankverbindungen unterstützen, kann Looker mit dieser Funktion Verbindungspools über den JDBC-Treiber verwenden. Das Pooling von Datenbankverbindungen ermöglicht eine schnellere Abfrageleistung. Für eine neue Abfrage muss keine neue Datenbankverbindung erstellt werden, sondern es kann stattdessen eine vorhandene Verbindung aus dem Verbindungspool verwendet werden. Durch die Verbindungspool-Funktion wird sichergestellt, dass eine Verbindung nach der Ausführung einer Abfrage bereinigt wird und nach Abschluss der Abfrage wiederverwendet werden kann. Weitere Informationen finden Sie auf der Dokumentationsseite Datenbankverbindungspool.
Ihre Verbindungseinstellungen testen
Sie können Ihre Verbindungseinstellungen an mehreren Stellen in der Looker-Benutzeroberfläche testen:
- Wählen Sie unten auf der Seite Verbindungseinstellungen die Schaltfläche Testen aus.
- Wählen Sie auf der Seite Verbindungen auf der Seite „Verwaltung“ neben dem Eintrag der Verbindung die Schaltfläche Testen aus, wie auf der Dokumentationsseite Verbindungen beschrieben.
Nachdem Sie die Verbindungseinstellungen eingegeben haben, klicken Sie auf Testen, um die Richtigkeit der Daten zu verifizieren und sicherzustellen, dass die Datenbank eine Verbindung herstellen kann.
Sollte Ihre Verbindung einen oder mehrere Tests nicht bestehen, haben Sie folgende Möglichkeiten zur Fehlerbehebung:
- Führen Sie einige der auf der Dokumentationsseite Datenbankkonnektivität testen aufgeführten Schritte zur Fehlerbehebung durch.
- Wenn Sie MongoDB 3.6 oder niedriger in Atlas ausführen und eine Kommunikationsverbindung fehlschlägt, lesen Sie die MongoDB-Connector-Dokumentation.
- 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.
Sollten weiterhin Probleme auftreten, stellen Sie eine Supportanfrage.
Als Nutzer testen
Wenn Sie mindestens einen Wert für einen Verbindungsparameter für 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.
Nächste Schritte
Nachdem Sie Ihre Datenbank mit Looker verbunden haben, können Sie Anmeldeoptionen für Ihre Nutzer konfigurieren.