Aggregatfunktion

Übersicht

Looker verwendet die Aggregate Awareness-Logik, um die kleinste und effizienteste Tabelle in Ihrer Datenbank zu finden, um eine Abfrage auszuführen und gleichzeitig die Genauigkeit beizubehalten.

Für sehr große Tabellen in Ihrer Datenbank können Looker-Entwickler kleinere aggregierte Datentabellen erstellen, die nach verschiedenen Kombinationen von Attributen gruppiert sind. Die zusammengefassten Tabellen dienen als Zusammenfassungstabellen, die Looker nach Möglichkeit anstelle der ursprünglichen großen Tabelle für Abfragen verwenden kann. Bei strategischer Implementierung kann die Aggregationsaufmerksamkeit die durchschnittliche Abfrage um ein Vielfaches beschleunigen.

Angenommen, Sie haben eine Datentabelle im Petabyte-Maßstab mit einer Zeile für jede Bestellung, die auf Ihrer Website aufgegeben wurde. Aus dieser Datenbank können Sie eine Gesamtübersichtstabelle mit den täglichen Umsatzsummen erstellen. Wenn auf Ihrer Website täglich 1.000 Bestellungen eingehen, enthält die tägliche Summentabelle für jeden Tag 999 Zeilen weniger als die ursprüngliche Tabelle. Sie können eine weitere zusammengefasste Tabelle mit monatlichen Gesamtumsätzen erstellen, die noch effizienter ist. Wenn ein Nutzer jetzt 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 Jahresverkäufen ausführt und Sie keine Jahressummentabelle haben, verwendet Looker die nächstbeste Lösung, in diesem Beispiel die Summentabelle für monatliche Verkäufe.

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

  • Für eine Abfrage zum monatlichen Gesamtumsatz verwendet Looker die aggregierte Tabelle, die auf dem monatlichen Umsatz (sales_monthly_aggregate_table) basiert.
  • Für eine Abfrage zur Gesamtsumme der einzelnen Verkäufe an einem Tag gibt es keine aggregierte Tabelle mit dieser Detailebene. Daher erhält Looker die Abfrageergebnisse aus der ursprünglichen Datenbanktabelle (orders_database). 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 gibt es keine aggregierte Wochentabelle. Daher verwendet Looker die nächstbeste Lösung, nämlich die aggregierte Tabelle auf der Grundlage der täglichen Umsätze (sales_daily_aggregate_table).

Mithilfe der Aggregate Awareness-Logik wird in Looker die kleinstmögliche Aggregationstabelle abgefragt, um die Fragen der Nutzer zu beantworten. Die ursprüngliche Tabelle wird nur für Abfragen verwendet, die eine höhere Detailgenauigkeit erfordern, als die zusammengefassten Tabellen bieten können.

Aggregierte Tabellen müssen nicht mit einem separaten Explore verbunden oder diesem hinzugefügt werden. Stattdessen passt Looker die FROM-Klausel der explorativen Abfrage dynamisch an, um auf die beste Aggregationstabelle für die Abfrage zuzugreifen. Das bedeutet, dass Ihre Aufschlüsselungen beibehalten und explorative Datenanalysen konsolidiert werden können. Wenn Sie die Aggregation berücksichtigen, können Sie in einem Explore automatisch aggregierte Tabellen verwenden, aber bei Bedarf auch detaillierte Daten analysieren.

Mithilfe von Aggregierungstabellen lässt sich die Leistung von Dashboards drastisch verbessern, insbesondere bei Kacheln, für die riesige Datenmengen abgefragt werden. Weitere Informationen finden Sie auf der Seite mit der Parameterdokumentation für aggregate_table im Abschnitt LookML-Code einer aggregierten Tabelle aus einem Dashboard abrufen.

Ihrem Projekt Summentabellen hinzufügen

Looker-Entwickler können strategische Aggregationstabellen erstellen, um die Anzahl der Abfragen zu reduzieren, die für die großen Tabellen in einer Datenbank erforderlich sind. Aggregierungstabellen müssen in Ihrer Datenbank persistent gespeichert werden, damit sie für die Aggregation der Markenbekanntheit zugänglich sind. Aggregierte Tabellen sind daher eine Art persistente abgeleitete Tabelle (PDT).

Eine zusammengefasste Tabelle wird in Ihrem LookML-Projekt mit dem Parameter aggregate_table unter einem explore-Parameter definiert.

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

Wenn Sie eine zusammengefasste Tabelle erstellen möchten, können Sie die LookML von Grund auf neu schreiben oder die LookML für die zusammengefasste Tabelle aus einem Explore oder aus einem Dashboard abrufen. Weitere Informationen zu aggregate_table und seinen Unterparametern finden Sie auf der Seite aggregate_table.

Zusammengefasste Tabellen entwerfen

