Die Top 10 Best Practices zur Performance-Optimierung von AI/BI-Dashboards (Teil 1)

Performanceprobleme bei Dashboards haben selten eine einzige Ursache. Sie sind in der Regel die kombinierte Wirkung von Dashboard-Design, Warehouse-Parallelität und -Caching und dem Datenlayout in Ihrem Lakehouse. Wenn Sie nur eine Ebene optimieren – SQL, die Dimensionierung der Rechenleistung oder das Tabellenlayout – werden Sie oft nur Teilerfolge erzielen, aber das Dashboard kann sich bei realer Nutzung immer noch langsam oder unvorhersehbar anfühlen.

In diesem Beitrag verfolgen wir einen ganzheitlichen Ansatz für die Performance von Databricks AI/BI. Wir verfolgen eine Dashboard-Interaktion durchgängig: vom Browser und der AI/BI-Orchestrierungsebene über die Databricks SQL Admission und das Caching-Verhalten bis hin zum Dateiscan und Data Skipping im Lakehouse. Dabei beleuchten wir die Muster, die am häufigsten zu Latenzspitzen, Queuing und Kosten bei Scale führen – insbesondere, wenn viele Benutzer gleichzeitig mit denselben Dashboards interagieren.

Die Anatomie eines AI/BI-Dashboard-Refresh

Um die Performance zu optimieren, müssen Sie zuerst verstehen, welchen Weg ein einzelner Klick durch den Stack nimmt. Wenn ein Benutzer ein Dashboard öffnet oder einen Filter ändert, wird eine Kettenreaktion über mehrere Schichten hinweg ausgelöst. Wenn eine Schicht falsch konfiguriert ist, spürt der Benutzer die Verzögerung.

• Der Browser (clientseitig): Dies ist die erste Verteidigungslinie. Bei Datasets mit weniger als 100.000 Zeilen und unter 100 MB fungiert der Browser als lokale Engine, die Feldfilter und diagrammübergreifende Interaktionen sofort im Arbeitsspeicher verarbeitet. Wenn Ihre Daten diesen Schwellenwert überschreiten, muss jede Interaktion an das Warehouse zurückgesendet werden.
• Das Dashboard-Design (Der Orchestrator): Der KI/BI-Dienst bestimmt, welche Abfragen ausgeführt werden müssen. Ein "Single-Page"-Design sendet die Abfrage jedes Widgets gleichzeitig, was zu einem massiven Gleichzeitigkeits-Spike führt. Ein "mehrseitiges" Design fordert nur Daten für den sichtbaren Tab an und gestaltet so effektiv die Nachfrage nach Ihrem compute.
• Databricks SQL (Die Engine): Ihr SQL-Warehouse (idealerweise Serverless) empfängt den Burst. Es überprüft den Cache – der mehrere Ebenen hat –, um zu sehen, ob die Arbeit bereits erledigt wurde. Wenn nicht, lässt das Intelligent Workload Management (IWM) die Query zu und skaliert Cluster in Sekundenschnelle automatisch, um die Last ohne Warteschlangen zu bewältigen.
• Das Lakehouse (Der Speicher): Schließlich greift die Engine auf die Daten zu. Es scannt Delta-Dateien im Cloud-Objektspeicher. Hier bestimmen Liquid Clustering und Datentypen die I/O-Effizienz. Das Ziel ist es, so viele Daten wie möglich zu überspringen, indem Statistiken und Metadaten auf Dateiebene verwendet werden, um den Ergebnissatz in der Kette zurückzugeben.

Durch die Optimierung jedes dieser vier Berührungspunkte entfernen Sie sich von der Brute-Force-compute und hin zu einer optimierten Architektur, die mit Ihren Benutzern skaliert.

Voraussetzung – Verständnis Ihrer Daten und Ihres Dashboards

Bevor Sie mit der Optimierung beginnen, müssen Sie zunächst das Optimierungsziel definieren. Die Performance von Dashboards ist kein einheitliches Konzept, und Verbesserungen sind nur dann sinnvoll, wenn sie an ein klares Ziel geknüpft sind. Häufige Ziele sind die Verkürzung der Zeit bis zur ersten visuellen Darstellung, die Verbesserung der Interaktionslatenz, die Aufrechterhaltung einer stabilen Performance bei gleichzeitiger Nutzung oder die Senkung der Kosten pro Dashboard-Ansicht.

