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

Anleitung zur Aggregatfunktion

Weitere Informationen finden Sie auf der Dokumentationsseite Aggregatfunktion.

Einführung

Diese Seite ist ein Leitfaden zur Implementierung der aggregierten Bekanntheit in der Praxis. Sie enthält Informationen zur Identifizierung von Umsetzungsmöglichkeiten, zu den Aggregatfunktionen zur Steigerung der Bekanntheit und zu einem einfachen Workflow für die Implementierung in einem echten Modell. Diese Seite ist keine tiefgehende Erläuterung aller Funktionen oder Grenzfälle der Aggregatfunktion und auch keine umfassende Liste aller Funktionen.

Was ist Aggregate Awareness?

In Looker führen Sie in der Regel Abfragen nach Rohtabellen oder Ansichten in Ihrer Datenbank durch. Manchmal sind dies nichtflüchtige abgeleitete Tabellen (PDTs) von Looker.

Häufig stoßen Sie auf sehr große Datasets oder Tabellen, für die für eine optimale Leistung Aggregationstabellen oder Sammeltabellen erforderlich sind.

In der Regel können Sie Aggregationstabellen wie eine orders_daily-Tabelle mit begrenzter Dimensionalität erstellen. Diese müssen im Explore separat behandelt und separat modelliert werden. Sie befinden sich nicht richtig im Modell. Diese Einschränkungen führen zu einer schlechten User Experience, wenn Nutzende zwischen mehreren Explores für dieselben Daten wählen müssen.

Jetzt können Sie mithilfe der Aggregatfunktion von Looker aggregierte Tabellen mit verschiedenen Ebenen von Detaillierungsgrad, Dimensionalität und Aggregation vorab konstruieren und Looker darüber informieren, wie sie in vorhandenen Explores verwendet werden sollen. Abfragen nutzen diese Sammeltabellen dann, wenn Looker dies für angemessen hält, ohne dass Nutzereingaben erforderlich sind. Dies reduziert die Größe der Abfragen, verkürzt die Wartezeiten und verbessert die Nutzerfreundlichkeit.

HINWEIS: Die aggregierten Tabellen von Looker sind eine Art von nichtflüchtigen abgeleiteten Tabellen. Das bedeutet, dass aggregierte Tabellen die gleichen Datenbank- und Verbindungsanforderungen haben wie PDTs.
Informationen dazu, ob Ihr Datenbankdialekt und Ihre Looker-Verbindung PDTs unterstützen, finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker.
Auf der Dokumentationsseite Aggregatfunktion können Sie nachlesen, ob der Dialekt Ihrer Datenbank Aggregatfunktion unterstützt.

Die Bedeutung von Aggregatfunktion

Es gibt eine Reihe wichtiger Nutzenversprechen, um die Bekanntheit Ihres bestehenden Looker-Modells zu steigern:

Leistungsverbesserung:Durch die Implementierung von Aggregatfunktionen werden Suchanfragen von Nutzern beschleunigt. Looker verwendet eine kleinere Tabelle, wenn sie Daten enthält, die zum Abschließen der Benutzerabfrage erforderlich sind.
Kosteneinsparungen:Bei bestimmten Dialekten werden die Gebühren nach der Größe der Abfrage in einem Nutzungsmodell berechnet. Wenn Sie mit Looker kleinere Tabellen abfragen, sinken die Kosten pro Nutzerabfrage.
Verbesserte Nutzerfreundlichkeit:Durch die Konsolidierung wird das redundante Erstellen von Explores eliminiert und sie werden schneller abgerufen.
Reduzierter LookML-Speicherplatz:Wenn vorhandene, auf Liquid-basierte Aggregatstrategien durch eine flexible, native Implementierung ersetzt werden, erhöht sich die Ausfallsicherheit und weniger Fehler.
Möglichkeit zur Nutzung vorhandener LookML: Aggregierte Tabellen verwenden das query-Objekt, das vorhandene modellierte Logik wiederverwendet, anstatt Logik mit explizitem benutzerdefiniertem SQL zu duplizieren.

Einfaches Beispiel

Hier sehen Sie eine sehr einfache Implementierung in einem Looker-Modell, die zeigt, wie einfach Aggregatfunktion sein kann. Bei einer hypothetischen flights-Tabelle in der Datenbank mit einer Zeile für jeden über die FAA aufgezeichneten Flug können wir diese Tabelle in Looker mit einer eigenen Ansicht und einem eigenen Explore modellieren. Hier ist der LookML-Code für eine aggregierte Tabelle, die wir für das Explore definieren können:

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week]
        measures: [cancelled_count, count]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

