Looker kann zeitbasierte Daten durch die Konvertierung in verschiedene Zeitzonen leichter verstehen. Nutzer können Abfrageergebnisse ansehen und Filter mit zeitbasierten Daten erstellen, die in ihre lokale Zeitzone konvertiert werden. Beispiel: Ein Nutzer in New York, der sich in Kalifornien erstellte Daten ansieht, muss nicht manuell drei Stunden abziehen, um seine Abfragen zu filtern oder zu interpretieren.
Looker konvertiert zeitbasierte Daten, wenn es während einer Abfrage für einen Look, ein Explore oder ein Dashboard SQL generiert. Die zugrunde liegenden Daten sind nicht betroffen. Stattdessen werden die Abfrageergebnisse mit den Zeitzoneneinstellungen von Looker konvertiert. Dies bedeutet auch, dass Abfragen, die mit SQL Runner ausgeführt werden, keine zeitbasierten Daten konvertieren.
Verschiedene Einstellungen in Looker geben an, wie zeitbasierte Daten umgewandelt werden:
- Systemzeitzone
- Zeitzone der Datenbank
- Nutzerspezifische Zeitzonen
- Zeitzone der Anwendung
- Zeitzone der Suchanfrage
convert_tz
LookML-Parametersql
LookML-Parameter
Systemzeitzone
Die Systemzeitzone ist die Zeitzone, für die der Server konfiguriert ist, auf dem Looker ausgeführt wird. Die interne Looker-Datenbank, die die in den i__looker
- und Systemaktivitäts-Explores verfügbaren Informationen speichert, speichert zeitbasierte Daten in der Systemzeitzone.
Die Systemzeitzone kann in der Looker-Anwendung nicht konfiguriert werden. Bei von Looker gehosteten Instanzen ist die Systemzeitzone immer auf UTC eingestellt. Vom Kunden gehostete Instanzen können sich in einer anderen Systemzeitzone befinden. Das Ändern der Systemzeitzone ist nicht einfach und wird nicht empfohlen. Wenn Sie Zeitstempel in einem i__looker
- oder Systemaktivitäts-Explore anpassen müssen, empfiehlt Looker, Tabelleberechnungen zu verwenden, um zeitangepasste Spalten zu erstellen. Wenn Sie beispielsweise von UTC in EST umrechnen möchten, können Sie eine Spalte mit der Tabellenkalkulation add_hours(-5, ${time})
erstellen.
Zeitzone der Datenbank
Wenn Sie eine Verbindung zu einer Datenbank hinzufügen, legen Sie den Wert für die Zeitzone für Datenbank auf der Seite Verbindungseinstellungen fest.
Diese Einstellung stellt die Zeitzone dar, in der sich Ihre Datenbank befindet, typischerweise koordinierte Weltzeit (UTC). Wenn Sie für diesen Wert einen anderen Wert als die Zeitzone festlegen, in der sich Ihre Datenbank befindet, kann dies zu unerwarteten Ergebnissen führen.
nutzerspezifische Zeitzone
Die wichtigste Einstellung für die zeitbasierte Datenkonvertierung ist die Option Nutzerspezifische Zeitzonen. Sie finden sie in Looker im Bereich Admin auf der Seite Allgemeine Einstellungen.
Sie können Nutzerspezifische Zeitzonen aktivieren oder deaktivieren:
- Wenn diese Option aktiviert ist, wird jedem Looker-Benutzer eine Zeitzone zugewiesen, und diese Zeitzone bestimmt die Darstellung der Abfrageergebnisse.
- Wenn diese Option deaktiviert ist, sind ihren Konten keine einzelnen Zeitzonen zugewiesen. Stattdessen werden alle Abfragen mit dem Wert für die Abfragezeitzone ausgeführt.
Wenn Nutzerspezifische Zeitzonen aktiviert ist, können Nutzer ihre Zeitzone auf der Seite Konto festlegen oder Looker-Administratoren können Nutzern auf der Seite Nutzer Zeitzonen zuweisen. Wenn für einen Nutzer keine Zeitzone festgelegt ist, wird für sein Konto standardmäßig die Looker-Einstellung Zeitzone der Anwendung verwendet.
Wenn ein Nutzer eine Abfrage erstellt, wird diese in der Zeitzone des Nutzers erstellt. Wenn eine Abfrage zeitbasierte Daten zurückgibt, konvertiert Looker die Daten daher aus der Datenbankzeitzone in die Zeitzone des Nutzers. Wenn ein Nutzer zeitbezogene Filterwerte in einer Abfrage verwendet, konvertiert Looker die Filterwerte in die Datenbankzeitzone.
Wenn Sie diese Option aktivieren, wird in Looker außerdem unter Explores und Looks ein Drop-down-Menü Zeitzone angezeigt.
In diesem Drop-down-Menü sind folgende Optionen verfügbar:
- Zeitzone jeder Tile (nur Dashboards): Alle Abfragen werden in der Zeitzone ausgeführt, mit der sie gespeichert wurden.
- Zeitzone des Betrachters: Alle Abfragen werden in der aktuellen Zeitzoneneinstellung des Nutzers ausgeführt.
- Eine Liste jeder einzelnen Zeitzone, die Nutzer manuell auswählen können.
Für alle Abfragen wird standardmäßig die Zeitzone verwendet, mit der die Abfrage erstellt wurde. Mit anderen Worten: Wenn Alice eine Abfrage mit der Zeitzone „America/Los Angeles“ erstellt, an Bob sendet, sieht Bob die Abfrage mit der Zeitzone "America/Los Angeles", auch wenn als Zeitzone „Amerika/New York“ festgelegt ist. Ebenso wird beim Aufschlüsseln standardmäßig immer die Zeitzone verwendet, mit der die Abfrage erstellt wurde.
Beim Aufrufen einer Abfrage können Nutzer über das Drop-down-Menü die Zeitzone überschreiben und ihre Zeitzone des Betrachters oder eine andere Zeitzone für diese Abfrage oder die Abfragegruppe dieses Dashboards auswählen.
Was bei nutzerspezifischen Zeitzonen zu beachten ist
Wenn Sie Nutzerspezifische Zeitzonen aktivieren, sehen Nutzer in verschiedenen Zeitzonen Daten unter Umständen unterschiedlich.
Beispielsweise unterscheiden sich die genauen Stunden, aus denen sich der Zeitraum last month
zusammensetzt, je nach Zeitzone unterschiedlich. Nutzer sehen also möglicherweise unterschiedliche Datenwerte, wenn sie sich in verschiedenen Zeitzonen befinden, aber beide nach last month
filtern.
Zeitzone der Anwendung
Die Zeitzone der Anwendung kann in Looker im Bereich Admin auf der Seite Allgemeine Einstellungen konfiguriert werden.
Die Application Time Zone ist die Standardzeitzone für Inhaltsübermittlungen. Die für Inhaltsübermittlungen verwendete Zeitzone wirkt sich nicht auf zeitbasierte Daten aus, die von einer Abfrage zurückgegeben werden. wirkt sich dies nur auf die Zeit aus, zu der eine Datenlieferung gesendet wird.
Wenn Sie die Option Nutzerspezifische Zeitzonen aktivieren, wird die Zeitzone der Anwendung als Standardzeitzone für Nutzer verwendet, die für ihre Konten keine Zeitzone festgelegt haben.
Zeitzone der Abfrage
Die Option Zeitzone für Suchanfrage wird nur angezeigt, wenn Sie die Option Nutzerspezifische Zeitzonen deaktiviert haben. In diesem Fall legen Sie den Wert für die Abfragezeitzone fest, wenn Sie auf der Seite Verbindungseinstellungen eine Verbindung zu einer Datenbank hinzufügen.
Wenn Sie Nutzerspezifische Zeitzonen deaktivieren,verwenden alle Abfragen zeitbasierter Daten die Abfragezeitzone. Looker wandelt alle zeitbasierten Daten von der Datenbankzeitzone in die Abfragezeitzone um.
LookML-Parameter convert_tz
Looker führt standardmäßig die Zeitzonenkonvertierung durch. Wenn Sie die Zeitzonenkonvertierung für ein einzelnes Feld deaktivieren möchten, können Sie den LookML-Parameter convert_tz
verwenden. Beispiel:
dimension_group: created {
type: time
timeframes: [time, date]
convert_tz: no
}
Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter convert_tz
.
LookML-Parameter sql
Sie können die Zeitzonenkonvertierung auch manuell mithilfe der Funktionen Ihres Datenbankdialekts im Parameter sql
in einer LookML-Dimension definieren. Um beispielsweise die Zeitzonenkonvertierung in MySQL manuell zu definieren, können Sie den folgenden LookML-Code verwenden:
dimension_group: created {
type: time
timeframes: [time, date]
sql: CONVERT_TZ(${TABLE}.created_at,'UTC','PST') ;;
}
Hinweise zu MySQL-Dialekten
MySQL benötigt eine Zeitzonentabelle, damit seine Zeitzonenkonvertierungsfunktion funktioniert. Dies kann von einem Administrator ausgeführt werden. Weitere Informationen finden Sie in der MySQL-Dokumentation.
Notizen aus Postgres-Dialekten
Looker verwendet die Treibereinstellung, um die Zielzeitzone auszuwählen. Dies kann sich darauf auswirken, wie Abfragen in SQL Runner im Vergleich zu pgAdmin verarbeitet werden, da Looker das aktuelle Datum und die Uhrzeit in der ausgewählten Zeitzone verwendet.
Unterstützung von Datenbankdialekten für die Zeitzonenkonvertierung
Damit Looker Zeitzonen in Ihrem Looker-Projekt umwandeln kann, muss Ihr Datenbankdialekt die Konvertierung der Zeitzone unterstützen. Die folgende Tabelle zeigt, welche Dialekte die Zeitzonenkonvertierung in der neuesten Version von Looker unterstützen:
Dialekt | Unterstützt? |
---|---|
Actian Lawine | Nein |
Amazon Athena | Ja |
Amazon Aurora MySQL | Ja |
Amazon Redshift | Ja |
Druid | Nein |
Apache Druid 0.13+ | Ja |
Apache Druid 0.18+ | Ja |
Apache Hive 2.3 und höher | Ja |
Apache Hive 3.1.2 und höher | Ja |
Apache Spark 3 und höher | Ja |
ClickHouse | Nein |
Cloudera Impala 3.1 und höher | Ja |
Cloudera Impala 3.1+ mit nativem Treiber | Ja |
Cloudera Impala mit nativem Treiber | Ja |
DataVirtuality | Nein |
Databricks | Ja |
Denodo 7 | Nein |
Denodo 8 | Nein |
Dremio | Ja |
Dremio 11+ | Ja |
Exasol | Nein |
Firebolt | Nein |
Google BigQuery Legacy-SQL | Nein |
Google BigQuery-Standard-SQL | Ja |
Google Cloud PostgreSQL | Ja |
Google Cloud SQL | Ja |
Google Spanner | Ja |
Greenplum | Ja |
HyperSQL | Nein |
IBM Netezza | Ja |
MariaDB | Ja |
Microsoft Azure PostgreSQL | Ja |
Microsoft Azure SQL-Datenbank | Ja |
Microsoft Azure Synapse-Analyse | Ja |
Microsoft SQL Server 2008 oder höher | Nein |
Microsoft SQL Server 2012 und höher | Nein |
Microsoft SQL Server 2016 | Ja |
Microsoft SQL Server 2017 und höher | Ja |
MongoBI | Nein |
MySQL | Ja |
MySQL 8.0.12 und höher | Ja |
Oracle | Ja |
Oracle ADWC | Ja |
PostgreSQL 9.5+ | Ja |
PostgreSQL vor 9.5 | Ja |
PrestoDB | Ja |
PrestoSQL | Ja |
SAP HANA 2 und höher | Nein |
SingleStore | Ja |
SingleStore 7 und höher | Ja |
Snowflake | Ja |
Teradata | Nein |
Trino | Ja |
Vektor | Nein |
Vertica | Ja |