Diese Best Practices spiegeln die Empfehlungen eines interdisziplinären Teams erfahrener Looker wider. Diese Erkenntnisse basieren auf jahrelanger Erfahrung in der Zusammenarbeit mit Looker-Kunden – von der Implementierung bis hin zum langfristigen Erfolg. Die Best Practices sind so konzipiert, dass sie für die meisten Nutzer und Situationen funktionieren. Bei der Implementierung sollten Sie jedoch nach bestem Wissen und Gewissen vorgehen.
Abfrageleistung optimieren
Mit den folgenden Tipps für das Frontend und das Backend können Sie dafür sorgen, dass Abfragen optimal für Ihre Datenbank erstellt und ausgeführt werden:
-
Erstellen Sie Explores nach Möglichkeit mit
many_to_one
-Joins. Die beste Abfrageleistung wird in der Regel durch das Zusammenführen von Datenansichten von der untersten bis zur höchsten Detailebene (many_to_one
) erzielt. -
Maximieren Sie den Cache, um ihn nach Möglichkeit mit Ihren ETL-Richtlinien zu synchronisieren und den Traffic bei Datenbankabfragen zu reduzieren. Standardmäßig speichert Looker Abfragen eine Stunde lang im Cache. Sie können die Caching-Richtlinie steuern und die Aktualisierung von Looker-Daten mit Ihrem ETL-Prozess synchronisieren, indem Sie Datengruppen in Explores mit dem Parameter
persist_with
anwenden. So kann Looker noch stärker in die Backend-Datenpipeline eingebunden werden, sodass die Cachenutzung maximiert werden kann, ohne dass das Risiko besteht, veraltete Daten zu analysieren. Namensbasierte Caching-Richtlinien können auf ein gesamtes Modell und/oder auf einzelne Explores und persistente abgeleitete Tabellen (PDTs) angewendet werden. - Mit der Funktion „Aggregat-Awareness“ von Looker können Sie Zusammenfassungen oder Übersichtstabellen erstellen, die Looker nach Möglichkeit für Abfragen verwenden kann, insbesondere für häufige Abfragen großer Datenbanken. Mit der zusammengefassten Markenbekanntheit lässt sich auch die Leistung ganzer Dashboards drastisch verbessern. Weitere Informationen finden Sie in der Anleitung zum Aggregieren von Bekanntheit.
- Verwenden Sie PDTs für schnellere Abfragen. Wandeln Sie Explores mit vielen komplexen oder ineffizienten Joins oder Dimensionen mit Unterabfragen oder Unterauswahlen in PDTs um, damit die Datenansichten vor der Laufzeit zusammengeführt und bereit sind.
- Wenn Ihr Datenbankdialekt inkrementelle PDTs unterstützt, konfigurieren Sie inkrementelle PDTs, um die Zeit zu verkürzen, die Looker für das Erstellen neuer PDT-Tabellen benötigt.
- Vermeiden Sie es, Ansichten in Explores über zusammengesetzte Primärschlüssel zu verbinden, die in Looker definiert sind. Führen Sie stattdessen einen Join mit den Basisfeldern aus, die den zusammengesetzten Primärschlüssel aus der Ansicht bilden. Alternativ können Sie die Ansicht als PDT mit dem zusammengesetzten Primärschlüssel neu erstellen, der in der SQL-Definition der Tabelle und nicht in der LookML der Ansicht vordefiniert ist.
- Verwenden Sie das Tool „In SQL Runner erklären“ für das Benchmarking.
EXPLAIN
erstellt eine Übersicht über den Abfrageausführungsplan Ihrer Datenbank für eine bestimmte SQL-Abfrage, mit der Sie Abfragekomponenten erkennen können, die optimiert werden können. Weitere Informationen finden Sie im Communitybeitrag SQL mitEXPLAIN
optimieren. -
Indexe deklarieren. Sie können sich die Indexe der einzelnen Tabellen direkt in Looker im SQL Runner ansehen. Klicken Sie dazu in einer Tabelle auf das Zahnradsymbol und wählen Sie Indexe anzeigen aus.
Die häufigsten Spalten, die von Indexen profitieren können, sind wichtige Datumsangaben und Fremdschlüssel. Wenn Sie diesen Spalten Indexe hinzufügen, wird die Leistung bei fast allen Abfragen gesteigert. Dies gilt auch für PDTs. LookML-Parameter wie
indexes
,sort keys
unddistribution
können entsprechend angewendet werden. - Erhöhen Sie den Arbeitsspeicher, die Kerne und die E/A-Leistung (Eingabe/Ausgabe) von Datenbanken mit unzureichender Hardware oder nicht ausreichend bereitgestellten Ressourcen (z. B. AWS) für die Verarbeitung großer Datensätze, um die Abfrageleistung zu verbessern.
Leistung des Looker-Servers optimieren
Sie können auch Maßnahmen ergreifen, um die Leistung des Looker-Servers und der Looker-Anwendung zu optimieren:
- Begrenzen Sie die Anzahl der Elemente in einem einzelnen Dashboard. Es gibt keine genaue Regel für die Definition der Anzahl, da das Design jedes Elements aufgrund verschiedener Faktoren den Arbeitsspeicherverbrauch beeinflusst. Dashboards mit 25 oder mehr Kacheln sind jedoch in Bezug auf die Leistung in der Regel problematisch.
- Verwenden Sie die Funktion Dashboard automatisch aktualisieren strategisch. Wenn für ein Dashboard die automatische Aktualisierung verwendet wird, darf diese nicht schneller erfolgen als die ETL-Prozesse, die im Hintergrund ausgeführt werden.
- Verwenden Sie Pivot-Tabellen strategisch und vermeiden Sie eine übermäßige Verwendung in Dashboard-Kacheln und Looks. Abfragen mit pivotierten Dimensionen verbrauchen mehr Arbeitsspeicher. Je mehr Dimensionen gepivotet werden, desto mehr Arbeitsspeicher wird beim Laden von Inhalten (Explores, Looks oder Dashboards) verbraucht.
- Verwenden Sie Funktionen wie zusammengeführte Ergebnisse, benutzerdefinierte Felder und Tabellenkalkulationen sparsam. Diese Funktionen sollen als Proof of Concept dienen, um Ihr Modell zu entwerfen. Es empfiehlt sich, häufig verwendete Berechnungen und Funktionen in LookML zu hartcodieren. Dadurch wird SQL generiert, das in Ihrer Datenbank verarbeitet wird. Zu viele Berechnungen können um den Java-Speicher der Looker-Instanz konkurrieren, was zu einer langsameren Reaktion der Looker-Instanz führt.
-
Begrenzen Sie die Anzahl der Ansichten in einem Modell, wenn eine große Anzahl von Ansichtsdateien vorhanden ist. Wenn Sie alle Datenansichten in einem einzigen Modell einbeziehen, kann die Leistung beeinträchtigt werden. Wenn ein Projekt eine große Anzahl von Ansichten enthält, sollten Sie in jedem Modell nur die erforderlichen Ansichtsdateien einschließen. Verwenden Sie strategische Benennungskonventionen für Dateinamen von Ansichten, um Gruppen von Ansichten in einem Modell einfach einbinden zu können. Ein Beispiel finden Sie in der Parameterdokumentation für
includes
. -
Vermeiden Sie, in Dashboard-Kacheln und Looks standardmäßig eine große Anzahl von Datenpunkten zurückzugeben. Abfragen, die Tausende von Datenpunkten zurückgeben, verbrauchen mehr Arbeitsspeicher. Begrenzen Sie die Daten nach Möglichkeit, indem Sie
Filter auf der Frontendebene auf Dashboards, Looks und Explores anwenden und auf LookML-Ebene die Parameter
required filters
,conditionally_filter
undsql_always_where
verwenden. - Verwenden Sie die Option Alle Ergebnisse sparsam, da einige Abfragen sehr groß sein können und den Looker-Server bei der Verarbeitung überlasten.
Weitere Informationen zur Ermittlung der Ursache von Leistungsproblemen finden Sie auf der Seite Best Practices für die Leistungsübersicht.