Weitere Informationen finden Sie auf der Dokumentationsseite Aggregate Awareness.
Einleitung
Auf dieser Seite finden Sie eine Anleitung zur Implementierung der zusammengefassten Markenbekanntheit in einem praktischen Szenario. Dazu gehören die Identifizierung von Implementierungschancen, der Wert, den die zusammengefasste Markenbekanntheit bietet, und ein einfacher Workflow zur Implementierung in einem echten Modell. Auf dieser Seite werden nicht alle Funktionen zur Aggregierung von Markenbekanntheit oder Grenzfälle ausführlich erläutert. Es ist auch kein vollständiger Katalog aller Funktionen.
Was ist die kumulierte Bekanntheit?
In Looker führen Sie hauptsächlich Abfragen aus Rohtabellen oder Ansichten in Ihrer Datenbank durch. Manchmal sind dies persistente abgeleitete Looker-Tabellen (PDTs).
Sie werden häufig auf sehr große Datensätze oder Tabellen stoßen, die für eine gute Leistung Aggregationstabellen oder Zusammenfassungen erfordern.
Normalerweise erstellen Sie Aggregationstabellen wie eine orders_daily-Tabelle, die eingeschränkte Dimensionalität enthält. Sie müssen separat behandelt und im Explore separat modelliert werden. Außerdem sind sie im Modell nicht richtig positioniert. Diese Einschränkungen führen zu einer schlechten Nutzererfahrung, wenn der Benutzer zwischen mehreren Explores für dieselben Daten wählen muss.
Dank der neuen Funktion für Aggregationen in Looker können Sie jetzt aggregierte Tabellen mit verschiedenen Detaillierungsgraden, Dimensionen und Aggregationen vorab erstellen und Looker mitteilen, wie sie in vorhandenen Explores verwendet werden sollen. Bei Abfragen werden diese zusammengefassten Tabellen dann von Looker verwendet, wenn dies angebracht ist, ohne dass der Nutzer etwas eingeben muss. Dies reduziert die Abfragegröße, verkürzt die Wartezeiten und verbessert die Nutzererfahrung.
HINWEIS:Die aggregierten Tabellen von Looker sind eine Art persistenter abgeleiteter Tabelle (Persistent Derived Table, PDT). Das bedeutet, dass Aggregationstabellen dieselben Datenbank- und Verbindungsanforderungen wie PDTs haben.Informationen dazu, ob Ihr Datenbankdialekt und Ihre Looker-Verbindung PDTs unterstützen, finden Sie in den Anforderungen 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 wichtiger Vorteile, die sich durch die Kombination von Angeboten zur Bekanntheitssteigerung erzielen lassen, um den Mehrwert Ihres vorhandenen Looker-Modells zu steigern:
- Leistungsverbesserung: Durch die Implementierung der Aggregationsfunktion werden Nutzerabfragen beschleunigt. Looker verwendet eine kleinere Tabelle, wenn sie Daten enthält, die zum Ausführen der Benutzerabfrage erforderlich sind.
- Kosteneinsparungen: Bei bestimmten Dialekten werden die Kosten nach der Größe der Abfrage auf einem Verbrauchsmodell berechnet. Wenn Looker kleinere Tabellen abfragt, sinken die Kosten pro Nutzerabfrage.
- Verbesserte Nutzerfreundlichkeit: Neben einer verbesserten Nutzerfreundlichkeit, die das Abrufen von Antworten beschleunigt, wird durch die Zusammenführung redundantes Erstellen von explorativen Datenanalysen vermieden.
- Reduzierter LookML-Footprint: Wenn Sie vorhandene Liquid-basierte Strategien zur gesamtheitlichen Markenbekanntheit durch eine flexible native Implementierung ersetzen, erhöht sich die Ausfallsicherheit und es kommt zu weniger Fehlern.
- Verwendung vorhandener LookML: Für aggregierte Tabellen wird das Objekt
queryverwendet. Dabei wird vorhandene modellierte Logik wiederverwendet, anstatt die Logik mit explizitem benutzerdefiniertem SQL zu duplizieren.
Einfaches Beispiel
Hier sehen Sie eine sehr einfache Implementierung in einem Looker-Modell, die zeigt, wie einfach die Aggregationserkennung sein kann. 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 die LookML für eine zusammengefasste 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 zusammengefassten Tabelle kann ein Nutzer das flights-Explore abfragen. Looker nutzt dann automatisch die in der LookML definierte zusammengefasste Tabelle, um Abfragen zu beantworten. Der Benutzer muss Looker nicht über Sonderbedingungen informieren: Wenn die Tabelle zu den vom Benutzer ausgewählten Feldern passt, verwendet Looker diese Tabelle.
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. Hier ist ein Beispiel für einen SQL-Tab in Looker für eine Abfrage, in der die Aggregationstabelle 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
Um die Vorteile der zusammengefassten Bekanntheit zu maximieren, sollten Sie ermitteln, wo sie bei der Optimierung eine Rolle spielen oder den Wert der zusammengefassten Bekanntheit steigern 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. Als Verknüpfung können Sie diesen Link zum Explore „Systemaktivitätsverlauf“ in einem Browser öffnen und dann „hostname“ in der URL durch den Namen Ihrer Looker-Instanz ersetzen. Sie sehen eine explorative Datenvisualisierung mit Daten zu den Dashboards Ihrer Instanz, darunter Titel, Verlauf, Anzahl der explorativen Datenanalysen, Cache-/Datenbankverhältnis und Leistung schlechter als Mittelwert:
In diesem Beispiel gibt es eine Reihe von Dashboards mit hoher Auslastung, die eine schlechtere Leistung als der Durchschnitt erzielen, z. B. das Dashboard Beispielvisualisierungen. Im Dashboard Beispielvisualisierungen werden zwei Explores verwendet. Daher ist es sinnvoll, für beide Explores zusammengefasste Tabellen 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. Als Verknüpfung können Sie den Link zum Explore „Systemaktivitätsverlauf“ 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 Explore-Typen in Ihrer 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 einer schlechten 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 Optimierungsmöglichkeiten auf Datenebene erkennen, wenn Sie die Felder kennen, die Nutzer häufig in Abfragen und Filter einbeziehen.
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. Als Verknüpfung können Sie diesen Link zum Explore zur Feldnutzung der Systemaktivität 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 des 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 Summentabellen aufgenommen werden sollen.
Konkrete Daten wie diese sind hilfreich, aber es gibt auch subjektive Elemente, die Ihre Auswahlkriterien beeinflussen. Anhand der vier vorherigen Felder können Sie beispielsweise davon ausgehen, dass sich Nutzer häufig die Anzahl der geplanten Flüge und die Anzahl der annullierten Flüge ansehen und diese Daten sowohl nach Woche als auch nach Fluggesellschaft aufgeschlüsselt haben möchten. Dies ist ein Beispiel für eine klare, logische, reale Kombination aus Feldern und Messwerten.
Fazit
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.
Zusammengefasste Tabellen entwerfen
Nachdem Sie Möglichkeiten für die gesamtheitliche Bekanntheit identifiziert haben, können Sie zusammengefasste Tabellen entwerfen, die diese Möglichkeiten am besten nutzen. 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 die Granularität „Woche“ hat und Sie eine zusammenfassende Tabelle auf Tagesbasis haben, verwendet Looker die aggregierte Tabelle anstelle der Rohdatentabelle auf Zeitstempelebene. Wenn Sie eine zusammengefasste Tabelle auf die Ebenenbrandunddatehochgerollt haben und ein Nutzer nur auf Ebenebrandabfragt, kann diese Tabelle trotzdem von Looker für die zusammengefasste Bekanntheit verwendet werden.
Aggregate Awareness wird für die folgenden Messwerte unterstützt:
- Standardmesswerte: Messwerte vom Typ SUMME, ANZAHL, MITTELWERT, MIN und MAX
- Kompositmesswerte: Messwerte vom Typ ZAHL, STRING, JA/NEIN und DATUM
- Ungefähre unterschiedliche Messwerte : Dialekte, die HyperLogLog-Funktionen verwenden können.
Aggregate Awareness wird für die folgenden Messwerte nicht unterstützt:
- Einzelne Messwerte: Da Einzelheit nur für atomare, nicht aggregierte Daten berechnet werden kann, werden
*_DISTINCT-Messwerte nicht unterstützt, es sei denn, es handelt sich um Näherungswerte, die HyperLogLog verwenden. - Auf Kardinalität basierende Messwerte: Wie bei eindeutigen Messwerten können Mediane und Perzentile nicht vorab zusammengefasst werden und werden nicht unterstützt.
HINWEIS: Wenn Sie eine potenzielle Nutzerabfrage mit Messtypen kennen, die von der zusammengefassten Bekanntheit nicht unterstützt werden, können Sie eine zusammengefasste 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 zusammengefassten 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 nicht genau mit einer Abfrage übereinstimmen, um für die Abfrage verwendet zu werden. 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, werden zwei Dimensionen (flights.depart_week und flights.carrier) sehr häufig ausgewählt sowie zwei Kennzahlen, (flights.count und flights.cancelled_count). Daher wäre es logisch, eine aggregierte Tabelle zu erstellen, die alle vier Felder verwendet. Außerdem wird eine einzelne Summentabelle für flights_by_week_and_carrier häufiger verwendet als zwei verschiedene Summentabellen für flights_by_week- und flights_by_carrier-Tabellen.
Hier ist ein Beispiel für eine aggregierte Tabelle, die wir für Abfragen zu den gemeinsamen 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;;
}
}
}
Die Nutzer Ihres Unternehmens, anekdotische Evidenz 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 es wurden 38 Millionen Zeilen ohne Joins mit Amazon Redshift gescannt. Das Pivotieren der Abfrage, ein normaler Nutzervorgang, 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.
In der explorativen Datenanalyse „Nutzung von Systemaktivitätsfeldern“ sehen wir, wie oft unsere Nutzer diese Felder in Abfragen verwenden. 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 mäßig schätzen, dass bei 25% dieser Anfragen alle 4 Felder auf die einfachste Weise (einfache Auswahl, kein Pivoting) verwendet wurden, 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 wie folgt aus:
| Quelle | Abfragezeitpunkt | Gescannte Zeilen |
|---|---|---|
| Basistisch | 13,1 Sekunden | 285.000 |
| Zusammengefasste Tabelle | 5,1 Sekunden | 138.000 |
| Delta | 8 Sekunden | 147.000 |
Die Felder, die in der Abfrage und der nachfolgenden Aggregierungstabelle verwendet wurden, waren brand, created_date, orders_count und total_revenue. Dabei wurden zwei Joins verwendet. Die Felder wurden insgesamt 11.000 Mal verwendet. Bei einer geschätzten kombinierten Nutzung von etwa 25 % würden Nutzer insgesamt 6 Stunden und 6 Minuten einsparen (8 Sekunden × 2.750 = 22.000 Sekunden). Das Erstellen der zusammengefassten Tabelle hat 17,9 Sekunden gedauert.
Wenn Sie sich diese Ergebnisse ansehen, sollten Sie einen Moment innehalten und die potenziellen Vorteile der folgenden Optionen bewerten:
- Größere, komplexere Modelle/Explores mit einer „akzeptablen“ Leistung optimieren, die durch bessere Modellierungspraktiken möglicherweise verbessert werden können
im Vergleich zu
- Aggregierte Bekanntheit nutzen, um einfachere Modelle zu optimieren, die häufiger verwendet werden und eine schlechte Leistung erzielen
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. Die Gesamtbekanntheit kann diese Einschränkungen nicht überwinden.
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;;
}
}
}Dadurch wird die Gesamtübersichtstabelle für jede Kombination der angezeigten Dimensionen und für alle enthaltenen Messwerte verwendet. So kann diese Tabelle für viele verschiedene Nutzeranfragen verwendet werden. 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. Bei der Tabelle mit 885.000 Zeilen wird die Tabellengröße immer noch um 97% reduziert (im Vergleich zu den vorherigen 38 Millionen Zeilen). Durch das Hinzufügen einer weiteren Dimension wird die Tabellengröße jedoch auf 20 Millionen Zeilen erhöht. 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.
Zusammengefasste 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
Die einfachste Möglichkeit, diese zusammengefassten Tabellen zu erstellen, besteht darin, die LookML für die zusammengefasste Tabelle aus einer Explore-Abfrage oder aus einem Dashboard abzurufen und sie Ihren Looker-Projektdateien hinzuzufügen.
Nachdem Sie die zusammengefassten Tabellen Ihrem LookML-Projekt hinzugefügt und die Updates in der Produktion bereitgestellt haben, werden die zusammengefassten Tabellen in Ihren Explores für die Abfragen der Nutzer verwendet.
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. Sie sollten dieselbe Datengruppe für eine zusammengefasste Tabelle verwenden, die auch für das zugehörige Explore genutzt wird. Wenn Sie keine Datengruppen verwenden können, können Sie stattdessen den Parameter sql_trigger_value verwenden. Hier sehen Sie einen allgemeinen, datumsbasierten Wert für sql_trigger_value:
sql_trigger_value: SELECT CURRENT_DATE() ;;
So werden Ihre zusammengefassten Tabellen jeden Tag 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 der Basistabelle in der Datenbank später angefügt wurden, werden normalerweise aus den Ergebnissen einer Abfrage mit dieser Aggregierungstabelle 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 in Looker neue Daten mit einer Aggregierungstabelle UNIONiert werden können, werden die Bestellungen, die nach dem Erstellen der Aggregierungstabelle eingegangen sind, in die Ergebnisse des Nutzers aufgenommen, wenn er nach einem Zeitraum filtert, der sich mit dem Ende der Aggregierungs- und der Basistabelle überschneidet. Auf der Seite Aggregationsinformationen finden Sie Details und die Bedingungen, die erfüllt sein müssen, damit neue Daten mit Abfragetabellen aggregiert werden können.
Fazit
Zur Erinnerung: Für die Implementierung einer aggregierten Bekanntheit gibt es drei grundlegende Schritte:
- Ermitteln Sie Optimierungsmöglichkeiten, bei denen die Verwendung von Aggregierungstabellen sinnvoll und wirkungsvoll ist.
- 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.
- Erstellen Sie die aggregierten Tabellen im Looker-Modell und koppeln Sie die Persistenz der Tabelle mit der Persistenz des Explore-Cache.