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

Besondere Regeln
  • Die table_name muss innerhalb eines 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 Richtigkeit zu beeinträchtigen. Einen Überblick über das Erstellen von aggregierten Tabellen und Strategien dafür finden Sie auf der Dokumentationsseite Aggregate 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 zusammengefassten Tabellen Looker verwendet. Weitere Informationen finden Sie im Abschnitt Ermitteln, welche zusammengefasste Tabelle für eine Abfrage verwendet wird auf der Dokumentationsseite Aggregate Awareness.

Im Abschnitt Fehlerbehebung auf der Dokumentationsseite Aggregatbewusstsein finden Sie häufige Gründe dafür, dass Aggregattabellen nicht verwendet werden.

Zusammengefasste Tabelle in LookML definieren

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

Der Parameter aggregate_table hat die Unterparameter query und materialization.

query

Mit dem Parameter query wird die Abfrage für die zusammengefasste Tabelle definiert, 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 der explorativen Datenanalyse, die in Ihre 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 einfügen möchten, das in der Explore-Abfrage als filter-Feld definiert ist, können Sie es der Liste filters in der Abfrage der aggregierten 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 verwendet dieses Format:

measures: [measure1, measure2, ...]

Informationen zu den Messwerttypen, die für die aggregierte Bekanntheit unterstützt werden, finden Sie im Abschnitt Faktoren für Messwerttypen auf der Dokumentationsseite Aggregierte Bekanntheit. 		measures:

  [orders.count]
filters Fügt optional einen Filter zu einer query hinzu. Filter werden der WHERE-Klausel des SQL-Codes hinzugefügt, mit dem die Aggregattabelle 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 auf der Dokumentationsseite Aggregatbewusstsein im Abschnitt Filterfaktoren.		 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 in der zusammengefassten 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 Aggregatbewusstsein.

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

materialization

Mit dem Parameter materialization wird die Persistenzstrategie für Ihre zusammengefasste Tabelle sowie andere Optionen für Verteilung, Partitionierung, Indexe und Clustering angegeben, 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 haben, um die Persistenzstrategie anzugeben:

Außerdem werden für Ihre zusammengefasste Tabelle je nach SQL-Dialekt möglicherweise die folgenden materialization-Unterparameter 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

Mit dem Parameter sql_trigger_value können Sie die Neugenerierung der zusammengefassten Tabelle basierend auf einer von Ihnen angegebenen SQL-Anweisung auslösen. Wenn das Ergebnis der SQL-Anweisung sich vom vorherigen Wert unterscheidet, wird die Tabelle neu generiert. Diese sql_trigger_value-Anweisung löst die Neuerstellung 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. Die persist_for-Strategie bietet jedoch möglicherweise nicht die beste Leistung für Aggregate Awareness. Das liegt daran, dass Looker bei einer Abfrage, die auf einer persist_for-Tabelle basiert, das Alter der Tabelle mit der persist_for-Einstellung vergleicht. Wenn die Tabelle älter als die persist_for-Einstellung ist, wird sie vor der Ausführung der Abfrage neu generiert. Wenn das Alter unter der persist_for-Einstellung liegt, wird die vorhandene Tabelle verwendet. Wenn ein Nutzer also nicht innerhalb des persist_for-Zeitraums eine Abfrage ausführt, muss die zusammengefasste Tabelle neu erstellt werden, bevor sie für Aggregate 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 bestimmten Anwendungsfall für die persist_for-Implementierung haben, sollten Sie datagroup_trigger oder sql_trigger_value als Persistenzstrategie für aggregierte Tabellen 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.
  • Mit distribution_style: even wird eine gleichmäßige Verteilung angegeben, sodass Zeilen im 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

Mit dem Parameter partition_keys wird ein Array von Spalten definiert, 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 Presto- und BigQuery-Dialekten 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 festgelegt 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 inkrementelle PDTs in Ihrem Projekt 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 Inkrementelle persistente abgeleitete Tabellen.

Zusammengefasste Tabellen sind eine Art von PDT und können inkrementell erstellt werden, indem der Parameter increment_key hinzugefügt wird. 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

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

Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter increment_offset.

LookML-Code einer zusammengefassten Tabelle aus einem Explore abrufen

Looker-Entwickler können 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 in Ihre zusammengefasste Tabelle aufgenommen werden sollen.
  2. Klicken Sie auf Ausführen, um die Ergebnisse zu erhalten.
  3. Wählen Sie im Zahnradmenü des Explores LookML abrufen aus. Diese Option ist nur für Looker-Entwickler verfügbar.
  4. Klicken Sie auf den Tab Aggregate Table (Aggregierte Tabelle).
  5. Looker stellt den LookML-Code für ein Refinement für ein Explore 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 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 Datei des Explores anstelle der Modelldatei hinzufügen. Beide Orte sind geeignet.

Wenn Sie die LookML-Datei 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 Explore-Abfrage auswirkt. Alle anderen Änderungen an der zusammengefassten Tabelle können jedoch dazu führen, dass Looker die zusammengefasste Tabelle nicht für die Explore-Abfrage verwenden kann. Im Abschnitt Zusammengefasste Tabellen entwerfen auf der Dokumentationsseite Aggregate Awareness finden Sie Tipps zur Optimierung Ihrer zusammengefassten Tabellen, damit sie für Aggregate Awareness verwendet werden.

LookML-Code einer aggregierten Tabelle aus einem Dashboard abrufen

Looker-Entwickler haben auch die Möglichkeit, den LookML-Code der zusammengefassten Tabelle für alle Kacheln in einem Dashboard abzurufen und dann in das LookML-Projekt zu kopieren.

Durch das Erstellen von Aggregationstabellen kann die Leistung eines Dashboards erheblich verbessert werden, insbesondere bei Kacheln, mit denen riesige Datasets abgefragt werden.

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

Für jede Kachel, die noch nicht mit der Funktion „Aggregate-Awareness“ optimiert ist, stellt Looker den LookML-Code für ein Explore-Refinement bereit, mit dem die zusammengefasste Tabelle dem Explore hinzugefügt wird. Wenn das Dashboard mehrere Kacheln aus demselben Explore enthält, werden alle zusammengefassten Tabellen in einem einzigen Explore-Refinement platziert. Um die Anzahl der generierten zusammengefassten Tabellen zu reduzieren, ermittelt Looker, ob eine generierte zusammengefasste Tabelle für mehrere Kacheln verwendet werden kann. Wenn dies der Fall ist, werden alle redundanten zusammengefassten Tabellen, die für weniger Kacheln verwendet werden können, gelöscht.

Kopieren Sie jede Explore-Verfeinerung und fügen Sie sie in die zugehörige Modelldatei ein. Diese wird im Kommentar vor der Explore-Verfeinerung angegeben. 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 Orte sind geeignet.

Wenn ein Dashboardfilter auf eine Kachel angewendet wird, fügt Looker die Dimension des Filters der zusammengefassten Tabelle der Kachel hinzu, damit die zusammengefasste Tabelle für die Kachel verwendet werden kann. Das liegt daran, dass zusammengefasste Tabellen nur 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 Aggregatbewusstsein.

Wenn Sie die LookML-Datei 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-Kachel auswirkt. Alle anderen Änderungen an der zusammengefassten Tabelle können jedoch dazu führen, dass Looker die zusammengefasste Tabelle nicht mehr für das Dashboard verwenden kann. Im Abschnitt Zusammengefasste Tabellen entwerfen auf der Dokumentationsseite Aggregate Awareness finden Sie Tipps zur Optimierung Ihrer zusammengefassten Tabellen, damit sie für Aggregate Awareness verwendet werden.

Beispiel

Im folgenden Beispiel wird eine zusammengefasste Tabelle monthly_orders für den Explore event erstellt. In der zusammengefassten Tabelle wird die monatliche Anzahl der Bestellungen erfasst. Looker verwendet die zusammengefasste Tabelle für Abfragen zur Anzahl der Bestellungen, die Daten auf Monatsebene nutzen können, z. B. Abfragen zur Anzahl der Bestellungen pro Jahr, Quartal und Monat.

Die zusammengefasste Tabelle wird mit Persistenz mithilfe der datagroup orders_datagroup 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 in der Datenbank erstellt.

Die Definition der zusammengefassten Tabelle sieht wie folgt 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 Aggregattabellen entwerfen auf der Dokumentationsseite Aggregatbewusstsein finden Sie Tipps zum strategischen Erstellen von Aggregattabellen:

Unterstützung von Dialekten für „Aggregate awareness“

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

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