Anleitung für Aggregate Awareness

Weitere Informationen finden Sie auf der Dokumentationsseite Aggregate Awareness.

Einleitung

Diese Seite ist ein Leitfaden zur Implementierung von Aggregate Awareness in einem praktischen Szenario, einschließlich der Identifizierung von Implementierungsmöglichkeiten, der Förderung des Bewusstseins für die Wertschöpfung und eines einfachen Workflows für die Implementierung in ein echtes Modell. Diese Seite bietet weder eine ausführliche Erläuterung aller Funktionen oder Grenzfälle noch einen vollständigen Katalog aller Funktionen.

Was ist Aggregate Awareness?

In Looker führen Sie Abfragen hauptsächlich aus Rohtabellen oder Ansichten in Ihrer Datenbank durch. Manchmal sind dies Persistente abgeleitete Tabellen (PDTs) von Looker.

Sie stoßen häufig auf sehr große Datensätze oder Tabellen, die zusammengefasste Tabellen oder Sammel-Tabellen erfordern, um eine optimale Leistung zu erzielen.

Normalerweise erstellen Sie Aggregationstabellen wie eine orders_daily-Tabelle, die eingeschränkte Dimensionalität enthält. Diese müssen im Explore separat behandelt und modelliert werden und sind nicht sauber im Modell enthalten. Diese Einschränkungen führen zu einer schlechten Nutzererfahrung, wenn der Benutzer zwischen mehreren Explores für dieselben Daten wählen muss.

Mit der Aggregatfunktion von Looker können Sie nun aggregierte Tabellen mit verschiedenen Detaillierungs-, Dimensionalitäts- und Aggregationsebenen vorkonstruieren und Looker darüber informieren, wie sie in vorhandenen Explores verwendet werden sollen. Abfragen verwenden diese Rollup-Tabellen dann, wenn Looker dies für angemessen erachtet, ohne Benutzereingabe. Dies reduziert die Abfragegröße, verkürzt die Wartezeiten und verbessert die User Experience.

HINWEIS: Die aggregierten Tabellen von Looker sind eine Art persistenter abgeleiteter Tabelle (Persistent Derived Table, PDT). Dies bedeutet, dass aggregierte Tabellen dieselben Datenbank- und Verbindungsanforderungen wie PDTs haben.

Informationen dazu, ob Ihr Datenbankdialekt und Ihre Looker-Verbindung PDTs unterstützen, finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker.

Auf der Dokumentationsseite Aggregate Awareness finden Sie Informationen dazu, ob Ihr Datenbankdialekt Aggregate Awareness unterstützt.

Der Wert der aggregierten Bekanntheit

Es gibt eine Reihe von nennenswerten Vorzügen, die Aggregate Awareness anbieten, um einen Mehrwert aus Ihrem bestehenden Looker-Modell zu ziehen:

• Leistungsverbesserung:Durch die Implementierung von Aggregatfunktion können Nutzeranfragen schneller gestellt werden. Looker verwendet eine kleinere Tabelle, wenn sie Daten enthält, die zum Ausführen der Benutzerabfrage erforderlich sind.
• Kosteneinsparungen:Bestimmte Dialekte werden nach der Größe der Abfrage in einem Nutzungsmodell abgerechnet. Wenn Looker kleinere Tabellen abfragt, senken Sie die Kosten pro Benutzerabfrage.
• Verbesserte Benutzerfreundlichkeit:Durch die Konsolidierung können Antworten schneller abgerufen werden. Durch die Konsolidierung wird das überflüssige Erstellen von Explores vermieden.
• Reduzierter LookML-Fußabdruck: Der Ersatz bestehender, liquid-basierter Aggregate-Awareness-Strategien durch flexible, native Implementierung führt zu erhöhter Ausfallsicherheit und weniger Fehlern.
• Verwendung vorhandener LookML-Funktionen:Aggregierte Tabellen verwenden das Objekt query, das die vorhandene modellierte Logik wiederverwendet, anstatt Logik mit explizitem benutzerdefiniertem SQL zu duplizieren.

