Aggregatfunktion

Ü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 Genauigkeit 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 erfolgt ist. Aus dieser Datenbank können Sie eine zusammengefasste Tabelle mit Ihren täglichen Umsatzzahlen erstellen. Wenn auf Ihrer Website täglich 1.000 Bestellungen eingehen, enthält die tägliche aggregierte Tabelle für jeden Tag 999 Zeilen weniger als die Originaltabelle. Sie können eine weitere zusammengefasste Tabelle mit monatlichen Umsatzzahlen erstellen, die noch effizienter ist. Wenn ein Nutzer nun eine Abfrage für den täglichen oder wöchentlichen Umsatz ausführt, verwendet Looker die Tabelle mit dem täglichen Gesamtumsatz. Wenn ein Nutzer eine Abfrage zu den jährlichen Verkäufen ausführt und Sie keine jährlich zusammengefasste Tabelle haben, verwendet Looker die nächstbeste Option, in diesem Beispiel die monatlich zusammengefasste Tabelle für Verkäufe.

Looker beantwortet die Fragen Ihrer Nutzer nach Möglichkeit mit den kleinsten aggregierten Tabellen. Beispiel:

  • Für eine Abfrage zum monatlichen Gesamtumsatz verwendet Looker die zusammengefasste Tabelle basierend auf dem monatlichen Umsatz (sales_monthly_aggregate_table).
  • Für eine Abfrage zum Gesamtwert der einzelnen Verkäufe an einem Tag gibt es keine zusammengefasste Tabelle mit dieser Granularität. Daher ruft Looker die Abfrageergebnisse aus der ursprünglichen Datenbanktabelle (orders_database) ab. Wenn Ihre Nutzer diese Art von Abfrage jedoch häufig ausführen, können Sie eine zusammengefasste Tabelle dafür erstellen.
  • Für eine Abfrage zu wöchentlichen Umsätzen ist keine wöchentlich zusammengefasste Tabelle vorhanden. Daher verwendet Looker die nächstbeste Option, nämlich die auf täglichen Umsätzen basierende aggregierte Tabelle (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 Originaltabelle wird nur für Abfragen verwendet, die eine feinere Granularität erfordern, als die aggregierten Tabellen bieten können.

Aggregierte Tabellen müssen nicht mit einem separaten Explore verknüpft oder einem separaten Explore hinzugefügt werden. Stattdessen wird die FROM-Klausel der Explore-Abfrage in Looker dynamisch angepasst, um auf die beste Aggregattabelle für die Abfrage zuzugreifen. Das bedeutet, dass Ihre Drilldowns beibehalten 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 große 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.

Aggregierte 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 sehen Sie ein Beispiel für eine 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 zum 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 zutreffen:

  • Die Felder der Explore-Abfrage sind eine Teilmenge der Felder der Aggregattabelle (siehe Abschnitt Feld-Faktoren 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 den Abschnitt Zeitraumfaktoren auf dieser Seite).
  • Die Explore-Abfrage enthält Messwerttypen, die von Aggregate Awareness unterstützt werden (siehe Abschnitt Faktoren für Messwerttypen auf dieser Seite), oder die Explore-Abfrage hat eine Aggregattabelle, die genau übereinstimmt (siehe Abschnitt Aggregattabellen erstellen, die genau mit Explore-Abfragen übereinstimmen auf dieser Seite).
  • Die Zeitzone der Explore-Abfrage entspricht der Zeitzone der zusammengefassten Tabelle (siehe Abschnitt Zeitzonenfaktoren auf dieser Seite).
  • Die Filter der Explore-Abfrage verweisen auf Felder, die in der zusammengefassten Tabelle als Dimensionen verfügbar sind, oder jeder Filter der Explore-Abfrage entspricht einem Filter in der zusammengefassten Tabelle (siehe den Abschnitt Filterfaktoren auf dieser Seite).

Eine Möglichkeit, dafür zu sorgen, dass eine aggregierte Tabelle genaue Daten für eine Explore-Abfrage liefert, besteht darin, eine aggregierte Tabelle zu erstellen, die genau einer Explore-Abfrage entspricht. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Aggregierte Tabellen erstellen, die genau mit Explore-Abfragen übereinstimmen.

Feldvariablen

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 einen Measure enthält, die bzw. der nicht in einer zusammengefassten Tabelle vorhanden ist, kann Looker die zusammengefasste Tabelle nicht verwenden und greift stattdessen auf die Basistabelle zurück.

Wenn in einer Abfrage beispielsweise nach den Dimensionen A und B gruppiert, nach dem Messwert C aggregiert und nach der Dimension D gefiltert wird, muss die zusammengefasste Tabelle mindestens die Dimensionen A, B und D sowie den Messwert C enthalten.

Die Aggregattabelle kann auch andere Felder enthalten, muss aber mindestens die Felder der Explore-Abfrage enthalten, damit sie für die Optimierung infrage kommt. Eine Ausnahme bilden Zeitrahmendimensionen, da Zeiträume mit gröberem Detaillierungsgrad aus Zeiträumen mit feinerem Detaillierungsgrad abgeleitet werden können.

Aufgrund dieser Feldüberlegungen ist eine zusammengefasste Tabelle spezifisch für das Explore, unter dem sie definiert ist. Eine zusammengefasste Tabelle, die unter einem Explore definiert ist, wird nicht für Abfragen für ein anderes Explore verwendet.

Zeitraumfaktoren

Mit der Logik für die aggregierte Bekanntheit von Looker kann ein Zeitraum aus einem anderen abgeleitet werden. Eine zusammengefasste Tabelle kann für eine Abfrage verwendet werden, solange der Zeitraum der zusammengefassten Tabelle eine feinere (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, in der andere Zeiträume angegeben sind, 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, die stündliche Daten erfordert, 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 für die letzten drei Monate 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 aggregierte Tabelle kann für eine Abfrage mit einem Zeitrahmenfilter verwendet werden, solange der Zeitrahmen der aggregierten 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:

Wenn in einer Explore-Abfrage ein anderer Typ von Measure verwendet wird, verwendet Looker die Originaltabelle 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 Originaltabelle und nicht die zusammengefasste Tabelle, um Ergebnisse zurückzugeben.

Measures mit unterstützten Measure-Typen

Die aggregierte Bekanntheit kann für Explore-Abfragen verwendet werden, in denen Messwerte mit den folgenden Messwerttypen verwendet werden:

Damit eine zusammengefasste Tabelle für eine Explore-Abfrage verwendet werden kann, muss Looker die Measures der zusammengefassten Tabelle verarbeiten können, um genaue Daten in der Explore-Abfrage zu liefern. Ein Measure mit type: sum kann beispielsweise 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 eine Measure mit type: max verwendet werden, da mit einer zusammengefassten Tabelle mit täglichen Höchstwerten der genaue wöchentliche Höchstwert ermittelt werden kann.

Bei Messwerten mit type: average wird die Aggregat-Awareness unterstützt, da Looker Summen- und Zähldaten verwendet, um Durchschnittswerte aus Aggregattabellen abzuleiten.

Mit SQL-Ausdrücken definierte Messwerte

Die aggregierte Vertraulichkeit kann auch für Messwerte verwendet werden, die mit Ausdrücken im Parameter sql definiert sind. Wenn sie mit SQL-Ausdrücken definiert werden, werden auch die folgenden Messwerttypen unterstützt:

Die Aggregat-Awareness 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 Messwerte unterstützt, bei denen Berechnungen im Parameter sql definiert sind, z. B. für diesen Messwert:

measure: wholesale_value {
  type: number
    sql: (${order_items.total_sale_price} * 0.60) ;;
}

Die Aggregatberücksichtigung wird für Messwerte unterstützt, bei denen MIN-, MAX- und COUNT-Vorgänge im Parameter sql definiert sind, z. B. bei diesem Messwert:

measure: most_recent_order_date {
  type: date
  sql: MAX(${users.created_at_raw})
}

Messwerte, die auf LookML-Felder verweisen

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 auf Felder in derselben Ansicht verweisen

Die aggregierte Bekanntheit wird nicht für Messwerte unterstützt, die im Format ${TABLE}.column_name definiert sind. 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.

Ein mit diesem sql-Parameter definierter Measure wird beispielsweise nicht in einer zusammengefassten Tabelle unterstützt, da er das Format ${TABLE}.column_name verwendet:

measure: wholesale_value {
  type: number
  sql: (${TABLE}.total_sale_price * 0.60) ;;
}

Wenn Sie diesen Messwert in eine aggregierte Tabelle einfügen möchten, können Sie stattdessen eine Dimension mit dem Format ${TABLE}.column_name erstellen und dann einen Messwert, der auf die Dimension verweist, z. B. so:


 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 Anzahl einzelner Aufrufe liefern

Im Allgemeinen werden Distinct Counts bei der aggregierten Bekanntheit nicht 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ögliche Lösung besteht darin, eine zusammengefasste Tabelle zu erstellen, die genau einer Explore-Abfrage entspricht. Das wird auf dieser Seite im Abschnitt Zusammengefasste Tabellen erstellen, die genau Explore-Abfragen entsprechen beschrieben. Wenn die Explore-Abfrage und die Abfrage für die zusammengefasste Tabelle identisch sind, liefern Distinct Count-Messwerte genaue Daten und können daher für die Aggregat-Awareness verwendet werden.

Eine weitere Option ist die Verwendung von Schätzungen für die Anzahl der eindeutigen Werte. Für Dialekte, die HyperLogLog-Skizzen unterstützen, kann Looker den HyperLogLog-Algorithmus verwenden, um die Anzahl der eindeutigen Werte für Aggregattabellen zu schätzen.

Der HyperLogLog-Algorithmus hat einen bekannten Fehler von etwa 2 %. Für den Parameter allow_approximate_optimization: yes müssen Ihre Looker-Entwickler bestätigen, dass es in Ordnung ist, ungefähre Daten für den Messwert zu verwenden, damit er ungefähr aus aggregierten Tabellen berechnet werden kann.

Weitere Informationen und die Liste der Dialekte, die die Anzahl der eindeutigen 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 zum Konvertieren von Zeitzonen, damit Ihre Nutzer Abfrageergebnisse in ihrer eigenen Zeitzone erhalten:

  • Zeitzone für Abfragen: Diese Einstellung gilt für alle Abfragen der Datenbankverbindung. Wenn sich alle Ihre Nutzer in derselben Zeitzone befinden, können Sie eine einzelne Abfragezeitzone festlegen, damit alle Abfragen von der Datenbankzeitzone in die Abfragezeitzone konvertiert werden.
  • Nutzerspezifische Zeitzonen, in denen Nutzern Zeitzonen individuell zugewiesen werden können und sie diese selbst auswählen können. In diesem Fall werden Abfragen von der Zeitzone der Datenbank in die Zeitzone des jeweiligen Nutzers konvertiert.

Weitere Informationen zu diesen Optionen finden Sie auf der Dokumentationsseite Verwenden von Zeitzoneneinstellungen.

Diese Konzepte sind wichtig, um die aggregierte Wahrnehmung zu verstehen. Damit eine zusammengefasste Tabelle für eine Abfrage mit Datumsdimensionen oder ‑filtern verwendet werden kann, muss die Zeitzone in der zusammengefassten Tabelle mit der Zeitzoneneinstellung der ursprünglichen Abfrage übereinstimmen.

Aggregattabellen verwenden die Datenbankzeitzone, wenn kein timezone Wert angegeben ist. Für Ihre Datenbankverbindung wird auch die Zeitzone der Datenbank verwendet, wenn einer der folgenden Punkte zutrifft:

  • Ihre Datenbank unterstützt keine Zeitzonen.
  • Die Abfragezeitzone Ihrer Datenbankverbindung ist auf die gleiche Zeitzone wie die Datenbankzeitzone eingestellt.
  • Für Ihre Datenbankverbindung ist weder eine Abfragezeitzone noch eine nutzerspezifische Zeitzone angegeben. In diesem Fall wird für die Datenbankverbindung die Zeitzone der Datenbank verwendet.

Wenn eine dieser Bedingungen 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 größerer Wahrscheinlichkeit verwendet wird:

  • Wenn für Ihre Datenbankverbindung eine einzelne Zeitzone für Abfragen verwendet wird, sollte der timezone-Wert Ihrer Aggregattabelle mit dem Wert der Zeitzone für Abfragen übereinstimmen.
  • Wenn für Ihre Datenbankverbindung nutzerspezifische Zeitzonen verwendet werden, sollten Sie identische Aggregattabellen erstellen, die jeweils einen anderen timezone-Wert haben, der den möglichen Zeitzonen Ihrer Nutzer entspricht.

Faktoren filtern

Seien Sie vorsichtig, wenn Sie Filter in Ihre zusammengefasste Tabelle einfügen. Filter in einer zusammengefassten 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äglichen Bestellmengen und filtern die zusammengefasste Tabelle nach Sonnenbrillenbestellungen aus Australien. Wenn ein Nutzer eine Explore-Abfrage für die täglichen Bestellmengen 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 Daten in der zusammengefassten Tabelle werden zu stark gefiltert, sodass sie nicht für die Explore-Abfrage verwendet werden 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 Datenbeschränkungen an.
  • always_filter: Benutzer müssen für eine Explore-Abfrage bestimmte Filter angeben. Benutzer können den Standardfilterwert für ihre Abfrage ändern, aber sie können den Filter 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 Ihre Explore-Funktion diese Filter enthält, müssen Sie deren Felder in den dimensions-Parameter des aggregate_table-Parameters 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 für dieses Explore erstellen möchten, muss sie das Feld enthalten, auf dem der Zugriffsfilter basiert. Im nächsten Beispiel basiert der Zugriffsfilter auf dem Feld orders.region, und dasselbe Feld ist 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.

Dies gilt auch für Explore-Abfragen, die eine native abgeleitete Tabelle verwenden, die mit bind_filters konfiguriert ist. Mit dem Parameter bind_filters werden angegebene Filter aus einer Explore-Abfrage an die Unterabfrage der nativen abgeleiteten Tabelle übergeben. Im Falle der Aggregatwerterkennung gilt: Wenn Ihre Explore-Abfrage eine native abgeleitete Tabelle erfordert, die bind_filters verwendet, kann die Explore-Abfrage eine zusammengefasste Tabelle nur dann verwenden, wenn alle Felder, die im Parameter bind_filters der nativen abgeleiteten Tabelle verwendet werden, in der Explore-Abfrage genau die gleichen Filterwerte haben wie in der zusammengefassten Tabelle.

Aggregierte Tabellen erstellen, die genau mit Explore-Abfragen übereinstimmen

Eine Möglichkeit, sicherzustellen, dass eine aggregierte Tabelle für eine Explore-Abfrage verwendet werden kann, besteht darin, eine aggregierte 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 mit beliebigen Arten von Measures verwenden.

Sie können eine zusammengefasste Tabelle aus einem Explore erstellen, indem Sie die Option Get LookML aus dem Zahnradmenü eines Explore verwenden. Sie können auch exakte Übereinstimmungen für alle Kacheln in einem Dashboard erstellen, indem Sie die Option LookML abrufen aus dem Zahnradmenü eines Dashboards verwenden.

Ermitteln, welche zusammengefasste Tabelle für eine Abfrage verwendet wird

Nutzer mit see_sql-Berechtigungen können auf dem Tab SQL eines Explores in den Kommentaren sehen, welche zusammengefasste Tabelle für eine Abfrage verwendet wird. Die Kommentare auf der Registerkarte SQL werden auch im Entwicklungsmodus angezeigt, sodass Entwickler neue Aggregattabellen testen können, um zu sehen, wie Looker sie verwendet, bevor Sie neue Tabellen in die Produktion übertragen.

Anhand der Beispiel-Tabelle mit monatlichen Aggregaten oben können Sie beispielsweise zum Explore wechseln und 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, in denen die zusammengefasste Tabelle angegeben ist, die für die Abfrage verwendet wurde.

Anhand der folgenden Kommentare auf dem Tab SQL sehen wir, dass Looker die aggregierte Tabelle sales_monthly für diese Abfrage verwendet und Informationen dazu, warum andere aggregierte 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 Fehlerbehebung.

Schätzungen der Rechenersparnis 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 Rechenressourceneinsparungen angezeigt, die sich durch die Verwendung der zusammengefassten Tabelle anstelle einer direkten Abfrage der Datenbank ergeben. Die geschätzten Einsparungen bei der Steigerung der Bekanntheit werden in einem Explore neben dem Button Ausführen angezeigt, bevor die Abfrage ausgeführt wird.

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 Bekanntheit werden für Datenbankverbindungen angezeigt, für die Kostenschätzungen aktiviert sind. Weitere Informationen finden Sie auf der Dokumentationsseite Daten in Looker untersuchen .

Looker führt neue Daten mit Ihren zusammengefassten Tabellen zusammen

Bei zusammengefassten Tabellen mit Zeitfiltern kann Looker neue Daten zusammenführen. Möglicherweise haben Sie eine zusammengefasste Tabelle mit Daten für die letzten drei Tage, die gestern erstellt wurde. Der zusammengefassten Tabelle würden die Informationen von heute fehlen, sodass Sie nicht erwarten würden, sie für eine Explore-Abfrage zu den neuesten täglichen Informationen zu 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.

Unter den folgenden Umständen kann Looker neue Daten mit den Daten Ihrer Aggregattabelle 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 enthält 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 dann mit den Ergebnissen aus der zusammengefassten Tabelle zusammen. Ihre Nutzer erhalten also die neuesten Daten, während die Leistung weiterhin durch die Nutzung von zusammengefassten Informationen optimiert wird.

Wenn Sie sich im Entwicklungsmodus befinden, können Sie auf dem Tab SQL eines Explores die Aggregat-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 Aggregat-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 aggregierten Tabelle angegeben. Da aggregierte Tabellen eine Art persistenter abgeleiteter Tabelle (PDT) sind, gelten für sie dieselben Anforderungen wie für PDTs. Weitere Informationen finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker.

Sie können inkrementelle PDTs in Ihrem Projekt erstellen, wenn Ihr Dialekt sie unterstützt. Inkrementelle PDTs werden in Looker erstellt, 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 persistenten abgeleiteten Tabellen finden Sie auf der Dokumentationsseite Inkrementelle persistente abgeleitete Tabellen. 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 aggregierten 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 neu erstellt, auf die in der Abfrage verwiesen wird, sowie alle abgeleiteten Tabellen, von denen die Tabellen in der Abfrage abhängen. Dazu gehören auch zusammengefasste Tabellen, die selbst eine Art persistenter abgeleiteter Tabelle sind.

Für den Benutzer, der die Option Rebuild Derived Tables & Run startet, werden die Ergebnisse erst geladen, wenn die Tabellen neu erstellt wurden. Abfragen anderer Nutzer 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 für das Explore ausführen und auf den Tab SQL klicken, um Kommentare zur für die Abfrage verwendeten zusammengefassten Tabelle zu sehen, sofern vorhanden.

Die Registerkarte SQL enthält gegebenenfalls auch Kommentare dazu, warum für eine Abfrage keine Aggregattabellen verwendet wurden. Bei nicht verwendeten aggregierten Tabellen beginnt der Kommentar mit:

Did not use [explore name]::[aggregate table name];

Hier ist beispielsweise ein Kommentar dazu, warum die in der order_items Explore-Funktion definierte Aggregattabelle 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 verhinderten die Filter in der Abfrage die Verwendung der Aggregattabelle.

In der folgenden Tabelle sind einige weitere mögliche Gründe dafür aufgeführt, dass eine zusammengefasste Tabelle nicht verwendet werden kann, sowie Schritte, die Sie unternehmen können, um die Nutzbarkeit der zusammengefassten Tabelle zu erhöhen.

Grund für die Nichtverwendung der Aggregattabelle Erläuterung und mögliche Schritte
Ein solches Feld ist im Explore nicht vorhanden. Es liegt ein LookML-Validierungsfehler vor. Dies liegt höchstwahrscheinlich daran, dass die Aggregattabelle nicht korrekt definiert wurde oder dass sich im LookML für Ihre Aggregattabelle ein Tippfehler befand. Eine wahrscheinliche Ursache ist ein falscher Feldname oder Ähnliches.

Prüfen Sie, ob die Dimensionen und Measures in der zusammengefassten Tabelle mit den Feldnamen im Explore übereinstimmen, um dieses Problem zu beheben. Weitere Informationen zur Definition einer Aggregattabelle 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 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 einen Measure enthält, die bzw. der nicht in einer zusammengefassten Tabelle vorhanden ist, kann Looker die zusammengefasste Tabelle nicht verwenden und greift stattdessen auf die Basistabelle zurück. Weitere Einzelheiten finden Sie im Abschnitt Feldfaktoren auf dieser Seite. Eine Ausnahme bilden Zeitrahmendimensionen, da Zeiträume mit gröberem Detaillierungsgrad aus Zeiträumen mit feinerem Detaillierungsgrad abgeleitet werden können.

Um dieses Problem zu beheben, überprüfen Sie, 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:
  • Fügen Sie denselben Filter Ihrer zusammengefassten Tabelle hinzu.
  • Fügen Sie der zusammengefassten Tabelle das Feld hinzu, das für den Filter verwendet wird.
  • Entfernen Sie die Filter aus der Explore-Abfrage.
Siehe dieFilterfaktoren Weitere Details finden Sie im entsprechenden Abschnitt auf dieser Seite.
Die Abfrage enthält die folgenden Kennzahlen, die nicht aggregiert werden können. Die Abfrage enthält einen oder mehrere Measure-Typen, die für die Aggregat-Sensibilisierung nicht unterstützt werden, z. B. Anzahl der eindeutigen Werte, Median oder Perzentil.

Prüfen Sie zur Behebung dieses Problems den Typ der einzelnen Messwerte in der Abfrage und achten Sie darauf, dass es sich um einen der unterstützten Messwerttypen handelt. Wenn Ihre Explore-Funktion Joins enthält, überprüfen Sie außerdem, ob Ihre Kennzahlen nicht durch aufgefächerte Joins in unterschiedliche Kennzahlen (symmetrische Aggregate) umgewandelt werden. Eine Erklärung finden Sie im Abschnitt Symmetrische Aggregate für Explores mit Joins auf dieser Seite.
Eine andere Aggregattabelle eignete sich besser zur Optimierung. Es gab mehrere geeignete aggregierte Tabellen für die Abfrage und Looker hat eine optimale aggregierte Tabelle gefunden, die stattdessen verwendet werden kann. In diesem Fall ist nichts zu unternehmen.
Looker hat keine Gruppierung vorgenommen (wegen eines primary_key oder cancel_grouping_fields Parameters), daher kann die Abfrage nicht zusammengefasst werden. Die Abfrage verweist auf eine Dimension, die die Verwendung einer GROUP BY-Klausel verhindert, und daher kann Looker keine Aggregattabelle für die Abfrage verwenden.

Prüfen Sie, ob der Parameter primary_key der Ansicht und der Parameter cancel_grouping_fields des Explorers richtig eingerichtet sind, um das Problem zu beheben.
Die Aggregattabelle enthielt Filter, die nicht in der Abfrage enthalten waren. Die aggregierte Tabelle enthält einen Filter, der nicht auf Zeit basiert und nicht in der Abfrage enthalten ist.

Um dieses Problem zu beheben, können Sie den Filter aus der Aggregattabelle entfernen. Weitere Informationen finden Sie im Abschnitt Filterfaktoren auf dieser Seite.
Ein Feld ist in der Explore-Abfrage als reines Filterfeld definiert, wird aber im Parameter dimensions der Aggregattabelle aufgeführt. Der Parameter dimensions der Aggregattabelle listet ein Feld auf, das in der Explore-Abfrage nur als Feld filter definiert ist.

Entfernen Sie das Feld aus der Liste dimensions der aggregierten Tabelle, um das Problem zu beheben. Falls dieses Feld für die Aggregattabelle benötigt wird, fügen Sie es der Liste filters in der Abfrage der Aggregattabelle hinzu.
Der Optimierer kann nicht feststellen, warum die Aggregattabelle nicht verwendet wurde. Dieser Kommentar ist für Sonderfälle reserviert. Wenn Sie diese Meldung für eine Explore-Abfrage sehen, die häufig verwendet wird, können Sie eine Aggregat-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, in dem mehrere Datenbanktabellen verknüpft werden, Measures vom Typ SUM, COUNT und AVERAGE als SUM DISTINCT, COUNT DISTINCT bzw. AVERAGE DISTINCT rendern kann. Looker tut dies, um Fehlberechnungen des Fanout zu vermeiden. Beispiel: Der Messwert count wird als Messwerttyp count_distinct gerendert. So werden Fehlberechnungen des Fanout für Joins vermieden. Dies ist Teil der Funktion für symmetrische Aggregate in Looker. Eine Erläuterung dieser Looker-Funktion finden Sie auf der Seite Best Practices für symmetrische Summen.

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:

  • Das Measure stammt aus der „1“-Ansicht eines n:1-Joins oder 1:n-Joins.
  • Das Measure stammt aus einer der beiden Ansichten eines n:n-Joins.

Eine Erläuterung dieser Arten von Joins 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 Measure-Typen für ein Explore mit Joins zu verwenden. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Aggregierte Tabellen 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-Measure mit allow_approximate_optimization: yes definiert wird, kann Looker das Measure für die aggregierte Bekanntheit verwenden, auch wenn es als Anzahl unterschiedlicher Elemente 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 aggregiertes Bewusstsein

Die Möglichkeit, Aggregate Awareness zu nutzen, hängt von dem Datenbankdialekt ab, den Ihre Looker-Verbindung verwendet. In der neuesten Version von Looker werden die folgenden Dialekte für die Aggregaterkennung unterstützt:

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

Unterstützung von Dialekten für das inkrementelle Erstellen von zusammengefassten 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 das inkrementelle Erstellen von PDTs in der aktuellen Looker-Version 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
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