aggregate_table

Nutzung

explore: explore_name {
  aggregate_table: table_name {

    query:  {
      dimensions: [dimension1, dimension2, ... ]
      measures: [measure1, measure2, ... ]
      sorts: [field1: asc, field2: desc, ... ]
      filters: [field1: "value1", field2: "value2", ... ]
      timezone: timezone
    }

    materialization:  {
      ...
    }
  }

  ...

}
Hierarchie
explore
aggregate_table
Standardwert
Keine

Akzeptiert
Einen Namen für die zusammengefasste Tabelle, den Unterparameter query zum Definieren der Tabelle und den Unterparameter materialization zum Definieren der Persistenzstrategie der Tabelle

Sonderregeln
  • Die table_name muss innerhalb einer bestimmten explore eindeutig sein.
  • Im Unterparameter materialization müssen Sie eine Persistenzstrategie für die zusammengefasste Tabelle angeben.

Definition

Mit dem Parameter aggregate_table werden zusammengefasste Tabellen erstellt, die die Anzahl der erforderlichen Abfragen für die großen Tabellen in Ihrer Datenbank minimieren.

Durch Aggregate Awareness findet Looker automatisch die kleinste und effizienteste zusammengefasste Tabelle in Ihrer Datenbank, die für die jeweilige Abfrage geeignet ist, ohne dabei die Accuracy zu beeinträchtigen. (Eine Übersicht und Strategien zum Erstellen von zusammengefassten Tabellen finden Sie auf der Dokumentationsseite Aggregat-Awareness.)

Bei sehr großen Tabellen in Ihrer Datenbank können Sie kleinere zusammengefasste Tabellen mit Daten erstellen, die nach verschiedenen Attributkombinationen gruppiert sind. Diese zusammengefassten Tabellen dienen als sogenannte „Rollup-“ bzw. Zusammenfassungstabellen, die Looker – wann immer möglich – anstelle der ursprünglichen großen Tabelle für Abfragen verwenden kann.

Nachdem Sie Ihre zusammengefassten Tabellen erstellt haben, können Sie Abfragen im Explore ausführen, um zu sehen, welche Tabellen Looker verwendet. Weitere Informationen finden Sie im Abschnitt Bestimmen, welche zusammengefasste Tabelle für eine Abfrage verwendet wird auf der Dokumentationsseite Aggregat-Awareness.

Häufige Gründe, warum zusammengefasste Tabellen nicht verwendet werden, finden Sie im Abschnitt Fehlerbehebung auf der Dokumentationsseite Aggregat-Awareness.

Zusammengefasste Tabelle in LookML definieren

Jeder aggregate_table-Parameter muss einen Namen haben, der innerhalb einer bestimmten explore eindeutig ist.

Der Parameter aggregate_table enthält die Unterparameter query und materialization.

query

Der Parameter query definiert die Abfrage für die zusammengefasste Tabelle, einschließlich der zu verwendenden Dimensionen und Messwerte. Der Parameter query enthält die folgenden Unterparameter:

Parametername Beschreibung Beispiel
dimensions Eine durch Kommas getrennte Liste der Dimensionen aus dem Explore, die in die zusammengefasste Tabelle aufgenommen werden sollen. Das Feld dimensions hat das folgende Format:

dimensions: [dimension1, dimension2, ...]

Jede Dimension in dieser Liste muss in der Ansichtsdatei für das Explore der Abfrage als dimension definiert sein. Wenn Sie ein Feld, das als filter-Feld definiert ist, in die Explore-Abfrage aufnehmen möchten, können Sie es der Liste filters in der Abfrage der zusammengefassten Tabelle hinzufügen. 		dimensions:

  [orders.created_month, orders.country]
measures Eine durch Kommas getrennte Liste der Messwerte aus dem Explore, die in die zusammengefasste Tabelle aufgenommen werden sollen. Das Feld measures hat das folgende Format:

measures: [measure1, measure2, ...]

Informationen zu den für die aggregierte Awareness unterstützten Messwerttypen finden Sie im Abschnitt Faktoren für Messwerttypen auf der Dokumentationsseite Aggregierte Awareness. 		measures:

  [orders.count]