Damit eine Explore-Abfrage eine aggregierte Tabelle verwenden kann, muss die aggregierte Tabelle korrekte Daten für die Explore-Abfrage liefern können. Looker kann eine aggregierte Tabelle für eine Explore-Abfrage verwenden, wenn Folgendes zutrifft:

  • Die Felder der explorativen Datenanalyse sind eine Teilmenge der Felder der Gesamtdatentabelle (siehe Abschnitt Feldfaktoren auf dieser Seite). Bei Zeiträumen können die Zeiträume der explorativen Datenanalyse aus den Zeiträumen in der Gesamttabelle abgeleitet werden (siehe Abschnitt Faktoren für Zeiträume auf dieser Seite).
  • Die Explore-Abfrage enthält Messtypen, die für die zusammengefasste Bekanntheit unterstützt werden (siehe Abschnitt Faktoren für Messtypen auf dieser Seite). Die Explore-Abfrage enthält eine aggregierte Tabelle, die genau übereinstimmt (siehe Abschnitt Aggregierte Tabellen erstellen, die genau mit Explore-Abfragen übereinstimmen auf dieser Seite).
  • Die Zeitzone der explorativen Datenanalyse stimmt mit der Zeitzone der Summentabelle überein (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 Abschnitt Filterfaktoren auf dieser Seite).

Eine Möglichkeit, dafür zu sorgen, dass eine aggregierte Tabelle genaue Daten für eine Explore-Abfrage liefern kann, besteht darin, eine aggregierte Tabelle zu erstellen, die genau mit einer Explore-Abfrage übereinstimmt. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Summentabellen erstellen, die genau mit explorativen Datenanalysen übereinstimmen.

Feldfaktoren

Damit eine aggregierte Tabelle für eine Explore-Abfrage verwendet werden kann, müssen alle für diese Explore-Abfrage erforderlichen Dimensionen und Messwerte enthalten sein, einschließlich der Felder, die für Filter in der Explore-Abfrage verwendet werden. Wenn eine Explore-Abfrage eine Dimension oder ein Maß enthält, das nicht in einer zusammengefassten Tabelle enthalten ist, kann Looker die zusammengefasste Tabelle nicht verwenden und verwendet stattdessen die Basistabelle.

Wenn eine Abfrage beispielsweise nach den Dimensionen A und B gruppiert, nach dem Messwert C zusammengefasst und nach der Dimension D gefiltert wird, müssen in der zusammengefassten Tabelle mindestens A, B und D als Dimensionen und C als Messwert enthalten sein.

Die Aggregierungstabelle kann auch andere Felder enthalten, muss aber mindestens die Felder der Explore-Abfrage enthalten, damit sie für die Optimierung geeignet ist. Die einzige Ausnahme bilden Zeitrahmendimensionen, da Zeiträume mit gröberer Granularität aus Zeiträumen mit feinerer Granularität 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 in einem Explore definiert ist, wird nicht für Abfragen in einem anderen Explore verwendet.

Faktoren für den Zeitraum

Mit der Logik für die zusammengefasste Bekanntheit in Looker lässt sich ein Zeitraum aus einem anderen ableiten. Eine aggregierte Tabelle kann für eine Abfrage verwendet werden, solange der Zeitrahmen der aggregierten Tabelle eine höhere (oder genauso große) Granularität wie die Explore-Abfrage aufweist. Beispiel: Eine aggregierte 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 Wochentag, den Tag des Monats und den Wochentag 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 ausreichend detailliert für die Explore-Abfrage sind.

Dasselbe gilt für Teilmengen von Zeiträumen. Wenn Sie beispielsweise eine aggregierte Tabelle haben, die auf 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 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 Zeitrahmenfilter in der Explore-Abfrage aufweist. Beispiel: Eine aggregierte 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 Messtyp

Damit eine Explore-Abfrage eine aggregierte Tabelle verwenden kann, müssen die Messwerte in der aggregierten Tabelle korrekte Daten für die Explore-Abfrage liefern.

Aus diesem Grund werden nur bestimmte Arten von Messwerten unterstützt, wie in den folgenden Abschnitten beschrieben:

Wenn in einer Explore-Abfrage eine andere Art von Messwert verwendet wird, verwendet Looker die ursprüngliche Tabelle, nicht die aggregierte Tabelle, um Ergebnisse zurückzugeben. Die einzige Ausnahme ist, wenn die Explore-Abfrage genau mit einer Abfrage für eine aggregierte Tabelle übereinstimmt, wie im Abschnitt Aggregierte Tabellen erstellen, die genau mit Explore-Abfragen übereinstimmen beschrieben.

Andernfalls verwendet Looker die ursprüngliche Tabelle und nicht die aggregierte Tabelle, um Ergebnisse zurückzugeben.

Messwerte mit unterstützten Messtypen