Sobald das Ziel klar ist, müssen Sie die Parameter verstehen, die es beeinflussen. Dazu gehören die Größe und das Wachstum der Daten, die Anzahl der Benutzer und ihre Zugriffsmuster sowie das Verhalten der Abfragen in der Praxis – wie viele beim Laden der Seite ausgelöst werden, wie viele Daten sie scannen und ob die Ergebnisse wiederverwendet oder ständig neu berechnet werden. Ohne diesen Kontext wird die Optimierung zum Rätselraten und verschiebt oft Kosten oder Latenz von einer Ebene zur anderen.

Eine effektive Dashboard-Optimierung erfolgt daher gezielt: Wählen Sie ein messbares Ziel aus, verstehen Sie die Daten und Nutzungsmuster, die es beeinflussen, und wenden Sie erst dann die folgenden technischen Optimierungen an.

Optimierung Nr. 1: Organisieren Sie das Dashboard in Seiten (Tabs) 

Jede sichtbare Kachel ist ein potenzieller Auslöser: Sie wird beim ersten Laden ausgeführt und kann erneut ausgeführt werden, wenn Filter/Parameter geändert werden, bei einer Aktualisierung und wenn Benutzer zu einer Seite zurücknavigieren. Tabs beschränken diese erneuten Ausführungen auf die aktive Seite, wodurch Bursts und Head-of-Line-Blocking reduziert werden.

AI/BI-Dashboards ermöglichen Ihnen die Erstellung von mehrseitigen Berichten. Gruppieren Sie visuelle Elemente in Seiten, die auf die Benutzerabsicht ausgerichtet sind (Übersicht → Untersuchen → Detaillierte Analyse), sodass nur die aktuelle Seite ausgeführt wird. Dies reduziert das Head-of-Line-Blocking, formt die Parallelität in kleinere Bursts und erhöht die Cache-Trefferquoten für wiederholte deterministische Abfragen.

Empfohlene Seitentypen:

• Übersicht: Schnelle Zähler und Trendlinien für das erste Rendering, halten Sie aufwendige Joins/Windows von der Landing page fern.
• Untersuchen Sie: entitätsfokussierte Exploration (Kunde/Produkt/Region) mit Filtern, die Prädikate in SQL (Parameter) verschieben, wenn Sie eine Reduzierung vor der Aggregation benötigen.
• Deep Dive: aufwendige Aggregationen, die durch geplante Refreshs oder materialisierte/metrische Ansichten unterstützt werden (Sie können ein Dashboard-Dataset in eine materialisierte Ansicht exportieren).

Bevorzugen Sie deterministische Kacheln (vermeiden Sie NOW()), um die Treffer im Ergebnis-Cache zu maximieren, überwachen Sie Peak Queued Queries und erhöhen Sie die Clustergröße oder die maximale Anzahl an Clustern, wenn der Wert dauerhaft > 0 ist. 

Die Drill-Through-Feature in AI/BI-Dashboards ermöglicht die Navigation von übergeordneten Visualisierungen zu Detailseiten, wobei der ausgewählte Kontext übernommen wird. Es ist eine nützliche Strategie, ein seitenbasiertes Design durchzusetzen, indem teure Abfragen aufgeschoben werden, bis die Benutzerabsicht klar ist. Dies verbessert die First-Paint-Performance und reduziert unnötige Gleichzeitigkeitsspitzen.

Hinweis – Warum dies bei jedem Warehouse-Typ hilft: Kleinere, vorhersagbare Bursts sorgen dafür, dass Serverless IWM schnell reagiert und eine Überskalierung vermeidet, und sie verhindern, dass Pro/Classic die Cluster-Slots während des Ladens von Seiten sättigt. 

Weitere Details finden Sie unter: https://www.databricks.com/blog/whats-new-in-aibi-dashboards-fall24 

Optimierung Nr. 2: Optimieren des "First Paint" mit intelligenten Standardeinstellungen

Der erste Eindruck eines Dashboards wird durch seinen First Paintdefiniert – die Zeit, die vom Öffnen des Dashboards bis zum Anzeigen aussagekräftiger Ergebnisse vergeht. Standardfilterwerte spielen hier eine entscheidende Rolle, da sie bestimmen, welche Abfragen sofort beim Laden der Seite ausgeführt werden und wie viele Daten diese Abfragen verarbeiten müssen.

Wenn Filter keine Standardwerte haben, laden AI/BI-Dashboards beim ersten Öffnen oft das gesamte Dataset. Dies maximiert das Scan-Volumen, erhöht den Query-Fan-Out über Kacheln hinweg und verzögert den Moment, in dem Benutzer nützliche Einblicke sehen. Das Ergebnis ist eine langsame, unvorhersehbare erste Erfahrung – besonders schmerzhaft bei hoher Gleichzeitigkeit, wenn viele Benutzer dasselbe Dashboard öffnen.

