Looker-Leistung optimieren

Diese Best Practices basieren auf Empfehlungen eines bereichsübergreifenden Teams erfahrener Looker-Nutzer. Diese Erkenntnisse basieren auf jahrelanger Erfahrung in der Zusammenarbeit mit Looker-Kunden – von der Implementierung bis zum langfristigen Erfolg. Die Best Practices sind für die meisten Nutzer und Situationen geeignet. Sie sollten jedoch bei der Implementierung nach bestem Wissen und Gewissen vorgehen.

Abfrageleistung optimieren

Mit den folgenden Frontend- und Backend-Tipps 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. Wenn Sie Ansichten von der feinsten Detailebene mit höher aggregierten Ebenen zusammenführen (many_to_one), erzielen Sie in der Regel die beste Abfrageleistung.
• Nutzen Sie das Caching umfassend und synchronisieren Sie es nach Möglichkeit mit Ihren ETL-Richtlinien, um den Datenbanktraffic durch Abfragen zu reduzieren. Standardmäßig speichert Looker Abfragen für eine Stunde im Cache. Sie können die Caching-Richtlinie steuern und Looker-Datenaktualisierungen mit Ihrem ETL-Prozess synchronisieren, indem Sie Datengruppen in Explores mit dem Parameter persist_with anwenden. Dadurch kann Looker enger in die Backend-Datenpipeline eingebunden werden. Der Cache wird dann optimal genutzt, ohne das Risiko, dass veraltete Daten analysiert werden. Benannte Caching-Richtlinien können auf ein gesamtes Modell und/oder auf einzelne Explores und persistente abgeleitete Tabellen (Persistent Derived Tables, PDTs) angewendet werden.
• Verwenden Sie die Aggregate Awareness-Funktion von Looker, um Roll-up- oder Zusammenfassungstabellen zu erstellen, die Looker nach Möglichkeit für Abfragen verwenden kann, insbesondere für häufige Abfragen großer Datenbanken. Sie können die Aggregatfunktion auch nutzen, um die Leistung ganzer Dashboards deutlich zu verbessern. Weitere Informationen finden Sie in der Anleitung zu aggregierten Daten.
• Verwenden Sie PDTs, um Abfragen zu beschleunigen. Konvertieren Sie Explores mit vielen komplexen oder leistungsschwachen Joins oder Dimensionen mit Unterabfragen oder Unterauswahlen in PDTs, damit die Ansichten 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 Neuerstellen von PDTs benötigt.
• Vermeiden Sie es, Ansichten in Explores mit verketteten Primärschlüsseln zusammenzuführen, die in Looker definiert sind. Verwenden Sie stattdessen die Basisfelder, aus denen der verkettete Primärschlüssel der Ansicht besteht. Alternativ können Sie die Ansicht als PDT neu erstellen, wobei der verkettete Primärschlüssel in der SQL-Definition der Tabelle und nicht im LookML einer Ansicht vordefiniert ist.
• Verwenden Sie das Tool „In SQL-Runner erklären“ für Benchmarking. EXPLAIN gibt einen Überblick über den Ausführungsplan Ihrer Datenbank für eine bestimmte SQL-Abfrage und ermöglicht es Ihnen, Abfragekomponenten zu erkennen, die optimiert werden können. Weitere Informationen finden Sie im Communitybeitrag zum Optimieren von SQL mit EXPLAIN.
• Indexe deklarieren Sie können sich die Indexe jeder Tabelle direkt in Looker im SQL Runner ansehen. Klicken Sie dazu in einer Tabelle auf das Zahnradsymbol und wählen Sie dann 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 für fast alle Abfragen gesteigert. Dies gilt auch für PDTs. LookML-Parameter wie indexes, sort keys und distribution können entsprechend angewendet werden.
• Erhöhen Sie den Arbeitsspeicher, die Anzahl der Kerne und die E/A-Leistung (Ein-/Ausgabe) von Datenbanken mit unzureichender Hardware oder erforderlichen bereitgestellten Ressourcen (z. B. AWS) für die Verarbeitung großer Datasets, um die Abfrageleistung zu steigern.

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 in einem einzelnen Dashboard. Es gibt keine genaue Regel für die Anzahl, da das Design jedes Elements den Speicherverbrauch auf Grundlage verschiedener Faktoren beeinflusst. Dashboards mit 25 Kacheln oder mehr sind jedoch in der Regel problematisch in Bezug auf die Leistung.
• Nutzen Sie die Funktion Dashboard automatisch aktualisieren strategisch. Wenn ein Dashboard die automatische Aktualisierung verwendet, sollte es nicht schneller aktualisiert werden als die ETL-Prozesse, die im Hintergrund ausgeführt werden.
• Setzen Sie Pivots strategisch ein und vermeiden Sie es, sie in Dashboard-Kacheln und Looks zu häufig zu verwenden. Abfragen mit pivotierten Dimensionen verbrauchen mehr Arbeitsspeicher. Je mehr Dimensionen pivotiert werden, desto mehr Arbeitsspeicher wird beim Laden von Inhalten (einem Explore, einem Look oder einem Dashboard) benötigt.
• Verwenden Sie Funktionen wie benutzerdefinierte Felder und Tabellenkalkulationen nur sparsam. Diese Funktionen sind als Proof of Concept gedacht, um Ihnen bei der Entwicklung Ihres Modells zu helfen. Es empfiehlt sich, alle häufig verwendeten Berechnungen und Funktionen in LookML zu codieren. Dadurch wird SQL generiert, das in Ihrer Datenbank verarbeitet wird. Zu viele Berechnungen können den Java-Arbeitsspeicher der Looker-Instanz beanspruchen und dazu führen, dass die Looker-Instanz langsamer reagiert.
• Verwenden Sie für Abfragen mit zusammengeführten Ergebnissen nach Möglichkeit Abfragen zum Zusammenführen in der Datenbank. Zusammenführungsabfragen in der Datenbank werden in Ihrer Datenbank und nicht im Looker-Arbeitsspeicher verarbeitet.
• Begrenzen Sie die Anzahl der Ansichten in einem Modell, wenn viele Ansichtsdateien vorhanden sind. Wenn Sie alle Ansichten in ein einziges Modell einbeziehen, kann sich die Leistung verlangsamen. Wenn ein Projekt eine große Anzahl von Ansichten enthält, sollten Sie in jedes Modell nur die Ansichtsdateien einbeziehen, die benötigt werden. Verwenden Sie strategische Namenskonventionen für Ansichtsdateinamen, damit Sie Gruppen von Ansichten in ein Modell einbeziehen können. Ein Beispiel finden Sie in der Dokumentation zum Parameter includes.
• Vermeiden Sie es, standardmäßig eine große Anzahl von Datenpunkten in Dashboard-Kacheln und Looks zurückzugeben. Abfragen, die Tausende von Datenpunkten zurückgeben, benötigen mehr Arbeitsspeicher. Sorgen Sie dafür, dass Daten nach Möglichkeit eingeschränkt werden, indem Sie Frontend- Filter auf Dashboards, Looks und Explores anwenden und auf LookML-Ebene die Parameter required filters, conditionally_filter und sql_always_where verwenden.
• Laden Sie Abfragen mit der Option Alle Ergebnisse nur selten herunter oder stellen Sie sie nur selten zu, da einige Abfragen sehr groß sein können und den Looker-Server bei der Verarbeitung überlasten.
• Auswirkungen der Verbindungsleistung auf die gesamte Looker-Instanz nachvollziehen Looker verwendet freigegebene Ressourcen, um Abfragen aus allen Datenbankverbindungen zu verarbeiten. Dazu gehören Kubernetes-Pods, Abfragewarteschlangen und Threadpools. Aufgrund dieser gemeinsam genutzten Infrastruktur kann sich eine einzelne langsame oder überlastete Datenbankverbindung negativ auf die Leistung von Abfragen für alle anderen Verbindungen auswirken. Wenn Sie eine allgemeine Leistungsverschlechterung feststellen, untersuchen Sie den Zustand aller Datenbankverbindungen und nicht nur der Verbindungen, die direkt mit den langsamen Dashboards oder Explores zusammenhängen.

Weitere Informationen zur Ermittlung der Ursache von Leistungsproblemen finden Sie auf der Seite Leistungsübersicht mit Best Practices.