„Bekanntheitsgrad insgesamt“ kann für Explore-Abfragen verwendet werden, in denen Messwerte mit den folgenden Messwerttypen verwendet werden:

Damit eine aggregierte Tabelle für eine Explore-Abfrage verwendet werden kann, muss Looker die Messwerte der aggregierten Tabelle bearbeiten können, um korrekte Daten in der Explore-Abfrage bereitzustellen. Ein Messwert mit type: sum kann beispielsweise für die zusammengefasste Bekanntheit verwendet werden, da sich mehrere Summen addieren lassen: 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 mit einer aggregierten Tabelle der Tageshöchstwerte das genaue Wochenmaximum ermittelt werden kann.

Bei Messwerten mit type: average wird die zusammengefasste Datenerkenntnis unterstützt, da Looker Summen- und Zähldaten verwendet, um Mittelwerte aus zusammengefassten Tabellen genau abzuleiten.

Mit SQL-Ausdrücken definierte Messwerte

Die zusammengefasste Bekanntheit kann auch mit Messwerten 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 zusammengefasste 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 zusammengefasste Bekanntheit 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) ;;
}

Außerdem wird die Aggregationsaufmerksamkeit für Messwerte unterstützt, bei denen MIN, MAX und COUNT im Parameter sql definiert sind, z. B. für diesen 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, werden für die zusammengefasste Bekanntheit die folgenden Arten von Feldreferenzen unterstützt:

  • 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 Funktion „Aggregate Awareness“ wird für Messwerte, die im Format ${TABLE}.column_name definiert sind, nicht unterstützt. 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 Messwert, der mit diesem Parameter sql definiert ist, wird beispielsweise in einer Aggregationstabelle nicht 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 Summentabelle aufnehmen möchten, können Sie stattdessen eine Dimension mit dem Format ${TABLE}.column_name erstellen und dann einen Messwert erstellen, der auf die Dimension verweist. So gehts:


 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 die Anzahl einzelner Aufrufe annähernd ermitteln

Im Allgemeinen werden eindeutige Zählungen bei der zusammengefassten Bekanntheit nicht unterstützt, da Sie keine genauen Daten erhalten, wenn Sie versuchen, eindeutige Zählungen zu aggregieren. Wenn Sie beispielsweise die eindeutigen Nutzer auf 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 Summentabelle anzuwenden, um die monatliche Anzahl der einzelnen Nutzer auf Ihrer Website zu ermitteln, wird dieser Nutzer in der monatlichen Abfrage für die eindeutige Anzahl zweimal gezählt und die Daten sind falsch.

Eine Lösung für dieses Problem besteht darin, eine aggregierte Tabelle zu erstellen, die genau mit einer Explore-Abfrage übereinstimmt. Eine entsprechende Anleitung finden Sie auf dieser Seite im Abschnitt Aggregierte Tabellen erstellen, die genau mit Explore-Abfragen übereinstimmen. Wenn die Explore-Abfrage und die Abfrage einer zusammengefassten Tabelle identisch sind, liefern eindeutige Zählmesswerte korrekte Daten und können für die zusammengefasste Bekanntheit verwendet werden.

Alternativ können Sie Näherungswerte für die Anzahl der eindeutigen Elemente verwenden. Bei Dialekten, die HyperLogLog-Skizzen unterstützen, kann Looker den HyperLogLog-Algorithmus verwenden, um die Anzahl der einzelnen Werte für Aggregationstabellen zu approximieren.

Der HyperLogLog-Algorithmus hat einen Fehler von etwa 2 %. Für den Parameter allow_approximate_optimization: yes müssen Ihre Looker-Entwickler zustimmen, dass ungefähre Daten für den Messwert verwendet werden dürfen, damit der Messwert ungefähr aus Aggregierungstabellen berechnet werden kann.

Weitere Informationen und eine Liste der Dialekte, die „Anzahl eindeutiger Werte mit HyperLogLog“ unterstützen, finden Sie auf der Seite mit der Parameterdokumentation für allow_approximate_optimization.

Zeitzonenfaktoren

In vielen Fällen verwenden Datenbankadministratoren UTC als Zeitzone für Datenbanken. Viele Nutzer befinden sich jedoch nicht in der Zeitzone UTC. In Looker gibt es mehrere Optionen zum Umrechnen von Zeitzonen, damit Nutzer Suchergebnisse in ihrer eigenen Zeitzone erhalten:

  • Abfragezeitzone: Diese Einstellung gilt für alle Abfragen in der Datenbankverbindung. Wenn sich alle 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, bei denen Nutzern Zeitzonen zugewiesen und individuell ausgewählt werden können. In diesem Fall werden Abfragen aus der Zeitzone der Datenbank in die Zeitzone des einzelnen Nutzers konvertiert.

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

