Übersicht
Durch Aggregate Awareness findet Looker automatisch die kleinste und effizienteste Tabelle in Ihrer Datenbank, die für die jeweilige Abfrage geeignet ist, ohne dabei die Accuracy zu beeinträchtigen.
Bei sehr großen Tabellen in Ihrer Datenbank können Looker-Entwickler 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. Wird Aggregate Awareness strategisch eingesetzt, kann die durchschnittliche Abfragegeschwindigkeit deutlich steigen.
Sie haben beispielsweise eine Datentabelle im Petabyte-Bereich mit einer Zeile für jede Bestellung, die auf Ihrer Website eingegangen ist. Aus dieser Datenbank können Sie eine zusammengefasste Tabelle mit Ihren täglichen Umsatzzahlen erstellen. Wenn Ihre Website täglich 1.000 Bestellungen erhält, würde die tägliche zusammengefasste Tabelle jeden Tag mit 999 Zeilen weniger als die ursprüngliche Tabelle darstellen. Sie können eine weitere zusammengefasste Tabelle mit monatlichen Umsatzzahlen erstellen, die noch effizienter ist. Wenn ein Nutzer jetzt eine Abfrage für tägliche oder wöchentliche Verkäufe ausführt, verwendet Looker die Tabelle mit den täglichen Gesamtverkäufen. Wenn ein Nutzer eine Abfrage zu jährlichen Verkäufen ausführt und Sie keine zusammengefasste Tabelle für jährliche Verkäufe haben, verwendet Looker die nächstbeste Option, in diesem Beispiel die zusammengefasste Tabelle für monatliche Verkäufe.
Looker beantwortet die Fragen Ihrer Nutzer nach Möglichkeit mit den kleinsten zusammengefassten Tabellen. Beispiel:
- Für eine Abfrage zum monatlichen Gesamtumsatz verwendet Looker die zusammengefasste Tabelle basierend auf monatlichen Umsätzen (
sales_monthly_aggregate_table). - Für eine Abfrage zum Gesamtbetrag jedes Verkaufs an einem Tag gibt es keine zusammengefasste Tabelle mit dieser Granularität. Looker ruft die Abfrageergebnisse daher aus der ursprünglichen Datenbanktabelle (
orders_database) ab. Wenn Ihre Nutzer diese Art von Abfrage jedoch häufig ausführen, können Sie dafür eine zusammengefasste Tabelle erstellen. - Für eine Abfrage zu wöchentlichen Verkäufen gibt es keine wöchentlich zusammengefasste Tabelle. Looker verwendet daher die nächstbeste Option, nämlich die zusammengefasste Tabelle basierend auf täglichen Verkäufen (
sales_daily_aggregate_table).

