Aggregatfunktion

Überblick

Looker verwendet Aggregatlogik, um die kleinste, 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 aggregierten Tabellen dienen als Sammel- oder Zusammenfassungstabellen, die Looker nach Möglichkeit für Abfragen verwenden kann, und nicht als die ursprüngliche große Tabelle. Bei strategischer Implementierung kann die Aggregation der Bekanntheit die durchschnittliche Suchanfrage um mehrere Größenordnungen beschleunigen.

Angenommen, Sie haben eine Datentabelle im Petabytebereich mit einer Zeile für jede Bestellung, die auf Ihrer Website aufgetreten ist. Aus dieser Datenbank können Sie eine zusammengefasste Tabelle mit den täglichen Gesamtumsatzzahlen erstellen. Wenn Ihre Website 1.000 Bestellungen pro Tag erhält, würde Ihre zusammengefasste Tabelle pro Tag jeden Tag 999 weniger Zeilen umfassen als Ihre ursprüngliche Tabelle. Sie können eine weitere zusammengefasste Tabelle mit den monatlichen Gesamtumsatzzahlen erstellen, die noch effizienter ist. Wenn also ein Benutzer eine Abfrage für den täglichen oder wöchentlichen Umsatz ausführt, verwendet Looker die Tabelle „Tägliche Verkäufe insgesamt“. Wenn ein Nutzer eine Abfrage zu Jahresumsätzen ausführt und Sie keine zusammengefasste Tabelle für jährliche Umsätze haben, verwendet Looker die nächstbeste Lösung, in diesem Beispiel die aggregierte Tabelle mit den monatlichen Verkäufen.

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

  • Für eine Abfrage zum monatlichen Gesamtumsatz verwendet Looker die zusammengefasste Tabelle, die auf den monatlichen Verkäufen basiert (sales_monthly_aggregate_table).
  • Für eine Abfrage nach der Summe jedes Verkaufs an einem Tag gibt es keine zusammengefasste Tabelle mit diesem Detaillierungsgrad. Daher erhält Looker Abfrageergebnisse aus der ursprünglichen Datenbanktabelle (orders_database). (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 Verkäufen gibt es keine wöchentliche zusammengefasste Tabelle. Daher verwendet Looker die nächstbeste Variante, die zusammengefasste Tabelle, die auf dem täglichen Umsatz basiert (sales_daily_aggregate_table).

Mithilfe von Aggregatlogik fragt Looker die kleinste zusammengefasste Tabelle ab, um die Fragen Ihrer Benutzer zu beantworten. Die ursprüngliche Tabelle wird nur für Abfragen verwendet, die einen höheren Detaillierungsgrad erfordern, als die aggregierten Tabellen bieten können.

Aggregierte Tabellen müssen nicht verknüpft oder einem separaten Explore hinzugefügt werden. Stattdessen passt Looker die FROM-Klausel der Explore-Abfrage dynamisch an, um auf die beste zusammengefasste Tabelle für die Abfrage zuzugreifen. Das bedeutet, dass die Drilldowns verwaltet und Explores konsolidiert werden können. Mit Aggregate Awareness kann ein Explore automatisch aggregierte Tabellen nutzen, aber bei Bedarf trotzdem tief in detaillierte Daten eintauchen.

Sie können auch aggregierte Tabellen nutzen, um die Leistung von Dashboards drastisch zu verbessern, insbesondere für Kacheln, die riesige Datasets abfragen. Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter aggregate_table im Abschnitt LookML für aggregierte Tabellen aus einem Dashboard abrufen.

Einem Projekt zusammengefasste Tabellen hinzufügen

Looker-Entwickler können strategische zusammengefasste Tabellen erstellen, um die Anzahl der erforderlichen Abfragen für die großen Tabellen in einer Datenbank zu minimieren. Aggregierte Tabellen müssen in Ihrer Datenbank persistiert werden, damit sie für aggregierte Daten zugänglich sind. Aggregierte Tabellen sind daher eine Art nichtflüchtiger abgeleiteter Tabelle (PDT).

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

Hier ist ein Beispiel für eine explore mit einer aggregierten 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 den LookML-Code von Grund auf neu schreiben oder den LookML-Code aus einem Explore oder einem Dashboard abrufen. Weitere Informationen zum Parameter aggregate_table und seinen Unterparametern finden Sie auf der Dokumentationsseite zum Parameter aggregate_table.

Aggregierte Tabellen entwerfen

Damit eine Explore-Abfrage eine aggregierte Tabelle verwenden kann, muss die aggregierte Tabelle in der Lage sein, genaue Daten für die Explore-Abfrage zu liefern. Looker kann eine aggregierte Tabelle für eine Explore-Abfrage verwenden, wenn alle folgenden Bedingungen erfüllt sind:

  • Die Felder der Explore-Abfrage sind eine Teilmenge der Felder der aggregierten Tabelle (siehe Abschnitt Feldfaktoren auf dieser Seite). Bei Zeitrahmen können die Zeitrahmen der Explore-Abfrage auch aus den Zeitrahmen in der aggregierten Tabelle abgeleitet werden (siehe den Abschnitt Zeitrahmenfaktoren auf dieser Seite).
  • Die Explore-Abfrage enthält Messwerttypen, die von der Aggregatfunktion unterstützt werden (siehe Abschnitt Faktoren des Messwerttyps auf dieser Seite), oder die Explore-Abfrage enthält eine aggregierte Tabelle mit einer genauen Übereinstimmung (siehe Abschnitt Aggregierte Tabellen erstellen, die genau mit Explore-Abfragen übereinstimmen auf dieser Seite).
  • Die Zeitzone der Explore-Abfrage stimmt mit der Zeitzone der aggregierten Tabelle überein (siehe Abschnitt Zeitzonenfaktoren auf dieser Seite).
  • Die Filter der Explore-Abfrage verweisen auf Felder, die als Dimensionen in der zusammengefassten Tabelle verfügbar sind, oder jeder Filter der Explore-Abfrage stimmt mit einem Filter in der zusammengefassten Tabelle überein (siehe Abschnitt Filterfaktoren auf dieser Seite).

Eine Möglichkeit sicherzustellen, 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 im Abschnitt Aggregierte Tabellen erstellen, die genau mit Explore-Abfragen übereinstimmen auf dieser Seite.

Feldfaktoren

Damit eine aggregierte Tabelle für eine Explore-Abfrage verwendet werden kann, muss sie alle Dimensionen und Kennzahlen enthalten, die für diese Explore-Abfrage erforderlich sind, einschließlich der Felder, die in der Explore-Abfrage für Filter verwendet werden. Wenn eine Explore-Abfrage eine Dimension oder einen Messwert enthält, die bzw. der nicht in einer aggregierten Tabelle enthalten ist, kann Looker die aggregierte Tabelle nicht verwenden. Stattdessen wird die Basistabelle verwendet.

Wenn eine Abfrage beispielsweise nach den Dimensionen A und B gruppiert, nach Messung C aggregiert und nach Dimension D filtert, muss die zusammengefasste Tabelle mindestens die Dimensionen A, B und D und C als Messwert enthalten.

Die aggregierte Tabelle kann auch andere Felder enthalten, muss jedoch mindestens die Explore-Abfragefelder enthalten, um für die Optimierung geeignet zu sein. Die einzige Ausnahme sind Zeitraumdimensionen, da obere Zeiträume aus engeren Detaillierungsgraden abgeleitet werden können.

Aufgrund dieser Überlegungen zu Feldern ist eine aggregierte Tabelle spezifisch für das Explore, in dem sie definiert ist. Eine aggregierte Tabelle, die unter einem Explore definiert ist, wird nicht für Abfragen in einem anderen Explore verwendet.

Faktoren für den Zeitrahmen

Die Aggregationslogik von Looker ist in der Lage, einen Zeitrahmen aus einem anderen abzuleiten. Eine zusammengefasste Tabelle kann für eine Abfrage verwendet werden, solange der Zeitrahmen der aggregierten Tabelle einen feineren (oder gleichen) Detaillierungsgrad wie die Explore-Abfrage hat. Beispielsweise kann eine aggregierte Tabelle, die auf täglichen Daten basiert, für eine Explore-Abfrage verwendet werden, die andere Zeitrahmen auffordert, z. B. Abfragen von täglichen, monatlichen und jährlichen Daten oder sogar Daten zum Tag des Monats, des Jahres und der Woche des Jahres. Eine jährlich aggregierte Tabelle kann jedoch nicht für eine Explore-Abfrage verwendet werden, die stündliche Daten aufruft, da die Daten der aggregierten Tabelle für die Explore-Abfrage nicht detailliert genug sind.

Dasselbe gilt für Teilmengen von Zeiträumen. Wenn Sie beispielsweise eine zusammengefasste Tabelle haben, die nach den letzten drei Monaten gefiltert ist, und ein Nutzer die Daten mit einem Filter für die letzten zwei Monate abfragt, kann Looker die aggregierte Tabelle für diese Abfrage verwenden.

Darüber hinaus gilt die gleiche Logik für Abfragen mit Zeitrahmen-Filtern: Eine aggregierte Tabelle kann für eine Abfrage mit einem Zeitrahmen-Filter verwendet werden, solange der Zeitrahmen der aggregierten Tabelle einen feiner (oder gleich) Detaillierungsgrad aufweist wie der in der Explore-Abfrage verwendete Zeitrahmen-Filter. Beispielsweise kann eine aggregierte Tabelle mit der Dimension „Täglicher Zeitrahmen“ für eine Explore-Abfrage verwendet werden, mit der nach Tag, Woche oder Monat gefiltert wird.

Typfaktoren der Messung

Damit für eine Explore-Abfrage eine aggregierte Tabelle verwendet werden kann, müssen die Messwerte in der aggregierten Tabelle genaue Daten für die Explore-Abfrage liefern können.

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

Wenn in einer Explore-Abfrage ein anderer Messwerttyp 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 aggregierten Tabellenabfrage übereinstimmt, wie im Abschnitt Zusammengefasste 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.

Messungen mit unterstützten Messwerttypen

Aggregatfunktionen können für Explore-Abfragen verwendet werden, bei denen Messwerte mit den folgenden Messwerttypen verwendet werden:

Damit eine aggregierte Tabelle für eine Explore-Abfrage verwendet werden kann, muss Looker in der Lage sein, die Messwerte der aggregierten Tabelle zu verarbeiten, um genaue Daten in der Explore-Abfrage bereitzustellen. Beispielsweise kann eine Messung mit type: sum für die Aggregatfunktion verwendet werden, da sich mehrere Summen summieren lassen: Eine zusammengefasste Tabelle mit wöchentlichen Summen kann addiert werden, um eine genaue monatliche Summe zu erhalten. In ähnlicher Weise kann eine Messung mit type: max verwendet werden, weil eine zusammengefasste Tabelle mit Tageshöchstwerten genutzt werden kann, um das genaue wöchentliche Maximum zu ermitteln.

Bei Messungen mit type: average wird Aggregation Awareness unterstützt, da Looker Summen- und Zählungsdaten verwendet, um Durchschnittswerte aus zusammengefassten Tabellen genau abzuleiten.

Mit SQL-Ausdrücken definierte Messungen

Aggregatfunktionen können auch mit Messwerten verwendet werden, die mit Ausdrücken im Parameter sql definiert sind. Wenn sie mit SQL-Ausdrücken definiert sind, werden auch die folgenden Messwerttypen unterstützt:

Aggregatfunktionen werden für Messwerte unterstützt, die als Kombinationen anderer Messwerte definiert sind, wie in diesem Beispiel:

measure: total_revenue_in_dollars {
  type: number
  sql: ${total_revenue_in_dollars} - ${inventory_item.total_cost_in_dollars} ;;
}

Aggregatfunktionen werden auch für Messwerte unterstützt, bei denen Berechnungen im sql-Parameter definiert sind, z. B. diesen Messwert:

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

Aggregierte Bekanntheit wird auch für Messwerte unterstützt, bei denen MIN-, MAX- und COUNT-Vorgänge im sql-Parameter definiert sind, z. B. diesen Messwert:

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

Messungen, die sich auf LookML-Felder beziehen

Wenn sql-Ausdrücke in Messwerten verwendet werden, unterstützt die Aggregatfunktion die folgenden Arten von Feldverweisen:

  • Verweise mit dem Format ${view_name.field_name}, das Felder in anderen Ansichten angibt
  • Verweise mit dem Format ${field_name}, das Felder in derselben Ansicht angibt

Aggregatfunktionen werden nicht für Messwerte unterstützt, die mit dem Format ${TABLE}.column_name definiert sind, das eine Spalte in einer Tabelle angibt. Auf der Dokumentationsseite SQL einbinden und auf LookML-Objekte verweisen finden Sie eine Übersicht zur Verwendung von Referenzen in LookML.

Beispielsweise wird eine mit diesem sql-Parameter definierte Messung in einer zusammengefassten Tabelle nicht unterstützt, da sie das ${TABLE}.column_name-Format verwendet:

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

Wenn Sie diesen Messwert in eine aggregierte Tabelle 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, zum Beispiel so:


 dimension: total_sale_price {
    sql: (${TABLE}.total_sale_price) ;;
  }

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

Jetzt können Sie den Messwert wholesale_value in der aggregierten Tabelle verwenden.

Messungen, die annähernd unterschiedlich viele Werte enthalten

Im Allgemeinen werden unterschiedliche Zahlen für Aggregatfunktionen nicht unterstützt, da Sie damit keine genauen Daten erhalten, wenn Sie versuchen, unterschiedliche Zahlen zu aggregieren. Wenn Sie beispielsweise die einzelnen Nutzer auf einer Website zählen, gibt es möglicherweise einen Nutzer, der die Website zweimal im Abstand von drei Wochen besucht hat. Wenn Sie versuchen, eine wöchentliche zusammengefasste Tabelle anzuwenden, um die monatliche Anzahl einzelner Nutzer auf Ihrer Website zu ermitteln, wird dieser Nutzer in Ihrer monatlichen Abfrage für die eindeutige Anzahl der Nutzer zweimal gezählt und die Daten wären falsch.

Eine Problemumgehung besteht darin, eine aggregierte Tabelle zu erstellen, die genau mit einer Explore-Abfrage übereinstimmt, wie im Abschnitt Zusammengefasste Tabellen erstellen, die genau mit Explore-Abfragen übereinstimmen auf dieser Seite beschrieben. Wenn die Explore-Abfrage und die Abfrage für eine zusammengefasste Tabelle identisch sind, liefern unterschiedliche Zählungsmaße genaue Daten, sodass sie für die Aggregatfunktion verwendet werden können.

Eine weitere Option besteht darin, Näherungswerte für unterschiedliche Anzahlen zu verwenden. Bei Dialekten, die HyperLogLog-Skizzen unterstützen, kann Looker den HyperLogLog-Algorithmus verwenden, um verschiedene Anzahlen für aggregierte Tabellen ungefähr zu bestimmen.

Es ist bekannt, dass der HyperLogLog-Algorithmus einen Fehler von etwa 2% hat. 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 die Messung zu verwenden, damit der Messwert ungefähr aus aggregierten Tabellen berechnet werden kann.

Weitere Informationen und eine Liste der Dialekte, die die unabhängige Erfassung mithilfe von HyperLogLog unterstützen, finden Sie auf der Dokumentationsseite für den 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, sodass Ihre Nutzer Abfrageergebnisse in ihrer eigenen Zeitzone erhalten:

  • Abfrage-Zeitzone: Eine Einstellung, die für alle Abfragen in der Datenbankverbindung gilt. Wenn sich alle Ihre Nutzer in derselben Zeitzone befinden, können Sie eine einzelne Abfragezeitzone festlegen, sodass alle Abfragen von der Datenbankzeitzone in die Zeitzone der Abfrage konvertiert werden.
  • Nutzerspezifische Zeitzonen, in denen Nutzer eigene Zeitzonen zuweisen und 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 Zeitzoneneinstellungen verwenden.

Diese Konzepte sind wichtig für das Verständnis der Aggregatfunktion. Damit eine zusammengefasste 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.

Aggregierte Tabellen verwenden die Datenbankzeitzone, wenn kein timezone-Wert angegeben ist. Die Datenbankverbindung verwendet außerdem die Datenbankzeitzone, wenn eine der folgenden Bedingungen zutrifft:

  • Ihre Datenbank unterstützt keine Zeitzonen.
  • Für die Zeitzone der Abfrage Ihrer Datenbankverbindung ist dieselbe Zeitzone festgelegt wie die Zeitzone der Datenbank.
  • Ihre Datenbankverbindung hat weder eine angegebene Abfragezeitzone noch benutzerspezifische Zeitzonen. In diesem Fall wird für Ihre Datenbankverbindung die Datenbankzeitzone verwendet.

Trifft eine dieser Aussagen zu, können Sie den Parameter timezone für die zusammengefassten Tabellen weglassen.

Andernfalls sollte die Zeitzone der aggregierten Tabelle so definiert werden, dass sie mit möglichen Abfragen übereinstimmt, damit die zusammengefasste Tabelle wahrscheinlicher verwendet wird:

  • Wenn Ihre Datenbankverbindung eine einzelne Abfragezeitzone verwendet, sollten Sie den timezone-Wert der aggregierten Tabelle mit dem Zeitzonenwert der Abfrage abgleichen.
  • Wenn Ihre Datenbankverbindung benutzerspezifische Zeitzonen verwendet, sollten Sie identische aggregierte Tabellen mit jeweils einem anderen timezone-Wert erstellen, um den möglichen Zeitzonen Ihrer Nutzer zu entsprechen.

Faktoren filtern

Seien Sie vorsichtig, wenn Sie Filter in die aggregierte Tabelle aufnehmen. Filter für eine zusammengefasste Tabelle können die Ergebnisse auf den Punkt eingrenzen, an dem die zusammengefasste Tabelle nicht verwendbar ist. Angenommen, Sie erstellen eine zusammengefasste Tabelle für die Anzahl der täglichen Bestellungen und filtern diese nur für Sonnenbrillenbestellungen aus Australien. Wenn ein Benutzer eine Explore-Abfrage für die tägliche Anzahl von Sonnenbrillen weltweit ausführt, kann Looker die aggregierte Tabelle für diese Explore-Abfrage nicht verwenden, da die aggregierte Tabelle nur die Daten für Australien enthält. Die aggregierte Tabelle filtert die Daten zu stark, um von der Explore-Abfrage verwendet zu werden.

Berücksichtigen Sie auch die Filter, die Ihre Looker-Entwickler möglicherweise in Ihr Explore eingebunden haben, z. B.:

  • access_filters: Es werden nutzerspezifische Dateneinschränkungen angewendet.
  • always_filter: Nutzer müssen einen bestimmten Satz von Filtern für eine Explore-Abfrage verwenden. Nutzer 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 auch im explorativen Analysetool definiert ist.

Diese Filtertypen basieren auf bestimmten Feldern. Wenn Ihr Explore diese Filter hat, müssen Sie deren Felder in den Parameter dimensions von aggregate_table aufnehmen.

Hier ist beispielsweise ein Explore mit einem Zugriffsfilter, der auf dem Feld orders.region basiert:

explore: orders {
  access_filter: {
    field: orders.region
    user_attribute: region
  }
}

Zum Erstellen einer aggregierten Tabelle, die für diesen Explore verwendet werden soll, muss die aggregierte Tabelle das Feld enthalten, auf dem der Zugriffsfilter basiert. Im nächsten Beispiel basiert der Zugriffsfilter auf dem Feld orders.region. Dieses 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 eine zusammengefasste Tabelle die Dimension orders.region enthält, kann Looker die Daten in der aggregierten Tabelle dynamisch filtern, damit sie mit dem Filter aus der Explore-Abfrage übereinstimmen. Daher kann Looker weiterhin die aggregierte Tabelle für die Abfragen des Explores verwenden, auch wenn das Explore über einen Zugriffsfilter verfügt.

Das gilt auch für Explore-Abfragen, die eine native abgeleitete Tabelle verwenden, die mit bind_filters konfiguriert ist. Der Parameter bind_filters übergibt bestimmte Filter aus einer Explore-Abfrage an die Unterabfrage der nativen abgeleiteten Tabelle. Wenn für Ihre Explore-Abfrage eine native abgeleitete Tabelle erforderlich ist, in der bind_filters verwendet wird, kann für die Explore-Abfrage nur dann eine zusammengefasste Tabelle verwendet werden, wenn alle Felder im bind_filters-Parameter der nativen abgeleiteten Tabelle exakt dieselben Filterwerte in der Explore-Abfrage haben wie in der aggregierten 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 mit der Explore-Abfrage übereinstimmt. Wenn die Explore-Abfrage und die zusammengefasste Tabelle dieselben Messwerte, Dimensionen, Filter, Zeitzonen und andere Parameter verwenden, werden die Ergebnisse der aggregierten Tabelle standardmäßig auf die Explore-Abfrage angewendet. Wenn eine aggregierte Tabelle eine genaue Übereinstimmung mit einer Explore-Abfrage ist, kann Looker aggregierte Tabellen verwenden, die eine beliebige Art von Messung enthalten.

Sie können eine zusammengefasste Tabelle aus einem Explore erstellen, indem Sie die Option LookML abrufen im Zahnrad-Menü eines Explore verwenden. Sie können auch genaue Übereinstimmungen für alle Kacheln in einem Dashboard erstellen. Verwenden Sie dazu die Option LookML abrufen aus dem Zahnradmenü eines Dashboards.

Bestimmen, welche aggregierte Tabelle für eine Abfrage verwendet wird

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

Basierend auf der zuvor gezeigten Beispieltabelle mit monatlicher Aggregattabelle können Sie z. B. das explorative Analysetool aufrufen und eine Abfrage für die jährlichen Verkaufssummen ausführen. Klicken Sie dann auf den Tab SQL, um die Details der von Looker erstellten Abfrage zu sehen. Wenn Sie sich im Entwicklungsmodus befinden, zeigt Looker Kommentare an, um die zusammengefasste Tabelle anzugeben, die für die Abfrage verwendet wurde.

Aus den folgenden Kommentaren auf dem Tab SQL geht hervor, dass Looker die aggregierte Tabelle sales_monthly für diese Abfrage verwendet. Außerdem sehen wir, warum keine anderen aggregierten Tabellen 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 auf dem Tab SQL sowie Vorschläge zum Beheben dieser Probleme.

Schätzungen zur Berechnung der Einsparungen bei der Bekanntheit insgesamt

Wenn Ihre Datenbankverbindung Kostenschätzungen unterstützt und eine zusammengefasste Tabelle für eine Abfrage verwendet werden kann, zeigt das Fenster „Explore“ die Einsparungen bei der Berechnung, wenn die aggregierte Tabelle anstelle der direkten Abfrage der Datenbank verwendet wird. Die Einsparungen bei der Bekanntheit insgesamt 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 wissen möchten, welche zusammengefasste Tabelle für die Abfrage verwendet wird, klicken Sie auf den Tab SQL, wie im Abschnitt Bestimmen, welche zusammengefasste Tabelle für eine Abfrage verwendet wird auf dieser Dokumentationsseite beschrieben.

Nachdem die Abfrage ausgeführt wurde, wird im Fenster „Explore“ neben der Schaltfläche Run (Ausführen) angezeigt, mit welcher aggregierten Tabelle die Abfrage beantwortet wurde.

Einsparungen bei der Aggregation 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 neue Daten mit aggregierten Tabellen zusammen

Bei aggregierten Tabellen mit Zeitfiltern kann Looker aktuelle Daten in einer zusammengefassten Tabelle zusammenführen. Möglicherweise haben Sie eine zusammengefasste Tabelle, die die Daten der letzten drei Tage enthält, aber diese zusammengefasste Tabelle wurde möglicherweise gestern erstellt. In der aggregierten Tabelle würden die heutigen Informationen fehlen, sodass Sie sie nicht für eine Explore-Abfrage mit den aktuellsten täglichen Informationen verwenden würden.

Looker kann jedoch die Daten in dieser aggregierten Tabelle 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 aggregierten Tabelle verbindet.

Unter folgenden Umständen kann Looker aktuelle Daten mit den Daten Ihrer aggregierten Tabelle zusammenführen:

  • Die zusammengefasste Tabelle verfügt über 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 aggregierte Tabelle gestern erstellt wurde, ruft Looker die neuesten Daten ab, die noch nicht in der aggregierten Tabelle enthalten sind, und führt dann die neuen Ergebnisse mit den Ergebnissen aus der aggregierten Tabelle zusammen. Das bedeutet, dass Ihre Nutzer die neuesten Daten erhalten und gleichzeitig die Leistung mithilfe von Aggregatfunktionen optimieren können.

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

Aggregierte Tabellen müssen dauerhaft gespeichert werden

Damit Aggregatfunktionen für Aggregatfunktionen zugänglich sind, muss die zusammengefasste Tabelle in Ihrer Datenbank persistiert werden. Die Persistenzstrategie wird im Parameter materialization der aggregierten Tabelle angegeben. Da es sich bei aggregierten Tabellen um nichtflüchtige abgeleitete Tabellen (PDT) handelt, gelten für sie dieselben Anforderungen wie für PDTs. Weitere Informationen finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker.

Sie können in Ihrem Projekt inkrementelle PATs erstellen, wenn sie von Ihrem Dialekt unterstützt werden. Looker erstellt inkrementelle PDTs, indem neue Daten an die Tabelle angehängt werden, anstatt die gesamte Tabelle neu zu erstellen. Da aggregierte Tabellen selbst ein PAT-Typ sind, können Sie auch inkrementelle zusammengefasste Tabellen erstellen. Weitere Informationen zu inkrementellen PDTs finden Sie auf der Dokumentationsseite Inkrementelle PDTs. Ein Beispiel für eine inkrementelle zusammengefasste Tabelle finden Sie auf der Dokumentationsseite zum Parameter increment_key.

Ein Nutzer mit der Berechtigung develop kann die Persistenzeinstellungen überschreiben und alle zusammengefassten Tabellen für eine Abfrage neu erstellen, um die aktuellsten Daten zu erhalten. Um die Tabellen für eine Abfrage neu zu erstellen, 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 neu erstellt, die von den Tabellen in der Abfrage abhängig sind. Dazu gehören auch zusammengefasste Tabellen, die selbst eine Art persistenter abgeleiteter Tabelle sind.

Bei dem Nutzer, der die Option Abgeleitete Tabellen neu erstellen und ausführen initiiert, wartet die Abfrage mit dem Laden der Ergebnisse, bis die Tabellen neu erstellt wurden. Bei den Abfragen anderer Nutzer werden weiterhin die vorhandenen Tabellen verwendet. 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 Bestimmen, welche aggregierte Tabelle für eine Abfrage verwendet wird beschrieben, können Sie im Entwicklungsmodus Abfragen im Explore ausführen und auf den Tab SQL klicken, um Kommentare zur aggregierten Tabelle anzuzeigen, die für die Abfrage verwendet wird, falls vorhanden.

Der Tab SQL enthält auch Kommentare dazu, warum aggregierte Tabellen nicht für eine Abfrage verwendet wurden, falls dies der Fall ist. Bei nicht verwendeten aggregierten Tabellen beginnt der Kommentar mit:

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

Im Folgenden finden Sie beispielsweise einen Kommentar dazu, warum die im Explore order_items definierte zusammengefasste Tabelle sales_daily nicht für eine Abfrage verwendet wurde:

-- Did not use order_items::sales_daily; query contained the following filters
that were neither included as fields nor exactly matched by filters in the aggregate table:
order_items.created_year.

In diesem Fall haben die Filter in der Abfrage verhindert, dass die zusammengefasste Tabelle verwendet wurde.

In der folgenden Tabelle finden Sie weitere mögliche Gründe dafür, dass eine zusammengefasste Tabelle nicht verwendet werden kann, sowie Schritte, mit denen Sie die Nutzerfreundlichkeit der zusammengefassten Tabelle verbessern können.

Grund dafür, dass die zusammengefasste Tabelle nicht verwendet wird Erläuterung und mögliche Schritte
Kein solches Feld im Explore vorhanden. Es liegt ein LookML-Validierungstypfehler vor. Das liegt meistens daran, dass die zusammengefasste Tabelle nicht richtig definiert wurde oder im LookML-Code für Ihre zusammengefasste Tabelle ein Tippfehler vorhanden ist. Vermutlich ist ein falscher Feldname o. Ä. der Schuldige.

Um dieses Problem zu beheben, müssen Sie überprüfen, ob die Dimensionen und Messwerte in der zusammengefassten Tabelle mit den Feldnamen im explorativen Analysetool übereinstimmen. Weitere Informationen zum Definieren einer zusammengefassten Tabelle finden Sie auf der Dokumentationsseite für den Parameter aggregate_table.
Die folgenden Felder in der Abfrage sind in der zusammengefassten Tabelle nicht enthalten. Damit eine aggregierte Tabelle für eine Explore-Abfrage verwendet werden kann, muss sie alle Dimensionen und Kennzahlen enthalten, die für diese Explore-Abfrage erforderlich sind, einschließlich der Felder, die in der Explore-Abfrage für Filter verwendet werden. Wenn eine Explore-Abfrage eine Dimension oder einen Messwert enthält, die bzw. der nicht in einer aggregierten Tabelle enthalten ist, kann Looker die aggregierte Tabelle nicht verwenden. Stattdessen wird die Basistabelle verwendet. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Feldfaktoren. Die einzige Ausnahme sind Zeitraumdimensionen, da obere Zeiträume aus engeren Detaillierungsgraden abgeleitet werden können.

Um dieses Problem zu beheben, prüfen Sie, ob die Felder der Explore-Abfrage in der Definition der aggregierten Tabelle enthalten sind.
Die Abfrage enthielt die folgenden Filter, die in der zusammengefassten Tabelle weder als Felder enthalten noch genau mit Filtern übereinstimmen. Die Filter in der Explore-Abfrage verhindern, dass Looker die aggregierte Tabelle verwendet.

Sie haben folgende Möglichkeiten, das Problem zu beheben:
  • Fügen Sie Ihrer aggregierten Tabelle denselben Filter hinzu.
  • Fügen Sie das vom Filter verwendete Feld in die zusammengefasste Tabelle ein.
  • 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 mindestens einen Messwerttyp, der für Aggregatfunktionen nicht unterstützt wird, z. B. distinct count, median oder percentile.

Um dieses Problem zu beheben, prüfen Sie den Typ jeder Messung in der Abfrage und stellen Sie sicher, dass es sich um einen der unterstützten Messwerttypen handelt. Wenn Ihr Explore Joins enthält, stellen Sie außerdem sicher, dass Ihre Messungen nicht über aufgefächerte Joins in verschiedene Messungen (symmetrische Summen) umgewandelt werden. Eine Erläuterung finden Sie im Abschnitt Symmetrische Summen für Explores mit Joins auf dieser Seite.
Eine andere zusammengefasste Tabelle war für die Optimierung besser geeignet. Für die Abfrage waren mehrere brauchbare aggregierte Tabellen vorhanden und Looker hat stattdessen eine optimalere zusammengefasste Tabelle gefunden. In diesem Fall müssen Sie nichts tun.
Looker hat aufgrund eines primary_key- oder cancel_grouping_fields-Parameters keine Gruppierung vorgenommen. Daher kann die Abfrage nicht zusammengefasst werden. Die Abfrage verweist auf eine Dimension, die verhindert, dass sie eine GROUP BY-Klausel enthält. Daher kann Looker keine aggregierte Tabelle für die Abfrage verwenden.

Prüfen Sie, ob der Parameter primary_key der Ansicht und der Parameter cancel_grouping_fields des Explores korrekt eingerichtet sind, um dieses Problem zu beheben.
Die zusammengefasste Tabelle enthielt Filter, die nicht in der Abfrage enthalten waren. Die zusammengefasste Tabelle hat einen Nicht-Zeitfilter, der nicht in der Abfrage enthalten ist.

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

Um dieses Problem zu beheben, entfernen Sie das Feld aus der Liste dimensions der aggregierten Tabelle. Wenn dieses Feld für die zusammengefasste Tabelle benötigt wird, fügen Sie es der Liste filters in der Abfrage der zusammengefassten Tabelle hinzu.
Die Optimierung kann nicht ermitteln, warum die zusammengefasste Tabelle nicht verwendet wurde. Dieser Kommentar ist nur für Sonderfälle vorgesehen. Wenn Sie dies bei einer häufig verwendeten Explore-Abfrage sehen, können Sie eine aggregierte Tabelle erstellen, die genau mit der Explore-Abfrage übereinstimmt. Sie können LookML-Code für zusammengefasste Tabellen ganz einfach aus einem Explore abrufen, wie auf der Parameterseite aggregate_table beschrieben.

Wichtige Punkte

Symmetrische Summen für Explores mit Joins

Wichtig: In einem Explore, das mehrere Datenbanktabellen verknüpft, kann Looker Messwerte vom Typ SUM, COUNT und AVERAGE jeweils als SUM DISTINCT, COUNT DISTINCT bzw. AVERAGE DISTINCT rendern. Looker tut dies, um Fanout-Fehler zu vermeiden. Beispielsweise wird ein Messwert vom Typ count als Messwert vom Typ count_distinct gerendert. Dies dient dazu, Fehlkalkulationen des Fanouts für Joins zu vermeiden, und ist Teil der symmetrischen Aggregatfunktion von Looker. Eine Erläuterung dieser Looker-Funktion finden Sie auf der Seite Best Practices zu symmetrischen Summen.

Die Funktion für symmetrische Aggregatfunktionen verhindert Fehlkalkulationen, kann jedoch in bestimmten Fällen auch verhindern, dass Ihre zusammengefassten Tabellen verwendet werden. Daher ist es wichtig zu verstehen.

Bei den Messtypen, die von der Aggregatfunktion unterstützt werden, gilt dies für sum, count und average. Looker rendert diese Arten von Messungen als DISTINCT, wenn:

  • Die Messung ergibt sich aus der „1“-Ansicht eines m:1-Joins oder eines 1:n-Join.
  • Die Messung ergibt sich aus beiden Ansichten eines m:n-Join.

Eine Erläuterung dieser Join-Typen finden Sie auf der Dokumentationsseite zum Parameter 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 Messwerttypen für ein Explore mit Joins zu verwenden. Weitere Informationen finden Sie im Abschnitt Aggregierte Tabellen erstellen, die genau mit Explore-Abfragen übereinstimmen auf dieser Seite.

Wenn Sie einen SQL-Dialekt haben, 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 wird, kann Looker den Messwert für die Aggregatfunktion verwenden, auch wenn er als separate Anzahl gerendert wird.

Weitere Informationen und eine Liste der SQL-Dialekte, die HyperLogLog-Skizzen unterstützen, finden Sie auf der Dokumentationsseite für den allow_approximate_optimization-Parameter.

Dialektunterstützung für Aggregatfunktion

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

Dialekt Unterstützt?
Lawine Actian
Ja
Amazon Athena
Ja
Amazon Aurora MySQL
Ja
Amazon Redshift
Ja
Apache Druid
Nein
Apache Druid 0.13 und höher
Nein
Apache Druid 0.18 und höher
Nein
Apache Hive 2.3+
Ja
Apache Hive 3.1.2+
Ja
Apache Spark 3 und höher
Ja
ClickHouse
Nein
Cloudera Impala 3.1+
Ja
Cloudera Impala 3.1+ mit nativem Treiber
Ja
Cloudera Impala mit nativem Fahrer
Ja
DataVirtuality
Nein
Databricks
Ja
Denodo 7
Nein
Denodo 8
Nein
Dremio
Nein
Dremio 11+
Nein
Exasol
Ja
Firebolt
Nein
Legacy-SQL von Google BigQuery
Ja
Google BigQuery-Standard-SQL
Ja
Google Cloud PostgreSQL
Ja
Google Cloud SQL
Nein
Google Spanner
Nein
Grünpflaumen
Ja
HyperSQL
Nein
IBM Netezza
Ja
MariaDB
Ja
Microsoft Azure PostgreSQL
Ja
Microsoft Azure SQL-Datenbank
Ja
Microsoft Azure Synapse-Analyse
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 oder höher
Ja
Oracle
Ja
Oracle ADWC
Ja
PostgreSQL 9.5 oder höher
Ja
PostgreSQL vor Version 9.5
Ja
PrestoDB
Ja
PrestoSQL
Ja
SAP HANA 2+
Ja
SingleStore
Ja
SingleStore 7+
Ja
Snowflake
Ja
Teradata
Ja
Trino
Ja
Vektor
Ja
Vertica
Ja

Dialektunterstützung für das inkrementelle Erstellen aggregierter Tabellen

Damit Looker inkrementelle aggregierte Tabellen in Ihrem Looker-Projekt unterstützen kann, müssen diese auch von Ihrem Datenbankdialekt unterstützt werden. Die folgende Tabelle zeigt, welche Dialekte die inkrementelle Erstellung von PDTs in der neuesten Version von Looker unterstützen:

Dialekt Unterstützt?
Lawine Actian
Nein
Amazon Athena
Nein
Amazon Aurora MySQL
Nein
Amazon Redshift
Ja
Apache Druid
Nein
Apache Druid 0.13 und höher
Nein
Apache Druid 0.18 und höher
Nein
Apache Hive 2.3+
Nein
Apache Hive 3.1.2+
Nein
Apache Spark 3 und höher
Nein
ClickHouse
Nein
Cloudera Impala 3.1+
Nein
Cloudera Impala 3.1+ mit nativem Treiber
Nein
Cloudera Impala mit nativem Fahrer
Nein
DataVirtuality
Nein
Databricks
Ja
Denodo 7
Nein
Denodo 8
Nein
Dremio
Nein
Dremio 11+
Nein
Exasol
Nein
Firebolt
Nein
Legacy-SQL von Google BigQuery
Nein
Google BigQuery-Standard-SQL
Ja
Google Cloud PostgreSQL
Ja
Google Cloud SQL
Nein
Google Spanner
Nein
Grünpflaumen
Ja
HyperSQL
Nein
IBM Netezza
Nein
MariaDB
Nein
Microsoft Azure PostgreSQL
Ja
Microsoft Azure SQL-Datenbank
Nein
Microsoft Azure Synapse-Analyse
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 oder höher
Ja
Oracle
Nein
Oracle ADWC
Nein
PostgreSQL 9.5 oder höher
Ja
PostgreSQL vor Version 9.5
Ja
PrestoDB
Nein
PrestoSQL
Nein
SAP HANA 2+
Nein
SingleStore
Nein
SingleStore 7+
Nein
Snowflake
Ja
Teradata
Nein
Trino
Nein
Vektor
Nein
Vertica
Ja