Einfaches Beispiel

Hier ist eine sehr einfache Implementierung in einem Looker-Modell, um zu zeigen, wie leicht Aggregatfunktionen sein können. Bei einer hypothetischen flights-Tabelle in der Datenbank mit einer Zeile für jeden über die FAA erfassten 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 Explore flights abfragen. Looker verwendet dann automatisch die in LookML definierte aggregierte Tabelle und verwendet die aggregierte Tabelle, um Abfragen zu beantworten. Der Benutzer muss Looker nicht über spezielle Bedingungen informieren: Wenn die Tabelle zu den vom Benutzer ausgewählten Feldern passt, verwendet Looker diese Tabelle.

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. Hier sehen Sie ein Beispiel für einen Looker-Tab SQL für eine Abfrage, in der die aggregierte Tabelle flights:flights_by_week_and_carrier in teach_scratch verwendet wird:

Auf der Dokumentationsseite Aggregate Awareness finden Sie Informationen dazu, wie Sie feststellen können, ob aggregierte Tabellen für eine Abfrage verwendet werden.

Chancen erkennen

Wenn Sie die Vorteile der aggregierten Bekanntheit maximieren möchten, sollten Sie ermitteln, wo diese bei der Optimierung oder bei der Steigerung des Werts des aggregierten Bekanntheitsgrads eine Rolle spielen kann.

Dashboards mit einer hohen Laufzeit identifizieren

Eine großartige Gelegenheit für Aggregatfunktion besteht darin, aggregierte Tabellen für stark genutzte Dashboards mit einer sehr hohen Laufzeit zu erstellen. Möglicherweise hören Sie von Ihren Nutzern von langsamen Dashboards. Wenn Sie jedoch see_system_activity haben, können Sie auch den Systemaktivitätsverlauf von Looker verwenden, um Dashboards mit einer langsameren als durchschnittlichen Laufzeit zu finden. Sie können aber auch diesen Link zum Erkunden des Systemaktivitätsverlaufs in einem Browser öffnen und dann „hostname“ in der URL durch den Namen Ihrer Looker-Instanz ersetzen. Es wird eine Explore-Visualisierung mit Daten zu den Dashboards Ihrer Instanz angezeigt, darunter Titel, Verlauf, Anzahl der Explores, Ration aus Cache im Vergleich zur Datenbank und Ist schlechter als der Durchschnitt:

In diesem Beispiel gibt es eine Reihe von Dashboards mit hoher Auslastung, die schlechter als der Mittelwert abschneiden, z. B. das Dashboard Beispielvisualisierungen. Im Dashboard Beispielvisualisierungen werden zwei Explores verwendet. Daher bietet es sich an, aggregierte Tabellen für beide Explores zu erstellen.

Explores identifizieren, die langsam sind und von Nutzern häufig abgefragt werden

Eine weitere Möglichkeit für Aggregatfunktion sind Explores, die stark von Benutzern abgefragt werden und eine überdurchschnittliche Abfrageantwort haben.

Der Verlauf des Systemaktivitätsverlaufs kann als Ausgangspunkt für die Optimierung von Explores dienen. Sie können aber auch den Link zum Erkunden des Systemaktivitätsverlaufs in einem Browser öffnen und dann „hostname“ in der URL durch den Namen Ihrer Looker-Instanz ersetzen. Es wird eine Explore-Visualisierung mit Daten zu den Explores Ihrer Instanz angezeigt, einschließlich Explore, Modell, Anzahl der Abfrageausführungen, Nutzeranzahl und Durchschnittliche Laufzeit in Sekunden:

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

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

Im vorherigen Beispiel der Explore-Analyse zum Systemaktivitätsverlauf sind die Explores flights und order_items wahrscheinliche Kandidaten für die Implementierung der Aggregatfunktion.

Felder identifizieren, die häufig in Abfragen verwendet werden

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

