Looker-Leistung optimieren

Diese Best Practices enthalten Empfehlungen, die von einem bereichsübergreifenden Team erfahrener Looker-Nutzer zusammengestellt wurden. Sie basieren auf jahrelanger Erfahrung in der Zusammenarbeit mit Looker-Kunden von der Implementierung bis zum langfristigen Erfolg. Die Best Practices sind so formuliert, dass sie für die meisten Nutzer und Situationen geeignet sind. Sie sollten jedoch Ihr bestes Urteilsvermögen bei der Implementierung einsetzen.

Abfrageleistung optimieren

Mit den folgenden Tipps für das Frontend und Backend können Sie dafür sorgen, dass Abfragen optimal für Ihre Datenbank erstellt und ausgeführt werden:

  • Erstellen Sie nach Möglichkeit Explores 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 anwenden. Verwenden Sie dazu den persist_with Parameter. 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 (PDTs) angewendet werden.
  • Verwenden Sie die Funktion „Aggregate Awareness“ von Looker, um Roll-ups oder Zusammenfassungstabellen zu erstellen, die Looker nach Möglichkeit für Abfragen verwenden kann. Das ist besonders bei häufigen Abfragen großer Datenbanken hilfreich. Sie können die Funktion auch nutzen, um die Leistung ganzer Dashboards erheblich zu verbessern. Weitere Informationen finden Sie in der Anleitung zu Aggregate Awareness.
  • Verwenden Sie PDTs für schnellere Abfragen. Wandeln Sie Explores mit vielen komplexen oder leistungsschwachen Joins oder Dimensionen mit Unterabfragen oder Unterauswahlen in PDTs um, 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. Führen Sie stattdessen Joins für die Basisfelder aus, 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 in der LookML einer Ansicht vordefiniert ist.
  • Verwenden Sie das Tool „In SQL-Runner erklären“ für Benchmarking. EXPLAIN gibt eine Übersicht über den Abfrageausführungsplan Ihrer Datenbank für eine bestimmte SQL-Abfrage. So können Sie Abfragekomponenten erkennen, die optimiert werden können. Weitere Informationen finden Sie im Community-Beitrag How to optimize SQL with EXPLAIN.
  • Deklarieren Sie Indexe. Sie können die Indexe jeder Tabelle direkt in Looker über den SQL-Runner aufrufen. 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 für fast alle Abfragen verbessert. Das gilt auch für PDTs. LookML-Parameter wie indexes, sort keys und distribution können entsprechend angewendet werden.
  • Erhöhen Sie den Arbeitsspeicher, die 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 Datensätze, um die Abfrageleistung zu verbessern.

Looker-Serverleistung optimieren

Sie können auch Maßnahmen ergreifen, um sicherzustellen, dass der Looker-Server und die Looker-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 Arbeitsspeicherverbrauch anhand einer Vielzahl von Faktoren beeinflusst. Dashboards mit 25 oder mehr Kacheln sind jedoch in der Regel problematisch in Bezug auf die Leistung.
  • Verwenden Sie die automatische Aktualisierung von Dashboards strategisch. Wenn ein Dashboard automatisch aktualisiert wird, sollte die Aktualisierung nicht schneller erfolgen als die ETL-Prozesse, die im Hintergrund ausgeführt werden.
  • Verwenden Sie Pivottabellen strategisch und vermeiden Sie eine übermäßige Verwendung in Dashboard-Kacheln und Looks. Abfragen mit Pivot-Dimensionen verbrauchen mehr Arbeitsspeicher. Je mehr Dimensionen pivotisiert werden, desto mehr Arbeitsspeicher wird beim Laden von Inhalten (einem Explore, einem Look oder einem Dashboard) verbraucht.
  • Verwenden Sie Funktionen wie benutzerdefinierte Felder und Tabellenkalkulationen sparsam. Diese Funktionen sind als Proof of Concept gedacht, um Sie bei der Gestaltung Ihres Modells zu unterstützen. Es empfiehlt sich, alle häufig verwendeten Berechnungen und Funktionen in LookML fest zu codieren. Dadurch wird SQL generiert, das in Ihrer Datenbank verarbeitet wird. Übermäßige Berechnungen können um den Java-Arbeitsspeicher in der Looker-Instanz konkurrieren, was dazu führt, dass die Looker-Instanz langsamer reagiert.
  • Verwenden Sie für Abfragen mit zusammengeführten Ergebnissen nach Möglichkeit Abfragen zur Zusammenführung in der Datenbank. Abfragen zur Zusammenführung 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 in einem Projekt viele Ansichten vorhanden sind, sollten Sie in jedes Modell nur die Ansichtsdateien einbeziehen, die benötigt werden. Verwenden Sie strategische Namenskonventionen für Ansichtsdateinamen, um Gruppen von Ansichten in ein Modell einzubeziehen. Ein Beispiel finden Sie in der includes Parameterdokumentation.
  • 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, verbrauchen mehr Arbeitsspeicher. Achten Sie darauf, dass die Daten nach Möglichkeit begrenzt 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.
  • Verwenden Sie die Option Alle Ergebnisse beim Herunterladen oder Bereitstellen von Abfragen nur sparsam, da einige Abfragen sehr groß sein können und den Looker-Server bei der Verarbeitung überlasten können.
  • Machen Sie sich die Auswirkungen der Verbindungsleistung auf die gesamte Looker-Instanz bewusst. Looker verwendet freigegebene Ressourcen, um Abfragen aus allen Datenbankverbindungen zu verarbeiten. Dazu gehören Kubernetes-Pods, Abfragewarteschlangen und Threadpools. Aufgrund dieser freigegebenen Infrastruktur kann eine einzelne langsame oder überlastete Datenbankverbindung die Leistung von Abfragen für alle anderen Verbindungen beeinträchtigen. Wenn Sie eine weitverbreitete Leistungsverschlechterung feststellen, untersuchen Sie den Zustand aller Datenbankverbindungen und nicht nur derjenigen, die direkt mit den langsamen Dashboards oder Explores zusammenhängen.

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