Beachten Sie, dass Sie sich gerade die Looker-Dokumentation ansehen. Die Looker Studio-Dokumentation finden Sie unter https://support.google.com/looker-studio.

Diese Seite wurde von der Cloud Translation API übersetzt.

Aggregatfunktion

Überblick

Looker verwendet Aggregate-Awareness-Logik, um die kleinste, effizienteste Tabelle in Ihrer Datenbank zu finden, die zur Ausführung einer Abfrage unter Beibehaltung der Genauigkeit verwendet wird.

Für sehr große Tabellen in Ihrer Datenbank können Looker-Entwickler kleinere zusammengefasste Datentabellen erstellen, die nach verschiedenen Kombinationen von Attributen gruppiert sind. Die aggregierten Tabellen fungieren als Sammel- oder Zusammenfassungstabellen, die Looker anstelle der ursprünglichen großen Tabelle nach Möglichkeit für Abfragen verwenden kann. Bei strategischer Umsetzung kann Aggregate Awareness die durchschnittliche Abfrage um eine Größenordnung beschleunigen.

Angenommen, Sie haben eine Datentabelle im Petabytebereich mit einer Zeile für jede Bestellung auf Ihrer Website. Aus dieser Datenbank können Sie eine zusammengefasste Tabelle mit Ihren täglichen Gesamtverkäufen erstellen. Wenn Ihre Website 1.000 Bestellungen pro Tag erhält, würde die aggregierte Tabelle für jeden Tag 999 Zeilen weniger Zeilen umfassen als in der ursprünglichen Tabelle. Sie können eine weitere zusammengefasste Tabelle mit den Gesamtumsatz pro Monat erstellen, die noch effizienter ist. Wenn nun ein Benutzer eine Abfrage für den täglichen oder wöchentlichen Umsatz ausführt, verwendet Looker die Tabelle mit dem Gesamtumsatz des Tages. Wenn ein Benutzer eine Abfrage zum Jahresumsatz ausführt und Sie keine Tabelle für jährliche aggregierte Daten haben, verwendet Looker die nächstbeste Tabelle, die in diesem Beispiel die aggregierte Tabelle für den monatlichen Umsatz ist.

Looker beantwortet die Fragen Ihrer Benutzer nach Möglichkeit immer 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 der Gesamtsumme jedes Verkaufs an einem Tag gibt es keine aggregierte Tabelle mit dieser Detaillierungsgrad. 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 dafür eine aggregierte Tabelle erstellen.
Für eine Abfrage zu wöchentlichen Umsätzen gibt es keine wöchentliche aggregierte Tabelle. Daher verwendet Looker die zweitbeste Variante, nämlich die aggregierte Tabelle auf Grundlage der täglichen Verkäufe (sales_daily_aggregate_table).

Mithilfe der Logik zur Aggregierung des Bewusstseins fragt Looker die kleinstmögliche aggregierte Tabelle ab, um die Fragen Ihrer Benutzer zu beantworten. Die ursprüngliche Tabelle wird nur für Abfragen verwendet, die eine höhere Detailgenauigkeit erfordern, als die zusammengefassten Tabellen bieten.

Aggregierte Tabellen müssen nicht mit einem separaten Explore verknüpft oder diesem hinzugefügt werden. Stattdessen passt Looker die FROM-Klausel der Explore-Abfrage dynamisch an, um auf die beste aggregierte Tabelle für die Abfrage zuzugreifen. Das bedeutet, dass Ihre Drilldown-Vorgänge beibehalten und Explores konsolidiert werden können. Mit der Aggregatfunktion kann ein einziges 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 bei Tiles, die große Datensätze abfragen. Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter aggregate_table im Abschnitt LookML-Code für aggregierte Tabellen aus einem Dashboard abrufen.

Ihrem Projekt zusammengefasste Tabellen hinzufügen

Looker-Entwickler können strategische aggregierte Tabellen erstellen, die die Anzahl der Abfragen minimieren, die für die großen Tabellen in einer Datenbank erforderlich sind. Aggregierte Tabellen müssen in Ihrer Datenbank persistiert werden, damit sie für die Aggregatfunktion zugänglich sind. Aggregierte Tabellen sind daher eine Art von persistenter abgeleiteter Tabelle (Persistent Derived Table, PDT).

Eine zusammengefasste Tabelle wird mithilfe des Parameters aggregate_table unter dem Parameter explore 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
}