filters Fügt optional einen Filter zu einem query hinzu. Filter werden der WHERE-Klausel des SQL-Codes hinzugefügt, mit dem die zusammengefasste Tabelle generiert wird.

Das Feld filters hat das folgende Format:

filters: [field1: "value1", field2: "value2", ...]

Informationen dazu, wie Filter die Verwendung Ihrer zusammengefassten Tabelle verhindern können, finden Sie im Abschnitt Filterfaktoren auf der Dokumentationsseite Aggregate Awareness.		 filters: [orders.country: "United States", orders.state: "California"]
sorts Gibt optional Sortierfelder und die Sortierrichtung (aufsteigend oder absteigend) für query an.

Das Feld sorts hat das folgende Format:

sorts: [field1: asc|desc, field2: asc|desc, ...] 		[orders.country: asc, orders.state: desc]
timezone Legt die Zeitzone für query fest. Wenn keine Zeitzone angegeben ist, wird für die zusammengefasste Tabelle keine Zeitzonenkonvertierung durchgeführt. Stattdessen wird die Datenbankzeitzone verwendet.

Informationen zum Festlegen der Zeitzone, damit Ihre zusammengefasste Tabelle als Abfragequelle verwendet wird, finden Sie im Abschnitt Zeitzonenfaktoren auf der Dokumentationsseite Aggregat-Awareness.

Die IDE schlägt automatisch den Zeitzonenwert vor, wenn Sie den Parameter timezone in der IDE eingeben. In der IDE wird auch die Liste der unterstützten Zeitzonenwerte im Soforthilfe-Bereich angezeigt.		 timezone: America/Los_Angeles

materialization

Der Parameter materialization gibt die Persistenzstrategie für die zusammengefasste Tabelle sowie andere Optionen für Verteilung, Partitionierung, Indexe und Clustering an, die von Ihrem SQL-Dialekt unterstützt werden.

Damit Ihre zusammengefasste Tabelle für Aggregate Awareness zugänglich ist, muss sie persistent in Ihrer Datenbank gespeichert werden. Der Parameter materialization Ihrer zusammengefassten Tabelle muss einen der folgenden Unterparameter enthalten, um die Persistenzstrategie anzugeben:

Außerdem werden je nach SQL-Dialekt möglicherweise die folgenden materialization-Unterparameter für Ihre zusammengefasste Tabelle unterstützt:

Verwenden Sie die folgenden materialization-Unterparameter, um eine inkrementelle zusammengefasste Tabelle zu erstellen:

datagroup_trigger

Verwenden Sie den Parameter datagroup_trigger, um die Neuerstellung der zusammengefassten Tabelle basierend auf einer vorhandenen Datengruppe auszulösen, die in der Modelldatei definiert ist:


explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      datagroup_trigger: order_datagroup
    }
    query: {
      ...
    }
  }
  ...
}

sql_trigger_value

Verwenden Sie den Parameter sql_trigger_value, um die Neugenerierung der zusammengefassten Tabelle basierend auf einer von Ihnen angegebenen SQL-Anweisung auszulösen. Wenn sich das Ergebnis der SQL-Anweisung vom vorherigen Wert unterscheidet, wird die Tabelle neu generiert. Diese sql_trigger_value-Anweisung löst eine Neugenerierung aus, wenn sich das Datum ändert:

explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      sql_trigger_value: SELECT CURDATE() ;;
    }
    query: {
      ...
    }
  }
  ...
}

persist_for

Der Parameter persist_for wird auch für zusammengefasste Tabellen unterstützt. Mit der Strategie „persist_for“ erzielen Sie jedoch möglicherweise nicht die beste Leistung für die aggregierte Bekanntheit. Wenn ein Nutzer eine Abfrage ausführt, die auf einer persist_for-Tabelle basiert, vergleicht Looker das Alter der Tabelle mit der Einstellung persist_for. Wenn die Tabelle älter als die Einstellung persist_for ist, wird sie vor dem Ausführen der Abfrage neu generiert. Wenn das Alter kleiner als die Einstellung persist_for ist, wird die vorhandene Tabelle verwendet. Wenn ein Nutzer also keine Abfrage innerhalb der persist_for-Zeit ausführt, muss die zusammengefasste Tabelle neu erstellt werden, bevor sie für die Aggregat-Awareness verwendet werden kann.

explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      persist_for: "90 minutes"
    }
    query: {
      ...
    }
  }
  ...
}

Sofern Sie die Einschränkungen nicht kennen und keinen spezifischen Anwendungsfall für die persist_for-Implementierung haben, ist es besser, datagroup_trigger oder sql_trigger_value als Persistenzstrategie für zusammengefasste Tabellen zu verwenden.

cluster_keys

Mit dem Parameter cluster_keys können Sie partitionierten Tabellen in BigQuery oder Snowflake eine geclusterte Spalte hinzufügen. Beim Clustering werden die Daten in einer Partition anhand der Werte in den geclusterten Spalten sortiert und die geclusterten Spalten in Speicherblöcken mit optimaler Größe organisiert.

Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter cluster_keys.

distribution

Mit dem Parameter distribution können Sie die Spalte aus einer zusammengefassten Tabelle angeben, auf die ein Verteilungsschlüssel angewendet werden soll. distribution funktioniert nur mit Redshift- und Aster-Datenbanken. Verwenden Sie für andere SQL-Dialekte (z. B. MySQL und Postgres) stattdessen indexes.

Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter distribution.

distribution_style

Mit dem Parameter distribution_style können Sie angeben, wie die Abfrage für eine zusammengefasste Tabelle auf die Knoten in einer Redshift-Datenbank verteilt wird:

  • distribution_style: all gibt an, dass alle Zeilen vollständig auf jeden Knoten kopiert werden.
  • distribution_style: even gibt eine gleichmäßige Verteilung an, sodass Zeilen nach dem Round-Robin-Verfahren auf verschiedene Knoten verteilt werden.

Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter distribution_style.

indexes

Mit dem Parameter indexes können Sie Indexe auf die Spalten einer zusammengefassten Tabelle anwenden.

Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter indexes.

partition_keys

Der Parameter partition_keys definiert ein Array von Spalten, nach denen die zusammengefasste Tabelle partitioniert wird. partition_keys unterstützt Datenbankdialekte, die Spalten partitionieren können. Wenn eine Abfrage ausgeführt wird, die nach einer partitionierten Spalte gefiltert wird, scannt die Datenbank nur die Partitionen, die die gefilterten Daten enthalten, anstatt die gesamte Tabelle zu scannen. partition_keys wird nur mit den Dialekten Presto und BigQuery unterstützt.

Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter partition_keys.

publish_as_db_view

Mit dem Parameter publish_as_db_view können Sie eine zusammengefasste Tabelle für Abfragen außerhalb von Looker kennzeichnen. Für zusammengefasste Tabellen, bei denen publish_as_db_view auf yes gesetzt ist, erstellt Looker eine stabile Datenbankansicht in der Datenbank für die zusammengefasste Tabelle. Die stabile Datenbankansicht wird in der Datenbank selbst erstellt, sodass sie außerhalb von Looker abgefragt werden kann.

Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter publish_as_db_view.

sortkeys

Mit dem Parameter sortkeys können Sie eine oder mehrere Spalten einer zusammengefassten Tabelle angeben, auf die ein regulärer Sortierschlüssel angewendet werden soll.

Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter sortkeys.

increment_key

Sie können in Ihrem Projekt inkrementelle PDTs erstellen, wenn Ihr Dialekt sie unterstützt. Eine inkrementelle PDT ist eine persistente abgeleitete Tabelle (PDT), die von Looker aufgebaut wird. Dabei werden neue Daten an die Tabelle angehängt, anstatt dass die ganze Tabelle neu erstellt wird. Weitere Informationen finden Sie auf der Dokumentationsseite zu inkrementellen PDTs.

