Bei Dialekten, die diese Funktion unterstützen, können Sie mit der Funktion für benutzerdefinierte Kalender in Looker einen benutzerdefinierten Kalender in Ihrer Datenbank definieren, z. B. einen bestimmten Geschäfts- oder Einzelhandelskalender, und ihn dann auf eine datumsbasierte Dimensionsgruppe in Ihrem LookML-Modell anwenden. Ihre Nutzer können dann Explore-Abfragen mit Ihren benutzerdefinierten Zeiträumen wie custom_week und custom_period erstellen, als wären es Standardzeiträume.
Vorbereitung
Bevor Sie benutzerdefinierte Kalender verwenden, müssen die folgenden Voraussetzungen erfüllt sein:
- Sie benötigen eine Looker-Verbindung zu einem Dialekt, der benutzerdefinierte Kalender unterstützt.
- Sie müssen eine Kalendertabelle in Ihrer Datenbank erstellen, die Sie dann als Ansicht in Looker modellieren können. Looker verwendet die Kalendertabelle in Ihrer Datenbank, um benutzerdefinierte Zeiträume zu berechnen. Weitere Informationen finden Sie im Abschnitt Kalendertabelle in der Datenbank erstellen.
- Ihr LookML-Projekt muss die neue LookML-Laufzeit verwenden. Wenn die Legacy-Funktion Use Legacy LookML Runtime (Legacy-LookML-Laufzeit verwenden) für Ihre Instanz aktiviert ist, müssen Sie die Anweisung
new_lookml_runtime: yesin die Manifestdatei Ihres Projekts einfügen.
Benutzerdefinierten Kalender erstellen
Wenn Sie einen benutzerdefinierten Kalender implementieren möchten, müssen Sie die folgenden allgemeinen Schritte ausführen, die in den folgenden Abschnitten beschrieben werden:
- Kalendertabelle in der Datenbank erstellen
- Benutzerdefinierte Kalenderansicht in LookML definieren
- Benutzerdefinierte Kalenderdimensionsgruppe erstellen
Kalendertabelle in der Datenbank erstellen
Um Datumsangaben für benutzerdefinierte Kalender zu berechnen, benötigt Looker eine spezielle Kalendertabelle in Ihrer Datenbank, in der Ihre benutzerdefinierten Zeiträume definiert sind. Ihre Tabelle muss eine Spalte mit dem Referenzdatum enthalten, in der das Standardkalenderdatum verwendet wird. Looker verknüpft Ihre Kalendertabelle mit Ihren Datentabellen (z. B. einer orders-Tabelle) anhand der Spalte „Referenzdatum“.
Die Spaltennamen in der Kalendertabelle sind flexibel. Wenn Sie die benutzerdefinierte Kalenderansicht in LookML definieren, verwenden Sie den calendar_definition-Block, um die Spalten in Ihrer Datenbank den Standardnamen für benutzerdefinierte Zeiträume zuzuordnen.
Unten sehen Sie ein Beispiel für ein Tabellenschema für eine Kalendertabelle mit dem Namen fiscal_calendar_table.
| Spaltenname | Datentyp | Beschreibung |
|---|---|---|
reference_date |
DATE |
Das Standardkalenderdatum, z. B. „2023-01-01“. Wird für die Teilnahme verwendet. Sollte ein eindeutiger oder Primärschlüssel sein. |
fiscal_year |
VARCHAR |
Das Geschäftsjahr, z. B. „GJ2023“. |
fiscal_year_num |
INTEGER |
Das numerische Geschäftsjahr, z. B. 2023. |
fiscal_quarter_of_year |
VARCHAR |
Das Geschäftsquartal (z. B. „FQ1“). |
fiscal_quarter_of_year_num |
INTEGER |
Das numerische Geschäftsquartal (z. B. 1). |
fiscal_week_of_year |
VARCHAR |
Die Geschäftsjahrwoche des Jahres (z. B. „Week01“, „FW01“). |
fiscal_week_of_year_num |
INTEGER |
Die numerische Geschäftsjahrwoche des Jahres (z. B. 1). |
fiscal_period_of_year |
VARCHAR |
Ein benutzerdefinierter Zeitraumname, z. B. „P01“. |
fiscal_period_of_year_num |
INTEGER |
Der numerische benutzerdefinierte Zeitraum (z. B. 1). |
season |
VARCHAR |
Ein benutzerdefinierter Saisonname, z. B. „Winter“. |
season_num |
INTEGER |
Die numerische benutzerdefinierte Saison (z. B. 1). |
Hier einige Beispielzeilen aus der Tabelle fiscal_calendar_table:
reference_date |
fiscal_year |
fiscal_year_num |
fiscal_period |
fiscal_period_num |
|---|---|---|---|---|
2023-12-25 |
FY2024 |
2024 |
P01 |
1 |
2023-12-26 |
FY2024 |
2024 |
P01 |
1 |
2024-01-01 |
FY2024 |
2024 |
P02 |
2 |
2024-01-02 |
FY2024 |
2024 |
P02 |
2 |
Benutzerdefinierte Kalenderansicht in LookML definieren
Nachdem Sie eine Kalendertabelle in Ihrer Datenbank erstellt haben, müssen Sie eine LookML-Ansicht erstellen, um die Datenbank-Kalendertabelle zu modellieren.
Die Datei für die benutzerdefinierte Kalenderansicht muss Folgendes enthalten:
- Der Parameter
sql_table_name, der auf die benutzerdefinierte Kalendertabelle in Ihrer Datenbank verweist. - Der Block
calendar_definition, um die Spalten der Tabelle den benutzerdefinierten Looker-Zeitraumtypen zuzuordnen. dimension-Parameter zum Modellieren der Spalten der benutzerdefinierten Kalendertabelle in Ihrer Datenbank.
Hier sehen Sie eine Beispielansichtsdatei mit dem Namen fiscal_calendar.view.lkml, die das Beispiel fiscal_calendar_table modelliert:
view: fiscal_calendar {
sql_table_name: fiscal_calendar_table ;;
calendar_definition: {
reference_date: reference_date
timeframe_mapping: {
custom_year: fiscal_year
custom_quarter: fiscal_quarter_of_year
custom_date: fiscal_date
custom_week: fiscal_week_of_year
custom_period: fiscal_period_of_year
custom_season: season
}
timeframe_ordinal_mapping: {
custom_year: fiscal_year_num
custom_quarter: fiscal_quarter_of_year_num
custom_date: fiscal_date_num
custom_week: fiscal_week_of_year_num
custom_period: fiscal_period_of_year_num
custom_season: season_num
}
}
dimension: reference_date {
type: date
primary_key: yes
sql: ${TABLE}.reference_date ;; # Assuming column name is reference_date
}
dimension: fiscal_date {
type: string
sql: FORMAT_TIMESTAMP('%Y-%m-%d', ${TABLE}.reference_date) ;;
}
dimension: fiscal_year {
type: string
sql: ${TABLE}.fiscal_year ;;
}
dimension: fiscal_year_num {
type: number
sql: ${TABLE}.fiscal_year_num ;;
}
# ... other dimensions for quarters, weeks, periods, seasons, etc. ...
# Example placeholder dimensions for unused timeframes
dimension: season {
type: string
sql: 'N/A' ;;
hidden: yes
}
dimension: season_num {
type: number
sql: 0 ;;
hidden: yes
}
}
Weitere Informationen zu den calendar_definition-Parametern finden Sie auf der Parameterseite zu calendar_definition.
Benutzerdefinierte Kalenderdimensionsgruppe erstellen
Nachdem Sie eine Kalendertabelle in Ihrer Datenbank erstellt und die Datenbank-Kalendertabelle in LookML modelliert haben, können Sie eine Dimensionsgruppe vom Typ type: custom_calendar erstellen, die auf der benutzerdefinierten Kalenderansicht basiert.
Hier ist beispielsweise eine Ansichtsdatei mit dem Namen orders.view.lkml, in der eine benutzerdefinierte Kalenderdimensionsgruppe definiert wird.
include: "/views/fiscal_calendar.view"
view: orders {
sql_table_name: public.orders ;;
dimension_group: created {
type: custom_calendar
# Optional list of allowed timeframes
custom_timeframes: [
custom_date,
custom_week,
custom_year
]
sql: ${TABLE}.created_at ;;
based_on_calendar: fiscal_calendar # This links to your calendar view
}
}
Mit diesem LookML erstellt Looker automatisch eine neue Gruppe benutzerdefinierter Zeiträume für die Dimensionsgruppe created, z. B. „Benutzerdefiniertes Jahr (erstellt)“ und „Benutzerdefinierte Woche (erstellt)“. Nutzer können diese Felder dann zum Analysieren, Erstellen von Berichten und Filtern verwenden.
Weitere Informationen zum Erstellen einer Dimensionsgruppe für benutzerdefinierte Kalender finden Sie auf der Dokumentationsseite dimension_group.
Wichtige Punkte
Beachten Sie die folgenden Einschränkungen für benutzerdefinierte Kalender:
- Gefilterte Messwerte: Benutzerdefinierte Kalender werden für gefilterte Messwerte nicht unterstützt. Sie können im Parameter
filterseines Messwerts nicht auf eine benutzerdefinierte Kalenderdimension verweisen. - Erweiterte Filter: Benutzerdefinierte Kalender werden in erweiterten Filtern nicht unterstützt. Sie können in Looker-Filterausdrücken nicht auf eine benutzerdefinierte Kalenderdimension verweisen.
- Symmetrische Aggregate:In einigen komplexen Join-Szenarien werden symmetrische Aggregate möglicherweise nicht vollständig für Abfragen mit benutzerdefinierten Kalenderdimensionen unterstützt.
- Dimensionen auffüllen:Looker kann fehlende Datumsangaben für benutzerdefinierte Kalenderdimensionen nicht auffüllen.
- Filtern über Kalendergrenzen hinaus:Wenn ein Filter auf einen benutzerdefinierten Zeitraum angewendet wird, der ein Datum enthält, das nicht im Kalender ist, können unerwartete Ergebnisse zurückgegeben werden. Das hängt mit der ordinalen Arithmetik zusammen, die zur Berechnung des Beginns eines Zeitraums verwendet wird.
- Verhalten bei der Zeitzonenkonvertierung:Looker berücksichtigt die vorhandene Semantik für die Zeitzonenkonvertierung. Wenn die Zeitzone der Datenbank und der Abfrage übereinstimmen, wird keine Zeitzonenkonvertierung angewendet. Wenn sie nicht übereinstimmen, wendet Looker die Zeitzonenkonvertierung an. Sie können dieses Verhalten überschreiben, indem Sie
convert_tz: nofür Ihre benutzerdefinierte Kalenderdimensionsgruppe angeben. - Standardsortierung:Looker wendet eine Standardsortierung auf das erste Datumsfeld an, wenn benutzerdefinierte Kalenderfelder ausgewählt sind. Der Nutzer kann dann verschiedene Sortierungen der Daten festlegen.
Unterstützte Datenbankdialekte für benutzerdefinierte Kalender
In der folgenden Tabelle ist zu sehen, welche Dialekte benutzerdefinierte Kalender in der aktuellen Version von Looker unterstützen:
| Dialekt | Unterstützt? |
|---|---|
| Actian Avalanche | |
| Amazon Athena | |
| Amazon Aurora MySQL | |
| Amazon Redshift | |
| Amazon Redshift 2.1+ | |
| Amazon Redshift Serverless 2.1+ | |
| Apache Druid | |
| Apache Druid 0.13.x - 0.17.x | |
| Apache Druid 0.18+ | |
| Apache Hive 2.3+ | |
| Apache Hive 3.1.2+ | |
| Apache Spark 3+ | |
| ClickHouse | |
| Cloudera Impala 3.1+ | |
| Cloudera Impala 3.1+ with Native Driver | |
| Cloudera Impala with Native Driver | |
| DataVirtuality | |
| Databricks | |
| Denodo 7 | |
| Denodo 8 & 9 | |
| Dremio | |
| Dremio 11+ | |
| Exasol | |
| Google BigQuery Legacy SQL | |
| Google BigQuery Standard SQL | |
| Google Cloud AlloyDB for PostgreSQL | |
| Google Cloud PostgreSQL | |
| Google Cloud SQL | |
| Google Spanner | |
| Greenplum | |
| HyperSQL | |
| IBM Netezza | |
| MariaDB | |
| Microsoft Azure PostgreSQL | |
| Microsoft Azure SQL Database | |
| Microsoft Azure Synapse Analytics | |
| Microsoft SQL Server 2008+ | |
| Microsoft SQL Server 2012+ | |
| Microsoft SQL Server 2016 | |
| Microsoft SQL Server 2017+ | |
| MongoBI | |
| MySQL | |
| MySQL 8.0.12+ | |
| Oracle | |
| Oracle ADWC | |
| PostgreSQL 9.5+ | |
| PostgreSQL pre-9.5 | |
| PrestoDB | |
| PrestoSQL | |
| SAP HANA | |
| SAP HANA 2+ | |
| SingleStore | |
| SingleStore 7+ | |
| Snowflake | |
| Teradata | |
| Trino | |
| Vector | |
| Vertica |