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 Aggregattabelle, der Unterparameter query zum Definieren der Tabelle und der Unterparameter materialization zum Definieren der Persistenzstrategie der Tabelle

Besondere Regeln
  • Die table_name muss innerhalb einer bestimmten explore eindeutig sein.
  • Im Unterparameter materialization müssen Sie eine Persistenzstrategie für die Aggregattabelle 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 Tabellen Looker verwendet. Weitere Informationen finden Sie im Abschnitt Ermitteln, welche Aggregattabelle für eine Abfrage verwendet wird auf der Dokumentationsseite Aggregatbewusstsein.

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

Aggregierte 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 Aggregattabelle 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 die aggregierte 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 aggregierte Tabelle aufgenommen werden sollen. Das Feld measures hat das folgende 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 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 Aggregattabelle verhindern können, finden Sie auf der Dokumentationsseite Aggregate awareness im Abschnitt Filter factors.		 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 Aggregattabelle keine Zeitzonenkonvertierung durchgeführt. Stattdessen wird die Datenbankzeitzone verwendet.

Informationen zum Festlegen der Zeitzone, damit Ihre Aggregattabelle 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 aggregierte 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 aggregierten Tabelle muss einen der folgenden Unterparameter haben, um die Persistenzstrategie anzugeben:

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

Verwenden Sie die folgenden materialization-Unterparameter, um eine inkrementelle aggregierte 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 Aggregattabelle basierend auf einer von Ihnen angegebenen SQL-Anweisung auslösen. Wenn sich das Ergebnis der SQL-Anweisung 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 Strategie persist_for lässt sich die Bekanntheit jedoch möglicherweise nicht optimal steigern. Das liegt daran, dass Looker das Alter der Tabelle mit der Einstellung persist_for vergleicht, wenn ein Nutzer eine Abfrage ausführt, die auf einer persist_for-Tabelle basiert. Wenn die Tabelle älter als die Einstellung persist_for ist, wird sie neu generiert, bevor die Abfrage ausgeführt wird. Wenn das Alter geringer als die Einstellung persist_for ist, wird die vorhandene Tabelle verwendet. Wenn ein Nutzer also nicht innerhalb des Zeitraums von persist_for eine Abfrage ausführt, muss die Aggregattabelle neu erstellt werden, bevor sie für die Aggregaterkennung 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, sollten Sie datagroup_trigger oder sql_trigger_value als Persistenzstrategie für Aggregattabellen 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 zu cluster_keys-Parametern.

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 zu distribution-Parametern.

distribution_style

Mit dem Parameter distribution_style können Sie angeben, wie die Abfrage für eine Aggregattabelle 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 zu distribution_style-Parametern.

indexes

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

Weitere Informationen finden Sie auf der Dokumentationsseite zu indexes-Parametern.

partition_keys

Der Parameter partition_keys definiert ein Array von Spalten, nach denen die Aggregattabelle 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, anstatt die gesamte Tabelle. partition_keys wird nur mit den Dialekten Presto und BigQuery unterstützt.

Weitere Informationen finden Sie auf der Dokumentationsseite zu partition_keys-Parametern.

publish_as_db_view

Mit dem Parameter publish_as_db_view können Sie eine aggregierte 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 zu publish_as_db_view-Parametern.

sortkeys

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

Weitere Informationen finden Sie auf der Dokumentationsseite zu sortkeys-Parametern.

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 PAT und können inkrementell erstellt werden, indem der Parameter increment_key hinzugefügt wird. Der Parameter increment_key gibt das Zeitinkrement an, für das neue Daten abgefragt und an die Aggregattabelle angehängt werden sollen.

Weitere Informationen finden Sie auf der Dokumentationsseite zu increment_key-Parametern.

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 aggregierte Tabelle angehängt werden. Der Parameter increment_offset ist für inkrementelle PDTs und aggregierte Tabellen optional.

Weitere Informationen finden Sie auf der Dokumentationsseite zu increment_offset-Parametern.

LookML-Code einer aggregierten 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 der aggregierten Tabelle enthalten sein 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 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 das LookML für die zusammengefasste 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 aggregierte Tabelle umbenennen, ohne dass sich dies auf die Anwendbarkeit auf die ursprüngliche Explore-Abfrage auswirkt. Alle anderen Änderungen an der aggregierten Tabelle können jedoch dazu führen, dass Looker die aggregierte 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 aggregierten 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 die LookML 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 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 Orte sind geeignet.

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

Wenn Sie das LookML für die zusammengefasste 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 Dashboardkachel 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 aggregierte Tabelle monthly_orders für den Explore event erstellt. In der zusammengefassten Tabelle wird die monatliche Anzahl der Bestellungen erfasst. Looker verwendet die aggregierte 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 Aggregattabelle wird mit Persistenz mithilfe der datagroup orders_datagroup eingerichtet. Außerdem wird die aggregierte Tabelle mit publish_as_db_view: yes definiert. Das bedeutet, dass Looker eine stabile Datenbankansicht für die aggregierte Tabelle in der Datenbank erstellt.

Die Definition der aggregierten 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 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+
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 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