Wenn Sie eine aggregierte Tabelle erstellen möchten, können Sie den LookML-Code komplett neu schreiben oder aus einem Explore oder in einem Dashboard eine LookML für die aggregierte Tabelle abrufen. Auf der Dokumentationsseite zum Parameter aggregate_table finden Sie weitere Informationen zum Parameter aggregate_table und seinen Unterparametern.

Aggregierte Tabellen entwerfen

Damit eine Explore-Abfrage eine aggregierte Tabelle verwendet, muss die aggregierte Tabelle genaue Daten für die Explore-Abfrage liefern können. Looker kann eine aggregierte Tabelle für eine Explore-Abfrage verwenden, wenn die folgenden Bedingungen erfüllt sind:

Die Felder der Explore-Abfrage sind eine Teilmenge der Felder der aggregierten Tabelle. Weitere Informationen finden Sie im Abschnitt Feldfaktoren auf dieser Seite. Bei Zeitrahmen können die Zeitrahmen der Explore-Abfrage aus den Zeitrahmen in der aggregierten Tabelle abgeleitet werden (siehe Abschnitt Zeitrahmenfaktoren auf dieser Seite).
Die Explore-Abfrage enthält Messwerttypen, die von der Aggregatfunktion unterstützt werden (siehe Abschnitt Typfaktoren messen auf dieser Seite), oder die Explore-Abfrage hat eine aggregierte Tabelle, die genau übereinstimmt (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. Weitere Informationen finden Sie im 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. Weitere Informationen hierzu finden Sie im 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 zusammengefasste Tabelle für eine Explore-Abfrage verwendet werden kann, muss sie alle Dimensionen und Messwerte enthalten, die für diese Explore-Abfrage erforderlich sind, einschließlich der Felder, die für Filter in der Explore-Abfrage verwendet werden. Wenn eine Explore-Abfrage eine Dimension oder einen Messwert enthält, die bzw. der sich nicht in einer aggregierten Tabelle befindet, kann Looker die aggregierte Tabelle nicht verwenden und verwendet stattdessen die Basistabelle.

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

Die zusammengefasste Tabelle kann auch andere Felder enthalten, muss aber mindestens die Explore-Abfragefelder enthalten, damit sie für die Optimierung geeignet ist. Die einzige Ausnahme sind Zeitraumdimensionen, da Zeiträume mit gröberem Detaillierungsgrad von feineren Zeiträumen abgeleitet werden können.

Aufgrund dieser Feldüberlegungen ist eine zusammengefasste Tabelle spezifisch für das Explore, unter dem sie definiert ist. Eine unter einem Explore definierte aggregierte Tabelle wird nicht für Abfragen in einem anderen Explore verwendet.

Faktoren für den Zeitrahmen

Lookers Logik zur Aggregierung des Bewusstseins ist in der Lage, einen Zeitrahmen von einem anderen abzuleiten. Eine aggregierte Tabelle kann für eine Abfrage verwendet werden, solange der Zeitrahmen der aggregierten Tabelle eine feinere (oder gleichwertige) Detailgenauigkeit als die Explore-Abfrage hat. So kann beispielsweise eine aggregierte Tabelle, die auf täglichen Daten basiert, für eine Explore-Abfrage verwendet werden, die andere Zeitrahmen anfordert, z. B. Abfragen für Tages-, Monats- und Jahresdaten oder sogar Daten für den Tag des Monats, den Tag und die Woche. Eine jährlich aggregierte Tabelle kann jedoch nicht für eine Explore-Abfrage verwendet werden, die stündliche Daten anfordert, da die Daten der aggregierten Tabelle für die Explore-Abfrage nicht detailliert genug sind.

Dasselbe gilt für Zeitbereich-Teilmengen. Wenn Sie beispielsweise eine zusammengefasste Tabelle haben, die nach den letzten drei Monaten gefiltert wird, und ein Benutzer 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 Zeitraumfiltern: Eine aggregierte Tabelle kann für eine Abfrage mit einem Zeitrahmenfilter verwendet werden, solange der Zeitrahmen der aggregierten Tabelle eine feinere (oder gleichwertige) Granularität hat als der in der Explore-Abfrage verwendete Zeitrahmenfilter. Beispielsweise kann eine zusammengefasste Tabelle mit der Dimension „Täglicher Zeitraum“ für eine Explore-Abfrage verwendet werden, die nach Tag, Woche oder Monat filtert.

Faktoren des Messwerttyps

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

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

Messungen mit unterstützten Messwerttypen
Durch SQL-Ausdrücke definierte Messwerte
Nicht mit ${TABLE} definierte Messwerte
Messungen, die eine ungefähre Anzahl unterschiedlicher Zahlen aufweisen

Wenn bei einer Explore-Abfrage ein anderer Messwert verwendet wird, verwendet Looker die ursprüngliche Tabelle und nicht die zusammengefasste Tabelle, um Ergebnisse zurückzugeben. Die einzige Ausnahme ist, wenn die Explore-Abfrage eine genaue Übereinstimmung mit einer Abfrage für aggregierte Tabellen darstellt, 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.

Messungen mit unterstützten Messwerttypen

Aggregate Awareness kann für Explore-Abfragen verwendet werden, die Messwerte mit den folgenden Messwerttypen verwenden:

Um eine aggregierte Tabelle für eine Explore-Abfrage zu verwenden, muss Looker in der Lage sein, die Messwerte der aggregierten Tabelle zu verarbeiten, um genaue Daten in der Explore-Abfrage zu liefern. Beispielsweise kann ein Messwert mit type: sum für die Aggregatfunktion verwendet werden, weil Sie mehrere Summen summieren können: Eine aggregierte Tabelle mit wöchentlichen Summen kann addiert werden, um eine genaue monatliche Summe zu erhalten. In ähnlicher Weise kann ein Messwert mit type: max verwendet werden, da sich das genaue wöchentliche Maximum anhand einer aggregierten Tabelle mit Tageshöchstwerten ermitteln lässt.

Bei Messwerten mit type: average wird die Aggregatfunktion unterstützt, da Looker Summen- und Zählungsdaten verwendet, um Durchschnittswerte genau aus aggregierten Tabellen abzuleiten.

Mit SQL-Ausdrücken definierte Messwerte

Aggregate Awareness kann auch mit Messwerten verwendet werden, die mit Ausdrücken im sql-Parameter definiert sind. Bei der Definition mit SQL-Ausdrücken werden auch die folgenden Messwerttypen unterstützt:

Aggregate Awareness wird für Messwerte unterstützt, die als Kombinationen anderer Kennzahlen definiert sind, wie in diesem Beispiel:

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

Die Aggregatfunktion wird auch für Messungen unterstützt, bei denen Berechnungen im sql-Parameter definiert sind, z. B. bei diesem Messwert:

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

Und Aggregate Awareness wird für Messwerte unterstützt, bei denen MIN-, MAX- und COUNT-Vorgänge im sql-Parameter definiert sind, wie z. B. dieser Messwert:

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

Messungen, die auf LookML-Felder verweisen

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

Referenzen im Format ${view_name.field_name}, das Felder in anderen Ansichten angibt
Verweise im 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. Eine Übersicht über die Verwendung von Referenzen in LookML finden Sie auf der Dokumentationsseite SQL einbinden und auf LookML-Objekte verweisen.

Beispielsweise würde ein mit diesem sql-Parameter definierter Messwert in einer zusammengefassten Tabelle nicht unterstützt werden, 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 zusammengefasste Tabelle aufnehmen möchten, können Sie stattdessen eine mit dem Format ${TABLE}.column_name definierte Dimension und dann einen Messwert erstellen, der auf die Dimension verweist:


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

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

Jetzt können Sie den Messwert wholesale_value in Ihrer zusammengefassten Tabelle verwenden.

Ungefähre Anzahl unterschiedlicher Messwerte

Im Allgemeinen werden eindeutige Zählungen beim Aggregate Awareness nicht unterstützt, da Sie keine genauen Daten erhalten können, wenn Sie versuchen, unterschiedliche Zählungen zu aggregieren. Wenn Sie beispielsweise die verschiedenen Nutzer auf einer Website zählen, könnte es einen Nutzer geben, der die Website zweimal im Abstand von drei Wochen besucht hat. Wenn Sie versuchen, eine wöchentliche aggregierte Tabelle anzuwenden, um die monatliche Anzahl verschiedener Nutzer auf Ihrer Website zu erhalten, würde dieser Nutzer in Ihrer monatlichen Abfrage für eindeutige Zählungen zweimal gezählt werden und die Daten wären falsch.

Eine Umgehung dieses Problems besteht darin, eine zusammengefasste Tabelle zu erstellen, die genau mit einer Explore-Abfrage übereinstimmt, wie im Abschnitt Aggregierte Tabellen erstellen, die genau mit Explore-Abfragen übereinstimmen auf dieser Seite beschrieben wird. Wenn die Explore-Abfrage und eine Abfrage einer aggregierten Tabelle identisch sind, liefern unterschiedliche Zählwerte genaue Daten, sodass sie für die Aggregatfunktion verwendet werden können.

Eine weitere Möglichkeit besteht darin, Näherungswerte für eindeutige Zählungen zu verwenden. Bei Dialekten, die HyperLogLog-Skizzen unterstützen, kann Looker den HyperLogLog-Algorithmus nutzen, um die eindeutigen Zählungen für aggregierte Tabellen zu schätzen.

Der Algorithmus HyperLogLog weist bekanntermaßen einen Fehler von etwa 2% auf. Mit dem 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 der Messwert ungefähr aus aggregierten Tabellen berechnet werden kann.

Weitere Informationen und eine Liste der Dialekte, die die Zählung unterschiedlicher Dialekte mithilfe von 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 koordinierten Weltzeit UTC. Looker bietet mehrere Optionen zum Konvertieren von Zeitzonen, sodass Ihre Nutzer Abfrageergebnisse in ihrer eigenen Zeitzone erhalten:

Abfragezeitzone: Eine Einstellung, die für alle Abfragen der Datenbankverbindung gilt. Wenn sich alle Ihre Nutzer in der gleichen Zeitzone befinden, können Sie eine einzelne Abfragezeitzone festlegen, sodass alle Abfragen von der Datenbankzeitzone in die Abfragezeitzone konvertiert werden.
Nutzerspezifische Zeitzonen, in denen Nutzern Zeitzonen zugewiesen werden können und diese individuell ausgewählt werden 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, denn damit eine aggregierte Tabelle für eine Abfrage mit Datumsdimensionen oder Datumsfiltern verwendet werden kann, muss die Zeitzone in der zusammengefassten Tabelle mit der Zeitzoneneinstellung der ursprünglichen Abfrage übereinstimmen.

Aggregierte Tabellen verwenden die Datenbankzeitzone, wenn kein timezone-Wert angegeben ist. Für die Datenbankverbindung wird auch die Zeitzone der Datenbank verwendet, wenn eine der folgenden Bedingungen zutrifft:

Ihre Datenbank unterstützt keine Zeitzonen.
Die Abfragezeitzone Ihrer Datenbankverbindung ist auf dieselbe Zeitzone wie die Datenbankzeitzone festgelegt.
Für Ihre Datenbankverbindung sind weder eine Zeitzone für Abfragen noch benutzerspezifische Zeitzonen angegeben. In diesem Fall wird für die Datenbankverbindung die Zeitzone der Datenbank verwendet.

Wenn eine dieser Aussagen zutrifft, können Sie den timezone-Parameter für Ihre zusammengefassten Tabellen weglassen.

Andernfalls sollte die Zeitzone der aggregierten Tabelle so definiert werden, dass sie den möglichen Abfragen entspricht, damit die zusammengefasste Tabelle eher verwendet wird:

Wenn Ihre Datenbankverbindung nur eine Zeitzone für Abfragen verwendet, sollten Sie den timezone-Wert der aggregierten Tabelle mit dem Zeitzonenwert der Abfrage abgleichen.
Wenn Ihre Datenbankverbindung nutzerspezifische Zeitzonen verwendet, sollten Sie identische aggregierte Tabellen erstellen, die jeweils einen anderen timezone-Wert haben, um den möglichen Zeitzonen der Nutzer zu entsprechen.

Filterfaktoren

Gehen Sie mit Bedacht vor, wenn Sie Filter in Ihre aggregierte Tabelle einfügen. Durch Filter für eine aggregierte Tabelle können die Ergebnisse auf den Punkt beschränkt werden, an dem die aggregierte Tabelle unbrauchbar ist. Angenommen, Sie erstellen eine aggregierte Tabelle für die tägliche Anzahl der Bestellungen und die aggregierte Tabelle filtert nur nach 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 nicht für diese Explore-Abfrage verwenden, da die aggregierte Tabelle nur die Daten für Australien enthält. In der zusammengefassten Tabelle werden die Daten zu eng gefiltert, um von der Explore-Abfrage verwendet zu werden.

Berücksichtigen Sie auch die Filter, die Ihre Looker-Entwickler möglicherweise in Ihr Explore integriert haben, wie zum Beispiel:

access_filters: Es werden nutzerspezifische Dateneinschränkungen angewendet.
always_filter: Nutzer müssen eine bestimmte Gruppe von Filtern in eine Explore-Abfrage einbinden. Nutzer können den Standardfilterwert für ihre Abfrage ändern, den Filter jedoch 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 über diese Filter verfügt, müssen Sie die entsprechenden Felder in den dimensions-Parameter von 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
  }
}

Um eine zusammengefasste Tabelle für diesen Explore zu erstellen, muss die zusammengefasste Tabelle das Feld enthalten, auf dem der Zugriffsfilter basiert. Im nächsten Beispiel basiert der Zugriffsfilter auf dem Feld orders.region. Dieses Feld ist 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 der aggregierten Tabelle die Dimension orders.region enthält, kann Looker die Daten in der aggregierten Tabelle dynamisch so filtern, dass sie mit dem Filter der Explore-Abfrage übereinstimmen. Daher kann Looker weiterhin die aggregierte Tabelle für die Abfragen des Explores verwenden, obwohl das Explore über einen Zugriffsfilter verfügt.

Dies gilt auch für Explore-Abfragen, die eine native abgeleitete Tabelle verwenden, die mit bind_filters konfiguriert wurde. Der Parameter bind_filters übergibt angegebene Filter aus einer Explore-Abfrage an die Unterabfrage der nativen abgeleiteten Tabelle. Im Fall der Aggregatfunktion: Wenn Ihre Explore-Abfrage eine native abgeleitete Tabelle erfordert, die bind_filters verwendet, kann die Explore-Abfrage nur dann eine aggregierte Tabelle verwenden, wenn alle Felder im bind_filters-Parameter der nativen abgeleiteten Tabelle dieselben Filterwerte in der Explore-Abfrage wie in der aggregierten Tabelle haben.

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 aggregierte Tabelle dieselben Messwerte, Dimensionen, Filter, Zeitzonen und andere Parameter verwenden, werden die Ergebnisse der aggregierten Tabelle per Definition auf die Explore-Abfrage angewendet. Wenn eine aggregierte Tabelle eine genaue Übereinstimmung mit einer Explore-Abfrage ist, kann Looker aggregierte Tabellen verwenden, die beliebige Arten von Messwerten enthalten.

Sie können eine aggregierte Tabelle aus einem Explore erstellen, indem Sie im Zahnrad-Menü eines Explores die Option LookML abrufen verwenden. Sie können auch genaue Übereinstimmungen für alle Tiles in einem Dashboard erstellen, indem Sie im Zahnrad-Menü eines Dashboards die Option LookML abrufen verwenden.

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

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

Basierend auf der zuvor gezeigten Beispieltabelle für die monatliche Zusammenfassung können Sie beispielsweise das explorative Analysetool aufrufen und eine Abfrage für die gesamten Jahresumsätze ausführen. Anschließend können Sie auf den Tab SQL klicken, um die Details der von Looker erstellten Abfrage aufzurufen. Im Entwicklungsmodus zeigt Looker Kommentare an, um die aggregierte Tabelle anzugeben, die für die Abfrage verwendet wurde.

Den folgenden Kommentaren auf dem Tab SQL können Sie entnehmen, dass Looker die aggregierte Tabelle sales_monthly für diese Abfrage verwendet. Außerdem werden Informationen dazu angezeigt, 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, die auf dem Tab SQL angezeigt werden können, sowie Vorschläge zur Behebung dieses Problems.

Schätzungen der Computereinsparungen für die allgemeine Bekanntheit

Wenn Ihre Datenbankverbindung Kostenschätzungen unterstützt und eine aggregierte Tabelle für eine Abfrage verwendet werden kann, zeigt das Explore-Fenster die Kosteneinsparungen an, die durch die Verwendung der aggregierten Tabelle anstelle einer direkten Abfrage der Datenbank entstehen. Die Einsparungen bei der aggregierten 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 aggregierte Tabelle für die Abfrage verwendet wird, klicken Sie auf den Tab SQL, wie im Abschnitt Bestimmen, welche aggregierte Tabelle für eine Abfrage verwendet wird auf dieser Dokumentationsseite beschrieben.

Nachdem die Abfrage ausgeführt wurde, wird im Explore-Fenster neben der Schaltfläche Ausführen angezeigt, welche aggregierte Tabelle zum Beantworten der Abfrage verwendet wurde.

Die Einsparungen durch aggregierte Bekanntheit werden für Datenbankverbindungen angezeigt, für die Kostenschätzungen aktiviert sind. Weitere Informationen finden Sie auf der Dokumentationsseite Daten in Looker erkunden .

Looker führt neue Daten in aggregierten Tabellen zusammen

Bei aggregierten Tabellen mit Zeitfiltern kann Looker neue Daten zusammen mit Ihrer aggregierten Tabelle zusammenführen. Möglicherweise haben Sie eine aggregierte Tabelle, die die Daten der letzten drei Tage enthält, aber diese aggregierte 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 zu den neuesten täglichen Informationen verwenden würden.

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

Unter den folgenden Umständen kann Looker neue 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 immer die neuesten Daten erhalten und gleichzeitig die Leistung mithilfe von Aggregatfunktionen optimieren kann.

Wenn Sie sich im Entwicklungsmodus befinden, können Sie in einem Explore auf den Tab SQL klicken, um die aggregierte Tabelle zu sehen, die Looker für die Abfrage verwendet hat, und die UNION-Anweisung, die Looker verwendet hat, um neuere Daten einzubinden, die nicht in der aggregierten Tabelle enthalten waren.

Aggregierte Tabellen müssen dauerhaft gespeichert werden

Damit die aggregierte Tabelle für die Aggregatfunktion zugänglich ist, muss sie in Ihrer Datenbank persistiert werden. Die Persistenzstrategie wird im Parameter materialization der zusammengefassten Tabelle angegeben. Da es sich bei aggregierten Tabellen um eine Art persistenter abgeleiteter Tabelle (PDT) handelt, haben zusammengefasste Tabellen die gleichen Anforderungen wie PDTs. Weitere Informationen finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker.

Sie können in Ihrem Projekt inkrementelle PDTs 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 eine Art von 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 aggregierte Tabelle finden Sie auf der Dokumentationsseite zum Parameter increment_key.

Ein Nutzer mit der Berechtigung develop kann die Persistenzeinstellungen überschreiben und alle aggregierten Tabellen für eine Abfrage neu erstellen, um die neuesten Daten zu erhalten. Um die Tabellen für eine Abfrage neu zu erstellen, wählen Sie im Zahnrad-Menü Explore-Aktionen die Option Abgeleitete Tabellen neu erstellen und ausführen aus.

Diese Option ist erst verfügbar, wenn die Explore-Abfrage geladen wurde.

Mit der Option Abgeleitete Tabellen neu erstellen und ausführen werden alle abgeleiteten Tabellen, auf die in der Abfrage verwiesen wird, sowie alle abgeleiteten Tabellen, von denen die Tabellen in der Abfrage abhängig sind, neu erstellt. Dies gilt auch für zusammengefasste Tabellen, die selbst eine Art persistenter abgeleiteter Tabelle sind.

Für den Nutzer, der die Option Abgeleitete Tabellen neu erstellen und ausführen initiiert, wartet die Abfrage, bis die Tabellen neu erstellt wurden, bevor die Ergebnisse geladen werden. Abfragen anderer Benutzer verwenden weiterhin die vorhandenen 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 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 gegebenenfalls Kommentare zur für die Abfrage verwendeten aggregierten Tabelle anzuzeigen.

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

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

Im Folgenden finden Sie beispielsweise 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 verhinderten die Filter in der Abfrage, dass die aggregierte Tabelle verwendet wurde.

Die folgende Tabelle enthält weitere mögliche Gründe dafür, dass eine aggregierte Tabelle nicht verwendet werden kann, sowie Schritte, mit denen Sie die Nutzerfreundlichkeit der aggregierten Tabelle verbessern können.

Grund für die Nichtverwendung der zusammengefassten Tabelle	Erläuterung und mögliche Schritte
Kein entsprechendes Feld im Explore vorhanden.	Es ist ein LookML-Validierungstypfehler aufgetreten. Dies liegt meist daran, dass die aggregierte Tabelle nicht korrekt definiert wurde oder dass der LookML-Code für die aggregierte Tabelle einen Tippfehler enthielt. Ein wahrscheinlicher Schuldner ist ein falscher Feldname oder Ähnliches. Um dieses Problem zu beheben, überprüfen Sie, ob die Dimensionen und Messwerte in der zusammengefassten Tabelle mit den Feldnamen im Explore übereinstimmen. Weitere Informationen zum Definieren einer aggregierten Tabelle finden Sie auf der Dokumentationsseite zum Parameter `aggregate_table`.
Die folgenden Felder sind in der Abfrage nicht in der zusammengefassten Tabelle enthalten.	Damit eine zusammengefasste Tabelle für eine Explore-Abfrage verwendet werden kann, muss sie alle Dimensionen und Messwerte enthalten, die für diese Explore-Abfrage erforderlich sind, einschließlich der Felder, die für Filter in der Explore-Abfrage verwendet werden. Wenn eine Explore-Abfrage eine Dimension oder einen Messwert enthält, die bzw. der sich nicht in einer aggregierten Tabelle befindet, kann Looker die aggregierte Tabelle nicht verwenden und verwendet stattdessen die Basistabelle. Weitere Informationen finden Sie im Abschnitt Feldfaktoren auf dieser Seite. Die einzige Ausnahme sind Zeitraumdimensionen, da Zeiträume mit gröberem Detaillierungsgrad von feineren Zeiträumen abgeleitet werden können. Um dieses Problem zu lösen, überprüfen Sie, ob die Felder der Explore-Abfrage in der Definition der aggregierten Tabelle enthalten sind.
Die Abfrage enthielt die folgenden Filter, die weder als Felder enthalten waren noch exakt mit den Filtern in der zusammengefassten Tabelle ü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 Ihrer aggregierten Tabelle denselben Filter hinzu. Fügen Sie das vom Filter verwendete Feld zu Ihrer zusammengefasste Tabelle hinzu. Entfernen Sie die Filter aus der Explore-Abfrage. Weitere Informationen finden Sie im Abschnitt Filterfaktoren auf dieser Seite.
Die Abfrage enthält die folgenden Kennzahlen, die nicht zusammengefasst werden können.	Die Abfrage enthält einen oder mehrere Messwerttypen, die für die Aggregatfunktion nicht unterstützt werden, z. B. distinct count, median oder Perzentil. Um dieses Problem zu beheben, prüfen Sie den Typ jedes Messwerts in der Abfrage und achten Sie darauf, dass er zu den unterstützten Messwerttypen gehört. Wenn Ihr Explore Joins hat, achten Sie außerdem darauf, dass Ihre Messwerte nicht durch ausfächerte Joins in verschiedene Maße (symmetrische Summen) umgewandelt werden. Eine Erklärung finden Sie im Abschnitt Symmetrische Aggregatfunktionen für Explores mit Joins auf dieser Seite.
Eine andere zusammengefasste Tabelle eignete sich besser für die Optimierung.	Es gab mehrere brauchbare aggregierte Tabellen für die Abfrage und Looker fand eine optimalere aggregierte Tabelle, die stattdessen verwendet werden konnte. In diesem Fall müssen Sie nichts weiter tun.
Looker hat aufgrund eines `primary_key`- oder `cancel_grouping_fields`-Parameters keine Gruppierung durchgeführt, 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. Um dieses Problem zu beheben, prüfen Sie, ob der Parameter `primary_key` der Ansicht und der Parameter `cancel_grouping_fields` des Explores korrekt eingerichtet sind.
Die aggregierte 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 im Abschnitt Filterfaktoren auf dieser Seite.
Ein Feld ist in der Explore-Abfrage als reines Filterfeld definiert, wird aber im Parameter `dimensions` der zusammengefassten Tabelle aufgelistet.	Der Parameter `dimensions` der aggregierten Tabelle enthält ein Feld, das in der Explore-Abfrage nur als `filter`-Feld definiert ist. Entfernen Sie das Feld aus der Liste `dimensions` der aggregierten Tabelle, um dieses Problem zu beheben. Wenn dieses Feld für die aggregierte Tabelle benötigt wird, fügen Sie es der `filters`-Liste in der Abfrage der aggregierten Tabelle hinzu.
Das Optimierungstool kann nicht ermitteln, warum die zusammengefasste Tabelle nicht verwendet wurde.	Dieser Kommentar ist für Sonderfälle vorgesehen. Wenn Sie dies bei einer häufig verwendeten Explore-Abfrage feststellen, können Sie eine zusammengefasste Tabelle erstellen, die genau mit der Explore-Abfrage übereinstimmt. Sie können LookML-Code für aggregierte Tabellen ganz einfach aus einem Explore abrufen, wie auf der Parameterseite `aggregate_table` beschrieben.

Wichtige Punkte

Symmetrische Zusammenfassungen für Explores mit Joins

Beachten Sie, dass Looker in einem Explore, das mehrere Datenbanktabellen verknüpft, Messwerte vom Typ SUM, COUNT und AVERAGE als SUM DISTINCT, COUNT DISTINCT bzw. AVERAGE DISTINCT rendern kann. Looker tut dies, um Fanout-Fehlkalkulationen zu vermeiden. Ein Messwert count wird beispielsweise als Messwerttyp count_distinct gerendert. Dadurch sollen Fanout-Fehlkalkulationen für Joins vermieden werden und die Funktion ist Teil der Looker-Funktion für symmetrische Summen. Auf der Seite Best Practices zu symmetrischen Summen wird diese Funktion von Looker erläutert.

Die Funktion der symmetrischen Aggregatfunktionen verhindert Fehlberechnungen, kann aber auch verhindern, dass Ihre aggregierten Tabellen in bestimmten Fällen verwendet werden. Daher ist es wichtig, dies zu verstehen.

Für die Messwerttypen, die vom Aggregate Awareness unterstützt werden, gilt dies für sum, count und average. Looker gibt diese Arten von Messwerten als DISTINCT aus, wenn:

Der Messwert stammt aus der Eins-Ansicht eines n:1-Join oder 1:n-Join.
Der Messwert wird aus einer der beiden Ansichten eines m:n-Join erstellt.

Eine Erläuterung dieser Join-Typen finden Sie auf der Dokumentationsseite zum Parameter relationship.

Wenn Sie feststellen, dass Ihre zusammengefasste Tabelle aus diesem Grund nicht verwendet wird, können Sie eine zusammengefasste Tabelle erstellen, die genau 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 auch den Parameter allow_approximate_optimization: yes hinzufügen. Wenn ein Messwert für die Anzahl mit allow_approximate_optimization: yes definiert ist, kann Looker den Messwert für die Aggregatfunktion verwenden, auch wenn er als separate Anzahl gerendert wird.

Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter allow_approximate_optimization. Dort finden Sie auch eine Liste der SQL-Dialekte, die HyperLogLog-Skizzen unterstützen.

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 Aggregate Awareness:

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

Dialektunterstützung für die inkrementelle Erstellung 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?
Actian Lawine	Nein
Amazon Athena	Nein
Amazon Aurora MySQL	Nein
Amazon Redshift	Yes
Druid	Nein
Apache Druid 0.13+	Nein
Apache Druid 0.18+	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+ mit nativem Treiber	Nein
Cloudera Impala mit nativem Treiber	Nein
DataVirtuality	Nein
Databricks	Yes
Denodo 7	Nein
Denodo 8	Nein
Dremio	Nein
Dremio 11+	Nein
Exasol	Nein
Firebolt	Nein
Google BigQuery Legacy-SQL	Nein
Google BigQuery-Standard-SQL	Yes
Google Cloud PostgreSQL	Yes
Google Cloud SQL	Nein
Google Spanner	Nein
Greenplum	Yes
HyperSQL	Nein
IBM Netezza	Nein
MariaDB	Nein
Microsoft Azure PostgreSQL	Yes
Microsoft Azure SQL-Datenbank	Nein
Microsoft Azure Synapse-Analyse	Yes
Microsoft SQL Server 2008 oder 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	Yes
MySQL 8.0.12 und höher	Yes
Oracle	Nein
Oracle ADWC	Nein
PostgreSQL 9.5+	Yes
PostgreSQL vor 9.5	Yes
PrestoDB	Nein
PrestoSQL	Nein
SAP HANA 2 und höher	Nein
SingleStore	Nein
SingleStore 7 und höher	Nein
Snowflake	Yes
Teradata	Nein
Trino	Nein
Vektor	Nein
Vertica	Yes