Diese Konzepte sind wichtig für das Verständnis der Aggregationsaufmerksamkeit. Damit eine aggregierte Tabelle für eine Abfrage mit Datumsdimensionen oder Datumsfiltern verwendet werden kann, muss die Zeitzone der aggregierten Tabelle mit der Zeitzoneneinstellung der ursprünglichen Abfrage übereinstimmen.

Für zusammengefasste Tabellen wird die Zeitzone der Datenbank verwendet, wenn kein timezone-Wert angegeben ist. Die Datenbankzeitzone wird auch in folgenden Fällen für die Datenbankverbindung verwendet:

  • Ihre Datenbank unterstützt keine Zeitzonen.
  • Die Abfragezeitzone Ihrer Datenbankverbindung ist auf dieselbe Zeitzone wie die Datenbankzeitzone festgelegt.
  • 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 Aussagen zutrifft, können Sie den Parameter timezone für Ihre Summentabellen 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 für Ihre Datenbankverbindung eine einzige Abfragezeitzone verwendet wird, sollten Sie den timezone-Wert Ihrer Summentabelle mit dem Wert der Abfragezeitzone abgleichen.
  • Wenn für Ihre Datenbankverbindung nutzerspezifische Zeitzonen verwendet werden, sollten Sie identische Aggregationstabellen mit jeweils einem anderen timezone-Wert erstellen, der den möglichen Zeitzonen Ihrer Nutzer entspricht.

Filterfaktoren

Seien Sie vorsichtig, wenn Sie Filter in Ihre Gesamtübersicht aufnehmen. Filter in einer Summentabelle können die Ergebnisse so eingrenzen, dass die Summentabelle unbrauchbar wird. Angenommen, Sie erstellen eine zusammengefasste Tabelle für die tägliche Bestellanzahl und filtern in der zusammengefassten Tabelle nur nach Bestellungen für Sonnenbrillen aus Australien. Wenn ein Nutzer eine Explore-Abfrage für die tägliche Bestellanzahl von Sonnenbrillen weltweit ausführt, kann Looker die zusammengefasste Tabelle für diese Explore-Abfrage nicht verwenden, da sie nur die Daten für Australien enthält. Die Daten werden in der aggregierten Tabelle zu stark gefiltert, um für die Explore-Abfrage verwendet zu werden.

Achten Sie auch auf die Filter, die Ihre Looker-Entwickler in Ihr Explore eingefügt haben könnten, z. B.:

  • access_filters: Es werden nutzerspezifische Datenbeschränkungen angewendet.
  • always_filter: Nutzer müssen für eine Explore-Abfrage eine bestimmte Gruppe von Filtern angeben. Nutzer können den Standardfilterwert für ihre Abfrage ändern, den Filter jedoch nicht vollständig entfernen.
  • conditionally_filter: Hiermit werden Standardfilter definiert, die Nutzer überschreiben können, wenn sie mindestens einen Filter aus einer zweiten Liste anwenden, die ebenfalls im explorativen Analysetool definiert ist.

Diese Filtertypen basieren auf bestimmten Feldern. Wenn Ihr Explore diese Filter enthält, müssen Sie die zugehörigen Felder in den Parameter dimensions der 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 aggregierte 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, das auch als Dimension in der Summentabelle enthalten ist:

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 aggregierte Tabelle die Dimension orders.region enthält, kann Looker die Daten in der aggregierten Tabelle dynamisch so filtern, dass sie mit dem Filter aus der Explore-Abfrage übereinstimmen. Daher kann Looker die aggregierte Tabelle weiterhin für die Abfragen des Explores verwenden, auch wenn das Explore einen Zugriffsfilter hat.

Dies gilt auch für Explore-Abfragen, bei denen eine native abgeleitete Tabelle verwendet wird, die mit bind_filters konfiguriert ist. Über den Parameter bind_filters werden angegebene Filter aus einer Explore-Abfrage an die Unterabfrage der nativen abgeleiteten Tabelle übergeben. Wenn für Ihre Explore-Abfrage mit aggregierten Daten eine native abgeleitete Tabelle mit bind_filters erforderlich ist, kann in der Explore-Abfrage nur dann eine aggregierte Tabelle verwendet werden, wenn alle Felder, die im bind_filters-Parameter der nativen abgeleiteten Tabelle verwendet werden, in der Explore-Abfrage genau dieselben Filterwerte haben wie in der aggregierten Tabelle.

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

Eine Möglichkeit, sicherzugehen, dass eine aggregierte Tabelle für eine Explore-Abfrage verwendet werden kann, besteht darin, eine aggregierte Tabelle zu erstellen, die genau mit der Explore-Abfrage übereinstimmt. Wenn in der Explore-Abfrage und in der zusammengefassten Tabelle dieselben Messwerte, Dimensionen, Filter, Zeitzonen und anderen Parameter verwendet werden, gelten die Ergebnisse der zusammengefassten Tabelle per Definition auch für die Explore-Abfrage. Wenn eine aggregierte Tabelle genau mit einer Explore-Abfrage übereinstimmt, kann Looker aggregierte Tabellen mit beliebigen Messwerten verwenden.