Zusammengefasste Tabellen sind eine Art PDT und können durch Hinzufügen des Parameters increment_key inkrementell erstellt werden. Der Parameter increment_key gibt das Zeitinkrement an, in dem neue Daten abgefragt und an die zusammengefasste Tabelle angehängt werden sollen.

Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter increment_key.

increment_offset

Der Parameter increment_offset gibt die Anzahl vorheriger Zeiträume an (in der Granularität des Inkrementschlüssels), die neu erstellt werden, wenn Daten an die zusammengefasste Tabelle angehängt werden. Der Parameter increment_offset ist für inkrementelle PDTs und zusammengefasste Tabellen optional.

Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter increment_offset.

LookML-Code einer zusammengefassten Tabelle aus einem Explore abrufen

Als Abkürzung können Looker-Entwickler eine Explore-Abfrage verwenden, um eine zusammengefasste Tabelle zu erstellen, und dann die LookML in das LookML-Projekt kopieren:

  1. Wählen Sie in Ihrem Explore alle Felder und Filter aus, die Sie in die zusammengefasste Tabelle aufnehmen möchten.
  2. Klicken Sie auf Ausführen, um die Ergebnisse zu erhalten.
  3. Wählen Sie im Zahnradmenü des Explores die Option LookML abrufen aus. Diese Option ist nur für Looker-Entwickler verfügbar.
  4. Klicken Sie auf den Tab Zusammengefasste Tabelle.
  5. Looker stellt die LookML für ein Explore-Refinement bereit, mit dem die zusammengefasste Tabelle dem Explore hinzugefügt wird. Kopieren Sie den LookML-Code und fügen Sie ihn in die zugehörige Modelldatei ein, die im Kommentar vor dem Explore-Refinement angegeben ist. Wenn das Explore in einer separaten Explore-Datei und nicht in einer Modelldatei definiert ist, können Sie die Verfeinerung der Explore-Datei anstelle der Modelldatei hinzufügen. Beide Standorte sind geeignet.

Wenn Sie die LookML der zusammengefassten Tabelle ändern müssen, können Sie dazu die Parameter verwenden, die auf dieser Seite im Abschnitt Zusammengefasste Tabelle in LookML definieren beschrieben werden. Sie können die zusammengefasste Tabelle umbenennen, ohne dass sich dies auf die ursprüngliche explorative Datenanalyse auswirkt. Andere Änderungen an der zusammengefassten Tabelle können sich jedoch darauf auswirken, ob Looker die zusammengefasste Tabelle für die Explore-Abfrage verwenden kann. Tipps zur Optimierung Ihrer zusammengefassten Tabellen, damit sie für Aggregate Awareness verwendet werden, finden Sie im Abschnitt Zusammengefasste Tabellen entwerfen auf der Dokumentationsseite Aggregate Awareness.

LookML-Code einer aggregierten Tabelle aus einem Dashboard abrufen

Eine weitere Option für Looker-Entwickler besteht darin, die LookML für die zusammengefasste Tabelle für alle Tiles auf einem Dashboard abzurufen und dann die LookML in das LookML-Projekt zu kopieren.

Durch das Erstellen von zusammengefassten Tabellen kann die Leistung eines Dashboards drastisch verbessert werden, insbesondere bei Tiles, die riesige Datasets abfragen.

Wenn Sie die Berechtigung develop haben, können Sie den LookML-Code zum Erstellen zusammengefasster Tabellen für ein Dashboard abrufen. Öffnen Sie dazu das Dashboard, wählen Sie im Dreipunkt-Menü des Dashboards die Option LookML abrufen aus und rufen Sie den Tab Zusammengefasste Tabellen auf:

Für jede Tile, die noch nicht mit der Funktion „Aggregate Awareness“ optimiert wurde, stellt Looker die LookML für ein Refinement des Explores bereit, mit dem die zusammengefasste Tabelle dem Explore hinzugefügt wird. Wenn das Dashboard mehrere Tiles aus demselben Explore enthält, fügt Looker alle zusammengefassten Tabellen in ein einzelnes Explore-Refinement ein. Um die Anzahl der generierten zusammengefassten Tabellen zu reduzieren, ermittelt Looker, ob eine generierte zusammengefasste Tabelle für mehr als eine Tile verwendet werden kann. Wenn ja, werden alle redundanten zusammengefassten Tabellen gelöscht, die für weniger Tiles verwendet werden können.

