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

Ü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 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 Implementierung kann die Aggregationsaufmerksamkeit die durchschnittliche Abfrage um ein Vielfaches 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 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 Benutzer eine Abfrage zum Jahresumsatz ausführt und Sie keine Tabelle mit jährlichen aggregierten Daten haben, verwendet Looker das nächstbeste, nämlich die Tabelle mit den monatlichen Umsätzen in diesem Beispiel.

Looker beantwortet die Fragen Ihrer Benutzer möglichst kleine zusammengefasste Tabellen verwenden. 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 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 zusammengefasste 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).

Looker fragt mithilfe der Logik zur Aggregatfunktion die kleinstmögliche aggregierte Tabelle ab, um die Fragen Ihrer Benutzer zu beantworten. Fragen beantwortet wurden. Die ursprüngliche Tabelle wird nur für Abfragen verwendet, die eine höhere Granularität erfordern, als die zusammengefassten Tabellen bieten können.

Aggregierte Tabellen müssen nicht mit einem separaten Explore verknüpft 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 aggregierte Tabellen erstellen, die die Anzahl der Abfragen minimieren, 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 persistenter abgeleiteter Tabelle (Persistent Derived Table, PDT).

Eine zusammengefasste Tabelle wird in Ihrem LookML-Projekt mit dem Parameter aggregate_table unter einem explore-Parameter 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 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 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. Die Zeiträume der explorativen Datenanalyse können auch aus den Zeiträumen in der zusammengefassten 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, 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 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 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 vorhanden 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 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

Mit der Logik für die zusammengefasste Bekanntheit in Looker kann ein Zeitraum aus einem anderen abgeleitet werden. 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 Tage des Monats, Tages- und Wochenjahres. Eine Jahresaggregattabelle 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 Zeitbereich-Teilmengen. 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.

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) Detailgenauigkeit als der in der Explore-Abfrage verwendete Zeitrahmenfilter hat. 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 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
Maßeinheiten, die durch SQL-Ausdrücke definiert sind
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 eine Explore-Abfrage mit einer genauen Übereinstimmung mit einer Abfrage für aggregierte Tabellen, 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. 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 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) ;;
}

Die Funktion „Benachrichtigungen zu zusammengefassten Daten“ wird 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:

Referenzen im Format ${view_name.field_name}, das Felder in anderen Ansichten angibt
Verweise im Format ${field_name}, die auf Felder in derselben Ansicht verweisen

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 Gesamtübersichtstabelle 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.

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 den aggregierten Bewusstsein verwendet werden können.

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 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 finden Sie auf der Dokumentationsseite zum Parameter allow_approximate_optimization. Dort finden Sie auch die Liste der Dialekte, die die Zählung unterschiedlicher Dialekte mithilfe von HyperLogLog unterstützen.

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:

Zeitzone für Abfragen: Diese Einstellung gilt für alle Abfragen in der Datenbankverbindung. Wenn sich alle Ihre Nutzer in derselben Zeitzone befinden, können Sie eine einzelne Zeitzone für Abfragen festlegen, damit alle Abfragen von der Datenbankzeitzone in die Zeitzone der Abfrage 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 aus der Zeitzone der Datenbank in die Zeitzone des einzelnen Nutzers umgewandelt.

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.

Aggregierte Tabellen verwenden die Datenbankzeitzone, 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 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 Parameter timezone für Ihre Summentabellen weglassen.

Andernfalls sollte die Zeitzone der Aggregierungstabelle so definiert werden, dass sie mit möglichen Abfragen übereinstimmt, damit die Aggregierungstabelle mit höherer Wahrscheinlichkeit 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 in Ihrer Datenbankverbindung nutzerspezifische Zeitzonen verwendet werden, 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. Filter in einer Summentabelle können die Ergebnisse so eingrenzen, dass die Summentabelle unbrauchbar wird. Angenommen, Sie erstellen eine aggregierte Tabelle für die tägliche Anzahl der Bestellungen und die zusammengefasste 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 aggregierten Tabelle werden die Daten zu eng gefiltert, um von der Explore-Abfrage verwendet zu werden.

Achten Sie auch auf die Filter, die Ihre Looker-Entwickler in Ihren Explore eingebunden 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, aber den Filter nicht vollständig entfernen.
conditionally_filter: Definiert eine Reihe von Standardfiltern, die Nutzer überschreiben können, wenn sie mindestens einen Filter aus einer zweiten Liste anwenden, die ebenfalls im Explore definiert ist.

Diese Filtertypen basieren auf bestimmten Feldern. Wenn 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
  }
}

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, 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, können die Daten in der aggregierten Tabelle dynamisch so gefiltert werden, 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, 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, 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 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.

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.

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. Wenn Sie sich im Entwicklungsmodus befinden, 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 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 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 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 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 untersuchen.

Looker führt eine Zusammenführung neuer Daten mit Ihren zusammengefassten Tabellen durch.

Bei zusammengefassten Tabellen mit Zeitfiltern kann Looker neue Daten zusammenführen und in die zusammengefasste Tabelle einfügen. Eine Aggregationstabelle enthält möglicherweise Daten der letzten drei Tage, wurde aber möglicherweise erst 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 enthält einen Zeitfilter.
Die Summentabelle 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 Aggregierungstabelle gestern erstellt wurde, ruft Looker die neuesten Daten ab, die noch nicht in der Aggregierungstabelle enthalten sind, und führt dann eine Zusammenführung der neuen Ergebnisse mit den Ergebnissen aus der Aggregierungstabelle 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.

Aggregierte Tabellen müssen beibehalten werden

Damit die aggregierte Tabelle für die Aggregatfunktion zugänglich ist, muss sie in Ihrer Datenbank persistiert werden. 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 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 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. Dies gilt auch für zusammengefasste Tabellen, die selbst eine Art persistenter abgeleiteter Tabelle sind.

Für den Nutzer, der die Funktion Abgeleitete Tabellen neu erstellen und Run-Option verwenden, wartet die Abfrage, bis die Tabellen neu erstellt wurden, bevor die Ergebnisse geladen werden. Abfragen anderer Nutzer verwenden weiterhin die vorhandenen Tabellen. Wenn die persistenten Tabellen erneut erstellt wurden, verwenden alle Benutzer die neu erstellten Tabellen.

Auf der Dokumentationsseite Abgeleitete Tabellen in Looker finden Sie weitere Informationen zur Funktion Abgeleitete Tabellen neu erstellen und Ausführen.

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];

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 einige weitere mögliche Gründe, warum 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
Es gibt kein solches Feld in der explorativen Datenanalyse.	Es gibt einen Fehler beim LookML-Validierungstyp. 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. 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 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 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 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 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. 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 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 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 enthält, 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 auf dieser Seite im Abschnitt Symmetrische Summen für Explores mit Joins.
Eine andere zusammengefasste Tabelle war für die Optimierung besser geeignet.	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.
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. 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 Aggregierungstabelle enthält einen nicht zeitbezogenen Filter, 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 Nur-Filter-Feld definiert, wird aber im Parameter `dimensions` der aggregierten Tabelle aufgeführt.	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 Summentabelle, um das Problem zu beheben. Wenn dieses Feld für die aggregierte Tabelle benötigt wird, fügen Sie es der Liste `filters` in der Abfrage der aggregierten Tabelle hinzu.
Der Optimierer kann nicht feststellen, warum die Aggregationstabelle 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

In einem Explore, das mehrere Datenbanktabellen zusammenführt, kann Looker Messwerte vom Typ SUM, COUNT und AVERAGE als SUM DISTINCT, COUNT DISTINCT und AVERAGE DISTINCT rendern. So werden in Looker Fehlberechnungen bei Verzweigungen vermieden. 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 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. Looker gibt diese Arten von Messwerten als DISTINCT aus, wenn:

Der Measure stammt von der „Eins“, n:1-Join oder 1:n-Join
Das Maß stammt aus einer der beiden Ansichten eines n:n-Joins.

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 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.

Auf der Dokumentationsseite zum Parameter allow_approximate_optimization finden Sie weitere Informationen und eine Liste der SQL-Dialekte, die HyperLogLog-Skizzen unterstützen.

Unterstützung von Dialekten für die zusammengefasste Bekanntheit

Die Möglichkeit, Aggregate Awareness zu nutzen, hängt von dem 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+ 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-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 und höher	Ja
Oracle	Ja
Oracle ADWC	Ja
PostgreSQL 9.5+	Ja
PostgreSQL vor 9.5	Ja
PrestoDB	Ja
PrestoSQL	Ja
SAP HANA 2 und höher	Ja
SingleStore	Ja
SingleStore 7 und höher	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 9.5	Ja
PrestoDB	Nein
PrestoSQL	Nein
SAP HANA 2 und höher	Nein
SingleStore	Nein
SingleStore 7 und höher	Nein
Snowflake	Ja
Teradata	Nein
Trino	Nein
Vektor	Nein
Vertica	Ja