Sie können eine zusammengefasste Tabelle aus einem Explore erstellen. Klicken Sie dazu im Zahnradmenü eines Explores auf die Option LookML abrufen. Sie können auch über die Option LookML-Code abrufen im Zahnradmenü eines Dashboards genaue Übereinstimmungen für alle Kacheln in einem Dashboard erstellen.

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

Nutzer mit see_sql-Berechtigungen können anhand der Kommentare auf dem Tab SQL eines Explores sehen, welche aggregierte Tabelle für eine Abfrage verwendet wird. Die Kommentare auf dem Tab SQL werden auch im Entwicklungsmodus angezeigt. So können Entwickler neue Aggregate-Tabellen testen, um zu sehen, wie sie in Looker verwendet werden, bevor sie neue Tabellen in die Produktion verschieben.

Anhand der oben gezeigten Beispieltabelle für monatliche Summenwerte können Sie beispielsweise im Explore eine Abfrage für den Jahresumsatz 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, die die für die Abfrage verwendete Aggregattabelle angeben.

Aus den folgenden Kommentaren auf dem Tab SQL geht hervor, dass Looker für diese Abfrage die sales_monthly-Aggregattabelle verwendet. Außerdem wird erläutert, warum andere Aggregate für die Abfrage nicht 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 können, sowie Vorschläge zur Behebung.

Geschätzte Einsparungen bei der Berechnung der Gesamtbekanntheit

Wenn Ihre Datenbankverbindung Kostenschätzungen unterstützt und eine Aggregierungstabelle für eine Abfrage verwendet werden kann, werden im Explore-Fenster die Einsparungen bei der Datenverarbeitung angezeigt, die durch die Verwendung der Aggregierungstabelle statt einer direkten Abfrage der Datenbank erzielt werden. Die aggregierten Einsparungen bei der Bekanntheit werden in einem Explore neben der Schaltfläche Ausführen angezeigt, bevor die Abfrage ausgeführt wird.

Wenn Sie vor dem Ausführen der Abfrage sehen möchten, welche Aggregationstabelle dafür verwendet wird, klicken Sie auf den Tab SQL. Weitere Informationen finden Sie im Abschnitt Festlegen der Aggregationstabelle für eine Abfrage auf dieser Dokumentationsseite.

Nach der Ausführung der Abfrage wird im Explore-Fenster neben der Schaltfläche Ausführen angezeigt, welche Aggregierungstabelle zur Beantwortung der Abfrage verwendet wurde.

Die aggregierten Einsparungen durch die Steigerung der 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 eine Zusammenführung neuer Daten mit Ihren zusammengefassten Tabellen durch.

Bei zusammengefassten Tabellen mit Zeitfiltern kann Looker neue Daten mit der zusammengefassten Tabelle zusammenführen. Sie haben möglicherweise eine Aggregationstabelle mit Daten der letzten drei Tage, die aber erst gestern erstellt wurde. In der zusammengefassten Tabelle fehlen die Daten für den heutigen Tag. Sie können sie daher nicht für eine Explore-Abfrage mit den neuesten täglichen Daten 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.

In Looker können aktuelle Daten unter den folgenden Umständen mit den Daten Ihrer zusammengefassten Tabelle zusammengeführt werden:

  • Die zusammengefasste Tabelle enthält einen Zeitfilter.
  • Die Gesamtübersichtstabelle 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 Aggregationstabelle gestern erstellt wurde, ruft Looker die neuesten Daten ab, die noch nicht in der Aggregationstabelle enthalten sind, und führt dann eine Zusammenführung der neuen Ergebnisse mit den Ergebnissen aus der Aggregationstabelle durch. So erhalten Ihre Nutzer die neuesten Daten und Sie können gleichzeitig die Leistung mithilfe der zusammengefassten Bekanntheit optimieren.

Wenn Sie sich im Entwicklungsmodus befinden, können Sie auf den Tab SQL eines Explores klicken, um die Aggregierungstabelle zu sehen, die Looker für die Abfrage verwendet hat, und die UNION-Anweisung, mit der Looker neuere Daten einbezogen hat, die nicht in der Aggregierungstabelle enthalten waren.

Zusammengefasste Tabellen müssen gespeichert werden