Intelligente Standardeinstellungen beheben dieses Problem, indem sie die anfängliche Abfrageform einschränken. Häufige Beispiele sind:

• Default von Datumsfiltern auf ein aktuelles Zeitfenster (zum Beispiel die letzten 7 oder 30 Tage).
• Die Vorauswahl einer gängigen Region, Geschäftseinheit oder übergeordneten Entität.
• Die Auswahl eines sinnvollen „Alle“, das dennoch selektiv ist (zum Beispiel das aktuelle Geschäftsjahr anstelle des gesamten Verlaufs).

Technisch gesehen reduzieren Standardfilter die Menge der gescannten Daten, verbessern die Cache-Trefferquoten und ermöglichen die Wiederverwendung von Ergebnissen durch Benutzer, die das Dashboard mit demselben Ausgangszustand öffnen. Dies verbessert direkt die Time-to-First-Visual und sorgt für eine wesentlich konsistentere Performance.

Das zentrale Designprinzip ist einfach: Optimieren Sie für das Landing-Erlebnis. Sorgen Sie dafür, dass der erste Paint schnell und informativ ist, und lassen Sie die Benutzer dann den Umfang während der Erkundung gezielt erweitern. Ein schneller erster Paint schafft Vertrauen, fördert die Akzeptanz und legt die Performance-Baseline für jede folgende Interaktion fest.

Weitere Informationen finden Sie unter: https://docs.databricks.com/aws/en/dashboards/filters#-set-default-filter-values

Optimierung Nr. 3: Verwenden von Parametern zum Aufteilen großer Datensätze

Parameter sind eine der effektivsten Methoden zur Skalierung von AI/BI-Dashboards, da sie die Abfrage formen, bevor sie ausgeführt wird. Indem sie Werte direkt in die SQL-Anweisung einfügen, verschieben sie Prädikate frühzeitig nach unten – sodass Databricks Daten früher bereinigen kann und pro Abfrage weit weniger Arbeit leisten muss (idealerweise wird vor Joins und Aggregationen gefiltert).

Feldfilter verhalten sich anders. Wenn das zugrunde liegende Dataset klein genug ist, um im Browser zwischengespeichert zu werden (≤ 100.000 Zeilen und ≤ 100 MB), können Feldfilter und Cross-Filter-Interaktionen clientseitig ohne einen Warehouse-Roundtrip ausgewertet werden. Sobald Datensätze diesen Schwellenwert überschreiten, werden Feldfilter typischerweise an das Warehouse weitergeleitet, indem die Datensatzabfrage umschlossen wird (oft über eine CTE), was die SQL-Ausführung im Backend auslöst und die Scan-Kosten möglicherweise nicht so effektiv reduziert wie parametrisierte Prädikate, die vor Joins und Aggregation angewendet werden.

Parameter sind besonders effektiv für das Aufteilen nach Datumsbereichen, Regionen, Geschäftsbereichen oder anderen Dimensionen, die das Datenvolumen erheblich reduzieren. Sie machen die Performance auch vorhersehbarer: Jede Kachel führt kostengünstigere Abfragen aus, und Gleichzeitigkeitsspitzen können vom Warehouse leichter absorbiert werden.

Es gibt einen Kompromiss. Da unterschiedliche Parameterwerte unterschiedliche Abfragesignaturen erzeugen, kann die Wiederverwendung des Cache geringer sein, wenn Benutzer ständig eindeutige Werte auswählen. In der Praxis ist dies normalerweise der richtige Kompromiss: Eine kleine, kostengünstige Abfrage ohne Cache-Treffer ist weitaus besser als eine große, teure Abfrage, die auf Caching angewiesen ist. Sie können dies weiter ausgleichen, indem Sie sinnvolle Standardeinstellungen und eine begrenzte Anzahl gängiger Parameterwerte verwenden, sodass beliebte Pfade weiterhin vom Ergebniscache profitieren.

Eine praktische Faustregel lautet: Halten Sie Datensätze klein genug, um in den Browser-Cache zu passen, und verwenden Sie Feldfilter für die Interaktivität (im besten Fall: keine Roundtrips zum Warehouse). Wenn Sie nicht sicher sind, ob das Dataset zuverlässig innerhalb der Grenzen des Browser-Caches bleibt, verwenden Sie Parameter, um das Dataset frühzeitig zu reduzieren– damit das Warehouse im Voraus weniger Daten liest – und wenden Sie dann Filter für eine tiefere Untersuchung an. Dadurch werden „Alles scannen und später filtern“-Dashboards zu selektiven, skalierbaren Abfragen, die auch bei wachsendem Daten- und Benutzeraufkommen schnell bleiben.