Mit dieser aggregierten Tabelle kann ein Nutzer das flights-Explore abfragen. Looker nutzt dann automatisch die oben definierte zusammengefasste Tabelle und die aggregierte Tabelle zur Beantwortung von Abfragen. Der Benutzer muss Looker nicht über besondere Bedingungen informieren. Looker verwendet nur diese Tabelle, wenn sie für die vom Benutzer ausgewählten Felder geeignet ist.

Nutzer mit see_sql-Berechtigungen können die Kommentare auf dem Tab SQL eines Explores verwenden, um zu sehen, welche aggregierte Tabelle für eine Abfrage verwendet wird. Hier ist ein Beispiel für einen Looker-SQL-Tab für eine Abfrage, die die aggregierte Tabelle flights:flights_by_week_and_carrier in teach_scratch verwendet:

SQL-Tab eines Explores, in dem der zugrunde liegende SQL-Code und ein Kommentar angezeigt werden, der das Scratch-Schema der verwendeten aggregierten Tabelle angibt.

Weitere Informationen dazu, wie Sie bestimmen, ob aggregierte Tabellen für eine Abfrage verwendet werden, finden Sie auf der Dokumentationsseite Aggregatfunktion.

Chancen erkennen

Um die Vorteile der aggregierten Bekanntheit zu maximieren, sollten Sie herausfinden, in welchen Bereichen sie bei der Optimierung oder bei der Steigerung der oben genannten Werte eine Rolle spielen kann.

Dashboards mit einer hohen Laufzeit identifizieren

Eine großartige Möglichkeit für Aggregate Awareness besteht darin, zusammengefasste Tabellen für häufig genutzte Dashboards mit einer sehr hohen Laufzeit zu erstellen. Ihre Nutzer hören möglicherweise von langsamen Dashboards. Wenn Sie jedoch see_system_activity verwenden, können Sie auch die Explore-Funktion für den Systemaktivitätsverlauf von Looker verwenden, um Dashboards zu finden, die eine langsamere als durchschnittliche Laufzeit aufweisen. Dazu können Sie einfach diesen Link zum Untersuchen des Systemaktivitätsverlaufs in einem Browser öffnen und dann „hostname“ in der URL durch den Namen Ihrer Looker-Instanz ersetzen. Sie sehen nun eine Explore-Visualisierung mit Daten zu den Dashboards Ihrer Instanz, einschließlich Titel, Verlauf, Anzahl der Explores, Verhältnis aus Cache vs. Datenbank und Ist schlechter als durchschnittlich:

In diesem Beispiel gibt es eine Reihe von Dashboards mit hoher Auslastung, die eine schlechtere Leistung als der Mittelwert erbringen, z. B. das Dashboard Beispielvisualisierungen. Im Dashboard Beispielvisualisierungen werden zwei Explores verwendet. Es wäre also sinnvoll, zusammengefasste Tabellen für beide Explores zu erstellen.

Langsame und von Benutzern häufig abgefragte Explores identifizieren

Eine weitere Möglichkeit für Aggregatfunktionen sind Explores, die stark von Benutzern abgefragt werden und eine überdurchschnittliche Abfragereaktion aufweisen.

Sie können den Untersuchungsverlauf des Systemaktivitätsverlaufs als Ausgangspunkt verwenden, um Möglichkeiten zur Optimierung von Explores zu ermitteln. Dazu können Sie den Link zum Explore des Systemaktivitätsverlaufs in einem Browser öffnen und dann „hostname“ in der URL durch den Namen Ihrer Looker-Instanz ersetzen. Sie sehen nun eine Explore-Visualisierung mit Daten zu den Explores Ihrer Instanz, darunter Explore, Modell, Abfrageausführungsanzahl, Nutzeranzahl und Durchschnittliche Laufzeit in Sekunden:

Tabellenvisualisierung, die zeigt, dass die Explores „order_items“ und „flights“ am häufigsten von der Instanz abgefragt werden.

Im Verlaufs-Explore können Sie die folgenden Typen von Explores für Ihre Instanz ermitteln:

Explores, die von Benutzern abgefragt werden (im Gegensatz zu Abfragen aus der API oder Abfragen aus geplanten Lieferungen)
Häufig abgefragte Explores
Explores mit schlechter Leistung (im Vergleich zu anderen Explores)