Damit die Tabelle für die Gesamtdatenerhebung verwendet werden kann, muss sie in Ihrer Datenbank persistiert sein. Die Speicherstrategie wird im Parameter materialization der zusammengefassten Tabelle angegeben. Da aggregierte Tabellen eine Art persistente abgeleitete 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 diese unterstützt. Looker erstellt inkrementelle PDTs, indem neue Daten an die Tabelle angehängt werden, anstatt die Tabelle vollständig neu zu erstellen. Da aggregierte Tabellen selbst eine Art PDT sind, können Sie auch inkrementelle aggregierte Tabellen erstellen. Weitere Informationen zu inkrementellen PDTs finden Sie auf der Dokumentationsseite Inkrementelle PDTs. Ein Beispiel für eine inkrementelle Aggregationstabelle finden Sie auf der Dokumentationsseite des Parameters 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 neu erstellt, auf die in der Abfrage verwiesen wird, sowie alle abgeleiteten Tabellen, die von den Tabellen in der Abfrage abhängen. Dazu gehören auch Aggregationstabellen, die selbst eine Art persistente abgeleitete Tabelle sind.

Für den Nutzer, der die Option Abgeleitete Tabellen neu erstellen und ausführen startet, werden die Ergebnisse erst geladen, wenn die Tabellen neu erstellt wurden. Abfragen anderer Nutzer verwenden weiterhin die vorhandenen Tabellen. Sobald die persistenten Tabellen neu erstellt wurden, verwenden alle Nutzer 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 Feststellen, welche Aggregattabelle für eine Abfrage verwendet wird beschrieben, können Sie im Entwicklungsmodus Abfragen auf das Explore ausführen und auf den Tab SQL klicken, um ggf. Kommentare zur für die Abfrage verwendeten Aggregattabelle zu sehen.

Der Tab SQL enthält auch Kommentare dazu, warum für eine Abfrage keine zusammengefassten Tabellen verwendet wurden. Bei nicht verwendeten Summentabellen beginnt der Kommentar mit:

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

Hier ist beispielsweise ein Kommentar dazu, warum die im Explore order_items 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 haben die Filter in der Abfrage verhindert, dass die Summentabelle verwendet wurde.

In der folgenden Tabelle sind einige weitere mögliche Gründe aufgeführt, warum eine Summentabelle nicht verwendet werden kann, sowie Schritte, mit denen Sie die Nutzerfreundlichkeit der Summentabelle verbessern können.

Grund für die Nichtverwendung der zusammengefassten Tabelle Erläuterung und mögliche Schritte
Es gibt kein solches Feld in der explorativen Datenanalyse. Es gibt einen Fehler beim LookML-Validierungstyp. Das liegt wahrscheinlich daran, dass die zusammengefasste Tabelle nicht richtig definiert wurde oder in der LookML für die zusammengefasste Tabelle ein Tippfehler vorliegt. Eine wahrscheinliche Ursache ist ein falscher Feldname.

Prüfen Sie, ob die Dimensionen und Messwerte in der aggregierten Tabelle mit den Feldnamen im Explore übereinstimmen. Weitere Informationen zum Definieren einer Aggregierungstabelle finden Sie auf der Dokumentationsseite des Parameters aggregate_table.
Die folgende Tabelle enthält die folgenden Felder nicht in der Abfrage. Damit eine aggregierte Tabelle für eine Explore-Abfrage verwendet werden kann, müssen alle für diese Explore-Abfrage erforderlichen Dimensionen und Messwerte enthalten sein, einschließlich der Felder, die für Filter in der Explore-Abfrage verwendet werden. Wenn eine Explore-Abfrage eine Dimension oder ein Maß enthält, das nicht in einer zusammengefassten Tabelle enthalten ist, kann Looker die zusammengefasste Tabelle nicht verwenden und verwendet stattdessen die Basistabelle. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Feldfaktoren. Die einzige Ausnahme bilden Zeitrahmendimensionen, da Zeiträume mit gröberer Granularität aus Zeiträumen mit feinerer Granularität abgeleitet werden können.

Prü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 waren noch genau mit den Filtern in der Aggregierungstabelle übereinstimmten. Die Filter in der Explore-Abfrage verhindern, dass Looker die aggregierte Tabelle verwendet.

Sie haben folgende Möglichkeiten, dieses Problem zu beheben:
  • Fügen Sie der zusammengefassten Tabelle denselben Filter hinzu.
  • Fügen Sie der zusammengefassten Tabelle das Feld hinzu, das vom Filter verwendet wird.
  • Entfernen Sie die Filter aus der Explore-Abfrage.
Weitere Informationen finden Sie auf dieser Seite im Abschnitt Filterfaktoren.
Die Abfrage enthält die folgenden Messwerte, die nicht zusammengefasst werden können. Die Abfrage enthält einen oder mehrere Messwerttypen, die für die zusammengefasste Bekanntheit nicht unterstützt werden, z. B. Anzahl der eindeutigen Werte, Median oder Perzentil.