Weitere Informationen finden Sie unter:

• https://medium.com/@andrea0pica/databricks-KI-bi-caching-explained-0c4de1aa946b

Optimierung Nr. 4: Verwenden Sie den Browser-Cache

Browser-Caching hilft am meisten, wenn Interaktionen auf Feldfiltern für kleine Datasets basieren. Sobald Parameter SQL ändern – oder Datasets die Browser-Schwelle überschreiten – verlagern sich die Interaktionen zurück zur Warehouse-Ausführung.

Databricks AI/BI-Dashboards können Dataset-Ergebnisse direkt im Browser des Benutzers zwischenspeichern, sodass viele Interaktionen vollständig clientseitig ohne Roundtrips zum SQL warehouse abgewickelt werden können.

Wenn ein Dataset unter ungefähr 100.000 Zeilen liegt, wird der Browser zu einer lokalen Ausführungs-Engine. Cross-Filtering, Sortieren und einfache Aggregationen können sofort im Speicher aufgelöst werden, was zu Interaktionen mit nahezu null Latenz führt und den Druck auf die Backend-Gleichzeitigkeit vollständig eliminiert. Deshalb fühlen sich gut gestaltete Übersichtsseiten oft „sofort“ an, selbst bei starker Nutzung.

Der Browser-Cache wird automatisch verwendet, wenn:

• Das Dataset ist klein genug, um sicher in den Browser geladen zu werden.
• Interaktionen basieren auf Feldfiltern oder diagrammübergreifenden Auswahlen, die clientseitig ausgewertet werden können.
• Keine Parameteränderung erzwingt eine erneute SQL-Ausführung im Warehouse.

Sobald Datasets über diesen Schwellenwert hinauswachsen – oder wenn Parameter das zugrunde liegende SQL ändern – wird die Interaktion zurück an das Warehouse geleitet und das Browser-Caching gilt nicht mehr.

Die wichtigste Erkenntnis für das Design ist die bewusste Dimensionierung von Datasets. Halten Sie Landing-Page- und Übersichts-Datasets kompakt, voraggregiert und auf gängige KPIs ausgerichtet, damit sie sich für das Browser-Caching qualifizieren. Dies sorgt für einen sofortigen „First Paint“, reduziert den Query-Fan-Out und schont die Warehouse-Kapazität für tiefergehende Untersuchungsseiten, bei denen eine Backend-Ausführung unvermeidlich ist.

Weitere Informationen finden Sie unter: https://docs.databricks.com/aws/en/dashboards/caching#dataset-optimizations

Optimierung Nr. 5: Maximieren der Nutzung des Ergebnis-Cache

Die billigste und schnellste Abfrage ist die, die Sie nicht ausführen. 

Das Databricks SQL-Ergebniscaching verwandelt wiederholte Dashboard-Interaktionen in nahezu sofortige Antworten, indem Ergebnisse aus dem Cache bereitgestellt werden, anstatt sie neu zu berechnen.

Wie das Ergebnis-Caching funktioniert (was, wo und wie lange zwischengespeichert wird)

Databricks SQL prüft zwischengespeicherte Ergebnisse, bevor eine Abfrage ausgeführt wird:

• Lokaler Ergebnis-Cache (alle Warehouses): Cache pro Cluster.
   
• Remote-Ergebniscache (Serverless): workspace-weit und bleibt über Warehouse-Neustarts hinweg bestehen.

Beide Caches haben eine TTL von etwa 24 Stunden und werden invalidiert, wenn sich die zugrunde liegenden Tabellen ändern. So bleibt die Aktualität gewahrt, während Sie von der Wiederverwendung profitieren.

Entwerfen Sie Dashboards so, dass Cache-Treffer wahrscheinlich sind

Cache-Treffer sind nicht automatisch – sie sind ein Ergebnis des Designs. Sie ziehen den größten Nutzen, wenn viele Benutzer dem Warehouse dieselbe Frage auf dieselbe Weise stellen.

1) Machen Sie Kacheln deterministisch
Vermeiden Sie nicht-deterministische Funktionen (z. B. NOW() / current_timestamp()), da sie das Ergebnis der Abfrage ändern und eine Wiederverwendung verhindern. Bevorzugen Sie explizite Datums-/Zeitparameter und halten Sie den Abfragetext stabil, damit identische Auswahlen aus dem Cache bedient werden können.

