Diese Best Practices beruhen auf den Empfehlungen eines funktionsübergreifenden Teams erfahrener Lookers. Diese Erkenntnisse stammen aus jahrelanger Erfahrung in der Zusammenarbeit mit Looker-Kunden von der Implementierung bis zum langfristigen Erfolg. Die Methoden sind so geschrieben, dass sie für die meisten Nutzer und Situationen geeignet sind. Bei der Umsetzung sollten Sie jedoch nach eigenem Ermessen vorgehen.
Abfrageleistung optimieren
Mit den folgenden Tipps zum Front-End und Back-End können Sie dafür sorgen, dass Abfragen für Ihre Datenbank optimal erstellt und ausgeführt werden:
-
Erstellen Sie nach Möglichkeit Explores mit
many_to_one
-Joins. Wenn Sie Ansichten von der detailliertesten Ebene mit der höchsten Detailebene (many_to_one
) zusammenführen, erzielen Sie in der Regel die beste Abfrageleistung. -
Maximieren Sie das Caching, um nach Möglichkeit mit Ihren ETL-Richtlinien zu synchronisieren, um den Datenverkehr für Datenbankabfragen zu reduzieren. Standardmäßig speichert Looker Abfragen eine Stunde lang im Cache. Sie können die Caching-Richtlinie steuern und Looker-Datenaktualisierungen mit Ihrem ETL-Prozess synchronisieren. Wenden Sie dazu in Explores mit dem Parameter
persist_with
Datengruppen an. Dadurch kann Looker enger in die Back-End-Datenpipeline integriert werden, sodass die Cache-Nutzung maximiert werden kann, ohne das Risiko der Analyse veralteter Daten zu riskieren. Benannte Caching-Richtlinien können auf ein gesamtes Modell und/oder einzelne Explores und nichtflüchtige abgeleitete Tabellen (PDTs) angewendet werden. - Verwenden Sie die Aggregatfunktion von Looker, um Sammel- oder Zusammenfassungstabellen zu erstellen, die Looker nach Möglichkeit für Abfragen verwenden kann, insbesondere für häufige Abfragen in großen Datenbanken. Sie können auch Aggregate Awareness nutzen, um die Leistung ganzer Dashboards drastisch zu verbessern. Weitere Informationen finden Sie in der Anleitung zur Aggregatfunktion.
- Verwenden Sie PDTs für schnellere Abfragen. Konvertieren Sie Explores mit vielen komplexen oder nicht leistungsfähigen Joins oder Dimensionen mit Unterabfragen oder Unterauswahlen in PDTs, damit die Ansichten vor der Laufzeit verbunden und bereit sind.
- Wenn Ihr Datenbankdialekt inkrementelle PDTs unterstützt, konfigurieren Sie inkrementelle PDTs, um die Zeit zu reduzieren, die Looker für die Neuerstellung von PDT-Tabellen benötigt.
- Vermeiden Sie es, Ansichten über verkettete Primärschlüssel, die in Looker definiert sind, mit Explores zu verbinden. Führen Sie stattdessen die Zusammenführung mit den Basisfeldern durch, die aus der Ansicht den verketteten Primärschlüssel bilden. Alternativ können Sie die Ansicht als PDT mit dem verketteten Primärschlüssel neu erstellen, der in der SQL-Definition der Tabelle und nicht in der LookML einer Ansicht vordefiniert ist.
- Sie können das Explain in SQL Runner-Tool für das Benchmarking verwenden.
EXPLAIN
gibt einen Überblick über den Abfrageausführungsplan Ihrer Datenbank für eine bestimmte SQL-Abfrage, sodass Sie Abfragekomponenten erkennen können, die optimiert werden können. Weitere Informationen finden Sie im Communitybeitrag How to optimize SQL withEXPLAIN
. -
Indexe deklarieren Sie können sich die Indexe der einzelnen Tabellen direkt in Looker aus dem SQL Runner ansehen. Klicken Sie dazu in einer Tabelle auf das Zahnradsymbol und wählen Sie Indexe anzeigen aus.
Die gängigsten Spalten, die von Indexen profitieren können, sind wichtige Datumsangaben und Fremdschlüssel. Durch das Hinzufügen von Indexen zu diesen Spalten wird die Leistung bei fast allen Abfragen erhöht. Dies gilt auch für PATs. LookML-Parameter wie
indexes
,sort keys
unddistribution
können entsprechend angewendet werden. - Erhöhen Sie den Arbeitsspeicher, die Kerne und die E/A (Eingabe/Ausgabe) von Datenbanken mit unzureichender Hardware oder den erforderlichen Ressourcen (z. B. AWS) für die Verarbeitung großer Datasets, um die Abfrageleistung zu erhöhen.
Looker-Serverleistung optimieren
Sie können auch Maßnahmen ergreifen, um sicherzustellen, dass der Looker-Server und die Anwendung optimal funktionieren:
- Begrenzen Sie die Anzahl der Elemente innerhalb eines einzelnen Dashboards. Es gibt keine genaue Regel für die Definition der Zahl, da sich das Design jedes Elements auf der Grundlage einer Vielzahl von Faktoren auf den Speicherverbrauch auswirkt. Dashboards mit 25 oder mehr Kacheln sind jedoch in der Regel problematisch, wenn es um die Leistung geht.
- Nutzen Sie die Funktion zur automatischen Aktualisierung des Dashboards strategisch. Wenn ein Dashboard die automatische Aktualisierung verwendet, stellen Sie sicher, dass es nicht schneller aktualisiert wird als die ETL-Prozesse, die im Hintergrund ausgeführt werden.
- Setzen Sie Pivots strategisch ein und vermeiden Sie die übermäßige Verwendung von Pivots in Dashboard-Tiles und Looks. Abfragen mit als Drehpunkt festgelegten Dimensionen verbrauchen mehr Arbeitsspeicher. Je mehr Dimensionen als Drehpunkt festgelegt sind, desto mehr Arbeitsspeicher wird beim Laden von Inhalten (Explore, Look oder Dashboard) verbraucht.
- Verwenden Sie nur sparsam Funktionen für die Verarbeitung nach der Abfrage wie Ergebnisse zusammenführen, benutzerdefinierte Felder und Tabellenberechnungen. Diese Funktionen dienen als Proof of Concept für die Gestaltung Ihres Modells. Es empfiehlt sich, häufig verwendete Berechnungen und Funktionen in LookML zu hartcodieren, da diese SQL zur Verarbeitung in Ihrer Datenbank generieren. Übermäßige Berechnungen können auf der Looker-Instanz um den Java-Speicher konkurrieren, was dazu führt, dass die Looker-Instanz langsamer reagiert.
-
Begrenzen Sie die Anzahl der in einem Modell enthaltenen Ansichten, wenn eine große Anzahl von Ansichtsdateien vorhanden ist. Wenn alle Aufrufe in einem einzigen Modell enthalten sind, kann dies die Leistung beeinträchtigen. Wenn in einem Projekt eine große Anzahl von Ansichten vorhanden ist, sollten Sie erwägen, nur die Ansichtsdateien einzuschließen, die in jedem Modell erforderlich sind. Ziehen Sie die Verwendung strategischer Namenskonventionen für Ansichtsdateinamen in Betracht, um Ansichtsgruppen einfach in ein Modell einzubinden. Ein Beispiel finden Sie in der Dokumentation zum Parameter
includes
. -
Vermeiden Sie standardmäßig die Rückgabe einer großen Anzahl von Datenpunkten innerhalb von Dashboard-Tiles und Looks. Abfragen, die Tausende von Datenpunkten zurückgeben, verbrauchen mehr Arbeitsspeicher. Sorgen Sie dafür, dass die Daten nach Möglichkeit begrenzt sind, indem Sie
Front-End-Filter auf Dashboards, Looks und Explores und auf LookML-Ebene mit den Parametern
required filters
,conditionally_filter
undsql_always_where
anwenden. - Laden Sie Abfragen sparsam herunter oder übermitteln Sie sie mit der Option Alle Ergebnisse, da einige Abfragen sehr groß sein können und den Looker-Server bei der Verarbeitung überlasten.
Weitere Informationen zum Identifizieren der Ursache von Leistungsproblemen finden Sie auf der Seite Leistungsübersicht mit Best Practices.