Prüfen Sie dazu den Typ jedes Messwerts in der Abfrage und achten Sie darauf, dass er zu den unterstützten Messwerttypen gehört. Wenn Ihr Explore Joins enthält, prüfen Sie, ob Ihre Messwerte nicht durch verzweigte Joins in eindeutige Messwerte (symmetrische Aggregate) umgewandelt werden. Eine Erklärung finden Sie auf dieser Seite im Abschnitt Symmetrische Summen für Explores mit Joins.
Eine andere Summentabelle eignete sich besser für die Optimierung. Es gab mehrere geeignete aggregierte Tabellen für die Abfrage und Looker hat stattdessen eine optimalere aggregierte Tabelle gefunden. In diesem Fall müssen Sie nichts unternehmen.
In Looker wurde 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 eine GROUP BY-Klausel verhindert. Daher kann Looker keine aggregierte Tabelle für die Abfrage verwenden.

Prüfen Sie, ob der Parameter primary_key der Datenansicht und der Parameter cancel_grouping_fields des explorativen Datenanalysetools richtig eingerichtet sind.
Die zusammengefasste Tabelle enthielt Filter, die nicht in der Abfrage enthalten waren. Die Aggregierungstabelle enthält einen nicht zeitbezogenen Filter, der nicht in der Abfrage enthalten ist.

Sie können das Problem beheben, indem Sie den Filter aus der Gesamttabelle entfernen. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Filterfaktoren.
Ein Feld ist in der Explore-Abfrage als Nur-Filter-Feld definiert, wird aber im Parameter dimensions der aggregierten Tabelle aufgeführt. Im Parameter dimensions der zusammengefassten Tabelle ist ein Feld aufgeführt, das in der Explore-Abfrage nur als filter-Feld definiert ist.

Entfernen Sie das Feld aus der Liste dimensions der Gesamttabelle, um das Problem zu beheben. Wenn dieses Feld für die Summentabelle erforderlich ist, fügen Sie es der Liste filters in der Abfrage der Summentabelle hinzu.
Der Optimierer kann nicht feststellen, warum die Aggregationstabelle nicht verwendet wurde. Dieser Kommentar ist für Grenzfälle reserviert. Wenn Sie diese Meldung für eine häufig verwendete Explore-Abfrage sehen, können Sie eine aggregierte Tabelle erstellen, die genau mit der Explore-Abfrage übereinstimmt. Sie können den LookML-Code einer zusammengefassten Tabelle ganz einfach aus einem Explore abrufen, wie auf der Parameterseite aggregate_table beschrieben.

Wichtige Punkte

Symmetrische Summen für Explores mit Joins

In einem Explore, das mehrere Datenbanktabellen zusammenführt, kann Looker Messwerte vom Typ SUM, COUNT und AVERAGE jeweils als SUM DISTINCT, COUNT DISTINCT und AVERAGE DISTINCT rendern. So werden in Looker Fehlberechnungen bei Verzweigungen vermieden. Beispiel: Ein count-Messwert wird als count_distinct-Messwerttyp gerendert. So werden Fehlberechnungen bei Verzweigungen für Joins vermieden. Diese Funktion ist Teil der symmetrischen Aggregationen in Looker. Eine Erläuterung dieser Looker-Funktion finden Sie auf der Best Practices-Seite zu symmetrischen Summen.

Die Funktion für symmetrische Aggregate verhindert Fehlberechnungen, kann aber auch verhindern, dass Ihre Aggregationstabellen in bestimmten Fällen verwendet werden. Daher ist es wichtig, sie zu verstehen.

Für die Messtypen, die für die zusammengefasste Bekanntheit unterstützt werden, gilt dies für sum, count und average. In Looker werden diese Messwerte als DISTINCT gerendert, wenn:

  • Das Messwert stammt aus der „Eins“-Ansicht eines m:1- oder 1:n--Joins.
  • Das Maß stammt aus einer der beiden Ansichten eines n:n-Joins.

Eine Erläuterung dieser Join-Typen finden Sie auf der Dokumentationsseite des Parameters relationship.

Wenn Sie feststellen, dass Ihre aggregierte Tabelle aus diesem Grund nicht verwendet wird, können Sie eine aggregierte Tabelle erstellen, die genau mit einer Explore-Abfrage übereinstimmt, um diese Messtypen für einen Explore mit Joins zu verwenden. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Summentabellen erstellen, die genau mit explorativen Datenanalysen übereinstimmen.

Wenn Sie einen SQL-Dialekt verwenden, der HyperLogLog-Skizzen unterstützt, können Sie dem Messwert den Parameter allow_approximate_optimization: yes hinzufügen. Wenn ein Zählwert mit allow_approximate_optimization: yes definiert ist, kann Looker den Messwert für die zusammengefasste Bekanntheit verwenden, auch wenn er als eindeutige Zählung gerendert wird.