Kopieren Sie jede Explore-Verfeinerung und fügen Sie sie in die zugehörige Modelldatei ein, die im Kommentar vor der Explore-Verfeinerung angegeben ist. Wenn das Explore in einer separaten Explore-Datei und nicht in einer Modelldatei definiert ist, können Sie die Verfeinerung der Explore-Datei anstelle der Modelldatei hinzufügen. Beide Standorte sind geeignet.

Wenn ein Dashboard-Filter auf eine Tile angewendet wird, fügt Looker die Dimension des Filters der zusammengefassten Tabelle der Tile hinzu, damit die zusammengefasste Tabelle für die Tile verwendet werden kann. Das liegt daran, dass zusammengefasste Tabellen nur dann für eine Abfrage verwendet werden können, wenn die Filter der Abfrage auf Felder verweisen, die als Dimensionen in der zusammengefassten Tabelle verfügbar sind. Weitere Informationen finden Sie auf der Dokumentationsseite Aggregat-Awareness.

Wenn Sie die LookML der zusammengefassten Tabelle ändern müssen, können Sie dazu die Parameter verwenden, die auf dieser Seite im Abschnitt Zusammengefasste Tabelle in LookML definieren beschrieben werden. Sie können die zusammengefasste Tabelle umbenennen, ohne dass sich dies auf die Anwendbarkeit auf die ursprüngliche Dashboard-Tile auswirkt. Andere Änderungen an der zusammengefassten Tabelle können jedoch dazu führen, dass Looker die zusammengefasste Tabelle nicht mehr für das Dashboard verwenden kann. Tipps zur Optimierung Ihrer zusammengefassten Tabellen, damit sie für Aggregate Awareness verwendet werden, finden Sie im Abschnitt Zusammengefasste Tabellen entwerfen auf der Dokumentationsseite Aggregate Awareness.

Beispiel

Im folgenden Beispiel wird eine zusammengefasste Tabelle monthly_orders für das Explore event erstellt. In der zusammengefassten Tabelle wird die monatliche Anzahl der Bestellungen erstellt. Looker verwendet die zusammengefasste Tabelle für Abfragen zur Anzahl der Bestellungen, die Daten auf Monatsebene nutzen können, z. B. Abfragen zur jährlichen, vierteljährlichen und monatlichen Anzahl der Bestellungen.

Die zusammengefasste Tabelle wird mit der Datengruppe orders_datagroup persistent eingerichtet. Außerdem wird die zusammengefasste Tabelle mit publish_as_db_view: yes definiert. Das bedeutet, dass Looker eine stabile Datenbankansicht für die zusammengefasste Tabelle erstellt.

Die Definition der zusammengefassten Tabelle sieht so aus:

explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      datagroup_trigger: orders_datagroup
      publish_as_db_view: yes
    }
    query: {
      dimensions: [orders.created_month]
      measures: [orders.count]
      filters: [orders.created_date: "1 year", orders.status: "fulfilled"]
      timezone: America/Los_Angeles
    }
  }
}

Wichtige Punkte

Im Abschnitt Zusammengefasste Tabellen entwerfen auf der Dokumentationsseite Aggregate Awareness finden Sie Tipps zum strategischen Erstellen von zusammengefassten Tabellen:

Dialektunterstützung für Aggregate Awareness

Die Möglichkeit, die Funktion „Aggregate Awareness“ zu nutzen, hängt von dem Datenbankdialekt ab, den Ihre Looker-Verbindung verwendet. In der neuesten Version von Looker unterstützen die folgenden Dialekte die Aggregat-Awareness:

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
ClickHouse 26+
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+
Dremio 26+ with Arrow Flight SQL
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
MongoSQL
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