Im vorherigen Beispiel des Explores für den Systemaktivitätsverlauf sind die Explores flights und order_items wahrscheinlich mögliche Kandidaten für die Implementierung der aggregierten Bekanntheit.

Identifizieren Sie Felder, die häufig in Abfragen verwendet werden

Schließlich können Sie andere Möglichkeiten auf Datenebene identifizieren, indem Sie die Felder verstehen, die Benutzer häufig in Abfragen und Filtern verwenden.

Der Explore „Systemaktivität-Feldnutzung“ enthält Informationen zu den häufig ausgewählten Feldern in den Explores, die Sie oben identifiziert haben. Dazu können Sie diesen Link zum Explore der Systemaktivität-Feldnutzung in einem Browser öffnen und dann „hostname“ in der URL durch den Namen Ihrer Looker-Instanz ersetzen. Ersetzen Sie die Filter entsprechend. Sie sehen ein Explore mit einem Balkendiagramm, das angibt, wie oft ein Feld in einer Abfrage verwendet wurde:

Balkendiagramm, das zeigt, dass die Felder „flights.count“ und „flights.depart_week“ aus den „Flights“-Explores im FAa-Modell die am häufigsten verwendeten Felder sind.

In der Abbildung oben sehen Sie, dass flights.count und flights.depart_week die beiden am häufigsten ausgewählten Felder für den Explore sind. Dies sind also gute Kandidaten für Felder, die in aggregierte Tabellen aufgenommen werden sollen.

Konkrete Daten wie diese sind hilfreich, aber es gibt subjektive Elemente, die Ihre Auswahlkriterien beeinflussen. Wenn Sie sich beispielsweise die vorherigen vier Felder ansehen, können Sie sicher davon ausgehen, dass Nutzer sich normalerweise die Anzahl der geplanten Flüge und der annullierten Flüge ansehen und dass sie diese Daten sowohl nach Woche als auch nach Fluggesellschaft aufschlüsseln möchten. Dies ist ein Beispiel für eine klare, logische, praxisnahe Kombination aus Feldern und Messwerten.

Fazit

Die obigen Schritte dienen als Leitfaden für das Auffinden von Dashboards, Explores und Feldern, die für die Optimierung berücksichtigt werden müssen. Es ist auch zu verstehen, dass sich alle drei gegenseitig ausschließen können: Die problematischen Dashboards werden möglicherweise nicht von den problematischen Explores unterstützt und das Erstellen aggregierter Tabellen mit den häufig verwendeten Feldern kann für diese Dashboards überhaupt nicht hilfreich sein. Es ist möglich, dass dies drei separate Implementierungen der Aggregatfunktion ist.

Aggregierte Tabellen entwerfen

Nachdem Sie Möglichkeiten zur Aggregation der Bekanntheit identifiziert haben, können Sie zusammengefasste Tabellen erstellen, die diese Chancen optimal nutzen. Auf der Dokumentationsseite Aggregatfunktion finden Sie Informationen zu den Feldern, Messwerten und Zeiträumen, die in zusammengefassten Tabellen unterstützt werden, sowie andere Richtlinien zum Erstellen von aggregierten Tabellen.

HINWEIS: Aggregierte Tabellen müssen keine genaue Übereinstimmung sein, damit Ihre Abfrage verwendet werden kann. Wenn Ihre Abfrage den Detaillierungsgrad einer Woche hat und Sie eine tägliche Sammeltabelle haben, verwendet Looker Ihre aggregierte Tabelle anstelle der Rohdaten-Tabelle auf Zeitstempelebene. Wenn Sie eine aggregierte Tabelle bis auf die brand-und date-Ebene haben und ein Nutzer nur auf der brand-Ebene abfragt, eignet sich diese Tabelle trotzdem zur Verwendung von Looker zur Aggregatfunktion.

Aggregate Awareness wird für die folgenden Messwerte unterstützt:

Standardmessungen : Messungen vom Typ SUM, COUNT, AVERAGE, MIN und MAX
Zusammengesetzte Messungen : Messungen vom Typ NUMBER, STRING, YESNO und DATE
Ungefähre verschiedene Messwerte: Dialekte, die die HyperLogLog-Funktion verwenden können.

Aggregate Awareness wird für die folgenden Messwerte nicht unterstützt:

Eindeutige Messwerte:Da die Unterscheidbarkeit nur für atomare, nicht aggregierte Daten berechnet werden kann, werden *_DISTINCT-Messwerte außerhalb der Näherungswerte, die HyperLogLog verwenden, nicht unterstützt.
Kardinalitätsbasierte Messwerte:Wie bei einzelnen Messwerten können Medianwerte und Perzentile nicht vorab zusammengefasst werden und werden nicht unterstützt.

HINWEIS:Wenn Sie eine potenzielle Nutzerabfrage mit Messwerttypen kennen, die von der Aggregatfunktion nicht unterstützt werden, bietet es sich an, eine zusammengefasste Tabelle zu erstellen, die genau mit einer Abfrage übereinstimmt. Eine aggregierte Tabelle, die genau mit der Abfrage übereinstimmt, kann verwendet werden, um eine Abfrage mit Messwerttypen zu beantworten, die für die Aggregatfunktion sonst nicht unterstützt werden würden.

Detaillierungsgrad der aggregierten Tabelle

Bevor Sie Tabellen für Kombinationen aus Dimensionen und Messwerten erstellen, sollten Sie gängige Nutzungsmuster und Feldauswahlen festlegen, um zusammengefasste Tabellen zu erstellen, die so oft wie möglich mit der größten Auswirkung verwendet werden. Beachten Sie, dass alle in der Abfrage verwendeten Felder (egal ob ausgewählt oder gefiltert) in der zusammengefassten Tabelle enthalten sein müssen, damit die Tabelle für die Abfrage verwendet werden kann. Wie bereits erwähnt, muss die aggregierte Tabelle jedoch keine genaue Übereinstimmung für eine Abfrage von sein, die für die Abfrage verwendet wird. Sie können viele potenzielle Nutzeranfragen in einer einzigen aggregierten Tabelle adressieren und dennoch erhebliche Leistungssteigerungen verzeichnen.

Im obigen Beispiel zum Identifizieren von Feldern, die häufig in Abfragen verwendet werden, wurden zwei Dimensionen (flights.depart_week und flights.carrier) sowie zwei Messwerte (flights.count und flights.cancelled_count) sehr häufig ausgewählt. Daher ist es sinnvoll, eine aggregierte Tabelle zu erstellen, die alle vier Felder verwendet. Darüber hinaus führt das Erstellen einer einzelnen aggregierten Tabelle für flights_by_week_and_carrier zu einer häufigeren Nutzung der zusammengefassten Tabellen als zwei verschiedene zusammengefasste Tabellen für flights_by_week- und flights_by_carrier-Tabellen.

Hier ist ein Beispiel für eine zusammengefasste Tabelle, die wir für Abfragen in den allgemeinen Feldern erstellen könnten:

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week]
        measures: [cancelled_count, count]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

Ihre Geschäftsanwender und Anekdoten sowie Daten aus der Systemaktivität von Looker können Ihnen bei der Entscheidungsfindung helfen.

Anwendbarkeit und Leistung in Einklang bringen

Das folgende Beispiel zeigt eine Explore-Abfrage der Felder „Abflugwoche“, „Flugdetails“, „Fluggesellschaft“, „Anzahl der Flüge“ und „Detaillierte Anzahl der stornierten Flüge“ aus der zusammengefassten Tabelle flights_by_week_and_carrier:

Untersuchen Sie die Datentabelle mit vier Feldern aus der aggregierten Tabelle „flight_by_week_and_carrier“.

Die Ausführung dieser Abfrage aus der ursprünglichen Datenbanktabelle dauerte 15,8 Sekunden und hat 38 Millionen Zeilen ohne Joins mit Amazon Redshift gescannt. Die Neuausrichtung der Abfrage, was ein normaler Nutzervorgang wäre, dauerte 29,5 Sekunden.

Nach der Implementierung der zusammengefassten Tabelle flights_by_week_and_carrier dauerte die nachfolgende Abfrage 7, 2 Sekunden und scannt 4.592 Zeilen. Dies entspricht einer Reduzierung der Tabellengröße um 99,98 %. Das Pivotieren der Abfrage dauerte 9,8 Sekunden.

Im Feld „Systemaktivitäts-Untersuchung“ sehen wir, wie oft unsere Nutzer diese Felder in Abfragen aufnehmen. In diesem Beispiel wurde flights.count 47.848 Mal, flights.depart_week 18.169 Mal, flights.cancelled_count 16.570 Mal und flights.carrier 13.517 Mal verwendet.

Selbst wenn wir sehr leicht geschätzt haben, dass bei 25% dieser Suchanfragen alle vier Felder auf die einfachste Art verwendet wurden (einfache Auswahl, kein Pivoting), ergibt sich folgende Berechnung: 3379 × 8,6 Sekunden = 8 Stunden, 4 Minuten insgesamt keine Wartezeiten für Nutzer.

HINWEIS: Das hier verwendete Beispielmodell ist sehr einfach. Diese Ergebnisse sollten nicht als Benchmark oder Referenzwert für Ihr Modell verwendet werden.

Nachdem wir genau denselben Ablauf auf unser E-Commerce-Modell order_items angewendet haben, also das am häufigsten verwendete Explore der Instanz, ergibt sich folgendes Ergebnis:

Quelle	Abfragezeitpunkt	Gescannte Zeilen
Basistisch	13,1 Sekunden	285.000
Zusammengefasste Tabelle	5,1 Sekunden	138.000
Delta	8 Sekunden	147.000

Die in der Abfrage und der nachfolgenden aggregierten Tabelle verwendeten Felder waren brand, created_date, orders_count und total_revenue, wobei zwei Joins verwendet wurden. Die Felder wurden insgesamt 11.000 Mal verwendet. Wird dieselbe kombinierte Nutzung von etwa 25 % geschätzt, belaufen sich die Gesamteinsparungen für Nutzer*innen auf 6 Stunden, 6 Minuten (8 s * 2750 = 22.000 s). Das Erstellen der aggregierten Tabelle dauerte 17,9 Sekunden.

Bei der Betrachtung dieser Ergebnisse lohnt es sich, einen Moment zurückzuwerfen und die möglichen Erträge zu bewerten, die sich aus folgenden Bereichen ergeben:

Größere, komplexere Modelle/Explores optimieren, die eine „akzeptable“ Leistung haben und durch bessere Modellierungsverfahren möglicherweise Leistungsverbesserungen erzielen

gegen

Aggregierte Modelle zur Optimierung einfacherer Modelle verwenden, die häufiger verwendet werden und eine schlechte Leistung erzielen

Sie werden nachlassende Ergebnisse für Ihre Bemühungen feststellen, wenn Sie versuchen, die letzte Leistung von Looker und Ihrer Datenbank zu erhalten. Sie sollten sich immer über die grundlegenden Leistungserwartungen, insbesondere von geschäftlichen Benutzern, und die durch Ihre Datenbank auferlegten Beschränkungen (z. B. Nebenläufigkeit, Abfragegrenzwerte, Kosten usw.) im Klaren sein. Sie sollten nicht davon ausgehen, dass Aggregate diese Einschränkungen überwinden wird.

Bedenken Sie beim Entwerfen einer aggregierten Tabelle auch, dass eine größere Anzahl von Feldern zu einer größeren und langsameren aggregierten Tabelle führt. Größere Tabellen können mehr Abfragen optimieren und daher in mehr Situationen verwendet werden, aber große Tabellen sind nicht so schnell wie kleinere, einfachere Tabellen.

Beispiel:

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week,flights.distance, flights.arrival_week,flights.cancelled]
        measures: [cancelled_count, count, flights.average_distance, flights.total_distance]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

Dadurch wird die zusammengefasste Tabelle für eine beliebige Kombination der angezeigten Dimensionen und für alle enthaltenen Messwerte verwendet, sodass diese Tabelle für die Beantwortung vieler verschiedener Nutzeranfragen verwendet werden kann. Um diese Tabelle jedoch für eine einfache SELECT-Abfrage mit carrier und count zu verwenden,wäre ein Scan einer Tabelle mit 885.000 Zeilen erforderlich. Im Gegensatz dazu wäre für dieselbe Abfrage nur ein Scan von 4.592 Zeilen erforderlich, wenn die Tabelle auf zwei Dimensionen basiert. Die Tabellengröße von 885.000 Zeilen verringert sich immer noch um 97 % (im Vergleich zu den vorherigen 38 Millionen Zeilen). Durch das Hinzufügen einer weiteren Dimension erhöht sich jedoch die Tabellengröße auf 20 Millionen Zeilen. Daher gibt es abnehmende Ergebnisse, wenn Sie mehr Felder in Ihre aggregierte Tabelle aufnehmen, um ihre Anwendbarkeit auf mehr Abfragen zu erhöhen.

Aggregierte Tabellen erstellen

In unserem Beispiel der Flights-Analyse, die wir als Optimierungschance identifiziert haben, wäre die beste Strategie, drei verschiedene zusammengefasste Tabellen dafür zu erstellen:

flights_by_week_and_carrier
flights_by_month_and_distance
flights_by_year

Die einfachste Methode zum Erstellen dieser aggregierten Tabellen besteht darin, die LookML der aggregierten Tabelle aus einer Explore-Abfrage oder aus einem Dashboard abzurufen und den Looker-Projektdateien die LookML hinzuzufügen.

Nachdem Sie die zusammengefassten Tabellen Ihrem LookML-Projekt hinzugefügt und die Aktualisierungen für die Produktion bereitgestellt haben, nutzen Ihre Explores die aggregierten Tabellen für die Abfragen Ihrer Nutzer.

Persistenz

Aggregierte Tabellen müssen in Ihrer Datenbank beibehalten werden, um für Aggregationsanalyse darauf zugreifen zu können. Als Best Practice sollten Sie die automatische Neugenerierung dieser aggregierten Tabellen an Ihre Caching-Richtlinie anpassen, indem Sie Datengruppen nutzen. Für eine aggregierte Tabelle, die auch für das verknüpfte Explore genutzt wird, sollten Sie dieselbe Datengruppe verwenden. Wenn Sie keine Datengruppen verwenden können, können Sie stattdessen den Parameter sql_trigger_value verwenden. Hier sehen Sie einen generischen, datumsbasierten Wert für sql_trigger_value:

sql_trigger_value: SELECT CURRENT_DATE() ;;

Dadurch werden Ihre aggregierten Tabellen täglich automatisch um Mitternacht erstellt.

Zeitrahmenlogik

Wenn Looker eine zusammengefasste Tabelle erstellt, enthält sie Daten bis zum Zeitpunkt ihrer Erstellung. Alle Daten, die anschließend an die Basistabelle in der Datenbank angehängt wurden, werden normalerweise aus den Ergebnissen einer Abfrage mit dieser aggregierten Tabelle ausgeschlossen.

Dieses Diagramm zeigt die Zeitleiste, zu der Bestellungen in der Datenbank empfangen und protokolliert wurden, verglichen mit dem Zeitpunkt, zu dem die aggregierte Tabelle Orders erstellt wurde. Zwei heute eingegangene Bestellungen sind nicht in der zusammengefassten Tabelle Bestellungen enthalten, da die Bestellungen nach der Erstellung der zusammengefassten Tabelle eingegangen sind:

Zeitachse der heute und gestern eingegangenen Bestellungen ohne zwei Datenpunkte, die nach dem Erstellen der aggregierten Tabelle erfasst wurden.

Aber Looker kann neue Daten in der aggregierten Tabelle VEREINBAREN, wenn ein Nutzer einen Zeitraum abfragt, der sich mit der aggregierten Tabelle überschneidet, wie im selben Zeitachsendiagramm dargestellt:

Die Abfrage des Nutzers enthält die Datenpunkte auf der Zeitachse, die nach dem Erstellen der aggregierten Tabelle aufgetreten sind.

Da Looker aktuelle Daten in einer aggregierten Tabelle zusammenführen kann, werden die Bestellungen, die nach der Erstellung der aggregierten Tabelle eingegangen sind, in die Ergebnisse des Nutzers aufgenommen, wenn ein Nutzer nach einem Zeitraum filtert, der sich mit dem Ende der aggregierten Tabelle und der Basistabelle überschneidet. Weitere Informationen und die Bedingungen, die erfüllt werden müssen, um neue Daten mit aggregierten Tabellenabfragen zu verbinden, finden Sie auf der Dokumentationsseite Aggregatfunktion.

Fazit

Zur Erinnerung: Zum Erstellen einer Implementierung des Aggregats zur Steigerung der Bekanntheit sind drei grundlegende Schritte erforderlich:

Identifizieren Sie Möglichkeiten, bei denen die Optimierung mithilfe von zusammengefassten Tabellen angemessen und wirkungsvoll ist.
Erstellen Sie zusammengefasste Tabellen, die die größte Abdeckung für häufige Nutzerabfragen bieten und gleichzeitig klein genug sind, um die Größe dieser Abfragen ausreichend zu reduzieren.
Erstellen Sie die aggregierten Tabellen im Looker-Modell und koppeln Sie die Persistenz der Tabelle mit der Persistenz des Explore-Cache.