Weitere Informationen und eine Liste der SQL-Dialekte, die HyperLogLog-Skizzen unterstützen, finden Sie auf der Seite mit der Parameterdokumentation für allow_approximate_optimization.

Unterstützung von Dialekten für die gesamtheitliche Bekanntheit

Die Möglichkeit, Aggregate Awareness zu nutzen, hängt vom Datenbankdialekt ab, den Ihre Looker-Verbindung verwendet. In der aktuellen Looker-Version unterstützen die folgenden Dialekte die Berücksichtigung von Aggregaten:

Dialekt Unterstützt?
Actian Avalanche
Ja
Amazon Athena
Ja
Amazon Aurora MySQL
Ja
Amazon Redshift
Ja
Apache Druid
Nein
Apache Druid 0.13 oder höher
Nein
Apache Druid 0.18 und höher
Nein
Apache Hive 2.3 und höher
Ja
Apache Hive 3.1.2 und höher
Ja
Apache Spark 3 und höher
Ja
ClickHouse
Nein
Cloudera Impala 3.1 und höher
Ja
Cloudera Impala 3.1 und höher mit nativem Treiber
Ja
Cloudera Impala mit nativem Treiber
Ja
DataVirtuality
Nein
Databricks
Ja
Denodo 7
Nein
Denodo 8
Nein
Dremio
Nein
Dremio 11 und höher
Nein
Exasol
Ja
Firebolt
Nein
Google BigQuery Legacy SQL
Ja
Google BigQuery Standard SQL
Ja
Google Cloud PostgreSQL
Ja
Google Cloud SQL
Nein
Google Spanner
Nein
Greenplum
Ja
HyperSQL
Nein
IBM Netezza
Ja
MariaDB
Ja
Microsoft Azure PostgreSQL
Ja
Microsoft Azure SQL-Datenbank
Ja
Microsoft Azure Synapse Analytics
Ja
Microsoft SQL Server 2008 und höher
Ja
Microsoft SQL Server 2012 und höher
Ja
Microsoft SQL Server 2016
Ja
Microsoft SQL Server 2017 und höher
Ja
MongoBI
Nein
MySQL
Ja
MySQL 8.0.12 und höher
Ja
Oracle
Ja
Oracle ADWC
Ja
PostgreSQL 9.5 und höher
Ja
PostgreSQL vor Version 9.5
Ja
PrestoDB
Ja
PrestoSQL
Ja
SAP HANA 2 und höher
Ja
SingleStore
Ja
SingleStore 7+
Ja
Snowflake
Ja
Teradata
Ja
Trino
Ja
Vektor
Ja
Vertica
Ja

Unterstützung für Dialekte zum inkrementellen Erstellen von Aggregierungstabellen

Damit Looker inkrementelle Summentabellen 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 neuesten Looker-Version unterstützen:

Dialekt Unterstützt?
Actian Avalanche
Nein
Amazon Athena
Nein
Amazon Aurora MySQL
Nein
Amazon Redshift
Ja
Apache Druid
Nein
Apache Druid 0.13 oder höher
Nein
Apache Druid 0.18 und höher
Nein
Apache Hive 2.3 und höher
Nein
Apache Hive 3.1.2 und höher
Nein
Apache Spark 3 und höher
Nein
ClickHouse
Nein
Cloudera Impala 3.1 und höher
Nein
Cloudera Impala 3.1 und höher mit nativem Treiber
Nein
Cloudera Impala mit nativem Treiber
Nein
DataVirtuality
Nein
Databricks
Ja
Denodo 7
Nein
Denodo 8
Nein
Dremio
Nein
Dremio 11 und höher
Nein
Exasol
Nein
Firebolt
Nein
Google BigQuery Legacy SQL
Nein
Google BigQuery Standard SQL
Ja
Google Cloud PostgreSQL
Ja
Google Cloud SQL
Nein
Google Spanner
Nein
Greenplum
Ja
HyperSQL
Nein
IBM Netezza
Nein
MariaDB
Nein
Microsoft Azure PostgreSQL
Ja
Microsoft Azure SQL-Datenbank
Nein
Microsoft Azure Synapse Analytics
Ja
Microsoft SQL Server 2008 und höher
Nein
Microsoft SQL Server 2012 und höher
Nein
Microsoft SQL Server 2016
Nein
Microsoft SQL Server 2017 und höher
Nein
MongoBI
Nein
MySQL
Ja
MySQL 8.0.12 und höher
Ja
Oracle
Nein
Oracle ADWC
Nein
PostgreSQL 9.5 und höher
Ja
PostgreSQL vor Version 9.5
Ja
PrestoDB
Nein
PrestoSQL
Nein
SAP HANA 2 und höher
Nein
SingleStore
Nein
SingleStore 7+
Nein
Snowflake
Ja
Teradata
Nein
Trino
Nein
Vektor
Nein
Vertica
Ja