Mithilfe der Aggregate Awareness-Logik fragt Looker die kleinste mögliche zusammengefasste Tabelle ab, um die Fragen Ihrer Nutzer zu beantworten. Die ursprüngliche Tabelle wird nur für Abfragen verwendet, die eine höhere Granularität erfordern, als die zusammengefassten Tabellen bieten können.
Aggregierte Tabellen müssen nicht mit einem separaten Explore verknüpft oder einem separaten Explore hinzugefügt werden. Stattdessen passt Looker die FROM-Klausel der Explore-Abfrage dynamisch an, um auf die beste zusammengefasste Tabelle für die Abfrage zuzugreifen. Das bedeutet, dass Ihre Drilldowns beibehalten werden und Explores zusammengeführt werden können. Mit der Aggregat-Funktion kann ein Explore automatisch Aggregat-Tabellen nutzen, aber bei Bedarf trotzdem detaillierte Daten analysieren.
Sie können auch Aggregattabellen verwenden, um die Leistung von Dashboards drastisch zu verbessern, insbesondere für Kacheln, mit denen riesige Datasets abgefragt werden. Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter aggregate_table im Abschnitt LookML-Code einer zusammengefassten Tabelle aus einem Dashboard abrufen.
Zusammengefasste Tabellen zu Ihrem Projekt hinzufügen
Looker-Entwickler können strategisch zusammengefasste Tabellen erstellen, die die Anzahl der erforderlichen Abfragen für die großen Tabellen in einer Datenbank minimieren. Zusammengefasste Tabellen müssen persistent in Ihrer Datenbank gespeichert werden, damit sie für Aggregate Awareness zugänglich sind. Zusammengefasste Tabellen sind also eine Art persistenter abgeleiteter Tabelle (PAT).
Eine zusammengefasste Tabelle wird in Ihrem LookML-Projekt unter einem explore-Parameter mit dem Parameter aggregate_table definiert.
Hier ist ein Beispiel für ein explore mit einer zusammengefassten Tabelle in LookML:
explore: orders {
label: "Sales Totals"
join: order_items {
sql_on: ${orders.id} = ${order_items.id} ;;
}
aggregate_table: sales_monthly {
materialization: {
datagroup_trigger: orders_datagroup
}
query: {
dimensions: [created_month]
measures: [order_items.total_sales]
}
}
# other explore parameters
}
Um eine zusammengefasste Tabelle zu erstellen, können Sie LookML von Grund auf neu schreiben oder LookML für zusammengefasste Tabellen aus einem Explore oder aus einem Dashboard abrufen. Weitere Informationen zum Parameter aggregate_table und seinen Unterparametern finden Sie auf der Dokumentationsseite für den Parameter aggregate_table.
Zusammengefasste Tabellen entwerfen
Damit eine Explore-Abfrage eine zusammengefasste Tabelle verwenden kann, muss die zusammengefasste Tabelle genaue Daten für die Explore-Abfrage liefern können. Looker kann eine zusammengefasste Tabelle für eine Explore-Abfrage verwenden, wenn alle folgenden Bedingungen erfüllt sind:
- Die Felder der Explore-Abfrage sind eine Teilmenge der Felder der Aggregattabelle (siehe den Abschnitt Feldfaktoren auf dieser Seite). Bei Zeiträumen können die Zeiträume der Explore-Abfrage aus den Zeiträumen in der zusammengefassten Tabelle abgeleitet werden (siehe Abschnitt Zeitraumfaktoren auf dieser Seite).
- Die Explore-Abfrage enthält Measure-Typen, die von der Funktion „Aggregate Awareness“ unterstützt werden (siehe Abschnitt Faktoren für Measure-Typen auf dieser Seite), oder die Explore-Abfrage enthält eine zusammengefasste Tabelle, die genau übereinstimmt (siehe Abschnitt Zusammengefasste Tabellen erstellen, die genau mit Explore-Abfragen übereinstimmen auf dieser Seite).
- Die Zeitzone der Explore-Abfrage entspricht der Zeitzone, die für die zusammengefasste Tabelle verwendet wird (siehe Abschnitt Zeitzonenfaktoren auf dieser Seite).
- Die Filter der Explore-Abfrage verweisen auf Felder, die als Dimensionen in der zusammengefassten Tabelle verfügbar sind, oder jeder Filter der Explore-Abfrage entspricht einem Filter in der zusammengefassten Tabelle (siehe Abschnitt Filterfaktoren auf dieser Seite).
Eine Möglichkeit, um sicherzustellen, dass eine zusammengefasste Tabelle genaue Daten für eine Explore-Abfrage liefern kann, besteht darin, eine zusammengefasste Tabelle zu erstellen, die genau mit einer Explore-Abfrage übereinstimmt. Weitere Informationen finden Sie im Abschnitt Aggregierte Tabellen erstellen, die genau mit Explore-Abfragen übereinstimmen auf dieser Seite.
Faktoren im Feld
Damit eine zusammengefasste Tabelle für eine Explore-Abfrage verwendet werden kann, muss sie alle Dimensionen und Measures enthalten, die für diese Explore-Abfrage erforderlich sind, einschließlich der Felder, die für Filter in der Explore-Abfrage verwendet werden. Wenn eine Explore-Abfrage eine Dimension oder ein Measure enthält, die nicht in einer zusammengefassten Tabelle vorhanden sind, kann Looker die zusammengefasste Tabelle nicht verwenden und greift stattdessen auf die Basistabelle zurück.
Wenn eine Abfrage beispielsweise nach den Dimensionen A und B gruppiert, nach dem Messwert C aggregiert und nach der Dimension D filtert, muss die zusammengefasste Tabelle mindestens A, B und D als Dimensionen und C als Messwert enthalten.
Die zusammengefasste Tabelle kann auch andere Felder enthalten, muss aber mindestens die Felder der Explore-Abfrage enthalten, um für die Optimierung geeignet zu sein. Die einzige Ausnahme sind Zeitrahmen-Dimensionen, da Zeitrahmen mit gröberer Granularität aus Zeitrahmen mit feinerer Granularität abgeleitet werden können.
Aufgrund dieser Feldüberlegungen ist eine zusammengefasste Tabelle spezifisch für den Explore, unter dem sie definiert ist. Eine zusammengefasste Tabelle, die unter einem Explore definiert ist, wird nicht für Abfragen in einem anderen Explore verwendet.
Zeitraumfaktoren
Die Logik der aggregierten Erkennung von Looker kann einen Zeitraum von einem anderen ableiten. Eine zusammengefasste Tabelle kann für eine Abfrage verwendet werden, solange der Zeitrahmen der zusammengefassten Tabelle eine höhere (oder genauso große) Granularität wie die Explore-Abfrage aufweist. Beispiel: Eine zusammengefasste Tabelle, die auf täglichen Daten basiert, kann für eine Explore-Abfrage verwendet werden, die andere Zeiträume erfordert, z. B. Abfragen für tägliche, monatliche und jährliche Daten oder sogar Daten für den Tag des Monats, den Tag des Jahres und die Woche des Jahres. Eine jährliche zusammengefasste Tabelle kann jedoch nicht für eine Explore-Abfrage verwendet werden, für die stündliche Daten erforderlich sind, da die Daten der zusammengefassten Tabelle nicht die erforderliche Granularität für die Explore-Abfrage aufweisen.
Dasselbe gilt für Teilmengen von Zeiträumen. Wenn Sie beispielsweise eine zusammengefasste Tabelle haben, die nach den letzten drei Monaten gefiltert ist, und ein Nutzer die Daten mit einem Filter für die letzten zwei Monate abfragt, kann Looker die zusammengefasste Tabelle für diese Abfrage verwenden.
Außerdem gilt dieselbe Logik für Abfragen mit Zeitrahmenfiltern: Eine zusammengefasste Tabelle kann für eine Abfrage mit einem Zeitrahmenfilter verwendet werden, solange der Zeitrahmen der zusammengefassten Tabelle eine höhere (oder genauso große) Granularität wie der in der Explore-Abfrage verwendete Zeitrahmenfilter aufweist. Beispiel: Eine zusammengefasste Tabelle mit dem Zeitrahmen „Täglich“ als Dimension kann für eine Explore-Abfrage verwendet werden, die nach Tag, Woche oder Monat filtert.
Faktoren für den Messungstyp
Damit eine Explore-Abfrage eine zusammengefasste Tabelle verwenden kann, müssen die Messwerte in der zusammengefassten Tabelle genaue Daten für die Explore-Abfrage liefern können.
Aus diesem Grund werden nur bestimmte Arten von Messungen unterstützt, wie in den folgenden Abschnitten beschrieben:
- Measures mit unterstützten Measure-Typen
- Mit SQL-Ausdrücken definierte Messwerte
- Messwerte, die nicht mit
${TABLE}definiert sind - Messwerte, die die Anzahl unterschiedlicher Werte annähern
Wenn in einer Explore-Abfrage ein anderer Typ von Messwert verwendet wird, verwendet Looker die ursprüngliche Tabelle und nicht die zusammengefasste Tabelle, um Ergebnisse zurückzugeben. Die einzige Ausnahme ist, wenn die Explore-Abfrage genau mit einer Abfrage für eine zusammengefasste Tabelle übereinstimmt, wie im Abschnitt Zusammengefasste Tabellen erstellen, die genau mit Explore-Abfragen übereinstimmen beschrieben.
Andernfalls verwendet Looker die ursprüngliche Tabelle und nicht die zusammengefasste Tabelle, um Ergebnisse zurückzugeben.
Messwerte mit unterstützten Messwerttypen
Die Aggregat-Awareness kann für Explore-Abfragen verwendet werden, die Measures mit den folgenden Measure-Typen verwenden:
Damit eine zusammengefasste Tabelle für eine Explore-Abfrage verwendet werden kann, muss Looker die Messwerte der zusammengefassten Tabelle verarbeiten können, um genaue Daten in der Explore-Abfrage bereitzustellen. Beispiel: Ein Measure mit type: sum kann für die aggregierte Bekanntheit verwendet werden, da Sie mehrere Summen addieren können: Eine zusammengefasste Tabelle mit wöchentlichen Summen kann addiert werden, um eine genaue monatliche Summe zu erhalten. Ebenso kann ein Messwert mit type: max verwendet werden, da das genaue Wochenmaximum aus einer zusammengefassten Tabelle mit täglichen Höchstwerten ermittelt werden kann.
Bei Measures mit type: average wird die Aggregat-Awareness unterstützt, da Looker Summen- und Zähldaten verwendet, um Durchschnittswerte aus zusammengefassten Tabellen genau abzuleiten.
Mit SQL-Ausdrücken definierte Measures
Die aggregierte Bekanntheit kann auch mit Messwerten verwendet werden, die mit Ausdrücken im Parameter sql definiert werden. Wenn sie mit SQL-Ausdrücken definiert werden, werden auch die folgenden Messwerttypen unterstützt:
Die aggregierte Bekanntheit wird für Messwerte unterstützt, die als Kombinationen anderer Messwerte definiert sind, z. B. in diesem Beispiel:
measure: total_revenue_in_dollars {
type: number
sql: ${total_revenue_in_dollars} - ${inventory_item.total_cost_in_dollars} ;;
}
Die Aggregat-Awareness wird auch für Measures unterstützt, bei denen Berechnungen im Parameter sql definiert sind, wie dieses Measure:
measure: wholesale_value {
type: number
sql: (${order_items.total_sale_price} * 0.60) ;;
}
Die Aggregationserkennung wird für Measures unterstützt, bei denen MIN-, MAX- und COUNT-Vorgänge im Parameter sql definiert sind, wie z. B. dieses Measure:
measure: most_recent_order_date {
type: date
sql: MAX(${users.created_at_raw})
}
Messwerte, die sich auf LookML-Felder beziehen
Wenn sql-Ausdrücke in Messwerten verwendet werden, unterstützt „Aggregate Awareness“ die folgenden Arten von Feldreferenzen:
- Verweise im Format
${view_name.field_name}, die auf Felder in anderen Ansichten verweisen - Verweise im Format
${field_name}, die Felder in derselben Ansicht angeben
Aggregate Awareness wird nicht für Messwerte unterstützt, die mit dem Format ${TABLE}.column_name definiert werden. Dieses Format gibt eine Spalte in einer Tabelle an. Eine Übersicht über die Verwendung von Verweisen in LookML finden Sie auf der Dokumentationsseite SQL-Einbindung und Verweise auf LookML-Objekte.
Beispielsweise wird ein mit diesem sql-Parameter definierter Messwert in einer zusammengefassten Tabelle nicht unterstützt, da er das ${TABLE}.column_name-Format verwendet:
measure: wholesale_value {
type: number
sql: (${TABLE}.total_sale_price * 0.60) ;;
}
Wenn Sie diesen Messwert in eine zusammengefasste Tabelle einfügen möchten, können Sie stattdessen eine Dimension erstellen, die mit dem Format ${TABLE}.column_name definiert ist, und dann einen Messwert erstellen, der auf die Dimension verweist:
dimension: total_sale_price {
sql: (${TABLE}.total_sale_price) ;;
}
measure: wholesale_value {
type: number
sql: (${total_sale_price} * 0.60) ;;
}
Sie können den Messwert wholesale_value jetzt in Ihrer zusammengefassten Tabelle verwenden.
Messwerte, die ungefähre Werte für „Einzeln zählen“ liefern
Im Allgemeinen werden Distinct Counts nicht mit aggregierter Vertraulichkeit unterstützt, da Sie keine genauen Daten erhalten, wenn Sie versuchen, Distinct Counts zu aggregieren. Wenn Sie beispielsweise die eindeutigen Nutzer einer Website zählen, kann es sein, dass ein Nutzer die Website zweimal besucht hat, wobei drei Wochen zwischen den Besuchen lagen. Wenn Sie beispielsweise eine wöchentliche zusammengefasste Tabelle verwenden, um die monatliche Anzahl eindeutiger Nutzer auf Ihrer Website zu ermitteln, wird dieser Nutzer in Ihrer monatlichen Abfrage für eindeutige Nutzer zweimal gezählt und die Daten sind falsch.
Eine Möglichkeit, dieses Problem zu umgehen, besteht darin, eine zusammengefasste Tabelle zu erstellen, die genau einer Explore-Abfrage entspricht. Dies wird im Abschnitt Zusammengefasste Tabellen erstellen, die genau den Explore-Abfragen entsprechen auf dieser Seite beschrieben. Wenn die Explore-Abfrage und eine Abfrage der zusammengefassten Tabelle identisch sind, liefern Messwerte für die Anzahl unterschiedlicher Werte genaue Daten und können daher für die Aggregat-Awareness verwendet werden.
Eine weitere Möglichkeit besteht darin, Näherungswerte für die Anzahl unterschiedlicher Werte zu verwenden. Bei Dialekten, die HyperLogLog-Skizzen unterstützen, kann Looker den HyperLogLog-Algorithmus nutzen, um die Anzahl der unterschiedlichen Werte für zusammengefasste Tabellen zu schätzen.
Der HyperLogLog-Algorithmus hat bekanntermaßen eine Fehlerrate von etwa 2 %. Für den Parameter allow_approximate_optimization: yes müssen Ihre Looker-Entwickler bestätigen, dass es in Ordnung ist, Näherungsdaten für die Measure zu verwenden, damit die Measure näherungsweise aus zusammengefassten Tabellen berechnet werden kann.
Weitere Informationen und eine Liste der Dialekte, die die Zählung unterschiedlicher Werte mit HyperLogLog unterstützen, finden Sie auf der Dokumentationsseite zum Parameter allow_approximate_optimization.
Zeitzonenfaktoren
In vielen Fällen verwenden Datenbankadministratoren UTC als Zeitzone für Datenbanken. Viele Nutzer befinden sich jedoch möglicherweise nicht in der UTC-Zeitzone. Looker bietet mehrere Optionen für die Konvertierung von Zeitzonen, damit Ihre Benutzer Abfrageergebnisse in ihrer eigenen Zeitzone erhalten:
- Abfragezeitzone: Eine Einstellung, die für alle Abfragen über die Datenbankverbindung gilt. Wenn sich alle Ihre Nutzer in derselben Zeitzone befinden, können Sie eine einzelne Zeitzone für Abfragen festlegen, sodass alle Abfragen von der Datenbankzeitzone in die Zeitzone für Abfragen konvertiert werden.
- Nutzerspezifische Zeitzonen, bei denen Nutzern Zeitzonen zugewiesen werden können und sie diese einzeln auswählen können. In diesem Fall werden Abfragen von der Datenbankzeitzone in die Zeitzone des einzelnen Nutzers konvertiert.
Weitere Informationen zu diesen Optionen finden Sie auf der Dokumentationsseite Zeitzoneneinstellungen verwenden.
Diese Konzepte sind wichtig, um die Aggregat-Awareness zu verstehen. Damit eine zusammengefasste Tabelle für eine Abfrage mit Datumsdimensionen oder Datumsfiltern verwendet werden kann, muss die Zeitzone der zusammengefassten Tabelle mit der Zeitzoneneinstellung der ursprünglichen Abfrage übereinstimmen.
In aggregierten Tabellen wird die Datenbankzeitzone verwendet, wenn kein timezone-Wert angegeben ist. Ihre Datenbankverbindung verwendet auch die Datenbankzeitzone, wenn eine der folgenden Bedingungen erfüllt ist:
- Ihre Datenbank unterstützt keine Zeitzonen.
- Die Zeitzone der Abfrage Ihrer Datenbankverbindung ist auf dieselbe Zeitzone wie die Zeitzone der Datenbank festgelegt.
- Für Ihre Datenbankverbindung ist weder eine Abfragezeitzone noch eine nutzerspezifische Zeitzone angegeben. In diesem Fall wird für Ihre Datenbankverbindung die Datenbankzeitzone verwendet.
Wenn eine dieser Aussagen zutrifft, können Sie den Parameter timezone für Ihre aggregierten Tabellen weglassen.
Andernfalls sollte die Zeitzone der zusammengefassten Tabelle so definiert werden, dass sie mit möglichen Abfragen übereinstimmt, damit die zusammengefasste Tabelle mit höherer Wahrscheinlichkeit verwendet wird:
- Wenn Ihre Datenbankverbindung eine einzelne Abfragezeitzone verwendet, sollten Sie den
timezone-Wert Ihrer zusammengefassten Tabelle mit dem Wert der Abfragezeitzone abgleichen. - Wenn für Ihre Datenbankverbindung nutzerspezifische Zeitzonen verwendet werden, sollten Sie identische zusammengefasste Tabellen erstellen, die jeweils einen anderen
timezone-Wert haben, der den möglichen Zeitzonen Ihrer Nutzer entspricht.
Filterfaktoren
Seien Sie vorsichtig, wenn Sie Filter in Ihre zusammengefasste Tabelle aufnehmen. Filter für eine zusammengefasste Tabelle können die Ergebnisse so weit einschränken, dass die zusammengefasste Tabelle nicht mehr verwendet werden kann. Angenommen, Sie erstellen eine zusammengefasste Tabelle für die tägliche Anzahl von Bestellungen und filtern die zusammengefasste Tabelle nur nach Sonnenbrillenbestellungen aus Australien. Wenn ein Nutzer eine Explore-Abfrage für die tägliche Anzahl von Bestellungen von Sonnenbrillen weltweit ausführt, kann Looker die zusammengefasste Tabelle für diese Explore-Abfrage nicht verwenden, da die zusammengefasste Tabelle nur die Daten für Australien enthält. Die zusammengefasste Tabelle filtert die Daten zu stark, um von der Explore-Abfrage verwendet werden zu können.
Achten Sie auch auf die Filter, die Ihre Looker-Entwickler möglicherweise in Ihr Explore eingebaut haben, z. B.:
access_filters: Wendet nutzerspezifische Dateneinschränkungen an.always_filter: Nutzer müssen eine bestimmte Gruppe von Filtern für eine Explore-Abfrage einbeziehen. Nutzer können den Standardfilterwert für ihre Abfrage ändern, den Filter aber nicht vollständig entfernen.conditionally_filter: Definiert eine Reihe von Standardfiltern, die Nutzer überschreiben können, wenn sie mindestens einen Filter aus einer zweiten Liste anwenden, die ebenfalls im Explore definiert ist.
Diese Filtertypen basieren auf bestimmten Feldern. Wenn Ihr Explore diese Filter enthält, müssen Sie die entsprechenden Felder in den Parameter dimensions des aggregate_table aufnehmen.
Hier sehen Sie beispielsweise ein Explore mit einem Zugriffsfilter, der auf dem Feld orders.region basiert:
explore: orders {
access_filter: {
field: orders.region
user_attribute: region
}
}
Wenn Sie eine zusammengefasste Tabelle erstellen möchten, die für diesen Explore verwendet wird, muss die zusammengefasste Tabelle das Feld enthalten, auf dem der Zugriffsfilter basiert. Im nächsten Beispiel basiert der Zugriffsfilter auf dem Feld orders.region. Dieses Feld ist auch als Dimension in der zusammengefassten Tabelle enthalten:
explore: orders {
access_filter: {
field: orders.region # <-- orders.region field
user_attribute: region
}
aggregate_table: sales_monthly {
materialization: {
datagroup_trigger: orders_datagroup
}
query: {
dimensions: [orders.created_day, orders.region] # <-- orders.region field
measures: [orders.total_sales]
timezone: America/Los_Angeles
}
}
}
Da die Abfrage für die zusammengefasste Tabelle die Dimension orders.region enthält, kann Looker die Daten in der zusammengefassten Tabelle dynamisch filtern, um sie an den Filter aus der Explore-Abfrage anzupassen. Daher kann Looker die zusammengefasste Tabelle weiterhin für die Abfragen des Explores verwenden, auch wenn das Explore einen Zugriffsfilter hat.
Das gilt auch für Explore-Abfragen, in denen eine native abgeleitete Tabelle mit bind_filters verwendet wird. Mit dem Parameter bind_filters werden bestimmte Filter aus einer Explore-Abfrage an die Unterabfrage der nativen abgeleiteten Tabelle übergeben. Wenn Ihre Explore-Abfrage im Fall von Aggregate Awareness eine native abgeleitete Tabelle erfordert, die bind_filters verwendet, kann die Explore-Abfrage nur dann eine zusammengefasste Tabelle verwenden, wenn alle Felder, die im Parameter bind_filters der nativen abgeleiteten Tabelle verwendet werden, in der Explore-Abfrage genau dieselben Filterwerte wie in der zusammengefassten Tabelle haben.
Zusammengefasste Tabellen erstellen, die genau mit Explore-Abfragen übereinstimmen
Eine Möglichkeit, sicherzustellen, dass eine zusammengefasste Tabelle für eine Explore-Abfrage verwendet werden kann, besteht darin, eine zusammengefasste Tabelle zu erstellen, die genau der Explore-Abfrage entspricht. Wenn in der Explore-Abfrage und der zusammengefassten Tabelle dieselben Measures, Dimensionen, Filter, Zeitzonen und andere Parameter verwendet werden, gelten die Ergebnisse der zusammengefassten Tabelle per Definition für die Explore-Abfrage. Wenn eine zusammengefasste Tabelle genau mit einer Explore-Abfrage übereinstimmt, kann Looker zusammengefasste Tabellen verwenden, die jede Art von Measure enthalten.
Sie können eine zusammengefasste Tabelle aus einem Explore erstellen, indem Sie im Zahnradmenü eines Explores die Option LookML abrufen auswählen. Sie können auch exakte Übereinstimmungen für alle Tiles in einem Dashboard erstellen. Verwenden Sie dazu die Option LookML abrufen im Zahnradmenü eines Dashboards.
Ermitteln, welche zusammengefasste Tabelle für eine Abfrage verwendet wird
Nutzer mit der Berechtigung see_sql können auf der Registerkarte SQL eines Explores in den Kommentaren sehen, welche zusammengefasste Tabelle für eine Abfrage verwendet wird. Die Kommentare auf dem Tab SQL werden auch im Entwicklungsmodus angezeigt. So können Entwickler neue zusammengefasste Tabellen testen und sehen, wie Looker sie verwendet, bevor Sie neue Tabellen in die Produktion übertragen.
Beispiel: Basierend auf der zuvor gezeigten monatlich zusammengefassten Beispieltabelle können Sie im Explore eine Abfrage für die jährlichen Gesamtumsätze ausführen. Klicken Sie dann auf den Tab SQL, um die Details der von Looker erstellten Abfrage aufzurufen. Wenn Sie sich im Entwicklungsmodus befinden, zeigt Looker Kommentare an, um die zusammengefasste Tabelle anzugeben, die für die Abfrage verwendet wurde.
Anhand der folgenden Kommentare auf dem Tab SQL können wir sehen, dass Looker die zusammengefasste Tabelle sales_monthly für diese Abfrage verwendet. Außerdem finden wir Informationen dazu, warum andere zusammengefasste Tabellen nicht für die Abfrage verwendet wurden:
-- use existing orders::sales_monthly in sandbox_scratch.LR$LB4151619827209021_orders$sales_monthly
-- Did not use orders::sales_weekly; it does not include the following fields in the query: orders.created_month
-- Did not use orders::sales_daily; orders::sales_monthly was a better fit for optimization.
-- Did not use orders::sales_last_3_days; contained filters not in the query: orders.created_date
Im Abschnitt Fehlerbehebung auf dieser Seite finden Sie mögliche Kommentare, die auf dem Tab SQL angezeigt werden, sowie Vorschläge zur Behebung der Probleme.
Schätzungen der Recheneinsparungen für Aggregate Awareness
Wenn Ihre Datenbankverbindung Kostenschätzungen unterstützt und eine zusammengefasste Tabelle für eine Abfrage verwendet werden kann, werden im Explore-Fenster die Einsparungen bei der Rechenleistung angezeigt, die sich durch die Verwendung der zusammengefassten Tabelle anstelle einer direkten Abfrage der Datenbank ergeben. Die Einsparungen durch die Aggregatfunktion werden in einem Explore vor dem Ausführen der Abfrage neben der Schaltfläche Ausführen angezeigt.
Wenn Sie vor dem Ausführen der Abfrage sehen möchten, welche zusammengefasste Tabelle für die Abfrage verwendet wird, können Sie auf den Tab SQL klicken, wie im Abschnitt Ermitteln, welche zusammengefasste Tabelle für eine Abfrage verwendet wird auf dieser Dokumentationsseite beschrieben.
Nachdem die Abfrage ausgeführt wurde, wird im Explore-Fenster neben dem Button Ausführen angezeigt, welche zusammengefasste Tabelle zur Beantwortung der Abfrage verwendet wurde.
Die aggregierten Einsparungen durch Awareness werden für Datenbankverbindungen angezeigt, für die Kostenschätzungen aktiviert sind. Weitere Informationen finden Sie auf der Dokumentationsseite Daten in Looker explorieren .
Looker fügt neue Daten zu Ihren aggregierten Tabellen hinzu
Bei zusammengefassten Tabellen mit Zeitfiltern kann Looker neue Daten in Ihre zusammengefasste Tabelle einbinden. Sie haben möglicherweise eine zusammengefasste Tabelle, die Daten für die letzten drei Tage enthält, aber diese Tabelle wurde möglicherweise gestern erstellt. In der zusammengefassten Tabelle fehlen die Informationen des aktuellen Tages. Sie können sie also nicht für eine explorative Datenanalyse der neuesten täglichen Informationen verwenden.
Looker kann die Daten in dieser zusammengefassten Tabelle jedoch weiterhin für die Abfrage verwenden, da Looker eine Abfrage für die neuesten Daten ausführt und diese Ergebnisse dann mit den Ergebnissen in der zusammengefassten Tabelle zusammenführt.
Looker kann unter den folgenden Umständen aktuelle Daten mit den Daten Ihrer zusammengefassten Tabelle zusammenführen:
- Die zusammengefasste Tabelle hat einen Zeitfilter.
- Die zusammengefasste Tabelle enthält eine Dimension, die auf demselben Zeitfeld wie der Zeitfilter basiert.
Die folgende zusammengefasste Tabelle hat beispielsweise eine Dimension, die auf dem Feld orders.created_date basiert, und einen Zeitfilter ("3 days"), der auf demselben Feld basiert:
aggregate_table: sales_last_3_days {
query: {
dimensions: [orders.created_date]
measures: [order_items.total_sales]
filters: [orders.created_date: "3 days"] # <-- time filter
timezone: America/Los_Angeles
}
...
}
Wenn diese zusammengefasste Tabelle gestern erstellt wurde, ruft Looker die neuesten Daten ab, die noch nicht in der zusammengefassten Tabelle enthalten sind, und führt die neuen Ergebnisse mit den Ergebnissen aus der zusammengefassten Tabelle zusammen. Ihre Nutzer erhalten also die neuesten Daten, während die Leistung mithilfe von zusammengefassten Informationen optimiert wird.
Wenn Sie sich im Entwicklungsmodus befinden, können Sie auf dem Tab SQL eines Explores die zusammengefasste Tabelle sehen, die Looker für die Abfrage verwendet hat, sowie die UNION-Anweisung, mit der Looker neuere Daten abgerufen hat, die nicht in der zusammengefassten Tabelle enthalten waren.
Zusammengefasste Tabellen müssen persistent gespeichert werden
Damit Ihre zusammengefasste Tabelle für Aggregate Awareness zugänglich ist, muss sie persistent in Ihrer Datenbank gespeichert werden. Die Persistenzstrategie wird im Parameter materialization der zusammengefassten Tabelle angegeben. Da zusammengefasste Tabellen eine Art persistente abgeleitete Tabelle (PAT) sind, gelten für sie dieselben Anforderungen wie für PATs. Weitere Informationen finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker.
Sie können in Ihrem Projekt inkrementelle PATs erstellen, wenn Ihr Dialekt sie unterstützt. Looker erstellt inkrementelle PATs, indem neue Daten an die Tabelle angehängt werden, anstatt die gesamte Tabelle neu zu erstellen. Da zusammengefasste Tabellen selbst eine Art PAT sind, können Sie auch inkrementelle zusammengefasste Tabellen erstellen. Weitere Informationen zu inkrementellen PATs finden Sie auf der Dokumentationsseite Inkrementelle PATs. Ein Beispiel für eine inkrementelle zusammengefasste Tabelle finden Sie auf der Dokumentationsseite zum Parameter increment_key.
Ein Nutzer mit der Berechtigung develop kann die Persistenzeinstellungen überschreiben und alle zusammengefassten Tabellen für eine Abfrage neu erstellen, um die aktuellsten Daten zu erhalten. Wenn Sie die Tabellen für eine Abfrage neu erstellen möchten, wählen Sie im Zahnradmenü „Explore-Aktionen“ die Option Abgeleitete Tabellen neu erstellen und ausführen aus.
Diese Option ist erst verfügbar, wenn die Explore-Abfrage geladen wurde.
Mit der Option Abgeleitete Tabellen neu erstellen und ausführen werden alle abgeleiteten Tabellen, auf die in der Abfrage verwiesen wird, sowie alle abgeleiteten Tabellen, von denen die Tabellen in der Abfrage abhängig sind, neu erstellt. Dazu gehören auch zusammengefasste Tabellen, die selbst eine Art persistente abgeleitete Tabelle sind.
Für den Benutzer, der die Option Abgeleitete Tabellen neu erstellen und ausführen startet, werden die Ergebnisse erst geladen, wenn die Tabellen erneut erstellt wurden. Abfragen anderer Benutzer verwenden weiterhin die bestehenden Tabellen. Wenn die persistenten Tabellen erneut erstellt wurden, verwenden alle Benutzer die neu erstellten Tabellen.
Weitere Informationen zur Option Abgeleitete Tabellen neu erstellen und ausführen finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker.
Fehlerbehebung
Wie im Abschnitt Ermitteln, welche zusammengefasste Tabelle für eine Abfrage verwendet wird beschrieben, können Sie im Entwicklungsmodus Abfragen im Explore ausführen und auf den Tab SQL klicken, um Kommentare zur zusammengefassten Tabelle zu sehen, die für die Abfrage verwendet wurde, falls vorhanden.
Auf dem Tab SQL finden Sie auch Kommentare dazu, warum aggregierte Tabellen für eine Abfrage nicht verwendet wurden, falls dies der Fall ist. Bei aggregierten Tabellen, die nicht verwendet werden, beginnt der Kommentar mit:
Did not use [explore name]::[aggregate table name];
Hier ist ein Beispiel für einen Kommentar dazu, warum die im order_items-Explore definierte zusammengefasste Tabelle sales_daily nicht für eine Abfrage verwendet wurde:
-- Did not use order_items::sales_daily; query contained the following filters
that were neither included as fields nor exactly matched by filters in the aggregate table:
order_items.created_year.
In diesem Fall haben die Filter in der Abfrage verhindert, dass die zusammengefasste Tabelle verwendet wird.
In der folgenden Tabelle finden Sie einige weitere mögliche Gründe, warum eine aggregierte Tabelle nicht verwendet werden kann, sowie Schritte, die Sie unternehmen können, um die Nutzbarkeit der aggregierten Tabelle zu erhöhen.
| Grund für die Nichtverwendung der zusammengefassten Tabelle | Erläuterung und mögliche Schritte |
|---|---|
| Ein solches Feld ist im Explore nicht vorhanden. | Es liegt ein LookML-Validierungsfehler vor. Das liegt höchstwahrscheinlich daran, dass die zusammengefasste Tabelle nicht richtig definiert wurde oder dass es einen Tippfehler im LookML für die zusammengefasste Tabelle gab. Wahrscheinlich liegt das Problem an einem falschen Feldnamen oder Ähnlichem.Prüfen Sie, ob die Dimensionen und Messwerte in der zusammengefassten Tabelle mit den Feldnamen im Explore übereinstimmen, um dieses Problem zu beheben. Weitere Informationen zum Definieren einer zusammengefassten Tabelle finden Sie auf der Dokumentationsseite zum Parameter aggregate_table. |
| Die zusammengefasste Tabelle enthält die folgenden Felder nicht in der Abfrage. | Damit eine zusammengefasste Tabelle für eine Explore-Abfrage verwendet werden kann, muss sie alle Dimensionen und Messwerte enthalten, die für diese Explore-Abfrage erforderlich sind, einschließlich der Felder, die für Filter in der Explore-Abfrage verwendet werden. Wenn eine Explore-Abfrage eine Dimension oder ein Measure enthält, die bzw. das nicht in einer zusammengefassten Tabelle enthalten ist, kann Looker die zusammengefasste Tabelle nicht verwenden und verwendet stattdessen die Basistabelle. Weitere Informationen finden Sie im Abschnitt Feldfaktoren auf dieser Seite. Die einzige Ausnahme sind Zeiträume, da Zeiträume mit gröberer Granularität von solchen mit feinerer Granularität abgeleitet werden können. Prüfen Sie zur Behebung dieses Problems, ob die Felder der Explore-Abfrage in der Definition der zusammengefassten Tabelle enthalten sind. |
| Die Abfrage enthielt die folgenden Filter, die weder als Felder enthalten noch genau mit Filtern in der zusammengefassten Tabelle übereinstimmten. | Die Filter in der Explore-Abfrage verhindern, dass Looker die zusammengefasste Tabelle verwendet. Sie haben folgende Möglichkeiten, dieses Problem zu beheben:
|
| Die Abfrage enthält die folgenden Measures, die nicht zusammengefasst werden können. | Die Abfrage enthält einen oder mehrere Messwerttypen, die für die Aggregatberücksichtigung nicht unterstützt werden, z. B. Anzahl der eindeutigen Werte, Median oder Perzentil.Prüfen Sie zur Behebung dieses Problems den Typ der einzelnen Measures in der Abfrage und achten Sie darauf, dass es sich um einen der unterstützten Measure-Typen handelt. Wenn Ihr Explore Joins enthält, prüfen Sie außerdem, ob Ihre Measures durch aufgefächerte Joins in Distinct-Measures (symmetrische Aggregate) umgewandelt werden. Eine Erklärung finden Sie auf dieser Seite im Abschnitt Symmetrische Aggregate für Explores mit Joins. |
| Eine andere aggregierte Tabelle war besser für die Optimierung geeignet. | Es gab mehrere geeignete zusammengefasste Tabellen für die Abfrage und Looker hat eine bessere zusammengefasste Tabelle gefunden, die stattdessen verwendet werden kann. In diesem Fall müssen Sie nichts unternehmen. |
Looker hat keine Gruppierung vorgenommen (aufgrund eines primary_key- oder cancel_grouping_fields-Parameters). Daher kann die Abfrage nicht zusammengefasst werden. |
Die Abfrage verweist auf eine Dimension, die verhindert, dass sie eine GROUP BY-Klausel hat. Daher kann Looker keine zusammengefasste Tabelle für die Abfrage verwenden.
Prüfen Sie dazu, ob der Parameter primary_key der Ansicht und der Parameter cancel_grouping_fields des Explores richtig eingerichtet sind. |
| Die zusammengefasste Tabelle enthielt Filter, die nicht in der Abfrage enthalten waren. | Die zusammengefasste Tabelle enthält einen Filter, der sich nicht auf die Zeit bezieht und nicht in der Abfrage enthalten ist.Sie können den Filter aus der zusammengefassten Tabelle entfernen, um das Problem zu beheben. Weitere Informationen finden Sie im Abschnitt Filterfaktoren auf dieser Seite. |
Ein Feld ist in der Explore-Abfrage als Nur-Filter-Feld definiert, wird aber im Parameter dimensions der zusammengefassten Tabelle aufgeführt. |
Im Parameter dimensions der aggregierten Tabelle wird ein Feld aufgeführt, das in der Explore-Abfrage nur als filter-Feld definiert ist.Entfernen Sie das Feld aus der dimensions-Liste der zusammengefassten Tabelle, um das Problem zu beheben. Wenn dieses Feld für die zusammengefasste Tabelle erforderlich ist, fügen Sie es der Liste filters in der Abfrage der zusammengefassten Tabelle hinzu. |
| Der Optimierer kann nicht feststellen, warum die zusammengefasste Tabelle nicht verwendet wurde. | Dieser Kommentar ist für Grenzfälle reserviert. Wenn Sie dies für eine häufig verwendete Explore-Abfrage sehen, können Sie eine zusammengefasste Tabelle erstellen, die genau der Explore-Abfrage entspricht. Sie können LookML für zusammengefasste Tabellen aus einem Explore abrufen, wie auf der Parameterseite aggregate_table beschrieben. |
Wichtige Punkte
Symmetrische Aggregate für Explores mit Joins
Wichtig ist, dass Looker in einem Explore, das mehrere Datenbanktabellen verknüpft, Measures vom Typ SUM, COUNT und AVERAGE als SUM DISTINCT, COUNT DISTINCT bzw. AVERAGE DISTINCT rendern kann. Looker tut dies, um Fanout-Fehlberechnungen zu vermeiden. Ein count-Messwert wird beispielsweise als count_distinct-Messwerttyp gerendert. So werden Fehlberechnungen bei Fanouts für Joins vermieden. Dies ist Teil der Funktion für symmetrische Aggregate von Looker. Eine Erläuterung dieser Looker-Funktion finden Sie auf der Best Practices-Seite zu symmetrischen Aggregaten.
Die Funktion für symmetrische Aggregate verhindert Fehlberechnungen, kann aber auch dazu führen, dass Ihre Aggregattabellen in bestimmten Fällen nicht verwendet werden. Daher ist es wichtig, sie zu verstehen.
Für die von der aggregierten Wahrnehmung unterstützten Messwerttypen gilt dies für sum, count und average. Looker rendert diese Arten von Measures als DISTINCT, wenn:
- Der Messwert stammt aus der „one“-Ansicht eines n:1- oder 1:n-Joins.
- Die Measure stammt aus einer der beiden Ansichten eines Many-to-Many-Joins.
Eine Erläuterung dieser Join-Typen finden Sie auf der Dokumentationsseite zum Parameter relationship.
Wenn Sie feststellen, dass Ihre zusammengefasste Tabelle aus diesem Grund nicht verwendet wird, können Sie eine zusammengefasste Tabelle erstellen, die genau einer Explore-Abfrage entspricht, um diese Messwerttypen für ein Explore mit Joins zu verwenden. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Aggregattabellen erstellen, die genau mit Explore-Abfragen übereinstimmen.
Wenn Sie einen SQL-Dialekt verwenden, der HyperLogLog-Skizzen unterstützt, können Sie dem Messwert auch den Parameter allow_approximate_optimization: yes hinzufügen. Wenn ein Zähl-Messwert mit allow_approximate_optimization: yes definiert ist, kann Looker den Messwert für die Aggregat-Awareness verwenden, auch wenn er als eindeutige Anzahl gerendert wird.
Weitere Informationen und eine Liste der SQL-Dialekte, die HyperLogLog-Skizzen unterstützen, finden Sie auf der Dokumentationsseite zum Parameter allow_approximate_optimization.
Dialektunterstützung 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 | |
| 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 |
Dialektunterstützung für die inkrementelle Erstellung zusammengefasster Tabellen
Damit Looker inkrementelle zusammengefasste Tabellen in Ihrem Looker-Projekt unterstützen kann, müssen diese auch von Ihrem Datenbankdialekt unterstützt werden. In der folgenden Tabelle ist zu sehen, welche Dialekte die inkrementelle Erstellung von PDTs in der neuesten 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 | |
| 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 |