Looker-Leistung optimieren

Diese Best Practices spiegeln Empfehlungen wider, die von einem funktionsübergreifenden Team erfahrener Looker-Nutzer geteilt wurden. Diese Erkenntnisse stammen aus 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 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 (PATs) angewendet werden.
• Mit der Looker-Funktion Aggregate Awareness können Sie Roll-up- oder Zusammenfassungstabellen erstellen, die Looker nach Möglichkeit für Abfragen verwenden kann, insbesondere für gängige Abfragen großer Datenbanken. Sie können die Aggregatfunktion auch nutzen, um die Leistung ganzer Dashboards drastisch zu verbessern. Weitere Informationen finden Sie im Tutorial zu Aggregate Awareness.
• Verwenden Sie PDTs für schnellere Abfragen. Konvertieren Sie Explores mit vielen komplexen oder leistungsschwachen Joins oder Dimensionen mit Unterabfragen oder Unterauswahlen in PDTs, damit die Ansichten vor der Laufzeit vorab verknüpft und bereit sind.
• Wenn Ihr Datenbankdialekt inkrementelle PDTs unterstützt, konfigurieren Sie inkrementelle PDTs, um die Zeit zu verkürzen, die Looker für die Neuerstellung von PDTs benötigt.
• Vermeiden Sie es, Ansichten in Explores über verkettete Primärschlüssel zusammenzuführen, die in Looker definiert sind. Führen Sie stattdessen einen Join für die Basisfelder aus, die den verketteten Primärschlüssel aus der Ansicht 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 im LookML der Ansicht vordefiniert ist.
• Verwenden Sie das Tool In SQL-Runner erklären für Benchmarking. EXPLAIN erstellt eine Übersicht ü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 Community-Beitrag SQL mit EXPLAIN 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 gängigsten Spalten, die von Indexen profitieren können, sind wichtige Datumsangaben und Fremdschlüssel. Wenn Sie diesen Spalten Indexe hinzufügen, wird die Leistung fast aller Abfragen verbessert. 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 Kerne und die E/A (Eingabe/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 aufgrund einer Vielzahl von Faktoren beeinflusst. Dashboards mit 25 oder mehr Kacheln sind jedoch in der Regel problematisch, wenn es um die Leistung geht.
• Verwenden Sie die Funktion Automatische Aktualisierung des Dashboards strategisch. Wenn ein Dashboard automatisch aktualisiert wird, achten Sie darauf, dass es nicht schneller aktualisiert wird als die im Hintergrund ausgeführten ETL-Prozesse.
• Verwenden Sie Pivots strategisch und vermeiden Sie es, Pivots in Dashboard-Tiles und Looks zu oft zu verwenden. Abfragen mit Dimensionen, die als Pivot-Tabellen dargestellt werden, verbrauchen mehr Arbeitsspeicher. Je mehr Dimensionen per Pivot-Tabelle dargestellt 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 beim Entwerfen Ihres Modells zu unterstützen. Es empfiehlt sich, häufig verwendete Berechnungen und Funktionen in LookML fest zu codieren. Dadurch wird SQL generiert, das in Ihrer Datenbank verarbeitet werden kann. Übermäßige Berechnungen können mit dem Java-Arbeitsspeicher auf 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 datenbankinterne Zusammenführungsabfragen. Datenbankinterne Zusammenführungsabfragen werden in Ihrer Datenbank und nicht im Looker-Speicher verarbeitet.
• Begrenzen Sie die Anzahl der Ansichten, die in ein Modell aufgenommen werden, wenn eine große Anzahl von Ansichtsdateien vorhanden ist. Wenn Sie alle Ansichten in ein einziges Modell aufnehmen, kann dies die Leistung beeinträchtigen. Wenn ein Projekt eine große Anzahl von Ansichten enthält, sollten Sie nur die Ansichtsdateien einbeziehen, die im jeweiligen Modell benötigt werden. Verwenden Sie strategische Namenskonventionen für Ansichtsdateinamen, um die Einbeziehung von Gruppen von Ansichten in ein Modell zu ermöglichen. Ein Beispiel finden Sie in der Dokumentation zum Parameter includes.
• Vermeiden Sie es, standardmäßig eine große Anzahl von Datenpunkten in Dashboard-Tiles und Looks zurückzugeben. Abfragen, die Tausende von Datenpunkten zurückgeben, verbrauchen mehr Arbeitsspeicher. Achten Sie darauf, dass Daten nach Möglichkeit eingeschränkt werden. Wenden Sie dazu Frontend- Filter auf Dashboards, Looks und Explores an und verwenden Sie auf LookML-Ebene die Parameter required filters, conditionally_filter und sql_always_where.
• Verwenden Sie die Option Alle Ergebnisse zum Herunterladen oder Bereitstellen von Abfragen nur sparsam, da einige Abfragen sehr groß sein und den Looker-Server bei der Verarbeitung überlasten können.
• Auswirkungen der Verbindungsleistung auf die gesamte Looker-Instanz nachvollziehen. Looker verwendet freigegebene Ressourcen, um Abfragen von allen Datenbankverbindungen zu verarbeiten. Zu diesen Ressourcen gehören Kubernetes-Pods, Abfragewarteschlangen und Threadpools. Aufgrund dieser gemeinsam genutzten Infrastruktur kann eine einzelne langsame oder überlastete Datenbankverbindung die Leistung von Abfragen für alle anderen Verbindungen beeinträchtigen. Wenn Sie eine allgemeine Leistungsverschlechterung feststellen, sollten Sie den Zustand aller Datenbankverbindungen untersuchen, nicht nur derjenigen, die direkt mit den langsamen Dashboards oder Explores zusammenhängen.
• Verteilen Sie geplante Lieferungen und vermeiden Sie die gleichzeitige Ausführung von Jobs. Wenn mehrere Looks oder Dashboards genau zur selben Minute ausgeführt werden sollen (insbesondere zur vollen Stunde), kann die plötzliche Flut gleichzeitiger Abfrageanfragen die Instanzressourcen überlasten, die Warteschlangentiefe erhöhen und die Datenbankverbindungspools erschöpfen. Dieser Nebenläufigkeitsengpass kann dazu führen, dass sowohl geplante Lieferungen als auch interaktive Explore-Abfragen während der Abfrageinitialisierungsphase ins Stocken geraten. Verwenden Sie die folgenden Strategien, um Nebenläufigkeitsengpässe zu vermeiden:
  • Staffeln Sie geplante Jobs in 15- oder 30-Minuten-Intervallen (oder zu anderen Zeiten als zur vollen Stunde, z. B. :15, :30 oder :45), anstatt alle Lieferungen zur vollen Stunde zu planen.
  • Verwenden Sie nach Möglichkeit Datengruppen, um Lieferungen auszulösen, die auf dem Abschluss von ETL-Prozessen und nicht auf zeitbasierten Zeitplänen basieren. So vermeiden Sie unnötige Abfragen von nicht aktualisierten Daten.
  • Führen Sie externe Skripts und automatisierte API-Aufrufe, die Abfragen ausführen oder Lieferungen auslösen, im Batch aus oder drosseln Sie sie.
  • Wenn Ihre Instanz aufgrund einer plötzlichen Häufung von Abfragen nicht mehr reagiert oder Abfragen unendlich lange ausgeführt werden, können Sie laufende Aufgaben löschen, indem Sie die Instanz neu starten (siehe Looker (Google Cloud Core)-Instanz neu starten für Looker (Google Cloud Core)-Instanzen).

Weitere Informationen zum Ermitteln der Ursache von Leistungsproblemen finden Sie auf der Best-Practices-Seite Leistungsübersicht.