Die 10 besten Vorgehensweisen zur Performance-Optimierung von AI/BI-Dashboards (Teil 2)

Dieser Beitrag ist der zweite Teil einer zweiteiligen Reihe zur Optimierung der Performance von Databricks-AI/BI-Dashboards im großen Scale. 

Im vorherigen Beitrag haben wir uns darauf konzentriert, wie Layout, Filter, Parameter und Caching bestimmen, wie viel Arbeit das System bei jedem Klick leistet. Diese Optimierungen reichen oft aus, damit sich Dashboards schnell anfühlen. 

In diesem Beitrag konzentrieren wir uns auf die Plattformgrundlagen, die auch bei wachsender Nutzung für Schnelligkeit sorgen. Wir befassen uns mit der Auswahl und Dimensionierung von Warehouses, der Datenmodellierung und Schemaauswahl, dem Dateilayout und Clustering sowie der Frage, wann man sich auf die Materialisierung anstelle einer Neuberechnung verlassen sollte, um eine stabile, vorhersagbare Performance zu erzielen.

Optimierung Nr. 6: Wählen Sie die Warehouse-Konfiguration, die zum Design passt. 

Stimmen Sie die Form Ihres Dashboards (Seiten, Abfragemix, Benutzer-Burstiness) auf den Typ und die Größe des DBSQL-Warehouse ab, damit das System die Arbeit schnell und ohne Warteschlangenbildung annehmen kann.

Da sichtbare Widgets gemeinsam übermittelt werden, erzeugen Dashboards naturgemäß kurzlebige Nebenläufigkeitsspitzen. Wenn das Warehouse die Lastspitze nicht abfangen kann, kommt es zu Warteschlangen (Peak Queued Queries > 0) und inkonsistenten Ladezeiten für Kacheln – besonders zu Spitzenzeiten.

Wie die Gleichzeitigkeit von DBSQL-Warehouses funktioniert

• Serverless + IWM: Serverless verwendet Intelligent Workload Management, um Kosten vorherzusagen, Abfragen zuzulassen und zu priorisieren und schnell automatisch zu skalieren. Die typische startup beträgt 2–6 Sekunden, sodass Bursts ohne manuelle Abstimmung latenzarm bleiben.
• Pro/Classic: Die Beschränkung „10 gleichzeitige Abfragen pro Cluster“ wurde behoben, die Autoskalierung fügt Cluster bei Thresholds auf Minutenebene hinzu und der Startup dauert mehrere Minuten. Planen Sie die Kapazität entsprechend der erwarteten Gleichzeitigkeit und vermeiden Sie Lastspitzen beim Laden von Seiten.
• Überwachen und anpassen: Beobachten Sie „Peak Queued Abfragen“ und „Abfrageverlauf“. Wenn die Spitzenwerte dauerhaft über 0 liegen, erhöhen Sie die Clustergröße (insbesondere, wenn „Query Profile“ einen „Spill-to-Disk“ anzeigt) oder erhöhen Sie die maximale Anzahl der clusters. 

Warum Serverless zuerst

• Serverless empfohlen für interaktive BI: schnellster startup, dynamische Gleichzeitigkeit über IWM und effizientere IO.

Praktische Heuristiken zur Dimensionierung

• Starten Sie mit einer größeren Clustergröße und verkleinern Sie diese nach Tests. Überlassen Sie die Verarbeitung von Gleichzeitigkeitsspitzen der serverlosen automatischen Skalierung und erhöhen Sie die maximale Anzahl von Clustern nur bei anhaltenden Warteschlangenspitzen.
• Halten Sie aufwendige ETL- und BI-Prozesse getrennt: Weisen Sie dedizierte Serverless -Warehouses pro Workload/Domäne zu (vermeiden Sie Cache-Pollution und lassen Sie IWM das Workload-Muster lernen).
• Priorisieren Sie kleine, häufige Abfragen: Serverless IWM schützt kurze Interaktionen und skaliert bei gemischten Auslastungen schnell. Entwerfen Sie Seiten so, dass die Übersicht die leichtesten Kacheln zuerst ausführt. 

Weitere Informationen finden Sie unter: https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-behavior 

Optimierung Nr. 7: Anwenden von Best Practices für die Datenmodellierung

Gut konzipierte Datenmodelle sind ein grundlegendes Performance Feature für AI/BI-Dashboards. Das Sternschema bleibt das effektivste und vorhersehbarste Modellierungsmuster für interaktive Analysen, da es direkt damit übereinstimmt, wie BI-Abfragen geschrieben und optimiert werden.

In einem Sternschema enthält eine zentrale Faktentabelle messbare Ereignisse (Vertrieb, Transaktionen, Klicks) und wird mit umgebenden Dimensionstabellen (Datum, Kunde, Produkt, Region) verknüpft. Diese Struktur minimiert die Komplexität von Joins, reduziert die Datenduplizierung und ermöglicht effiziente Aggregationen mit einfachen, stabilen Abfragemustern. Dadurch führen Dashboards weniger Joins aus, scannen weniger Daten und profitieren konsistenter von Caching und Abfrageoptimierung.

Ein kritisches, aber oft übersehenes Detail sind die Datentypen der Join-Schlüssel. Dimensions- und Faktentabellen-Joins sollten integerbasierte Surrogatschlüssel und keine Strings verwenden. Integer-Joins sind deutlich schneller, benötigen weniger Speicher, verbessern die Cache-Effizienz und ermöglichen es Photon, Joins über hochoptimierte vektorisierte Pfade auszuführen. String-basierte Joins erhöhen die CPU-Kosten und können mit wachsender Datenmenge und Gleichzeitigkeit zu einem versteckten Engpass werden.

In Databricks passt dieses Muster natürlich zur Lakehouse-Architektur. Die Gold-Schicht sollte als Fakten und Dimensionen modelliert werden, die als Unity Catalog-Tabellen gespeichert sind und eine verwaltete, wiederverwendbare semantische Grundlage für AI/BI-Dashboards, Metrikansichten und materialisierte Ansichten bieten.

Das Fazit ist einfach: Modellieren Sie, wie BI-Abfragen tatsächlich ausgeführt werden. Ein Sternschema mit Integer-Join-Schlüsseln in der Gold-Schicht liefert einfacheres SQL, schnellere Joins und eine besser vorhersagbare Performance bei der Scale.

Optimierung Nr. 8: Parquet-Optimierungstechniken

Gestalten Sie Ihr Datenlayout so, dass Dashboards pro Abfrage wesentlich weniger Daten lesen, und lassen Sie die Engine dann Parquet -Statistiken und selektive Lesevorgänge nutzen. 

Betrachten Sie das Dateilayout als Performance-Feature

Databricks SQL ist am schnellsten, wenn Folgendes möglich ist:

• Ganze Dateien anhand von Metadaten (Min/Max-Statistiken) bereinigen,
• große, zusammenhängende Chunks effizient lesen,
• und vermeiden Sie das Öffnen von Tausenden von winzigen Dateien.

Die beiden größten Vorteile sind also: Dateien in optimale Größen komprimieren und
Daten clustern, damit Prädikate Dateien eliminieren.

Weitere Details finden Sie hier: https://www.databricks.com/discover/pages/optimize-data-workloads-guide

Ein klassisches Anti-Muster: ein Dashboard-Filter wie WHERE customer_id = ? sieht selektiv aus, aber wenn die Daten nicht geclustert sind, greift die Engine dennoch auf einen großen Teil der Dateien zu, da die übereinstimmenden Zeilen überall verstreut sind.

Technik

• Verwenden Sie Photon, um vom integrierten Predictive IO für Parquet zu profitieren: Photon wendet KI-gestütztes selektives Lesen und paralleles IO an, um nicht übereinstimmende Blöcke zu überspringen und weniger Dateien aufzulisten, und ermöglicht so schnelle selektive Scans ohne manuelle Indizierung.
• Aktivieren Sie Predictive Optimizations für verwaltete Tabellen: Databricks kann die Tabellenwartung basierend auf beobachteten Workload-Mustern automatisch planen und ausführen –OPTIMIZE (Komprimierung, um Dateigrößen optimal zu halten), ANALYZE (aktuelle Statistiken), VACUUM (Bereinigung) und Liquid Clustering (adaptives Layout) – wodurch Sie von der manuellen Feinabstimmung befreit werden und gleichzeitig das Preis-Performance-Verhältnis für Lesevorgänge im großen Scale verbessert wird. In der Praxis hilft dies, die Dateigrößen durch proaktives Komprimieren kleiner Dateien (über OPTIMIZE) optimal zu halten, sodass Parquet-Metadaten (Fußzeilen + Min/Max-Statistiken) für Data Skipping, selektive Scans und BI-Scans/Parallelität wirksam bleiben.
• Lösen Sie bei Bedarf dieselben Betriebe manuell aus: Sie können sie weiterhin selbst ausführen, wenn Sie eine engere Kontrolle oder eine schnellere Time-to-Benefit benötigen (z. B. nach großen Datenerfassungen/Backfills, Schemaänderungen oder vor einer bekannten Berichtsspitze), indem Sie Befehle wie OPTIMIZE und ANALYZE ausführen. Entscheidend ist, bewusst vorzugehen: Stimmen Sie die Wartungsfrequenz darauf ab, wie häufig sich die Tabelle ändert, und stellen Sie sicher, dass die Berechnungskosten durch nachgelagerte Gewinne bei Parallelität, Latenz und Scaneffizienz gerechtfertigt sind.
• Verwenden Sie Liquid Clustering anstelle einer aufwendigen Partitionierung. Liquid clustert Daten inkrementell für Punktsuchen und selektive Scans, und Sie können die Clustering-Spalten jederzeit (sogar solche mit hoher Kardinalität) ohne eine vollständige Neuschreibung ändern. Das Layout passt sich an, wenn sich die Nutzung weiterentwickelt.
• Richten Sie das Layout an den Dashboard-Prädikaten aus. Wählen Sie Liquid-Clustering-Spalten, die gängige Filter-/Group-by-Dimensionen (z. B. Datum, Kunde, Region) widerspiegeln, damit Predictive IO große Bereiche für die Seiten „Untersuchen“ und „Tiefenanalyse“ überspringen kann. 

Ergebnis: Weniger Dateizugriffe, mehr übersprungene Blöcke und eine kürzere Gesamtlaufzeit für die gleichen Erkenntnisse, ohne fehleranfällige Indizes oder manuelle Abstimmung. 

Weitere Informationen finden Sie unter: 

• https://www.databricks.com/blog/faster-lakeview-dashboards-materialized-views
• https://docs.databricks.com/aws/en/compute/photon
• https://docs.databricks.com/aws/en/delta/data-skipping
• https://docs.databricks.com/aws/en/delta/optimize 

Optimierung Nr. 9: Nutzen Sie die Materialisierung von Metrikenansichten

In Optimierung Nr. 7: Best Practices für die Datenmodellierung anwenden haben wir uns auf die Bedeutung des Sternschemas mit klar definierten Fakten, Dimensionen und KPIs konzentriert. Metric Views sind eine direkte Fortsetzung dieser Prinzipien in Databricks AI/BI.

Metrikansichten sind auf BI-Semantik ausgelegt: Sie bestehen aus Kennzahlen und Dimensionen, was sie zu einer natürlichen Abstraktion für die Modellierung von KPIs macht. Sie ermöglichen es Teams, Geschäftsmetriken einmalig zu definieren und dieselben KPIs konsistent über mehrere Dashboards, Agents und andere Client-Tools hinweg wiederzuverwenden. Dies reduziert Redundanzen, verhindert KPI-Drift und sorgt dafür, dass die Analyselogik bei zunehmender Nutzung abgestimmt bleibt.

Mit der Materialisierung für Metrikenansichten berechnet und pflegt Databricks automatisch häufig verwendete Aggregate. Diese Aggregate werden inkrementell aktualisiert, und zur Abfragezeit schreibt der Optimierer Dashboard-Abfragen transparent auf das am besten passende vorausberechnete Ergebnis um. Dadurch scannen Dashboard-Abfragen pro Interaktion weitaus weniger Daten – ohne dass Teams separate Aggregationstabellen oder benutzerdefinierte Pipelines verwalten müssen.

Wenn Metric Views nicht verwendet werden, kann derselbe Ansatz mit Materialized Views angewendet werden. Zum Beispiel kann eine aggregierte Version einer großen Faktentabelle vorberechnet und gespeichert werden, sodass Dashboards einen wesentlich kleineren, optimierten Datensatz abfragen können. Dies verbessert die Performance erheblich, indem die Menge der gescannten Daten reduziert und das wiederholte Neuberechnen aufwendiger Aggregationen für jede Benutzerinteraktion vermieden wird.

Alle diese Techniken optimieren dasselbe: weniger Daten scannen. Durch die einmalige Definition von KPIs und die Vorabberechnung häufig verwendeter Aggregate mit Metric Views oder Materialized Views vermeiden Dashboards die wiederholte Aggregation großer Faktentabellen. Weniger gescannte Bytes führen direkt zu schnelleren Abfragen, einer vorhersagbareren Latenz und einer besseren Performance bei Scale.

Weitere Informationen finden Sie unter: 

• https://docs.databricks.com/aws/en/metric-views/materialization

Optimierung Nr. 10: Datentypen optimieren

Datentypen beeinflussen direkt, wie viele Daten Databricks SQL für jede Dashboard-Abfrage lesen, verschieben und verarbeiten muss. Selbst bei perfektem SQL und Caching erhöhen ineffiziente Datentypen unbemerkt die IO, den Speicherdruck und die CPU-Kosten – was sich in langsameren Kacheln und geringerer Gleichzeitigkeit äußert.

Unter der Haube arbeitet Databricks SQL mit spaltenbasierten Parquet-Dateien. Kleinere, gut gewählte Datentypen bedeuten:

• Weniger aus dem Speicher gescannte Daten (schmalere Spalten),
• Bessere Cache-Dichte (mehr Werte passen in den Arbeitsspeicher und den Ergebnis-Cache),
• Schnellere vektorisierte Ausführung in Photon (SIMD-freundliche Layouts),
• Effektiveres Data Skipping, da die Min/Max-Statistiken genauer sind.

Einige Mechanismen sind am wichtigsten:

• Verwenden Sie wo immer möglich INT/BIGINT anstelle von STRING für Bezeichner. Strings sind aufwendig zu scannen, zu vergleichen und zwischenzuspeichern; numerische Schlüssel sind um Größenordnungen günstiger.
• Bevorzugen Sie DATE oder TIMESTAMP gegenüber zeichenfolgenbasierten Datumsangaben. Native temporale Typen ermöglichen Predicate Pushdown, effiziente Vergleiche und besseres Pruning.
• Verwenden Sie den kleinsten passenden numerischen Typ (INT im Vergleich zu BIGINT, FLOAT im Vergleich zu DOUBLE), um die Spaltenbreite und den Speicherbedarf zu reduzieren.
• Vermeiden Sie die übermäßige Verwendung von DECIMAL mit übermäßiger Genauigkeit in BI-Tabellen, sofern nicht erforderlich. Dezimalzahlen mit hoher Genauigkeit erhöhen die CPU-Kosten bei der Aggregation.
• Halten Sie Schemata sauber und stabil. Implizite Casts (z. B. STRING → INT zur Abfragezeit) deaktivieren Optimierungen und verursachen bei jeder Ausführung unnötigen Compute.

Bei BI-Workloads fallen diese Entscheidungen schnell ins Gewicht: Eine Dashboard-Seite kann Dutzende von Abfragen ausführen, von denen jede Millionen von Zeilen scannt. Schmale, gut typisierte Spalten reduzieren die Scan-Zeit, verbessern die Cache-Trefferquoten und ermöglichen Photon, mit maximaler Effizienz zu arbeiten.

Faustregel: Behandeln Sie das Schemadesign als Performance-Feature. Optimieren Sie Datentypen einmal im Lakehouse, und jedes Dashboard – aktuell und zukünftig – profitiert automatisch.

Fazit

Das Thema, das sich durch alle zehn Best Practices zieht, ist einfach: Zahlen Sie nicht jedes Mal den vollen Preis für eine Dashboard-Interaktion. Sorgen Sie dafür, dass das System pro Ansicht weniger Arbeit leistet (weniger Fan-Out, weniger gescannte Daten), und sorgen Sie dafür, dass die Arbeit, die es leistet, wiederverwendbar ist (gemeinsam genutzte Datasets, deterministische Abfragen, Caches und vorberechnete Aggregate). Wenn diese Teile zusammenpassen, wird die Performance unter Parallelität stabil – und die Kosten werden vorhersagbar.

Konkret sollten Sie in der Lage sein, diese Fragen für Ihre meistgenutzten Dashboards mit „Ja“ zu beantworten:

• Erhalten Nutzer einen schnellen ersten Bildaufbau (schlanke Landing-Ansicht + sinnvolle Standardwerte)?
• Löst eine typische Interaktion eine kleine Anzahl kostengünstiger Abfragen aus (Parameter filtern frühzeitig und nicht erst nach dem Scannen)?
• Werden wiederholte Ansichten zu Cache-Treffern (deterministische Kacheln, Wiederverwendung über Kacheln hinweg, geplantes Aufwärmen)?
• Kann das Warehouse Spitzenlasten ohne Warteschlangen oder Spilling bewältigen (Peak Queued Queries bleibt nahe null, Query Profile führt kein Spilling durch)?
• Ist das Lakehouse für Lesevorgänge optimiert (geeignete Dateigrößen, Liquid Clustering, saubere Datentypen und vorberechnete Hot-Aggregate)?

Wählen Sie ein Dashboard aus, das tatsächlich genutzt wird, führen Sie eine schnelle Baseline-Messung durch (First Paint, Interaktionslatenz, Spitzenwert der Abfragen in der Warteschlange, Spill, Cache-Trefferquote), wenden Sie einige der wirkungsvollsten Änderungen an und messen Sie erneut. Wenn Sie das konsequent tun, wird Ihre AI/BI mit wachsenden Datenmengen und Benutzerzahlen von „manchmal schnell“ zu zuverlässig schnell.

Referenzen und weiterführende Lektüre

• Dimensionierung, Skalierung, Queuing und Monitoring von SQL-Warehouses, Serverless IWM im Vergleich zur automatischen Skalierung von Pro/Classic. https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-behavior
• Warehouses erstellen/konfigurieren, Anleitung für Cluster pro Gleichzeitigkeit.
  https://docs.databricks.com/aws/en/compute/sql-warehouse/create
• Serverless-Vorteile und warum es empfohlen wird.
  https://docs.databricks.com/aws/en/compute/sql-warehouse/
• Warehouse Types und Performance Features (Photon, Predictive IO, IWM, startup 2–6 s für Serverless).
  https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-types
• Ergebnis-Caching (pro Cluster und serverloser Remote-Ergebnis-Cache).
  https://docs.databricks.com/aws/en/lakehouse-architecture/performance-efficiency/best-practices https://learn.microsoft.com/de-de/azure/databricks/sql/user/queries/query-caching
• AI/BI-Dashboards: Seiten/Canvas/Datenmodell und Komponenten.
  https://docs.databricks.com/aws/en/dashboards
• Parameter vs. Feldfilter, abfragebasierte Parameter.
  https://docs.databricks.com/aws/en/dashboards/parameters
• Exportieren Sie ein Dashboard-Dataset in eine materialisierte Ansicht, um hohe Workloads zu beschleunigen.
  https://docs.databricks.com/aws/en/ai-bi/release-notes/2025
• Ausführungen von Dashboard-Abfragen in Audit-logs (prüfen, was unter Last ausgeführt wird).
  https://docs.databricks.com/aws/en/admin/account-settings/audit-logs

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