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 aggregierte 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 aggregierte 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 in einem Explore automatisch auf Aggregat-Tabellen zurückgegriffen werden. Bei Bedarf können Sie aber trotzdem detaillierte Daten analysieren.

Sie können auch zusammengefasste Tabellen verwenden, um die Leistung von Dashboards erheblich zu verbessern, insbesondere für Kacheln, mit denen riesige Datasets abgefragt werden. Weitere Informationen finden Sie im Abschnitt LookML-Code einer zusammengefassten Tabelle aus einem Dashboard abrufen auf der Dokumentationsseite zum Parameter aggregate_table.

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 Aggregat-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 den Abschnitt Faktorfelder auf dieser Seite). Bei Zeiträumen können die Zeiträume der Explore-Abfrage aus den Zeiträumen in der aggregierten Tabelle abgeleitet werden (siehe den Abschnitt Zeitraumfaktoren auf dieser Seite).
• Die Explore-Abfrage enthält Messwerttypen, die von Aggregate Awareness unterstützt werden (siehe Faktoren für Messwerttypen auf dieser Seite), oder die Explore-Abfrage hat eine zusammengefasste Tabelle, die genau übereinstimmt (siehe Zusammengefasste Tabellen erstellen, die genau mit Explore-Abfragen übereinstimmen auf dieser Seite).
• Die Zeitzone der Explore-Abfrage entspricht der Zeitzone der Aggregattabelle (siehe Abschnitt Zeitzonenfaktoren auf dieser Seite).
• Die Filter der Explore-Abfrage verweisen auf Felder, die in der aggregierten Tabelle als Dimensionen verfügbar sind, oder jeder Filter der Explore-Abfrage entspricht einem Filter in der aggregierten 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 ein Measure enthält, das 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 zusammengefasste Tabelle 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 aggregierte 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, 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 aggregierte Tabelle kann jedoch nicht für eine Explore-Abfrage verwendet werden, die stündliche Daten erfordert, da die Daten der aggregierten Tabelle nicht die erforderliche Granularität für die Explore-Abfrage aufweisen.

Dasselbe gilt für Teilmengen von Zeiträumen. Beispiel: Wenn Sie eine aggregierte 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 aggregierte 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
• Messungen, die nicht mit ${TABLE} definiert sind
• Messwerte, die ungefähre Anzahl einzelner Aufrufe liefern

Wenn in einer Explore-Abfrage ein anderer Typ von Messwert 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 Aggregattabelle, 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:

• sum
• count
• min
• max
• average

Damit eine aggregierte Tabelle für eine Explore-Abfrage verwendet werden kann, muss Looker die Messwerte der aggregierten Tabelle verarbeiten können, um genaue Daten in der Explore-Abfrage zu liefern. Ein Messwert mit type: sum kann beispielsweise für „Aggregate Awareness“ verwendet werden, da mehrere Summen addiert werden können: Eine aggregierte 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 eine aggregierte Tabelle mit täglichen Höchstwerten verwendet werden kann, um den genauen wöchentlichen Höchstwert zu ermitteln.

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:

• number
• date
• string
• yesno

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 Aggregatberücksichtigung 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 Aggregatberücksichtigung 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 einbinden und auf LookML-Objekte verweisen.

Ein mit diesem sql-Parameter definierter Messwert wird beispielsweise nicht in einer Aggregattabelle 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 nicht mit aggregierter Vertraulichkeit unterstützt, da Sie keine genauen Daten erhalten, wenn Sie versuchen, Distinct Counts zu aggregieren. Wenn Sie beispielsweise die einzelnen Nutzer einer Website zählen, kann es sein, dass ein Nutzer die Website zweimal besucht hat, mit einem Abstand von drei Wochen. Wenn Sie versuchen, eine wöchentliche Aggregationstabelle zu verwenden, um eine monatliche Anzahl eindeutiger Nutzer auf Ihrer Website zu erhalten, wird dieser Nutzer zweimal in Ihrer monatlichen Distinct Count-Abfrage gezählt und die Daten sind falsch.

Eine mögliche Lösung besteht darin, eine aggregierte Tabelle zu erstellen, die genau einer Explore-Abfrage entspricht. Das wird auf dieser Seite im Abschnitt Aggregierte Tabellen erstellen, die genau Explore-Abfragen entsprechen beschrieben. Wenn die Explore-Abfrage und die Abfrage für die aggregierte 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 einzelnen Werte. Für Dialekte, die HyperLogLog-Skizzen unterstützen, kann Looker den HyperLogLog-Algorithmus verwenden, um die Anzahl der einzelnen 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 aus aggregierten Tabellen geschätzt 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: Hier können Nutzern Zeitzonen individuell zugewiesen und von ihnen ausgewählt werden. 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 Zeitzoneneinstellungen verwenden.

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.