Verwenden Sie das Explore zur Nutzung des Systemaktivitätsfelds, um die häufig ausgewählten Felder innerhalb der Explores zu verstehen, die Sie als langsam und intensiv genutzt haben. Alternativ können Sie diesen Link zum Explore der Systemaktivitätsfeldnutzung in einem Browser öffnen und dann „hostname“ in der URL durch den Namen Ihrer Looker-Instanz ersetzen. Ersetzen Sie die Filter entsprechend. Sie sehen nun ein Explore mit einem Balkendiagramm, das anzeigt, wie oft ein Feld in einer Abfrage verwendet wurde:

In dem Beispiel eines Systemaktivitäts-Explores, das in der Abbildung gezeigt wird, sehen Sie, dass flights.count und flights.depart_week die beiden am häufigsten ausgewählten Felder für das Explore sind. Daher sind diese Felder gute Kandidaten für Felder, die in aggregierten 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 sich Nutzer häufig die Anzahl der geplanten Flüge und die Anzahl der Flüge ansehen, die storniert wurden, 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, reale Kombination aus Feldern und Messwerten.

Zusammenfassung

Die Schritte auf dieser Dokumentationsseite sollten als Leitfaden für die Suche nach Dashboards, Explores und Feldern dienen, die für die Optimierung berücksichtigt werden müssen. Es ist auch wichtig zu verstehen, dass sich alle drei sich 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 wird diesen Dashboards möglicherweise überhaupt nicht helfen. Es ist möglich, dass es sich um drei eigenständige Aggregatfunktionen handelt.

Aggregierte Tabellen entwerfen

Nachdem Sie Möglichkeiten für die aggregierte Bekanntheit identifiziert haben, können Sie aggregierte Tabellen erstellen, mit denen diese Chancen am besten genutzt werden können. Auf der Dokumentationsseite zur Aggregatfunktion finden Sie Informationen zu den Feldern, Messwerten und Zeiträumen, die in aggregierten Tabellen unterstützt werden, sowie weitere Richtlinien zum Erstellen aggregierter Tabellen.

HINWEIS: Aggregierte Tabellen müssen keine genaue Übereinstimmung mit der Abfrage sein, damit sie verwendet werden kann. Wenn Ihre Abfrage den Detaillierungsgrad der Woche umfasst und Sie eine tägliche Sammel-Tabelle haben, verwendet Looker Ihre aggregierte Tabelle anstelle der Rohtabelle auf Zeitstempelebene. Das Gleiche gilt, wenn Sie eine aggregierte Tabelle auf der Ebene brand und date haben und Nutzerabfragen nur auf brand-Ebene durchgeführt haben, kann diese Tabelle weiterhin von Looker für die Aggregatfunktion verwendet werden.

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

• Standardmaße : Messwerte vom Typ SUMME, ANZAHL, MITTELWERT, MIN und MAX
• Zusammengesetzte Messungen : Messwerte vom Typ NUMBER, STRING, YESNO und DATE
• Ungefähre unterschiedliche Messwerte : Dialekte, die HyperLogLog-Funktionen verwenden können.

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

• Unterschiedliche Maße: Da die Unterscheidbarkeit nur für nicht aggregierte Daten berechnet werden kann, werden *_DISTINCT-Messwerte außer diesen Näherungswerte, die HyperLogLog verwenden, nicht unterstützt.
• Kardinalitätsbasierte Messwerte:Wie bei unterschiedlichen Messwerten können Medianwerte und Perzentile nicht vorab aggregiert werden und werden nicht unterstützt. 

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

Detaillierungsgrad der aggregierten Tabelle