2) Datensätze wiederverwenden und die Abfrage-„Form“ konsistent halten
Cache und Wiederverwendung verbessern sich drastisch, wenn Kacheln dieselbe Datensatzlogik und eine konsistente Prädikat- / GROUP BY-Form haben. Wenn mehrere visuelle Elemente durch dieselbe Backend-Abfrage (oder dasselbe kanonische Dataset) beantwortet werden können, reduzieren Sie die Anzahl der gesendeten Anweisungen und erhöhen die Cache-Trefferquoten.

3) Achten Sie auf Identität und Identitätswechsel
Die Wiederverwendung des Ergebnis-Cache ist am effektivsten, wenn dieselbe Abfrage im selben Zugriffskontext ausgeführt wird. Wenn Ihr Setup einen Identitätswechsel pro Betrachter verwendet, kann dies die Cache-Wiederverwendung verringern, da Ergebnisse nicht immer sicher über Identitäten hinweg geteilt werden können.
Best Practice: Sofern aus Sicherheits- und Governance-Sicht akzeptabel, bevorzugen Sie eine gemeinsame Ausführungsidentität für veröffentlichte Dashboards (z. B. einen Service-Prinzipal / Kontext für gemeinsamen Zugriff), damit wiederholte Aufrufe von der Cache-Wiederverwendung profitieren können. Wenn Sie einen benutzerbasierten Identitätswechsel verwenden müssen, kompensieren Sie dies durch eine maximale Wiederverwendung von Datasets und die Konzentration auf deterministische, parametrisierte gemeinsame Pfade.

Bevorzugen Sie Serverless für wiederholte Interaktionen

Serverless fügt den Remote-Ergebnis-Cache hinzu, der Workspace-weit geteilt wird, Neustarts übersteht und auch von ODBC/JDBC -Clients und der SQL Statement API verwendet wird. Bei Dashboards mit wiederholten Öffnungsvorgängen und gemeinsamen Filterpfaden führt dies oft zum größten „kostenlosen“ Performance-Gewinn.

Caches proaktiv aufwärmen

Fügen Sie für veröffentlichte Dashboards eine Schedule hinzu. Geplante Ausführungen führen die Datensatzlogik vor den Spitzenzeiten aus und füllen die Caches, wodurch der erste Paint verbessert und die Bursts zu Beginn der Stunde geglättet werden.

Überprüfen Sie Treffer (und vermeiden Sie irreführende Benchmarks)

Verwenden:

• Abfrageverlauf: from_result_cache und cache_origin_statement_id
• EXPLAIN EXTENDED, um die Cache-Eignung zu verstehen

Hinweise:

• Der lokale Cache fügt keine Ergebnisse ein, die größer als ca. 500 MiB sind (der Remote-Cache hat keine Größenbeschränkung).
• Der Remote-Cache erfordert Clients mit Cloud Fetch -Unterstützung (ältere Treiber haben diese möglicherweise nicht).

Deaktivieren Sie für das Benchmarking das Caching nur während kontrollierter Tests:
SET use_cached_result = false
… und aktivieren Sie es für die reale Nutzung wieder, damit Dashboards vom Caching in der Produktion profitieren.

Betriebshygiene: Cache-Verschmutzung vermeiden

Mischen Sie keine nicht zusammenhängenden Workloads auf demselben BI-Warehouse. Dedizierte Serverless -BI-Warehouses pro Domäne/Workload helfen dabei, den Remote-Cache mit den wiederholten Abfragen zu füllen, die für diese Dashboards wichtig sind.

Weitere Informationen finden Sie unter: https://www.databricks.com/blog/understanding-caching-databricks-sql-ui-result-and-disk-caches 

Ausblick: Teil 2

Dieser Teil konzentrierte sich darauf, wie Dashboard-Design und Interaktionsmuster die Performance beeinflussen, noch bevor das Warehouse und die Daten überhaupt involviert sind. Durch die Reduzierung des Fan-Outs, die Optimierung des First Paints und die Maximierung der Cache-Wiederverwendung können Sie oft große Gewinne erzielen, ohne die zugrunde liegenden Daten zu ändern. Im zweiten Teil vervollständigen wir das Bild, indem wir tiefer in die Plattform eintauchen: wie man das richtige SQL-Warehouse auswählt und dimensioniert, wie Datenmodellierung und Dateilayout die Scaneffizienz beeinflussen und wie Vorabberechnung, Materialisierung und Datentypen dafür sorgen, dass Dashboards bei zunehmender Nutzung schnell und stabil bleiben.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag