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
Ein Name für die zusammengefasste Tabelle, der Unterparameter query zum Definieren der Tabelle und der 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 aggregierte Tabelle angeben.

Definition

Mit dem Parameter aggregate_table können Sie zusammengefasste Tabellen erstellen, 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. Eine Übersicht ü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 Aggregat-Tabellen erstellt haben, können Sie Abfragen im Explore ausführen, um zu sehen, welche Tabellen Looker verwendet. Weitere Informationen finden Sie auf der Dokumentationsseite Aggregate-Awareness im Abschnitt Ermitteln, welche Aggregattabelle für eine Abfrage verwendet wird.

Im Abschnitt Fehlerbehebung auf der Dokumentationsseite Aggregate Awareness 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 eines 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 als dimension in der Ansichtsdatei für das Explore der Abfrage 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 hat das folgende Format:

measures: [measure1, measure2, ...]

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

  [orders.count]
filters Fügt optional einen Filter zu einem query hinzu. Filter werden der WHERE-Anweisung 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 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 in der zusammengefassten Tabelle keine Zeitzonenkonvertierung durchgeführt. Stattdessen wird die Datenbankzeitzone verwendet.

Informationen zum Festlegen der Zeitzone, damit Ihre Aggregattabelle als Abfragequelle verwendet wird, finden Sie auf der Dokumentationsseite Aggregatbewusstsein im Abschnitt Zeitzonenfaktoren.

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 in der Soforthilfe 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 zum Erstellen einer inkrementellen aggregierten Tabelle die folgenden materialization-Unterparameter:

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 aggregierte Tabellen unterstützt. Mit der persist_for-Strategie lässt sich jedoch möglicherweise nicht die beste Leistung für die Gesamtbekanntheit erzielen. Wenn ein Nutzer eine Abfrage ausführt, die auf einer persist_for-Tabelle basiert, vergleicht Looker das Alter der Tabelle mit der persist_for-Einstellung. Wenn die Tabelle älter als die Einstellung persist_for ist, wird sie vor der Ausführung der Abfrage neu generiert. Wenn das Alter geringer als die Einstellung persist_for ist, wird die vorhandene Tabelle verwendet. Wenn ein Nutzer also nicht innerhalb des Zeitraums persist_for eine Anfrage ausführt, muss die zusammengefasste Tabelle neu erstellt werden, bevor sie für die Aggregaterkennung verwendet werden kann.

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

Wenn 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 Aggregationstabellen 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 optimal großen Speicherblöcken organisiert.

Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter cluster_keys.

distribution

Mit dem Parameter distribution können Sie die Spalte aus einer Aggregattabelle 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 wurden.
  • 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

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, werden in der Datenbank nur die Partitionen gescannt, die die gefilterten Daten enthalten, und nicht die gesamte Tabelle. 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 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 auch 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

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 aggregierte 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 die Option LookML abrufen aus. Diese Option ist nur für Looker-Entwickler verfügbar.
  4. Klicken Sie auf den Tab 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 Explore 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 ihre Anwendbarkeit auf die ursprüngliche Explore-Abfrage zu ändern. 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, die LookML für zusammengefasste Tabellen 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, für die riesige Datasets abgefragt werden.

Wenn Sie die Berechtigung develop haben, können Sie den LookML-Code zum Erstellen aggregierter 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 dem Wissen über Aggregate optimiert ist, stellt Looker die LookML für eine Explore-Präzisierung bereit, mit der die zusammengefasste Tabelle dem Explore hinzugefügt wird. Wenn das Dashboard mehrere Kacheln aus demselben Explore enthält, werden alle zusammengefassten Tabellen in einem einzelnen Explore-Refinement platziert. Um die Anzahl der generierten zusammengefassten Tabellen zu reduzieren, ermittelt Looker, ob eine generierte zusammengefasste Tabelle für mehr als eine Kachel 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-Optimierung und fügen Sie sie in die zugehörige Modelldatei ein, die im Kommentar vor der Explore-Optimierung 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 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 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 Aggregate-Awareness.

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

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

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
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