Bevor Sie Tabellen für Kombinationen aus Dimensionen und Messwerten erstellen, sollten Sie gängige Nutzungsmuster und Feldauswahlmuster ermitteln, 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 (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 sein, die von für die Abfrage verwendet wird. Sie können viele potenzielle Nutzeranfragen in einer einzigen aggregierten Tabelle berücksichtigen und trotzdem erhebliche Leistungssteigerungen erzielen.

Im Beispiel der Identifizierung von Feldern, die häufig in Abfragen verwendet werden, gibt es zwei sehr häufig ausgewählte Dimensionen (flights.depart_week und flights.carrier) sowie zwei Messwerte (flights.count und flights.cancelled_count). Daher ist es logisch, eine aggregierte Tabelle zu erstellen, in der alle vier Felder verwendet werden. Außerdem führt das Erstellen einer einzelnen aggregierten Tabelle für flights_by_week_and_carrier zu einer häufigeren Nutzung zusammengefasster Tabellen als zwei verschiedene aggregierte 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 der allgemeinen Felder 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 anekdotische Nachweise 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 der Flüge“, „Fluggesellschaften für Flüge“, „Anzahl der Flüge“ und „Anzahl der stornierten Flüge“ aus der zusammengefassten Tabelle flights_by_week_and_carrier:

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

Nach der Implementierung der aggregierten 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 %. Die Neuausrichtung der Abfrage dauerte 9,8 Sekunden.

Im Explore zur Nutzung des Systemaktivitätsfelds können wir sehen, wie oft unsere Benutzer diese Felder in Abfragen verwenden. In diesem Beispiel wurde flights.count 47.848, flights.depart_week 18.169, flights.cancelled_count 16.570 und flights.carrier 13.517 Mal verwendet.

Selbst wenn wir sehr mäßig schätzen, dass bei 25% dieser Suchanfragen alle 4 Felder auf die einfachste Weise verwendet wurden (einfache Auswahl, kein Pivoting), gilt: 3.379 x 8,6 Sekunden = 8 Stunden, 4 Minuten Gesamtwartezeit für Nutzer.

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

Nachdem wir denselben Ablauf auf unser E-Commerce-Modell order_items angewendet haben – das am häufigsten verwendete Explore für die Instanz –, sehen die Ergebnisse so aus:

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 zusammengefassten 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. Bei einer Schätzung der gleichen kombinierten Nutzung von ca. 25 % ergeben sich für die Nutzer zusammengefasste Einsparungen von 6 Stunden, 6 Minuten (8 Sek. × 2.750 = 22.000 Sek.). Die Erstellung der aggregierten Tabelle dauerte 17,9 Sekunden.

Nehmen Sie sich einen Moment Zeit, um sich diese Ergebnisse anzusehen, und bewerten Sie die möglichen Erträge aus folgenden Quellen:

• Größere, komplexere Modelle/Explores mit „akzeptabler“ Leistung optimieren und Leistungsverbesserungen durch bessere Modellierungspraktiken erzielen

im Vergleich zu

• Mit Aggregate Awareness einfachere Modelle optimieren, die häufiger verwendet werden und schlecht abschneiden

Sie werden rückläufige Erträge aus Ihren Bemühungen feststellen, wenn Sie versuchen, das letzte Stück an Leistung von Looker und Ihrer Datenbank zu erhalten. Sie sollten sich immer über die grundlegenden Leistungserwartungen, insbesondere von Geschäftsnutzern, und die Einschränkungen Ihrer Datenbank (z. B. Nebenläufigkeit, Abfragegrenzwerte, Kosten usw.) im Klaren sein. Sie sollten nicht davon ausgehen, dass diese Einschränkungen durch die aggregierte Wahrnehmung überwunden werden.

Denken Sie beim Entwerfen einer aggregierten Tabelle außerdem daran, 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;;
      }
    }
  }

Das führt dazu, dass die zusammengefasste Tabelle für jede Kombination der angezeigten Dimensionen und für alle enthaltenen Messwerte verwendet wird, sodass diese Tabelle verwendet werden kann, um viele verschiedene Nutzeranfragen zu beantworten. Um diese Tabelle jedoch für eine einfache SELECT-Anweisung von carrier und count zu verwenden,wäre ein Scan einer Tabelle mit 885.000 Zeilen erforderlich. Im Gegensatz dazu erfordert dieselbe Abfrage nur einen Scan von 4.592 Zeilen, wenn die Tabelle auf zwei Dimensionen basiert. Die Tabellengröße mit 885.000 Zeilen ist im Vergleich zu den vorherigen 38 Millionen Zeilen immer noch um 97% reduziert. Wenn Sie jedoch eine weitere Dimension hinzufügen, erhöht sich die Tabellengröße auf 20 Millionen Zeilen. Daher gibt es rückläufige 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 für den Flights-Explore, das wir als Optimierungsmöglichkeit identifiziert haben, empfiehlt es sich, drei verschiedene aggregierte Tabellen dafür zu erstellen:

• flights_by_week_and_carrier
• flights_by_month_and_distance
• flights_by_year

Am einfachsten lassen sich diese aggregierten Tabellen erstellen, indem Sie die LookML der aggregierten Tabelle aus einer Explore-Abfrage oder aus einem Dashboard abrufen und den Looker-Projektdateien den LookML-Code hinzufügen.

Sobald Sie die aggregierten Tabellen zu Ihrem LookML-Projekt hinzugefügt und die Updates für die Produktion bereitgestellt haben, werden die aggregierten Tabellen für die Abfragen Ihrer Nutzer von den Explores genutzt.

Persistenz

Damit die Aggregatfunktion für die Aggregatfunktion zugänglich ist, müssen zusammengefasste Tabellen in Ihrer Datenbank dauerhaft gespeichert werden. Es empfiehlt sich, die automatische Neugenerierung dieser aggregierten Tabellen an Ihre Caching-Richtlinie anzupassen, indem Sie Datengruppen nutzen. Für eine aggregierte Tabelle sollten Sie dieselbe Datengruppe verwenden, die auch für das zugehörige Explore verwendet wird. 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 zusammengefassten Tabellen täglich um Mitternacht automatisch erstellt.

Zeitrahmenlogik

Wenn Looker eine aggregierte Tabelle erstellt, enthält sie Daten bis zu dem Zeitpunkt, zu dem die aggregierte Tabelle erstellt wurde. Alle Daten, die anschließend an die Basistabelle in der Datenbank angehängt werden, würden normalerweise aus den Ergebnissen einer Abfrage mit dieser aggregierten Tabelle ausgeschlossen.

Dieses Diagramm zeigt die Zeitleiste, auf der Bestellungen eingegangen sind und in der Datenbank protokolliert wurden, verglichen mit dem Zeitpunkt, an dem die aggregierte Tabelle Orders erstellt wurde. Wir sind heute zwei Bestellungen eingegangen, die in der zusammengefassten Tabelle Orders nicht enthalten sind, da die Bestellungen eingegangen sind, nachdem die aggregierte Tabelle erstellt wurde:

Looker kann jedoch neue Daten mit der aggregierten Tabelle verknüpfen, wenn ein Nutzer nach einem Zeitraum fragt, der sich mit der aggregierten Tabelle überschneidet, wie im selben Zeitachsendiagramm dargestellt:

Da Looker neue Daten mit einer aggregierten Tabelle verknüpfen kann, werden die nach dem Erstellen der aggregierten Tabelle erhaltenen Aufträge in die Ergebnisse des Benutzers aufgenommen, wenn ein Benutzer nach einem Zeitrahmen filtert, der sich mit dem Ende der aggregierten und der Basistabelle überschneidet. Auf der Dokumentationsseite Aggregate Awareness finden Sie weitere Informationen und die Bedingungen, die erfüllt sein müssen, um neue Daten für das Aggregieren von Tabellenabfragen zusammenzuführen.

Zusammenfassung

Um es noch einmal zusammenzufassen:

1. Identifizieren Sie Möglichkeiten, bei denen eine Optimierung mithilfe aggregierter Tabellen angemessen und wirkungsvoll ist.
2. Erstellen Sie aggregierte Tabellen, die häufige Nutzeranfragen am meisten abdecken und gleichzeitig klein genug sind, um die Größe dieser Abfragen ausreichend zu reduzieren.
3. Erstellen Sie die aggregierten Tabellen im Looker-Modell und koppeln Sie die Persistenz der Tabelle mit der Persistenz des Explore-Cache.