In aggregierten Tabellen wird die Datenbankzeitzone verwendet, 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 Zeitzone für Abfragen Ihrer Datenbankverbindung ist auf dieselbe Zeitzone wie die Datenbankzeitzone festgelegt.
• Für Ihre Datenbankverbindung ist weder eine Abfragezeitzone noch nutzerspezifische Zeitzonen 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 aggregierten Tabelle so definiert werden, dass sie mit möglichen Abfragen übereinstimmt, damit die aggregierte 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.

Filterfaktoren

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 die zusammengefasste Tabelle filtert nur 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 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 Datenbeschränkungen an.
• always_filter: Legt fest, dass Nutzer für eine Explore-Abfrage eine bestimmte Gruppe von Filtern angeben müssen. 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 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. 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, obwohl das Explore einen Zugriffsfilter hat.

Dies 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 für Ihre Explore-Abfrage eine native abgeleitete Tabelle mit bind_filters erforderlich ist, kann für die Explore-Abfrage nur eine aggregierte Tabelle verwendet werden, wenn alle Felder, die im Parameter bind_filters der nativen abgeleiteten Tabelle verwendet werden, in der Explore-Abfrage und in der aggregierten Tabelle genau dieselben Filterwerte haben.

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

Eine Möglichkeit, um sicherzugehen, 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 für die Explore-Abfrage und die aggregierte Tabelle dieselben Messwerte, Dimensionen, Filter, Zeitzonen und anderen Parameter verwendet werden, gelten die Ergebnisse der aggregierten Tabelle per Definition für die Explore-Abfrage. Wenn eine aggregierte Tabelle genau mit einer Explore-Abfrage übereinstimmt, kann Looker aggregierte Tabellen mit beliebigen Messwerttypen verwenden.

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 genaue Übereinstimmungen für alle Kacheln in einem Dashboard erstellen, indem Sie im Zahnradmenü eines Dashboards die Option LookML abrufen verwenden.

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

Nutzer mit der Berechtigung see_sql können auf dem Tab 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 Aggregat-Tabellen testen, 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 Aggregat-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 Einsparungen bei der Berechnung angezeigt, die sich durch die Verwendung der zusammengefassten Tabelle anstelle einer direkten Abfrage der Datenbank ergeben. Die Einsparungen durch die Verwendung von zusammengefassten Tabellen werden neben der Schaltfläche Ausführen in einem Explore angezeigt, bevor die Abfrage ausgeführt wird.

Wenn Sie vor dem Ausführen der Abfrage sehen möchten, welche Aggregationstabelle verwendet wird, können Sie auf den Tab SQL klicken, wie im Abschnitt Ermitteln, welche Aggregationstabelle 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 bei der Markenbekanntheit werden für Datenbankverbindungen angezeigt, die für Kostenschätzungen aktiviert sind. Weitere Informationen finden Sie auf der Dokumentationsseite Daten in Looker explorieren .

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 Aggregattabelle 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 Aggregat-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 Aggregat-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 zusammengefassten Tabelle angegeben. Da zusammengefasste Tabellen eine Art persistente abgeleitete Tabelle (PAT) 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 aggregierte Tabellen selbst eine Art PAT sind, können Sie auch inkrementelle aggregierte Tabellen erstellen. Weitere Informationen zu inkrementellen persistenten abgeleiteten Tabellen finden Sie auf der Dokumentationsseite Inkrementelle persistente abgeleitete Tabellen. Ein Beispiel für eine inkrementelle Aggregattabelle 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, auf die in der Abfrage verwiesen wird, sowie alle abgeleiteten Tabellen, von denen die Tabellen in der Abfrage abhängen, neu erstellt. Dazu gehören auch aggregierte 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 Aggregat-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 Aggregat-Tabelle zu sehen, sofern vorhanden.

Auf dem Tab SQL finden Sie auch Kommentare dazu, warum zusammengefasste Tabellen für eine Abfrage nicht verwendet wurden. In diesem Fall beginnt der Kommentar mit:

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

Hier sehen Sie ein Beispiel für einen Kommentar dazu, warum die im order_items-Explore definierte aggregierte 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 wurde die zusammengefasste Tabelle aufgrund der Filter in der Abfrage nicht verwendet.

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

Wichtige Punkte

Symmetrische Summen für Explores mit Joins

Wichtig ist, dass Looker in einem Explore, in dem mehrere Datenbanktabellen zusammengeführt 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 Summen in Looker. Eine Erläuterung dieser Looker-Funktion finden Sie auf der Seite Best Practices für symmetrische Aggregate.

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 Messwerttypen für ein Explore mit Joins zu verwenden. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Zusammengefasste Tabellen erstellen, die genau Explore-Abfragen entsprechen.

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.

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:

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 Version von Looker unterstützen: